Topics

QCX-SSB: SSB with your QCX transceiver


Jerry Gaffke
 

Yes, more jitter with fractional output dividers, but not as much as you might think.
If we mostly care about maintaining RF phase accuracy over millisecond long intervals,
then we may be better off with the output multisynth dividers.

Looking at datasheets for other members of the Si53** family, the extra jitter is less than a factor of two.
They do this by using programmable delay lines, and digitally computing an appropriate delay
for each rising and falling edge to correct the dirt created by bouncing between two different 
divider values.

But that "less than a factor of two" is mostly a guess till somebody measures jitter for
the specific code being used at a large collection of target frequencies, not just one or two.
Especially since ClockBuilderPro software from SiLabs does all sorts of undocumented tricks.

My guess is  jitter will not be a problem.
Nobody's mentioned an issue with phase noise on the uBitx, and that uses output multisynth dividers.
Abrupt small changes in frequency are probably ok, the clock pulse at the moment of transition
from the output multisynth divider is indistinguishable from its neighbors on a scope,
But if we are doing updates at only 8khz, those frequency changes could be large enough
to cause trouble.

Jerry


On Mon, Feb 4, 2019 at 09:02 AM, ajparent1/KB1GMX wrote:
Going fractional creates jitter ass to the phase noise spectra.


Jerry Gaffke
 

Most of the computations are in 32 bit floating point.
Doesn't really matter that it's an 8 bit CPU if the computations can be carried out
at the required 8khz rate.
 
Primary limitation I see is the speed and accuracy with with it can convey those computations
to the modulator and the si5351.

Don't have a QCX, experimenting on an ATMega328P would be limiting..
May try moving it to a Teensy 3.2 and an Si5351 breakout board.
See how fast I can wind up those i2c writes.

> Multibyte writes just take longer.

He's getting by with just 7 bytes over the i2c bus per update.
That's device id,  register address, and 5 multisynth registers.
I doubt there's any way to reduce it.

Jerry, KE7ER
 


On Mon, Feb 4, 2019 at 09:16 AM, ajparent1/KB1GMX wrote:
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.


jjpurdum
 

The Teensy 3.5 and 3.6 have floating point processors which might help.

Jack, W8TEE

On Monday, February 4, 2019, 2:01:11 PM EST, Jerry Gaffke via Groups.Io <jgaffke@...> wrote:


Most of the computations are in 32 bit floating point.
Doesn't really matter that it's an 8 bit CPU if the computations can be carried out
at the required 8khz rate.
 
Primary limitation I see is the speed and accuracy with with it can convey those computations
to the modulator and the si5351.

Don't have a QCX, experimenting on an ATMega328P would be limiting..
May try moving it to a Teensy 3.2 and an Si5351 breakout board.
See how fast I can wind up those i2c writes.

> Multibyte writes just take longer.

He's getting by with just 7 bytes over the i2c bus per update.
That's device id,  register address, and 5 multisynth registers.
I doubt there's any way to reduce it.

Jerry, KE7ER
 


On Mon, Feb 4, 2019 at 09:16 AM, ajparent1/KB1GMX wrote:
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.


ajparent1/KB1GMX
 

On Mon, Feb 4, 2019 at 11:01 AM, Jerry Gaffke wrote:
>>>Most of the computations are in 32 bit floating point.
Doesn't really matter that it's an 8 bit CPU if the computations can be carried out
at the required 8khz rate.<<<

============================================== 
volatile int32_t si5351_raw_freq;
volatile uint8_t si5351_prev_divider;
volatile uint8_t si5351_divider;  // note: because of int8 only freq > 3.6MHz can be covered for R_DIV=1
volatile uint8_t si5351_mult;
volatile uint8_t si5351_pll_data[8];
static int32_t si5351_prev_pll_freq = 0;
=============================================================================

Pulled from the code,  The only floats are outside the TX loop for the display.  Everything is integer
and there is little reason for floats as they take a long time and offer precision that is not usable by
5351 or PWM.

Allison 
 


Jerry Gaffke
 

You're right, not much FP.

I've been looking at his older RPi code:
    http://pe1nnz.nl.eu.org/2013/05/direct-ssb-generation-on-pll.html

Jerry



On Mon, Feb 4, 2019 at 05:29 PM, ajparent1/KB1GMX wrote:
Pulled from the code,  The only floats are outside the TX loop for the display.  Everything is integer
and there is little reason for floats as they take a long time and offer precision that is not usable by
5351 or PWM.


