Hojo and the case of the deaf Tentec Omni V

Hojo and the case of the deaf Tentec Omni V

A friend from the local ham club handed me his Tentec Omni V.  He hadn't used it in a while, and was preparing to sell it to another ham when he noticed it appeared to be very weak on receive.  He asked me to take a look.

Power supply

Right off the bat, I checked the power supply.  It was reading low.  The trimmer pot was right next to the activity LED, so I couldn't resist dialing it up to a proper voltage.

Initial problems

I powered up the rig and found the LED display blank.  I opened the covers and wiggled a few things directly behind the LED display.  It flashed back on.  The board was not seated very well, apparently.

At the same time, one of two incandescent bulbs behind the S-meter was intermittent.  I snugged up the fixture with a pair of pliers, and the bulb became more reliable.

Having taken care of those little physical problems, I could finally try injecting a signal into the radio.  Sure enough, it was quite hard of hearing.  I needed a signal of about -20 dbm to be discernible.  I confirmed the problem existed across multiple bands.

Diagnostics

I opened up the radio and started tracing the signal.  I injected a tone on 14 Mhz (1) and followed the path.  It got through the antenna selection circuits and initial attenuator just fine.  It reached the front-end mixer board (2), and exited that board mixed to 9 Mhz (3).  I also verified that the signal disappeared when the injected signal was stopped.  So far so good. The signal passed through the 9 MHZ IF board (3)  -> (4) unmolested and was amplified slightly.  From there, it went into the Pass Band Tuning board (4), and finally into the AF/IF board (5).  There's where the trouble began.

I measured a good signal coming into the board (5 above).  It passes through a few amplifier stages first thing.  I checked at the end of that stage and found no signal.  Tracing back, I found the signal disappeared after passing through a J310 Fet.

I next confirmed that there was power on the "+REG" rail.  It was reading 8.78 volts.  Unfortunately, I had no idea what the voltage was supposed to be.  After about 40 minutes of tracing the +REG rail back to a power board, I found a knockoff sentence in the service manual that +REG should be 8.5 volts.  So, it was a touch high, but shouldn't have been a problem for this situation.

Having narrowed it down to this Fet, I checked my parts bin, and voila, I had a few in stock!

The repair

The board had approximately a jillion connectors on it.  I carefully photographed everything before removing it.

Now that I had a better view of the FET in question, I confirmed the model, and that my parts-bin FET matched.

I pulled the FET and replaced it.

    

Testing

After putting things back together, the radio was hearing loud and clear.  My Service Monitor can generate signals as low as -130 DBM.  The signal was clearly discernible all the way down.

Talking with the owner, he was satisfied that the repair was sufficient, so I stopped there, rather than attempting to find alignment instructions.

Success!

Zeta FX-79 Buffalo Build - Port planning, Smartport and RSSI

Zeta FX-79 Buffalo Build - Port planning, Smartport and RSSI

Serial Port Planning

The Omnibus F4 Pro V2 offers 3 UARTs.

• UART1 - Used for SBUS
• UART6 - Available
• UART3 / I2C - Available if I2C is not needed

My Ublox Neo-M8N GPS with Compass module will need UART6 for the GPS, and the I2C pins for the Compass functionality.  Unfortunately, I want to do Smartport as well, but don't have a UART.  So, instead, I'll use softserial for the Smartport connection.

My configuration will be as follows:

• UART1 - Used for SBUS
• UART6 - GPS
• UART3 / I2C - Compass
• Softserial - Smartport

Smartport

The Softserial ports are available on the Omnibus F4 Pro V2 via two pads on the front of the board.  I followed the FrSky SmartPort using SoftwareSerial procedure at the bottom of the Omnibus F4 page.  They call for a 1k ohm resistor between the RX and TX pins.  I had one in 0603 in my parts bin, so I put it between the pads, and then attached a small wire-wrap wire to the RX pin.  It ended up working fine.

I love surface mount soldering!  Here's a 1K 0603 resistor from my parts bin.

There's the resistor, temporarily sitting on top of the processor.  I circled the two pads it's going to be crossing below.

Here's the resistor installed, with a bit of Wire Wrap wire connecting to the RX pin.  

