Saturday, July 29, 2017

Choosing "pull" value for the Si5351 VCXO for APRS

Choosing "pull" value for the Si5351 VCXO for APRS


When configuring the VCXO frequency on the Si5351b, there is a register setting for the "Pull range".  It is described as follows in Silicon Labs publication AN619 "Manually Generating an Si5351 Register Map":

Set VCXO_Param register value according to the equation below. Note that 1.03 is a margining factor to ensure the full desired pull range is achieved. For a desired pull-range of +/– 30 ppm, the value APR in the equation below is 30, for +/– 60 ppm APR is 60, and so on.
This sounds a lot like the FM Deviation to me, though I wish they used those words.

For APRS, the deviation for the 2200hz tone should be about 3.5khz.  The 1200hz tone will be proportionally lower.  So, I need to do some math:

Desired pull: 3,500 hz.
APRS frequency: 144.390 Mhz.

PPM = 3,500 / 144.390 = 24.2 .  Rounded to an integer, it's "24".

The Etherkit Si5351Arduino library, which I've ported to the STM32CubeMX environment, claims that the PPM value must be in the range of 30 .. 240.  I guess I'll set it to "30" and see how it goes.

Since the library does all the number crunching to calculate the register values, I don't need to calculate them myself..

Correction

Subsequent to posting this blog, I realized that I really want to set the PPM for 5 khz deviation (standard FM), but only modulate my signal to 3-3.5 khz.  Redoing the math:  PPM = 5000 / 144.390 = 34.6, rounded to 35.


Monday, July 10, 2017

AFSK modulation experiments - Part 1

AFSK modulation experiments - Part 1


So, on the next version of my Wisp tracker, I would like to attempt AFSK (APRS) modulation in addition to the WSPR modulation.  The Si5351b clock generator chip provides a VC input pin, which allows for FM modulation.  By using the DAC on the Microcontroller to make the appropriate sine waves, I should be able to achieve the proper 1200 and 2200hz tones necessary to modulate AFSK.

Step 0 of this project is to make a sine wave on an ARM Cortex processor similar to the one I will use in flight. The STM Nucleo L152RE fits the bill nicely.  I use the L151 processor on my Wisp tracker.  I did a fair bit of prototyping for the Wisp1 with this Nucleo.



Using STM32CubeMx, I was able to build some skeleton code to drive the DAC.  I found a Sinewave table online that someone had built that fit the bill nicely.  It had 128 points.

I ran the code, and it generated an absolutely beautiful Sine wave.  Sorry I forgot to take a picture. Unfortunately, when I tried to increase the frequency of the sine wave, I couldn't get above about 1500hz before the microcontroller failed to make a signal.  I didn't look into it deeply, but I suspect there simply wasn't time for the DAC to process the values between interrupts.

I reduced the number of samples from 128 to 36.  It made a respectable sine wave.


Having done that, I was curious how it would look with 12 samples.  As expected, it was rather lumpy.


So, I wondered whether I could throw a simple RC filter into the mix to smooth out the sine wave.  I built one with a 330 ohm resistor and 0.1uF cap.  



According to an online calculator, with those values, the filter cutoff frequency should be about 4825 hz, which is well above the 2200hz I was experimenting with.  Voila.  This is the sine wave with just 12 data points, run through the RC filter.


About attenuation


Note that the signal before filtering was about 3.3v peak to peak.  After the filter, it was about 2.7v peak to peak.  I didn't expect this much attenuation from the filter, but still, it's not bad.  It could simply be due to the breadboard and cheezy connections I was using.  Still, provided that 2.7v is sufficient to swing the signal on the Si5351b to achieve the proper deviation, I should be fine.

Alternatives


Should the attenuation prove too much to make a good signal on the Si5351, I have the option of running without a filter, and just fooling with the number of samples in the sine wave until I strike a good compromise.  Still, I'd really like to use the filter if I can.  I figure the GIGO (Garbage In, Garbage Out) philosophy applies here.  The cleaner the signal I put into the Si5351, the nicer the output should be.

Watch future blog posts for more experiments.