ajparent1/KB1GMX
 

On Mon, Feb 4, 2019 at 10:48 AM, Jerry Gaffke wrote:
>>>Nobody's mentioned an issue with phase noise on the uBitx, and that uses output multisynth dividers.<<<

No body has looked and likely buried under the IMD.

>>>Abrupt small changes in frequency are probably ok, the clock pulse at the moment of transition
from the output multisynth divider is indistinguishable from its neighbors on a scope,
But if we are doing updates at only 8khz, those frequency changes could be large enough
to cause trouble.<<<<

Well you have to wonder does changing he frequency say 400hz (phase change) have more
effect than the the act of changing it 8000 times a second?  Both modulate the oscillator
by changing it.

And a scope is far from the best tool to see frequency variation.  If the setup is for an
eye pattern then you can see the eyes close (fill) when there is phase changes but even then 
I has to be fairly pronounced.

Allison


Jerry Gaffke
 

> And a scope is far from the best tool to see frequency variation.

Not what I was looking for.
I was looking for an occasional ghost from a short or long clock pulse
when the output made the transition on small changes to
the si5351 output multisynth fractional divider.  Wasn't there.

Lots of folks using the si5351 in communications gear beyond the uBitx.
Including a bunch of stuff from Hans. 
Some of the Si53** docs suggest jitter when using multisynth output divides
within a factor of two of jitter when using integer divides, and I'm convinced
that's clean enough.
 
> Well you have to wonder ...

Indeed.  I had been thinking it was important to keep the frequency 
of the transmitted signal as close as possible to where it "should" be.
But if phase is all we really care about, perhaps it's ok to have the
square wave frequency push the edges of what is normally the passband.

I wonder ....  if we could get by with just two frequencies for the square wave.
One on the lower edge of the normal SSB passband, one on the upper edge.
Control the phase by adjusting the amount of time it spends at the low freq
vs the high freq.  My gut feeling is that it would not work well, but then
my gut has often been wrong about this EER stuff.  Would be an interesting
experiment, see what it does to audio quality, and to a spectrum analyzer display.
If it works well, imagine the guy at the far end, staring in disbelief at his waterfall.

Jerry, KE7ER



On Mon, Feb 4, 2019 at 06:30 PM, ajparent1/KB1GMX wrote:
And a scope is far from the best tool to see frequency variation.


Jerry Gaffke
 

I'd imagine a very abrupt change in frequency would not work.
But slewing at a reasonable rate between the two might.

And that "reasonable rate" may have to be slow enough that we spend
most of our time in the middle anyway.

Jerry


On Mon, Feb 4, 2019 at 07:33 PM, Jerry Gaffke wrote:
if we could get by with just two frequencies for the square wave.
One on the lower edge of the normal SSB passband, one on the upper edge.


Jerry Gaffke
 

I've dug around in Guido's SSB code for the QCX, here's a few notes.
Take this with a large grain of salt, as I haven't gotten down to messing with anything physical yet,
and don't know much about EER or DSP techniques.  Corrections are welcome.


On the si5351, Guido holds the vco close to 900mhz, locked to the 27mhz reference oscillator by a fractional ratio of (a + b/c).
The integer part 'a' is about 900/27 = 33, the value of 'c' is a constant 0xFFFFF, 'b' can be anything from 0 to 0xFFFFE.
That's a granularity of around 1 part in 33*(2**20), or 26.5 ppb.   Varies some, so let's call it 30 ppb.
Example:  vco = 27mhz*(32 + 0x99999/0xFFFFF) = 880200000 Hz, next step up is vco = 27mhz*(32 + 0x9999A/0xFFFFF) = 880200026 Hz.
Transmit frequency is always an even integer divide of the vco frequency, in this case might be  880.2mhz/62 = 14196774.194 Hz.
After one second with a 30 ppb error, that 14 Mhz carrier will be off in phase by 14e6*(30/1e9) = 0.42 cycles.
My best guess is that we care about holding the phase of the RF correct for at least as long as the period of the lowest
frequency audio we plan to transmit, perhaps 300 Hz, the phase error after 1/300'th second is 0.42/300 = 0.0014 of an RF cycle..  
Seems good enough, though could improve on that by including the error due to granularity in setting up the PLL multisynth 
for the previous si5351 update when calculating the register values for the current si5351 update.
 