After confirming that all worked well, I went ahead and secured this wire with a dab of glue to the top of the processor chip, for strain relief.

In order to use the Softserial port, it needs to be enabled in the iNav Configurator.

I enabled Softserial, and while I was at it, also enabled telemetry.

After a reboot, I went into the ports page, found the Softserial port, and configured it for Smartport at 57,600 bps, as suggested.

The final step was to go into the CLI and apply two settings:

set smartport_uart_unidir=OFF
set telemetry_inversion=on

Having done that, I was able to go onto my transmitter, do a "discover", and telemetry values populated from the flight controller.

One additional note.  The GPS telemetry does not appear for a "discover" on the radio until you have a GPS lock.  This caused me quite a bit of frustration.  Once the telemetry is discovered, it will be on the list on the radio, thereafter.  You do not have to rediscover it after it is in the list.

RSSI

The Omnibus F4 V2 uses a tiny little pad in the middle of the board to receive RSSI data from the receiver.  Many people are soldering a small wire to the pad, and just hanging it off the Flight Controller, with a bunch of glue and hope holding it in place.  I didn't really like that solution.  Instead, I opted to hijack the RAM pins to make the RSSI externally available.

The RAM pins on the Omnibus F4 pro V2 are wired together, but otherwise isolated, if you do not solder a jumper elsewhere on the board, linking them either to VCC or the 5v rail.  Since I left the jumper undone, the RAM pins are just tied to each other.    Since I'm powering my Camera and VTX via an external wiring harness, the RAM pins are unused.

I soldered a small jumper from the RSSI pad to one of the RAM pins.  I will then solder a heavier gauge wire into the other RAM pin hole, and connect that to the wiring harness going off to the receiver.  This should provide greater strain relieve for the RSSI jumper.  I think this is a much more resilient solution.  Here's the jumper wire going to one of the RAM pins.  This picture does not illustrate the wire harness leading off the board.

One thing to note.  I was concerned that the RSSI pin might have problems.  The MCU on the F4 board is running at 3.3 volts.  The receiver runs at 5 volts.  I was worried that the RSSI pin might be overdriven by the receiver.  I wondered whether a voltage divider would be needed to scale the voltage down.  Fortunately, FrSky had considered this.  The RSSI value is documented to be a PWM value between 0 - 3.3 volts.  So, even though the receiver is running at 5 volts, it is safe to run the wire to the Flight Controller.  So, the result was, I didn't have to do anything special.  I felt better having researched it, however.

Zeta FX-79 Buffalo Build - Wiring plan

Zeta FX-79 Buffalo Build - Wiring plan

The stock configurations for the FX-79 seem to recommend running with 3s lipos, so that's what I'm planning to do.  I'll be using two 5000 mah batteries in parallel.    My Flight Controller is rated up to 5s, as far as I can tell on the forums, so I have the option of upgrading later if I wish.

The Omnibus F4 Pro V2 comes with an onboard 3 amp BEC.  However, as I read the forums, I understand that it can get rather warm.  As a precaution, I'm planning to run very little through the onboard BEC.

Power Plan

• Direct from batteries
• Flight controller - rated to 5s (I think).
• Runcam and VTX (through a filter).  Both are rated up to 6s.
• ESC (via the Flight Controller for current measuring)
• BEC on Flight Controller
• GPS
• Uart inverter
• External BEC
• Servos
• Receiver
• External BEC (auxiliary port)
• Lights or special effects

I roughed out a wire plan on my office whiteboard.

About Club24A

There are known problems with this board with regards to reporting accurate current if VCC is jumpered into the Camera or VTX pins.  It's known as "Club24A" in the forums.  I'm avoiding that problem entirely by not using the onboard jumper to apply power to the RAM pins.  I'm actually hijacking the RAM pins for another purpose (RSSI).  I'm providing the power to the camera and VTX via the wiring harness, apart from the Omnibus board, so I do not expect any of the Club24A issues.

Riser pins

Since I'm providing power to most of the external devices via the external BEC rather than through the FC, it's led to a rather convoluted wiring harness.  While the FC provides 3 pins in most places, for powered servo cables, I'm generally using just the signal wire, and drawing power from my external BEC.  I decided to solder wires directly onto the Flight Controller and terminate with female servo connectors.  This makes the flight controller a bit of a hassle to wire up, but with care, it should be alright. 

