Topics

QCX-SSB: SSB with your QCX transceiver


Jerry Gaffke
 

Allison,

> Some of you speculation is about how the si5351 works and much is not given away.  

Yup, the si5351 is poorly documented.
It takes a little bit of reading between the lines and experimentation to figure out what it really does.

On the other hand, it is a $1 part meant mostly to replace a few fixed frequency crystal oscillators.
Using their ClockBuilderPro software to cook up the magic numbers, doing that is well documented.
Building an EER type radio with it is not well documented.


> All you need to test the signal generation is a raduino. 

At which point you get a somewhat intelligible SSB signal with a lot of artifacts.
Those artifacts due to lack of modulation will hide any artifacts due to i2c write delays. 
So hardly seems a conclusive test of i2c writes to the si5351.

> Then you have the overriding thing that moving 8bits via SPI even at 800khz takes about 11us.

Indeed.  Hence my thoughts of using some other method than i2c writes to vary the frequency.

> Putting a varactor on the crystal would create FM, you don't want that. 

The si5351 output clock will vary in frequency, just as it does using your i2c writes. 
I want that.  Even if you choose to call it FM.

> You would have to process the mic input to a D/A output and then your guessing on frequency as its in the analog realm. 

It the response in frequency to voltage on the varactor diode is non-linear. 
If I were to pursue this, it would be using a lookup table mapping control voltage to the measured deviation.
(Or piece=wise linear interpolation.)

> then the output of the 5351 will multiply that (crystal to VCO then divide to output frequency). 

I'm well aware that if I will get 100x the deviation at 700mhz on the VCO (expressed in Hz), as I will get at 7mhz.

> On a good day that would be band limited.

Yes, I did acknowledge that deviation won't be sufficient using the varactor diode.

> The use of a mixer, really?
> Mix the 5351 and I presume audio, then a crystal filter as you have both sidebands.

You totally missed the point.
With +/- 240ppm deviation using the Si5351b VCXO pin, we don't get enough deviation for direct synthesis on 80m.
(However it should be sufficient for synthesis on 40m and above.)
So for 80m, we would need to create the desired square wave out of the si5351b at 7mhz or higher, 
then translate that square wave down to 80m, apply it to the class C,D,E amp, and modulate the amp.

If the Si5351b were not available so cheaply, I'd consider using the varactor diode to create a square wave
at VHF (where I can get a large deviation, expressed in Hz), then down convert that square wave to HF.
But much easier to just use the VCXO pin on the si5351b.