So the granularity in setting the frequency of the EER square wave using an si5351 should be sufficient.
However, we only update the si5351 at an 8 KHz rate, and between updates the phase of the square wave is changing
in a linear fashion.  The ideal phase would not change linearly, it remains to be seen if 8 KHz updates are sufficient
to synthesize a clean enough signal.  If not, options include a move to the si5340 with its fast SPI interface, or driving 
the si5351's 27mhz reference from a DDC chip (the si5351 PLL loop filter should remove the DDC's spurs).

Operating at 1.8 mhz instead of 14mhz will reduce those phase errors to the EER square wave by nearly an order of magnitude.
 
The ATMega328P does not have enough compute power to perform the required calculations accurately, Guido's QCX firmware
makes a number of approximations that will cause significant phase errors.  One solution might be to remove the ATMega328P
from its socket, replace it with a small daughterboard with an ARM processor.  The ARM will have 3.3v IO, but should be possible
to adjust the rest of the QCX to accommodate this, especially if the LCD can correctly respond to 3.3v CMOS logic.
The 74ACT00, FST3253, op amps, and LCD want to remain powered from 5v, otherwise everything can be 3.3v
 
Here's a few places where the ATMega328P firmware can introduce phase errors:
Hilbert transform coefficients are implemented through right shifts.   First two coefficients should be around 0.636, 0.212, not 1.0, 0.25
The Hilbert transform should be getting fed with raw audio samples, why is it getting fed the difference from the previous sample?
arctan2(x,y): Off by 4 degrees in the region of 15 to 20 degrees, 20x worse than this recommended by Lyons: radians = x*y/(x*x+0.28125*y*y)
Between the Hilbert transform and arctan2(), our EER square wave's phase angle will be off considerably.
 
Between PWM, the amplitude=abs(i)+abs(q) approximation, and the audio compression scheme, the modulation at Q6 is rather ugly.
But other projects do get by with constant carrier SSB synthesis, so ugly might be ok here so long as there are no abrupt changes.
Could listen to the RF with a diode detector through an ADC to close the loop, perhaps process with a PID algorithm,
compensate for the delays in modulating the envelope by delaying updates to the si5351.
 
Mike input must have an analog low pass filter, removing anything above the 4khz Nyquist frequency of the 8khz ADC sampling rate.
A faster uC could perhaps sample at 16khz (and also run the Hilbert transform at that rate), making the external filter less critical.
The 16khz sample rate would allow more correct calculations of phase angle, even if the si5351 updates are kept down at 8khz.

Jerry, KE7ER


ajparent1/KB1GMX
 

I now have a real QCX in stock form for 40M up and running.  Sweet kit, easy
build and works very well.  Mine is doing a nice 5W at 13V, that's good enough.
I plan to play with it a few days then....

Guido's code and mods.  

Allison


ajparent1/KB1GMX
 

Built and tested...

Stock QCX that works perfectly on Han's code and with mods to permit operation as SSB.

Mod-1 expand filter bandwidth so that SSB rx sounds normal.  A few resistors and caps.

Mod-2 per Quido's paper to permit using a microphone.

Loaded a spare atmega328P  with guido's code.

Operating notes:

*Interface likes to change usb/lsb with tune rate or mode change, likely a code bug.

* all sorts of RX tones that are tuneable and heard even on dummy load not there before
using factory code.

* SSB opposing sideband balance changes with tuning, Phase from 5351 is not done right
 as it changes.  It also changes when going RX-TX-RX.

*Usable on RX on the antenna, though RX performance is decayed.

NOW FOR TX:

* Measured carrier changes with DC supply voltage, best attainable was almost -25dbc
  which by reasonable SSB standard is very poor.

* Measured power on audio peaks, single tone, and two tone is about right with single tone at 5W.

*Two tone IMD best attainable was maybe -12dbc, very distorted.
The band width of the signal is narrow but there are unless over driven.
When over driven it just gets wider as much as 5khz.

* Every transisition from RX-TX and back puts out a burst of RF at random frequencies
inside a 4mhz wide window .

* On air coms with a local, was is that you?  Sounds real bad, very compressed, clipped and 
 like a good ssb radio through a class C amp.  Spent time trying to make it sound good
by tweaking available parameters (and recompiling code) got it to "just bad, never heard a
signal that bad from you.".  Followed by a email with what was that mess.

First thing all the QCX features including CW are gone with the code.  Its simply no
longer a CW radio.