I'm planning to use extension cables everywhere, so that the FC can be removed for calibration or reprogramming if necessary.  Also, being the most convoluted part of the build, it should be fairly easy to transplant, if the plane crashes badly enough that I need to replace the foam.

Here's the flight controller wiring, about 3/4 done.  I'll update this picture when it's complete.  Note the heavy cables which lead to the batteries and ESC.  The servo cables patch into other cables to provide power.

Zeta FX-79 Buffalo Build - Preliminaries

Zeta FX-79 Buffalo Build

My wife bought me a Zeta FX-79 Buffalo flying wing for Christmas.  I'll be chronicling the build in this blog post.  My motivation for this plane was to have an FPV platform to use for balloon "Search and Rescue" operations.  I'd like to have an FPV camera, and a higher resolution camera for post-flight analysis.  I'd also like to be able to fly my Kenwood TH-D72A radio as an airborne APRS digipeater platform.  Since my trackers are very low power (10mw or so), the hope is that an airborne digipeater might be helpful in recovery operations.

I purchased the fittings from a variety of sources.  The Bill of Materials follows. 

• Zeta FX-79 Buffalo
• Propdrive V2 3548 900kv Brushless Outrunner
• YEP 60A (2~6S) SBEC Brushless Speed Controller
• UBEC DUO 4A/5~12V & 4A/5V
• GWS Style Slowfly Propeller 12x3.8 Black
• (5) Corona 939MG Metal Gear Servo 2.5kg / 0.14sec / 12.5g
• FrSky X8R - 8/16 Channel Receiver (Antenna Combo)
• Antenna Mount Holder for Frsky X8R
• OMNIBUS F4 Pro (v2) Flight Controller
• Ublox Neo-M8N GPS with Compass
• RunCam Eagle 2 FPV Camera - 4:3
• Lumenier TX5G6R Mini 600mW 5.8GHz FPV Transmitter
• ZIPPY Flightmax 5000mAh 3S1P 20C
• Zeta FX-79 Buffalo Aluminum Motor Mount

I'll be doing the build with the Omnibus F4 Pro V2 flight controller, which includes an OSD and can relay Smartport Telemetry back to my Tanaris Plus transmitter.

In future posts, I'll document the build process and initial flights.

AFSK modulation experiments - success!

AFSK modulation experiments - success!

So, in the previous blog entry, I confirmed that I had come up with some numbers and timer values to make the frequencies I needed.  For posterity, I'll document them here.

DAC configration

I'm running my DAC with 24 data points.  I generated my sinewave table using the script that I blogged previously.  Based on the results from AFSK modulation experiments - part 4, I set the PPM on the Si5351b to 30, and the DAC_PCT to 35 to achieve about 3000hz deviation.  It looks as follows:

#define DAC_PCT 35          // Percentage of DAC output#define SINE_RES        24const uint16_t sinewave[SINE_RES] = {        (0 * DAC_PCT / 100) + 2048, (530 * DAC_PCT / 100) + 2048, (1023 * DAC_PCT / 100) + 2048,        (1448 * DAC_PCT / 100) + 2048, (1773 * DAC_PCT / 100) + 2048, (1978 * DAC_PCT / 100) + 2048,        (2047 * DAC_PCT / 100) + 2048, (1978 * DAC_PCT / 100) + 2048, (1773 * DAC_PCT / 100) + 2048,        (1448 * DAC_PCT / 100) + 2048, (1024 * DAC_PCT / 100) + 2048, (530 * DAC_PCT / 100) + 2048,        (0 * DAC_PCT / 100) + 2048, (-530 * DAC_PCT / 100) + 2048, (-1023 * DAC_PCT / 100) + 2048,        (-1448 * DAC_PCT / 100) + 2048, (-1773 * DAC_PCT / 100) + 2048, (-1978 * DAC_PCT / 100) + 2048,        (-2047 * DAC_PCT / 100) + 2048, (-1978 * DAC_PCT / 100) + 2048, (-1773 * DAC_PCT / 100) + 2048,        (-1448 * DAC_PCT / 100) + 2048, (-1024 * DAC_PCT / 100) + 2048, (-530 * DAC_PCT / 100) + 2048,};