Given the lack of previous success with this, my impression is that i2c writes and PWM modulation
is not going to get us to a clean signal. 
Better to throw $10 worth of parts at this (16 bit DAC's, Si5351b, buck mode switcher),
and work on algorithms without dealing with the serious handicap of marginal hardware.

Best to start out at 0dBm or so and a nice linear modulator (as you are doing) till it works properly.
Then go to a buck mode switcher for the modulator, it should probably be switching at 1mhz or more
to minimize response time.  Hacking the ebay cheapies to make them programmable might not cut it.

Jerry, KE7ER


Kārlis Goba
 

Jerry, I can't see how the varactor FM method might work, as you need precise frequency control. With I2C writes, you control the PLL and thus you have precise control. With varactor, you don't. 

The reason is how the EER method works. So if you're transmitting a 1 kHz tone USB on 10.000 MHz, you are actually putting a 10.001 MHz carrier in the air. You need to shift the frequency by exactly 1 kHz from the reference to get that. The maths in Guido's code take audio input and generate a complex analytic signal from it (basically generate the 90 degrees shifted version). From that representation you can get something called the instantaneous frequency of the audio signal. Which is pretty much the same as converting a 2d vector (complex value) into its polar form (angle and length). The angle (or rather the speed of change) is sent to Si5351 as the FM part, and the length is sent to the envelope shaper (AM).

The instantaneous frequency is exactly the amount of frequency shift that is sent to the Si5351. It has to be exact. In case of 1 tone signal it is the frequency of the audio signal. You can have an offset error, which will just shift the SSB signal, but you can't have a scale error or nonlinearity here. Varactors have pretty much uncalibrated, nonlinear and varying response (e.g., temperature).

--
Karlis YL3JG


Kārlis Goba
 

Or let me put it this way:

- in traditional FM, you shift the carrier frequency by some amount proportional to the (instantaneous) amplitude of the audio signal
- in EER, you have to shift the carrier frequency exactly by the instataneous frequency of the audio signal, _not_ the amplitude

--
Karlis YL3JG


Jerry Gaffke
 

I agree, the varactor scheme would be cranky to work with.
We could calibrate out non-linearities and temp dependence in software,
operating at VHF so we are in a reasonably linear part of the voltage-to-frequency curve.
But that's all moot, the Si5351b with its VCXO pin is a much better solution, and at $2 is cheap enough. 

That VCXO pin may still need calibration in software (piece-wise linear interpolation),
since the Si5351b mentions a max of +/- 5% non-linearities in the response (mostly at the edges?).
Remains to be seen if the VCXO pin can be made precise enough.
The frequency you get from Guido's i2c writes can be much more precise,
but the discrete time intervals between updates could cause more trouble than VCXO non-linearities.

If neither method works, we could move up to the Si5340b.
That has an SPI bus, so updates can be very fast. 
And it is considerably more precise than the Si5351.
Relatively expensive at $12, and burns over half a watt.
But if we are trying to build an efficient 100+ Watt SSB transmitter, 
neither of those is a significant issue.

I appreciate your description of the algorithm, that helps.

Assume we transmitting a human voice, and 1000hz is dead on but we have a 10hz error
when synthesizing 3000hz.  Does that just change the perceived characteristics of the
received audio, or does it create spurious signals due to the frequency information
no longer lining up with the envelope information?
This won't be a problem for the single tones you describe, but it will be significant
when we have simultaneous tones to deal with, falling in and out of phase at regular intervals.
With two tones of equal amplitude, when out of phase the modulation must drop to zero.
Exactly how precise our frequency control must be is not yet obvious to me.

Jerry, KE7ER



On Sun, Feb 3, 2019 at 08:23 AM, Kārlis Goba wrote:
Jerry, I can't see how the varactor FM method might work, as you need precise frequency control. With I2C writes, you control the PLL and thus you have precise control. With varactor, you don't. 

The reason is how the EER method works. So if you're transmitting a 1 kHz tone USB on 10.000 MHz, you are actually putting a 10.001 MHz carrier in the air. You need to shift the frequency by exactly 1 kHz from the reference to get that. The maths in Guido's code take audio input and generate a complex analytic signal from it (basically generate the 90 degrees shifted version). From that representation you can get something called the instantaneous frequency of the audio signal. Which is pretty much the same as converting a 2d vector (complex value) into its polar form (angle and length). The angle (or rather the speed of change) is sent to Si5351 as the FM part, and the length is sent to the envelope shaper (AM).

The instantaneous frequency is exactly the amount of frequency shift that is sent to the Si5351. It has to be exact. In case of 1 tone signal it is the frequency of the audio signal. You can have an offset error, which will just shift the SSB signal, but you can't have a scale error or nonlinearity here. Varactors have pretty much uncalibrated, nonlinear and varying response (e.g., temperature).


Joshua Blanton
 

Hello all - sorry that my first post is wading into a mostly-off-topic thread, but I've been thinking about this topic for quite some time (ever since QEX published an article in the March/April 2017 edition - see https://www.arrl.org/files/file/QEX_Next_Issue/Mar-Apr2017/MBF.pdf for an online version). The key, to me, is efficiency - if you aren't getting the efficiency gain, EER is an enormously fiddly technology vs. everything that's already "normal" these days.  To that end, I like Steve's proposed experiment with building a linear audio modulator amp for testing - but in the end, the power consumption will approach a decent linear amplifier, I think.

I totally agree with Kārlis; a varactor-tuned VXO won't have the frequency accuracy required to perform the trick that's being done in Guido's sketch.  The goal isn't to produce FM directly - you're trying to produce an accurate phase, by way of FM'ing the carrier.  In order to correctly do so, you must integrate the frequency change over time to arrive at the proper phase - and the only way you have a chance of accuracy is if your frequency steps are known, and finite enough to provide a slow phase/time shift.  It also seems to me (intuitively - I haven't done the math to prove it!) that the clock accuracy of the processor matters quite a bit when generating PM-via-FM, as otherwise you'll get slow error accumulation in the resulting phase.  It might be best if your CPU clock were the same clock that fed the 5351.  I'm not quite smart enough to understand what that accumulated error will result in (ugly sidebands, harmonics, or a shift in output frequency?), but it can't be good.  Similarly, when using any FM scheme where the frequency shifts are generated by an unknown PLL scheme, quite a bit of experimentation must be performed to determine how quickly the frequency changes occur - because that can affect the accumulated error, as well as create instantaneous sidebands during the transitions.

The QEX article cited above shows (to me, at least) that modern computation can arrive at a reasonable EER modulation - but the bill of materials for the signal generation isn't cheap, or easy to come by.  I've been thinking about possible inexpensive ways to replace the high-side modulator (I believe Jerry mentioned a DC-to-DC switching supply - for efficiency, this is the right approach I think; the AM crowd already has quite a few nice designs for good-quality high-side DC modulators!) - and for the phase generation, I think that perhaps two balanced modulators 90deg out of phase being fed the I/Q modulation for the carrier (no AM modulation of the carrier - just generate the phase-modulated carrier, as if the generated SSB had been run through a limiter) might be the most computationally- and homebrew-easy solution.

Anyway, sorry for the mostly-off-topic first post.  The QCX looks like a neat rig - and it's clearly a nice platform for tinkering!

73,
Josh, KB8NYP

On Sun, Feb 3, 2019 at 11:36 AM Kārlis Goba <karlis.goba@...> wrote:
Or let me put it this way:

- in traditional FM, you shift the carrier frequency by some amount proportional to the (instantaneous) amplitude of the audio signal
- in EER, you have to shift the carrier frequency exactly by the instataneous frequency of the audio signal, _not_ the amplitude

--
Karlis YL3JG


ajparent1/KB1GMX
 

Josh,

You have pointed out of of my tech references (including Khan's paper in '52) and others.
Whats useful about the Polar explorer is where you end up when you build hardware to
get a still less than stellar signal.  His output spectrum show the problems for a fairly
high resolution system using a much fast 32bit cpu.   Imagine how that decays for
a slightly slower 8bitter.

Again with emphasis there are two areas for distortion and spurious signals in the system.
One is the phase modulated RF source, the other is the hardware to amplitude modulate it.

Once you have a fairly fast 32bitter and 14bit or more ADC and DACs then other
SDR techniques offer better chances for improved quality of signals and no greater
amount of hardware.

My level of curiosity is the proposed QCX based framework is how bad and can it get
to semi decent.

Allison


Jerry Gaffke
 

So phase must be accurate relative to what?
I'm now thinking that the phase of our square wave from the si5351/si5340 must be
accurate with respect to that same square wave over a time interval on the order of
the period of the lowest frequency in the audio that we are modulating with.
Correct within a small fraction (perhaps 5%?) of one RF cycle.
A very tall order indeed, if that''s right then I agree that the VCXO scheme would not work.

Si5351 frequency transitions when using the output multisynth dividers are instantaneous,
take effect immediately when the final multisynth register is written to.
That might be best the implementation to maintain phase accuracy.

In the case of using PLL multisynth dividers, there will be an unknown amount of time
for the VCO to slew to the new target frequency, a function of the loop filter
that SiLabs has in their PLL.

Locking the processor to the si5351 should be quite easy, just drive the processor clock
from one of the other si5351 outputs.  Or perhaps from the 25/27mhz reference oscillator.

Jerry, KE7ER


On Sun, Feb 3, 2019 at 09:53 AM, Joshua Blanton wrote:
In order to correctly do so, you must integrate the frequency change over time to arrive at the proper phase - and the only way you have a chance of accuracy is if your frequency steps are known, and finite enough to provide a slow phase/time shift.  It also seems to me (intuitively - I haven't done the math to prove it!) that the clock accuracy of the processor matters quite a bit


ajparent1/KB1GMX
 

Jerry,

>>So phase must be accurate relative to what?<<

The most obvious is RF phase ot amplitude phase

More finely the extracted frequency from the modulation source
should exactly translate to the TX base frequency plus modulation
phase.  So if the input are stepped frequency tones from
200hz to say 2200hz the output frequency should also be base
frequency plus (minus for LSB) the base or carrier and increase
the same as the modulating tone.  It also must change at the same
rate.

For amplitude the average transmitter has about 50-60db of dynamic
range (can vary) from zero to full power and the granualatiry of processing
digitally may be less that fine causing waveform distortion.  For Guido's
code its 64 steps or barely 6 bits or rather coarse.  At extreme example
is CD audio at anywhere from 16 to 22bits.

So yes there are a lot of relative to self and also relative to processing speed
and sampling speeds all of which can if not carefully done create side bands.

Famous line is:  iF It wEre easy everyone would dOing it.  Ignore the
phase and amplitude errors in typing.

Allison


ajparent1/KB1GMX
 

On Sun, Feb 3, 2019 at 02:26 PM, Jerry Gaffke wrote:
Si5351 frequency transitions when using the output multisynth dividers are instantaneous,

Yes and no.  Takes 11uS to transmit the change order.  At 7mhz 11US is 77 cycles.
at at 7.1mhz is 78.1..  frequency is time, phase is time.  Transmitting the data to
say do something takes time. 

Allison


Jerry Gaffke
 

> Takes 11uS to transmit the change order.

Ah, but i2c writes out to the si5351 are totally under our control. 
We can choose when the final register write gets kicked off.
As an extreme, could put down a $0.50 uC to keep time and bit bang the i2c bus,
perhaps with all interrupts turned off. s.


On Sun, Feb 3, 2019 at 05:29 PM, ajparent1/KB1GMX wrote:
Si5351 frequency transitions when using the output multisynth dividers are instantaneous,

Yes and no.  Takes 11uS to transmit the change order.  At 7mhz 11US is 77 cycles.
at at 7.1mhz is 78.1..  frequency is time, phase is time.  Transmitting the data to
say do something takes time. 

Allison


Steven Weber
 

11 us is 90.9 kHz. The other factor is how long does it take to do the required calculations? So long as you have an update rate faster then say 12 kHz, your doing good. The PWM rate I measured was 30.9 kHz, so it’s updating at a good clip. A lot of sound cards run at 44 kHz, right?

 

KD1JV

 

 

On Sun, Feb 3, 2019 at 02:26 PM, Jerry Gaffke wrote:
Si5351 frequency transitions when using the output multisynth dividers are instantaneous,

Yes and no.  Takes 11uS to transmit the change order.  At 7mhz 11US is 77 cycles.
at at 7.1mhz is 78.1..  frequency is time, phase is time.  Transmitting the data to
say do something takes time. 

Allison

 


Jerry Gaffke
 

Allison,

>>So phase must be accurate relative to what?<<
> The most obvious is RF phase ot amplitude phase

The envelope is changing at audio rates, looks like a flat line to our RF.
Not sure how to compare the timing of one particular edge of 14mhz RF with a flat line.
I think we are comparing the RF phase to what it was a millisecond or so in the past.

If speech is intelligible without any envelope modulation, that suggests this single square wave
that's always within 2 or 3 khz of our target frequency somehow contains information about
all the tones present, it must be in the phase of the square wave..
And if the information is at audio rates, then phase must be accurate across time periods
of a millisecond or more.  Hence this is hard.
 
I bet we'll have much less distortion due to phase errors on 160m than on 20m.
Perhaps synthesize the square wave at 200khz, up-convert to an HF square wave with a mixer?
That's what previous attempts at EER have been doing.

Using a buck mode switcher to modulate assumes there is always sufficient 
current draw to allow the output to quickly go lower when needed.
The QEX article mentions using a consumer type class D audio amp instead.

Take this all with a large grain of salt.
I don't yet have it figured out.

Jerry, KE7ER



On Sun, Feb 3, 2019 at 05:25 PM, ajparent1/KB1GMX wrote:
Jerry,

>>So phase must be accurate relative to what?<<

The most obvious is RF phase ot amplitude phase

More finely the extracted frequency from the modulation source
should exactly translate to the TX base frequency plus modulation
phase.  So if the input are stepped frequency tones from
200hz to say 2200hz the output frequency should also be base
frequency plus (minus for LSB) the base or carrier and increase
the same as the modulating tone.  It also must change at the same
rate.

For amplitude the average transmitter has about 50-60db of dynamic
range (can vary) from zero to full power and the granualatiry of processing
digitally may be less that fine causing waveform distortion.  For Guido's
code its 64 steps or barely 6 bits or rather coarse.  At extreme example
is CD audio at anywhere from 16 to 22bits.

So yes there are a lot of relative to self and also relative to processing speed
and sampling speeds all of which can if not carefully done create side bands.

Famous line is:  iF It wEre easy everyone would dOing it.  Ignore the
phase and amplitude errors in typing.

Allison


Jerry Gaffke
 

Sound cards send 16 bit words across at 44khz.
A simple minded pwm would take 256 bit periods to send a single 8 bit word's worth of information.
So our PWM is nowhere near the accuracy of a sound card.

And that 11uS is to send out a single 8 bit byte over the i2c bus at 800khz.
I have not looked at Guido's code yet, but it reportedly does not do burst writes.
So it will take 3 bytes to write to one register  (device id, register address, register data).
Updating the frequency once takes nearly a dozen register writes.

So that code for the uBitx is very close to the bottom end of what might sort of work.
Amazingly, it works moderately well.
If we upgrade for burst writes to the Si5351, that will improve frequency updates by a factor of 3.
If we also use a DAC of some sort to drive the modulator instead of PWM, 
performance should improve considerably.
    
Jerry, KE7ER


On Sun, Feb 3, 2019 at 06:47 PM, Steven Weber wrote:

11 us is 90.9 kHz. The other factor is how long does it take to do the required calculations? So long as you have an update rate faster then say 12 kHz, your doing good. The PWM rate I measured was 30.9 kHz, so it’s updating at a good clip. A lot of sound cards run at 44 kHz, right?

 


ajparent1/KB1GMX
 

On Sun, Feb 3, 2019 at 07:36 PM, Jerry Gaffke wrote:
o our PWM is nowhere near the accuracy of a sound card.

I thought I said that, roughly 6bits.

IF it takes a dozen byte then that is 132mS, or in real terms an eternity.  
that would be roughly 7500 updates per second.  I only gave a per byte 
overhead if there are more byte multiply be 11us.

We do not have any data/tests/measurements on how well or how
much trash there is.

Intelligible without envelope is partly due to the SSB receiver and its filters.
Like I said early on I can produce DSB and people take it as SSB as they
rarely look for the opposing sideband.  I've listened to some SSB radios
that had Better FM because the VFO was FMing and more than a few
with enough carrier leakage to hear on AM receiver.  It only show the
imperfections of the receiver or transmitter and how little intelligibility
is needed for our wetware to achieve recovery.  Nothing qualitative
in that.

Allison


ajparent1/KB1GMX
 

On Sun, Feb 3, 2019 at 06:47 PM, Steven Weber wrote:
11 us is 90.9 kHz.

Per 8 bits sent at 800khz SPI clock. 

Not PWM thats a separate issue. The PRM for for the PWM is much slower
but the increment between values or steps as I read the code is only 64 steps
or the equivilent of a 6bit D/A.

Allison


Allison


ajparent1/KB1GMX
 

On Sun, Feb 3, 2019 at 07:18 PM, Jerry Gaffke wrote:
I bet we'll have much less distortion due to phase errors on 160m than on 20m.
Perhaps synthesize the square wave at 200khz, up-convert to an HF square wave with a mixer?
That's what previous attempts at EER have been doing.<<<<


Likely you would and at 455khz maybe better.  Then upconverting , limiting, amplifiying
band filtering and we are approaching whats needed to do a filter type TX and more than
needed to so an Analog phasing TX.   We still haven't done RX to make a complete radio.

Like I said more hardware more cost, but how much better signal? The math seems to 
indicate needing lots of goood thing happening to get to a soso level.

Allison


Jerry Gaffke
 

I'm poking around in Guido's code now.
    https://github.com/threeme3/QCX-SSB

Only the initial setup of the Si5351 uses single register writes.
Si5351 updates are done as burst writes within ISR(ADC_vect)
through a call to si5351_SendPLLBRegister().  Each burst write to update
the si5351 frequency involves sending 7 bytes (each is 8 bits plus an ACK)
over the i2c bus, so 63 bit periods at 800khz, taking a total of about 79uS,
It won't get much better than that, he's got it very well optimized.

He is updating the PLL multisynth, which will take a bit of time to slew the VCO frequency.
If we use a fractional output divide and leave the VCO parked (as done on the uBitx),
the change in frequency is instantaneous and thus we might reduce the phase errors somewhat.
Worth trying, but the abrupt frequency change may possibly cause more trouble than it cures.

Jerry, KE7ER



On Sun, Feb 3, 2019 at 07:36 PM, Jerry Gaffke wrote:
And that 11uS is to send out a single 8 bit byte over the i2c bus at 800khz.
I have not looked at Guido's code yet, but it reportedly does not do burst writes.
So it will take 3 bytes to write to one register  (device id, register address, register data).
Updating the frequency once takes nearly a dozen register writes.


Jerry Gaffke
 

Guido's low level i2c_SendByte() uses bit-banging, that code could be
considerably tightened up for speed.
I suspect 800khz is a measured figure for that particular code,
and may not be the maximum rate that the si5351 can sustain.
Would be interesting to try running it faster.

Jerry



On Sun, Feb 3, 2019 at 09:53 PM, Jerry Gaffke wrote:
I'm poking around in Guido's code now.
    https://github.com/threeme3/QCX-SSB

Only the initial setup of the Si5351 uses single register writes.
Si5351 updates are done as burst writes within ISR(ADC_vect)
through a call to si5351_SendPLLBRegister().  Each burst write to update
the si5351 frequency involves sending 7 bytes (each is 8 bits plus an ACK)
over the i2c bus, so 63 bit periods at 800khz, taking a total of about 79uS,
It won't get much better than that, he's got it very well optimized.


ajparent1/KB1GMX
 

On Sun, Feb 3, 2019 at 09:53 PM, Jerry Gaffke wrote:
>>>He is updating the PLL multisynth, which will take a bit of time to slew the VCO frequency.
If we use a fractional output divide and leave the VCO parked (as done on the uBitx),
the change in frequency is instantaneous and thus we might reduce the phase errors somewhat.
Worth trying, but the abrupt frequency change may possibly cause more trouble than it cures.<<<<

Multibyte writes just take longer.

Going fractional creates jitter ass to the phase noise spectra.

Allison


ajparent1/KB1GMX
 

Jerry,

The problem is not that alone.  This design gets a amazing about from the 16mhz 8 bit CPU.
When you round the results to 8bits you get truncation and rounding errors so 1/256 is not
a great number if it translates to a DB value of distortion for amplitude, phase, or even time.
You can throw a fast 32bit cpu against it but many of the non digital external analog functions
are still there to cause or add distortion.

There is little question in my mind that its optimized.  I've spent a bit of time with the
code already.  Its very dense as there are multiple processes going on.

This type of technology is resistant to just throwing stuff at it in the hopes of making it better.
The often result of that is makes it worse.   Takes a very system view to get to better and 
also what you need to get there.

Allison