By my standards I'll keep this off the air.  I plan to play a few days trying to see
if improvement is possible but generally it sounds poor int he instrumentation radio,
and looks poor on the SA.  Also the once really nice RX has all manor of oddities
and artifacts, that seems bad.  When done playing I'll go back to standard QCX-CW.

The concept is simple, doing it right is not.  I feel it was an interesting experiement.

Allison


Jerry Gaffke
 

Thanks for the report!

It's a concept demo, primary goal is efficient SSB class E transmission,  
I don't care too much about rx, rx/tx switching, cw, etc.
I am curious how clean a signal we can put out with an si5351

The ATMega382P is woefully underpowered to compute the target phases.
And the modulation scheme is pretty chunky.
Both of those could be addressed using a better processor (with better ADC and a DAC).

I think the primary limitation will be si5351 update rate, 8khz max due to the i2c bus.
So phase rate-of-change only gets adjusted every 120uS, which seems awfully long.

I'm currently talking to an si5351 breakout board using a Teensy 3.2, works at 1mhz i2c clock rates.
Will see how much beyond 1mhz we can press that i2c bus if ACK's are ignored.
Then digitally synthesize a 2 tone test signal, see how clean that looks.
Initially no attempt at modulating.
Any idea what not modulating the final amp of an EER transmitter does to the spectrum?

Jerry


On Thu, Feb 14, 2019 at 02:48 PM, ajparent1/KB1GMX wrote:
Built and tested...


ajparent1/KB1GMX
 

>>>I am curious how clean a signal we can put out with an si5351<<<

Define clean, it was fairly narrow but unintelligible.  It would seem if the
other guy needs a lot of repeats to get a message its kinda broke.
It wasn't a weak signal only so horribly distorted as to be almost useless.
The inline power meter it looked like most SSB signals it bounced up
on voice peaks and more if I got louder.

The update rate is part of the issue its also the granularity of frequency to phase.
To the ear 120us is not an issue.  Also remarkable was the lack of serrations
showing in the sidebands.  However piping in discrete tones got a mismatch in
output frequency.  The math is either broken or way to rounded off to fit in 8bits.

More cpu and fancier D/A and A/D, let us know how it goes.

Not modulating the Amp means carrier and FM like operation with distortion
in the other guys SSB RX. 

If you don't play with the 5351 at all and do AM, a  5W Class e will do a 1.3W
AM signal very well but a CPU is not really needed for that.  I know the latter
can sound very good as commercially its done and many hams have really
nice sounding class D and E AM going.

I rank this with non-Foster matching.  Killer idea on paper now go try and make one.

Allison


ajparent1/KB1GMX
 

Follow up and abandonment:

With working with it the level of TX distortion never made it to to the level of acceptable.

A single or two tone to the mic input showed a low IMD about -10DBc and a carrier that 
ever got below the -25dbc range for a stay state signal.   if it was keyed it had artifacts
on start and end of the signal.  One thing noticed despite playing with PWM filter there
was very wideband lobes every 32khz out more than 300khz either side of carrier.
Best I got them to was about 40db down.    On the Watt meter it looked acceptable
but local contacts despite software tweaks and various adjustments always resulted in
"What did you say? Its very distorted.".  So I tried a news station as audio source and
dummy load and listened to it and no matter the level, drive and other software
adjustments the signal had audio distortion that sounded like clipping (SSB into a
class C amp or an audio amp with blown output), and also audio artifacts such as
random noise during silent moments and odd noises while voice was there.   Close
study with the scope and my audio SA (spectrm on PC) suggested serious
amplitude and frequency granularity and significant phase errors.

That and the RX acquired a lot of tunable birdies even on dummy load, those were
not there running QCX software prior.  They came from the mpu running the fast
IO. The opposing SB rejection was also diminished but acceptable for testing.

Long story short.  Not viable.  I have returned to the QCX to original.  The EER
approach is not been a successful way to get SSB and consumed a lot of time
for not so much.   The EER (Kahn) approach has always excited interest when
it hits the surface only to yield nothing useful.

Allison






Steven Weber
 

 

 

Follow up and abandonment:

With working with it the level of TX distortion never made it to to the level of acceptable.

Allison

I changed the range of the PWM to get rid of the standing carrier. That helped a lot. I still want to try a better envelope reconstruction circuit, basically a LPF with a gain stage following it to drive the PA over the full range. I’ll use a rail to rail op amp with an emitter follower on the output so it can deliver enough current and only reduce the max supply voltage by 600 mv. Someday I’ll get around to it.

