Hans,

On Wed, Nov 16, 2022 at 09:24 AM, Paul WB6CXC (wb6cxc.com) wrote:

Putting together my external mixer test setup has inspired me to add a digital mixer function to my little frequency counter design

Honestly, I'm not trying to blog-pimp here, but if anyone is interested in how the digital mixer function works I just added a post: http://wb6cxc.com/?p=275
 
--
Paul Elliott - WB6CXC

[shifting a conversation from the "QDX Heat and Mod" thread to here] 

Thank for the feedback. That means the error still present! I have ver3 with 1_05 but never run the test (by the way I have also an SA44 analyzer).

When you have time to redo the measurements it will be nice if you can quantize the errors due to this bad frequency shift! If it say 1% than not bother about it.

Interesting subject. Maybe Hans could say more if it is interesting for him?!

 

73 de YO3FFF

Cristi

The amount of error in the WSPR FSK modulation is significantly greater than 1%.  I'm measuring frequency step errors that are +/- 50% in some cases.  Here is a test that shows this (the "Frequency 42.7 Hz"  is the difference between the QDX output and my mixer frequency, but the step spacing shown is accurate):


As you can see, the error is more in the nature of a quantization error, as all steps are not equally affected.  The best way to see what is going on would be to run a slow audio frequency ramp into the QDX and see what the output frequency steps look like.  Using the WSPR tones only lets us see the results at a few discrete audio frequencies.  

I assume Hans knows what is going on, so the only reason I continue to look into this is because it's interesting.  Putting together my external mixer test setup has inspired me to add a digital mixer function to my little frequency counter design -- it now has a Numerically Controlled Oscillator (as a VFO) and a digital mixer (just a flip-flop) so I can measure low-speed FSK or oscillator drift with extreme accuracy without resorting to the external RF mixing gear.  These new features all fit inside the FPGA I am using, so it's just a matter of Verilog (a Hardware Description Language) coding.  I got it working last night, and now just need to clean it up.  Since my counter can use an external reference clock (OXCO or GPSDO) the accuracy is good.  The time resolution is still just 10ns, so that's the ultimate limit on resolution.--
Paul Elliott - WB6CXC

I have made some QDX modulation measurements that show and measure the type of frequency error that Glenn has seen,  My blog post describes the QDX assembly, a simple spectrum plot, and shows the several ways I was able to measure QDX (and my own project's) FSK WSPR modulation.  I'm using a down-conversion mixer and a reciprocal counter to get 0.000025 Hz frequency resolution (with measurement rate of 25 Hz), so I show some quite accurate deviation data. 

BTW, all of the gear I used to do this high-resolution / fast frequency measurement is homebrew, and other than my reciprocal counter it's all quite simple.

Here's the blog post:   http://wb6cxc.com/?p=244


--
Paul Elliott - WB6CXC

Booted the Orange Pi Zero 2 with a Debian server image, did an 'suds apt install wsjtx', logged
into the Zero and found the DISPLAY variable wasn't set (odd). I ran 'ssh -X orangepizero2.local'
so it should have been set. Checked the zero's ssh_config, X Forwarding is set to yes. Seems if
I want to run remotely I need author AND a .Xauthority file. I installed author and copied my
.Authority file from a working system. I reran the 'ssh -X gormandizer2.local' command
and now I have the DISPLAY correctly set (local:10.0). BTW, manually setting the DISPLAY doesn't
help. It's just a side effect of the missing xauth and .Xauthority file. Once I did that wsjtx
started right up. Now I just need to hook up an HF transceiver to an antenna and the wsjtx to
the transceiver and I can play.

Still building the QDX. Also looking for my kill-o-watt meter.

--
Linux Home Automation Neil Cherry kd2zrq@...
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
Author of: Linux Smart Homes For Dummies KD2ZRQ

On 10/24/22 10:30, Neil Cherry wrote:

On 10/24/22 09:43, Rob - KC4NYK wrote:

Correction on the Zero - it may have been the memory rather than clock speed as 1 gHz should be plenty but the 512 m memory as opposed to 1 gig could be the bottleneck. Ya think?

That might be trouble. Still going forward. I like the idea of a little transceiver with a
little computer. The Antique Radio guys would have a good laugh when they see it. :-)

