This subject has been raised before,? [
/g/QRPLabs/topic/94416795#94434? ] smaller frequency
shifts than WSPR not being transmitted correctly.

I attach 2 shots, one a Softrock/WSJT-X and A QDX/WSJT-X.
While due to a hardware mod I can only use my version 1 QDXs with the
1.02 firmware it shows similar to a previous post.

Has this been rectified since October 18? I see no note of this in the
1.06 firmware.

73 Alan G4ZFQ

V1.06 installed (quick and easy! -- Thanks, Hans!)

But as expected, the fine-frequency setting still exhibits the problem.? Whether the QDX emits two or three tones during FST4W-300 operation probably depends on where the tones fall within the set of tones?"achievable" with the current algorithm.
--
Paul Elliott - WB6CXC

On Nov 30, 2022, at 11:06 AM, Hans Summers <hans.summers@...> wrote:

Hi Paul, all

I worked on this problem this afternoon. Solved in Beta 1_06_005?

First step, reproduce the problem. To do this I used two QDX. My "Franken-QDX" Rev 3a having the Rev 4 mods and connected VGA monitor and PS/2 keyboard as the transmitter (dummy load); For reception, my 10-20m high-bands QDX prototype on 20m band. Testing at 14.044 for no good reason other than that was where the equipment was set up. I generated a 60 second audio clip in audacity with a linear sweep from 1000 to 1010Hz, and fed this audio to the transmitting QDX with VOX enabled. The receiving QDX audio was analyzed in Argo set to 10s QRSS mode and Fast speed. Results are as attached before.png which shows a few attempts to get a clean shot. It's a perfectly similar result to what Paul reported.

Many hours later...

Turns out there are THREE causes of the problem. Floating point accuracy is the first one, the major one, which hides both the others; but all three need to be solved to get fine-resolution transmit frequency control.?

1) A bug: the floating point frequency was passed into the Si5351A transmit configuration function where it was used as a floating?point number; but the actual parameter declared as an unsigned 32-bit integer. Dumb. This limits the transmit resolution to 1Hz. Resolving this was easy of course.?

2) Frequency shift threshold introduced to help the "popping" problem; remember that Rev 3 and Rev 3a boards suffer this "popping" sound in the transmit audio? That was solved by a combination of various strategies in firmware version 1_04. Each of the strategies didn't eliminate the pops but reduced them; one of these strategies was to reduce the amount of frequency updates to the Si5351A (100 times per second by default) by setting a 0.5Hz threshold; the frequency had to shift more than this amount in order for the Si5351A to be configured to a new frequency. This threshold itself had another bug which was covered up by the bug mentioned in 1) above.?

I resolved the bug easily; and I have created a new parameter on the Configuration screen called "TX shift threshold" which defines the shift threshold in milli Hertz and defaults to 500. More any mode such as WSPR and FT8 whose frequency steps are larger than 0.5Hz this would be fine; for modes with narrow-spaced frequency steps less than this, you could reduce it as needed.?

For anyone with a Rev 4 PCB, the popping problem was totally eliminated in hardware so setting 0 threshold is fine.?

3) Finally the main issue is one of floating point accuracy; if you have a frequency such as 14,044,000 USB Dial Frequency such as in my tests, then a frequency shift of 0.1Hz on this is just too small a fraction and single precission?IEEE 754 cannot represent it accurately enough in the calculations of Si5351A parameters. The significand is 24-bit which is roughly equivalent to 7 decimal digits see?

To solve this I could have simply changed the relevant parts of the code to use double precision floating point representation. I am sure this would have worked. However this could not then have used the STM32F4 microcontroller's hardware floating point unit which is only single precision IEEE 754. So it would have compiled in some double precision?floating point library presumably. Which would probably have been large, probably been slow to execute (both of which could potentially have created new problems) and definitely been about as elegant as a troll swinging a sledgehammer in a glassware shop.?

So instead I devised some careful tricks to let me use regular single precision floating point and 32-bit integer arithmetic and handle the main USB dial frequency and the audio offset as two separate components. The result should be that the frequency steps are now precise to better than a one millihertz resolution, which is about the accuracy of the audio cycle measurement on the incoming USB audio stream from the PC.?

Now the results are shown in attached "after.png" which shows the 10Hz, 60 second sweep with three settings of "TX shift threshold": 0.5Hz (500mHz the default); 2Hz (2000mHz) and 0Hz. 0Hz is run twice in the image. Note that the line thickness is a little variable, this is because between the transmitting QDX and receiving QDX there is no direct coupling, just leakage from the dummy load to my antenna.?

I believe this will comprehensively solve the problem and Paul I will be very interested if you re-run your tests on this beta version.?

Clearly QDX works extremely well already; however I do believe that use of this improved firmware version should be recommended for everyone (once I release an official 1_06, after a few people confirm there are no unintended issues with the beta version). Improved accuracy of the transmitted frequency does result in increased probability of decode, particularly under DX circumstances or other weak conditions.?

Thusly expired my Wednesday...

73 Hans G0UPL

On Wed, Nov 30, 2022 at 6:12 AM Paul WB6CXC (tech-blog:?) <paul@...> wrote:

First:? I think the QDX is a brilliant piece of engineering and a great little transceiver.? I have one, and have just ordered two more for use in "network base station" operation.? My interest in the frequency-setting issue is mostly because it's a topic I find interesting, and there are some modes I am exploring where this issue (soon to be corrected, I hope) will be a problem.? Most people using the QDX will neither notice, or care about this issue -- the rig will just work for them.

So I finally set up an audio frequency ramp feeding the QDX USB input channel.? Output frequency measurements were made with my home-brew counter.? The displayed frequencies are after down-conversion in my counter, the absolute values are arbitrary and what matters is are the frequency differences.? I was using a Windows program called "NCH Tone Generator" to create the frequency sweeps.
First, to check the sweep itself, I sent the audio to my IC-7200 transceiver, set for 20 meters.? This is a slow sweep, 1000 Hz - 1010 Hz, taking 60 seconds:
<IC7200 20m sweep 1000-1010.png>
There is measurement noise, but the frequency ramp appears to be smooth.

Then I sent the same audio sweep to the QDX, on 20 meters:
<QDX 20m sweep 1000-1010.png>
You can see that there are nine frequency steps over the 10 Hz range, each step roughly 1.25 Hz.? It is obvious that this will not work with the 1.46 Hz steps used in FST4W-120, and will cause some frequency error with the?1.4648 Hz steps used in WSPR.

Things got slightly better on the 30 and 40 meter bands, on 40m there were eleven steps (per 10Hz), but while I had expected better frequency resolution here, strangely the steps were less even than the 20m band:? The 30m band also showed eleven steps, although the spacing distribution was somewhat different.

40 meters:
<QDX 40m sweep 1000-1010.png>

Fractions are funny things, and perhaps if I had tried other audio frequencies the results would have been a bit different.

Finally, I set the audio sweep for 1000 - 1100 Hz, this time on the 10-meter band:
<QDX 30m sweep 1000-1100.png>
While the steps were uneven, there were no major discontinuities over this 100Hz range

So there you have it.
--?
Paul Elliott - WB6CXC

<before.png><after.png>