But I’m afraid your right, good idea, but not practical. Probably need a proper DSP chip clocking at 100 MHz to get acceptable, but still marginal results.

Steve KD1JV


_._,_._,_

 


ajparent1/KB1GMX
 

Steve,

I didn't list the things I tried like altering the PWM to get under .6V and playing
with the PWM to DC.  Standing carrier and sidebands were less a concern for
testing as the fact that it was unintelligible.  That was the stop here and find out why.

The problem in the frequency domain is you have voice in the range of 200 to 2200hz and 
multiple tones and the extraction just can't do it well enough that a 1100hz tone is 1100hz
higher(or lower) than carrier.  Mix that with envelope that does not follow well (out of phase)
and you get garbage.   

Also what no one noticed is the series pass device was getting hot as its dissipating
half the power, the fix is switch mode but that gets into the radio as noise and is
complicated to make work.  I cooked Q6 twice testing at half peak power, 200ma
and 6V across it was a bit (1.2W) too much.

Throwing more CPU gets to to the level of why not do real SDR.  The amount of hardware
does not go up as fast and the reproducibility does not.   More cpu can however do the
RX as well.  That buys you a lot less analog hardware to process the RX signal.

I liken it to Linvill-NonFoster matching.  Mathematically you can create a negative capacitor
or negative inductor but, go build a circuit that creates that....  Then you find out about the
20 papers that talk about stability and how that is hard it is to make it stable.    I enjoy
projects like that as you learn just because the model works, real parts just don't.   

Allison





Steven Weber
 

 

I did a similar thing years ago to make a non-SSB PSK transmitter. I detected the PSK envelope generated by the sound card and AM modulated a BS170 PA. It took a well heatsinked power transistor to do that and get 5W out. A zero crossing detector changed the phase using an XOR gate driving the BS170’s. It sort of worked. Turned out I wasn’t doing the phase shift right, but the decoder didn’t really care, so I wonder if the phase shift was really needed at all. But that was taking across the room, not to a distant station.  The envelope detector optimized for a 1 KHz tone so it required manual tuning, not very practical.

 

A better way was to use a MEAG48 -processor to directly input a keyboard and generate the proper PSK phase shifts and create the envelope with an A/D converter. But it still had the manual tuning problem.

 

Steve KD1JV   

 

Steve,

Also what no one noticed is the series pass device was getting hot as its dissipating
half the power, the fix is switch mode but that gets into the radio as noise and is
complicated to make work.  I cooked Q6 twice testing at half peak power, 200ma
and 6V across it was a bit (1.2W) too much.


Allison



 


ajparent1/KB1GMX
 

Steve,

I remember what you published about that.

I tend to go back to what some call first principles and ask are we trying to do
something tried before... A little research often answers with yes, and it was 
{good|bad} result.

Allison


Jerry Gaffke
 

The attraction of this EER stuff is that you get a class E amp at 95% efficiency transmitting SSB.
If you can get it to work.
Good luck doing that with SDR and a linear amp.

Getting it to work likely means faster updates into the PLL than the i2c bus can handle.
And as you say, lots more horsepower on the uC, and a better way to modulate that class E amp.

Having something almost work when starting with a CW transmitter
and making almost no hardware mods is already pretty amazing.
At least it gives an easy to understand blueprint of how to proceed.

Jerry, KE7ER



On Sun, Feb 24, 2019 at 02:53 PM, ajparent1/KB1GMX wrote:
Throwing more CPU gets to to the level of why not do real SDR. 


Kārlis Goba
 

As per 'first principles' mentioned by Allison, here's a good deal of read. Cândido Duarte's PhD thesis 'High-Efficiency Linear Transmitters for Mobile Communication Systems':
https://sigarra.up.pt/fcup/pt/pub_geral.show_file?pi_doc_id=25850

In particular section 2.3 regarding polar transmitters, including the EER method, and an analysis of their drawbacks (high bandwidth, linearity requirements etc). 

There are other interesting mentions there, the LINC architecture, and his proposed C-P architecture. I envisioned something similar to Fig 4.1 after contemplating on Guido's post. The architecture of Fig 4.1 could be viable for an efficient class-E SSB HF transmitter, where I and Q signals are generated (amplified/supplied) by a class D or Buck stages. 

--
Karlis YL3JG