I couldn't get the Pi Zero 2 W yet so I picked up 2 Orange Pi Zero 2.
It has 1G of memory and lots of gizmos and gadgets. Will be a while
before I'm setup and the QDX is a work in progress. I'll see if I can
find my Kill-o-watt meter and see how much power it uses (Orange Pi,
QDX and combined). I'll hook it up with a dummy load. I'll also need
to figure out if I can use the existing Pi code or if I need to compile
my own. Betting I'll need to cross compile my own.

--
Linux Home Automation Neil Cherry kd2zrq@...
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
Author of: Linux Smart Homes For Dummies KD2ZRQ

WRT (1), that is excellent news. I suspect that your GPSDO, GPS already needed for time synch and some extra FW can accomplish it, but as you say, it's yet another task in your workload.  (1) is a bit off topic and, as Rob has suggested deserves its own topic.

WRT  (2),  I'm very pleased to hear of your interest and like you I  am cautiously optimistic that some additional math library precision in Si5351 setting may solve it fabulously. 

If there's anything I can do to help on either of these, perhaps remeasuring at UHF or something else, please let me know and I'd be glad to try.

Best,
Glenn n6gn
Fort Collins, Colorado, USA

On 10/24/22 09:43, Rob - KC4NYK wrote:

Correction on the Zero - it may have been the memory rather than clock speed as 1 gHz should be plenty but the 512 m memory as opposed to 1 gig could be the bottleneck. Ya think?

That might be trouble. Still going forward. I like the idea of a little transceiver with a
little computer. The Antique Radio guys would have a good laugh when they see it. :-)

--
Linux Home Automation Neil Cherry kd2zrq@...
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
Author of: Linux Smart Homes For Dummies KD2ZRQ

On 10/24/22 09:35, Rob - KC4NYK wrote:

Neil,
I got the deb file to install and run on my Pi Zero but you need the deb file marked for RPi4 on the "way back machine" archive page (see my earlier posts on this).
I had tried the one for the Pi3 but it didn't install and then noticed the "u" in the filename. Ha! it WAS on a Pi - but running Ubuntu! Switched to the Pi4 deb file and it complained about not having libfortran. . . installed that - bada bing!

Yup, little things like that are annoying.

Having installed it on the Zero I found it was just not fast enough to operate smoothly so I am running it successfully on a 3+ year old Pi 3 something.
Good Luck,

Thanks

I wonder if the Pi Zero 2 W could keep up? Unfortunately it's pure unobtainium at this time.
I'll see what SBCs I have. I'll look into static compile. The other SBC are similar to the
Raspberry Pi but not exact.

--
Linux Home Automation Neil Cherry kd2zrq@...
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
Author of: Linux Smart Homes For Dummies KD2ZRQ

Correction on the Zero - it may have been the memory rather than clock speed as 1 gHz should be plenty but the 512 m memory as opposed to 1 gig could be the bottleneck. Ya think? 

Cheers, RT

Neil,

I got the deb file to install and run on my Pi Zero but you need the deb file marked for RPi4 on the "way back machine" archive page (see my earlier posts on this).

I had tried the one for the Pi3 but it didn't install and then noticed the "u" in the filename. Ha! it WAS on a Pi - but running Ubuntu! Switched to the Pi4 deb file and it complained about not having libfortran. . . installed that - bada bing!

Having installed it on the Zero I found it was just not fast enough to operate smoothly so I am running it successfully on a 3+ year old Pi 3 something.

Good Luck,

Rob, KC4NYK