Clock speed

I'm testing on the Nucleo-L152RE, which has a STM32L152RET6 processor.  My flght board uses an STM32L152CB, which is quite similar.  I'm running it at a clock speed of 32 MHZ, and the prescalars set such that the APB1 clock speed is also 32mhz.

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;  RCC_OscInitStruct.HSIState = RCC_HSI_ON;  RCC_OscInitStruct.HSICalibrationValue = 16;  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;  RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL4; // 32mhz  RCC_OscInitStruct.PLL.PLLDIV = RCC_PLL_DIV2;  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

Timer calculations

Based on the 32mhz clock, I calculated timers as follows.  The goal for the DAC timer was to be able to simply toggle the "counter" value back and forth, in order to change the tone between 1200hz and 2200hz.  You can calculate the Clock Ticks yourself by dividing:

Clock_Ticks_Hz = 32000000 / (DAC Datapoints * Prescaler * Counter)

Function	Timer	DAC sinewave data points	Prescaler	Counter	Clock ticks (hz)
Baud Timer 1200hz	TIM2	n/a	13,333	2	1200.03001
DAC timer 1200 hz	TIM6	24	101	11	1200.120012
DAC timer 2200 hz	TIM6	24	101	6	2200.220022

  htim2.Instance = TIM2;
  htim2.Init.Prescaler = 13333 - 1;
  htim2.Init.Period = 2 - 1; // 1200 hz
  htim2.Init.CounterMode = TIM_COUNTERMODE_UP;

  if (HAL_TIM_Base_Init(&htim2) != HAL_OK)
  {
    Error_Handler(__FILE__, __LINE__);
  }

  htim6.Instance = TIM6;
  htim6.Init.Prescaler = 101 - 1;
  htim6.Init.Period = 11 - 1;
// 1200 hz
  htim6.Init.CounterMode = TIM_COUNTERMODE_UP;


  if (HAL_TIM_Base_Init(&htim6) != HAL_OK)
  {
    Error_Handler(__FILE__, __LINE__);
  }
  // We turn on the ARPE register so that the counter is only updated AFTER a clean
  // count completes.  Otherwise, we run the risk of overcounting an interval.
  htim6.Instance->CR1  |= TIM_CR1_ARPE; // Turn on auto-preload register

The ARPE bit

Note that on the DAC timer (TIM6) we set the ARPE bit in the Control Register.   This causes any changes to the counter to take effect AFTER the next timer pop.  This assures that each timer cycle is complete, so that the DAC data points are properly spaced.

Switching between 1200hz and 2200hz

Because I'm using the DAC to make the sine wave, and just adjusting the TIM6 timer to change the frequency, I am able to greatly simplify the code that most APRS implementations use.  Rather than using a 512 element phase array, I'm simply using a 24 element sine array for the DAC.  I no longer need to track the phase position when switching.  Rather, I just adjust the timer counter.

The code is simple, but it confused me at first, because AX.25 is using NRZI encoding.  So, here's a bit about that, before showing the code.

From Wikipedia:

At the datalink level, AX.25 specifies HDLC (ISO 3309)^[3] frames transmitted with NRZI encoding.   

In NRZI encoding, you're not sending the actual bits, but rather toggling whatever bit you are sending, based on the next data value.  I borrowed a few lines from the Tracksoar code, and modified them to my purposes:

if ((current_byte & 1) == 0) {
// Toggle tone (1200 <> 2200)
current_timer_counter ^= (COUNTER_1200 ^ COUNTER_2200); // Switch to the opposite counter value
__HAL_TIM_SET_AUTORELOAD(&htim6,current_timer_counter); // Set frequency
}

That's it.  No math about phase arrays and accmulators!  Yay!

Initial test failures

I only had 3 tiny bugs in my code which prevented APRS from working.