Upconversion accuracy shows a cyclic patten with WSJT-X baseband  frequency.

There is a repeatable, cyclic error of up to +/- 0.4 Hz in the QDX upconversion from WSJT-X baseband (in this case WSPR) to RF at 14.097 MHz, see figure below.

• It is not an issue with temperature rise on transmit affecting the TCXO. Down-frequency and up-frequency measurements between 1590 and 1600 Hz several times showed the same consistent cyclic pattern. For these measurements the supply voltage was reduced to 7 V (for a 12 V QDX). RF output was about 0.5 Watt into a dummy load.
• The mean offset between the expected RF frequency (dial frequency of 14.0956 MHz plus baseband frequency) and the RF frequency measured by a KiwiSDR with a mini-Bodnar GPSDO clock running WsprDaemon v3.0.4 that logs decoded frequency to the full 0.1 Hz resolution provided by the wsprd decoder was -2.0 Hz.
• This mean frequency error was despite the QDX having been calibrated using the procedure in the manual at 10 MHz against an N6GN phase-locked GPSDO. Using WSJT-X's Frequency Cal mode the residual error at 10 MHz after calibration was -0.020 Hz, limited in part by the ability to only apply an integer Hz calibration.
• Observing the cyclic error does not need a GPSDO receiver, the points in red, which show the same cyclic behaviour, were from a separate KiwiSDR with its standard GPS aiding algorithm (not phase-locked) running KiwiSDR software after the v1.557 clock correction update.

It is possible that this error is related to, and shares the same root cause as, the frequency-setting error that is currently preventing the QDX being used for FST4W on the HF bands.

Gwyn G3ZIL

On Sun, Oct 23, 2022 at 02:58 PM, Rob Robinett wrote:

I appreciate your interest in my application, but it is really off topic for this thread.
SoI'll create a new thread about this topic where we can discuss it if you care to continue.

I'm certainly interested.  I'm working on a solar-powered beacon design as we speak.
 
--
Paul Elliott - WB6CXC

On 10/23/22 11:25, ajparent1/kb1gmx wrote:

Neil,
WSJT-X is more of same.  Lots of dependencies and at least one
modded library (hamlib).
I groan every time I have to install on a linux box as they can't seem to do
a package.

And there was an error in the instructions (at least with my Debian setup):

When compiling the hamlib, remove the --without-cxx-binding option from the
../src/configure command. Otherwise the jtdx compile will fail as it can't
find the cxx libraries.

There's a long list of dependencies such as asciidoctor, qt5 dev and many qt5
libraries and fortran.

--
Linux Home Automation Neil Cherry kd2zrq@...
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
Author of: Linux Smart Homes For Dummies KD2ZRQ

Hi Allison and Paul,

I appreciate your interest in my application, but it is really off topic for this thread.
SoI'll create a new thread about this topic where we can discuss it if you care to continue.

Thanks,

Rob

Rob,

The QDX would fit in the 10W if the power is dialed back (1.1A at 9V for 5W) but
adding a Rpi even a zero and GPS will put you over the top.  Rpi 3B+ uses easy
350ma idle (5V orabout 2W) and Rpi4D sucks down 1.25 A at full bore
(that's 6.25W @ 5V).  Zero would be better I've heard 100-200ma (about 1W).

I do this all the time. That is running stuff on solar.  Save for here overcast
days are a common thing especially winter where at worse the sun angle
is maybe 20 degrees for a few weeks and useful sun is in the 4 hour range.
Life in FN42.

Allison
------------------
Post online only, please no email.

On Sun, Oct 23, 2022 at 08:47 AM, Rob Robinett wrote:

remote QDX solar powered WSPR beacon

Is this a transmit-only beacon?  If so, the QDX is huge overkill, needing at a minimum a RPi and a GPS.  There are much simpler lower-power solutions for transmit-only

 
--
Paul Elliott - WB6CXC