1. I actually FORGOT the HAL_TIM_SET_AUTORELOAD command after setting the current_timer_counter.  lol.  
2. The more subtle one was that I had misread the manual, and thought that the ARPE bit was set by default.  When I tested without it, there were hesitations in the middle of the transmission. It was obvious what was going on when I heard it, and simple to fix.
3. I contrived the test by hard-coding GPS values into the strings that the aprssend() call uses.  I used the wrong number of digits in the Longitude, and so my Kenwood D72 caught my callsign, it wouldn't decode it until I fixed that coordinate.  Along the way, I noticed that my APRS comment was also too long.  I wanted it to read "Mr. Watson, come here, I want you." Unfortunately, that's too many characters.  So, I changed it to "Mr. Watson, Come here!..."

Successful test

AFSK modulation experiments - part 4

AFSK modulation experiments - part 4

I left off the last time with some concerns that the deviation might be too wide on the VCXO, and also that when using the VCXO, the Si5351 was somewhat off frequency (about 5 khz).  I set out to work on both of those issues tonight.

I began by setting up my scope and service monitor so that I could measure the P2P value of the modulating sine wave, and the deviation of the resulting signal.

 

Here, we see a 1200hz sine wave the VCXO signal should be ve being generated by the DAC.  The P2P value is 0.980 volts.  This is from setting the sine wave at 30% amplitude.  We also see that the wave is centered at (2.18 + 1.20) / 2 = 1.69 volts. That's just fine, since it should be centered around 1.65 volts.

The resulting deviation for the wave above (on the 0-6 scale) is coming in at about 2.7 khz.  That's a touch low.

So, I ran the tests over and over gathering data. I also varied the PPM value to see the effect.

PPM value	Sine wave %	P2P voltage (volts)	Deviation (hz)
30	50	1.52	3,500
30	30	0.98	2,700
30	40	1.24	3,300
40	40	1.24	3,700
40	30	0.98	3,200

Deviation Results

The PPM value definitely has an impact on the deviation.  Assuming that we would want the capability of 5 khz deviation for an FM signal, but then we would only want to modulate the signal to 3 khz, the ppm should be (5000 hz / 144.390) = 35 PPM.   In a previous post, I came up with the number 24, but that was when I was considering modulating to 3.2 khz, not 5 khz.

So, it appears that for flight use, I should be setting my PPM to 35 ppm, and setting my sinewave appropriately to get about a 3khz deviation.  That should be at about 30% or so.   I noticed a bit of variability when I was testing this evening, due to the fact that I was using breakout boards and jumpers all over.  I suspect this is a process I'll need to repeat when I have the production boards spun up.

Correcting for the incorrect frequency

I dabbled with the "Correction" call to fix the frequency of the VCXO this evening.

  MySi5351.set_correction(-12940);

In the end, the value above was sufficient to center up the frequency where I was testing, at 144.330 mhz.  According to the documentation, I can expect to do this with every board I build.

Conclusions

1. I'll build my flight code with a PPM of 35.
2. I'll build my flight code with a Calibration option.  When set, the tracker will generate a fixed tone (or maybe alternated between 1200 and 2200) so that I can confirm that the deviation is correct, and also so that I can diddle the "correction" value to assure the tracker is on frequency.

AFSK modulation experiments - part 3

AFSK modulation experiments - part 3

So, Part 2 of this little journey featured our hero barking up the wrong tree a bit.  I made two mistakes.

1. I assumed that I had to modulate the VC pin on the Si5351b with values from -3v3 .. 3v3.  That is incorrect.  The proper values for the VC pin on the Si5351b are from 0 .. 3v3.  The "typical" value is listed as VDD / 2 (IE: 1.65 volts).  I presume (see below) that this means that any modulation should be centered at 1.65 volts.
2. I assumed that the output of my signal generator was making an AC signal.  Of course, it wasn't, as I had things wired up.  It was a DC signal.

The mistakes above led to some seriously confusing results, and some pretty bad sounding signals.

Taking a step back

I decided to do some Science, and assure that I wasn't making any more bad assumptions.  I set up a test environment on my bench so that I could try moving the VC pin between 0 .. 3v3, and see the resulting impact on the signal being generated.

I wired up my Si5351b breakout board to my STM Nucleo-L152RE.  I ran the output into my spectrum analyzer so that I could get a good look at what was happening.  I wired the VC pin to a variable DC power supply so that I could vary it carefully, and see where the signal wound up.

Test 1: Baseline without VCXO

For the first test, I wanted to just set the frequency of the Si5351b to 144.330 without using the VCXO. This test was intended to see where the Si5351b was centered, without using the VC, so I had an idea of how well calibrated it was.

Here are the relevant lines which initialized the Si5351.  I am using the Etherkit Si5351 library.

    MySi5351.set_freq(14433000000ULL, SI5351_CLK0);

    MySi5351.output_enable(SI5351_CLK0, ENABLE);

This is the result.

My spectrum analyzer is reasonably well calibrated.  The center frequency of the Si5351b came in at 144.330004 mhz.  Dang.  Not bad at all!  My little breakout board actually uses a TCXO for the oscillator, and I think that helps with the accuracy.

Test 2: VC at 0 volts

  MySi5351.set_vcxo(86598000000ULL, 40);

  // Set CLK0 to be locked to VCXO

  MySi5351.set_ms_source(SI5351_CLK0, SI5351_PLLB);

  // Tune to 144.330 MHz center frequency

  MySi5351.set_freq_manual(14433000000ULL, 86598000000ULL, SI5351_CLK0);

  MySi5351.update_status();

  MySi5351.output_enable(SI5351_CLK0, ENABLE);

OK, that did just what one would expect.  It pulled the signal down to 144.323462 mhz.  That's 6.538 khz down.  Note, I set the PPM value to "40" in the initial tests, which is the value that was in the samples in the Etherkit Si5351 library I'm using.  Diddling with the PPM value will follow.

Test 3: VC at 3.3 volts

Great, OK, that set the top end of the swing.  It's at 144.332962.  I was a little surprised that it seemed a little asymmetric.   It's only 2.962 khz above the center (vs the 6,538 below we saw).

Test 4: VC at 1.65 volts

OK, this one, I would expect should show the signal centered up again.

Ruh Roh.  We should be at 144.330.  We're at 144.327212.   That's about 5khz off where I expected. Not cool.  If I split the difference between the low and high values, I should have been at 144.328212, which would still have been 1.788 khz off.

Test 5: What voltage do I need for Center frequency?

OK, I was able to get it centered up.  Rather than being at 1.65 volts, I had to apply 2.43 volts. Curious.

Test 6: How does modulation look at 1.65 volts with the DAC?

So, my DAC was all set up to make about 1 volt P2P, centered at 1.65 volts.  I put that 1200 hz modulation into the VC pin to see what it would look like,

Sure enough, it looks symmetric around 133.327 mhz, the same as when the VC pin is just held at 1.65 volts.

Other thoughts on the frequency error

In a later test, I had the VCXO set at 146.000 mhz.  When set up that way, the frequency was dead nuts on at 1.65 volts.  Modulating the frequency looked just fine, too.

I suspect that the frequency error has something to do with an error introduced by the multisynth multipliers and dividers.  I'm not too concerned, as I may be able to address it either by using the calibration subroutines, or different multipliers.

Deviation and the PPM value

OK, so I had set the PPM value in all of these tests to 40.  At 144.330 mhz, that should make for a deviation of  3.608 khz.  My observed deviation was 144.332962 - 144.323462 = 9.500 khz,  

Hmm...   Is that how you measure deviation?  If so, mine's WAY too big.

Test 7:  Different PPM values

PPM value	0 volt reading	3.3 volt reading	Delta
30	144.325164 mhz	144.332289 mhz	7,127 hz
40	144.323462 mhz	144.332962 mhz	9,500 hz

I also tried a test with 20 PPM (which isn't supported according to the documentation), and it seemed to show the same readings as 30 PPM.

If I understand "deviation" in this context, I think these numbers are too big.  I need to understand this better.

Next steps

Strictly speaking, the frequency being off isn't too much of a problem.  The Si5351 has a calibration routine which I can use to center this up.  It's just odd that the center frequency is different when using the VCXO.  I'm a little more concerned about the deviation right now.  The lowest deviation setting still seems to be too wide, unless I'm misunderstanding what to expect with regard to this kind of experiment.

Things to do:

1. Call the calibration routine to see if I can get it centered up.
2. Experiment with the amplitude of the VC signal to see the effect on the signal, and received modulation.
3. See if different multipliers work to improve the frequency accuracy of the VCXO.  I used 6 for these tests.   I could try 4 or 8