If I'm not mistaken, FSTW4, and certainly WSPR require time synchronization, and the QDX has no input that could be used for this other than perhaps the USB port.  If you don't want an attached computer, you would need to come up with a USB to network adaptor of some sort that would provide time-sync and network reporting.  That's essentially a computer.

Perhaps a QDX-v2 with an ethernet port?  C'mon Hans, how hard could that be? [/attempt_at_humor]  But a QRP Labs radio based on the QDX, that runs Linux and has a network interface at one end and an RF port at the other (like the Xiegu X6100 but without the bells and whistles) would be really useful.

 

 
--
Paul Elliott - WB6CXC

On Fri, Oct 21, 2022 at 05:30 PM, Paul WB6CXC wrote:

But a QRP Labs radio based on the QDX, that runs Linux and has a network interface at one end and an RF port at the other [...]

Sorry to keep going on about this, but the more I consider it the more I think that the QDX is just fine the way it is.  Sometimes we want a reasonable de-coupling of functions, and using a RPi for the network and software end of the solution seems like a perfect arrangement.  Yes, I know the RPi is currently unobtainable except at an insane price, but this situation won't last and once we get back to normal all we need is a good enclosure for the Pi/QDX combo.  Putting too many functions on one board, while cool, just leads to rapid obsolescence when the landscape is changing as rapidly as is now the case. 

And of course the QDX as it currently is, and the RPi are both in their way high-volume products.  Combining them on one board results in a much lower-volume product with much greater support issues.  Hans, don't do it!!!  But if you do, sign me up for the first one.
 
--
Paul Elliott - WB6CXC

Hi Paul,

You are correct about the time sync problem.  There are of course USB ethernet adapters, but some of the most interesting WSPR sites are very remote and thus have no Internet access.  However the GPS system of the U3S might provide both time and a way to GPS-aid the QDX's TCXO at modest cost.  

I have spent 4 years working on the WSPR receive system, so perhaps I need to turn my attention to WSPR tx ;=)

Rob

On 10/21/22 21:26, Paul WB6CXC wrote:

On Fri, Oct 21, 2022 at 05:30 PM, Paul WB6CXC wrote:
But a QRP Labs radio based on the QDX, that runs Linux and has a network interface at one end and an RF port at the other [...]
Sorry to keep going on about this, but the more I consider it the more I think that the QDX is just fine the way it is.  Sometimes we want a reasonable de-coupling of functions, and using a RPi for the network and software end of the solution seems like a perfect arrangement.  Yes, I know the RPi is currently unobtainable except at an insane price, but this situation won't last and once we get back to normal all we need is a good enclosure for the Pi/QDX combo.  Putting too many functions on one board, while cool, just leads to rapid obsolescence when the landscape is changing as rapidly as is now the case.
And of course the QDX as it currently is, and the RPi are both in their way high-volume products.  Combining them on one board results in a much lower-volume product with much greater support issues.  Hans, don't do it!!!  But if you do, sign me up for the first one.

I'm new to this so be gentle with the concrete clue bats (they're expensive to
replace). ;-)

How much CPU do you need, perhaps a Pi ZeroW? I'm not sure of the power load
but it would be less. Not sure but you might be able to get a USB to Ethernet
adapter.

Sometimes you don't need quad core and 8G of RAM.

Okay now you've gone and dunit! Now I have to order another QDX just to
see. :-)

--
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 21/10/2022 23:33, Rob Robinett wrote:

Developing such SW might be easy enough that I'll try it once I finish my never-ending wsprdaemon development work ;=)

Rob,

Thanks for that, I recently discovered it was easy to setup a pi4 and your daemon. (So far it ignores my FST4 .conf entries:-)

There was a bug in one WSJT-X version but I am running several instances for weeks before a Windows update forces me to restart.
The QDX is not stuck with WSJT-X, it will work with any suitable software.
I guess WSJT-X might be altered to provide a multimode schedule, maybe this suits a simplified fork rather than changing the whole program?

The hardware side of a TX WSPR/FST4 daemon will be relatively complex. The QDX might run a maximum of 4-5 bands depending on selection. I presume TX on all bands will be possible but 3 or 4 QDX would be required.
Perhaps we are talking of another TX-only version with more TX filters.

73 Alan G4ZFQ

Hans sells a standalone beacon:  http://shop.qrp-labs.com/U3S

It doesn't run FST4W yet but I am sure he is working on that as we speak along with the 50-100 other things he has going on ;-)

WSPR and FSAT4W transmission requires almost zero CPU.  One can calculate the series of output frequencies ahead of transmission and update the Si5351 every few seconds.
BUT WSPR, and especially FST4W-300 and longer, requires extreme frequency stability over the 2 to 30 minute long packet transmission: FST4W-300 tones are spaced by 0.56 Hz and FST4W-900 tones are spaced by 0.180 Hz.  Both are useful transmission modes on 20M, but few commercial transceivers are that stable at 14 Mhz.
One of the many strengths of the QDX is that its TXCO *is* stable enough at least for FST4-300 transmissions on 20M, even without GPS stabilization.

I have received reports that WSJT-x just stops transmitting after 300-400 tx cycles.  It doesn't crash, it just stops.
Have you been able to run WSJT-x continuously *transmitting* WSPR for more than 300-400 transmission cycles?

I own several U3S but they seem a poor candidate architecture for upgrade to FST4W.
One of the many attractions of the QDX is the 5W power output.  That is a 14 dB increase in power level above many low cost beacons.
When combined with the 2 dB to 13 dB greater sensitivity of the FST4W modes, the resulting 16 to 27 dB improvement in transmission efficiency may uncover previously unobserved HF propagation events.

On 22/10/2022 13:58, Rob Robinett wrote:

Have you been able to run WSJT-x continuously *transmitting* WSPR for more than 300-400 transmission cycles?

Yes, two QDX at 17-20%. Around 140 TX periods of WSPR2 each per day.
Runs continuously for weeks. v2.5.4
WSJT-X is regularly updated, yes, there were reports of possibly just one version stopping but that does not seem to have been reported recently.

Note that the QDX PA is compact, can get hot. Long periods of 5 Watts might reduce reliability. Also reputed to be sensitive to mismatch.

73 Alan G4ZFQ

On Sat, Oct 22, 2022 at 06:37 AM, Rob Robinett wrote:

WSPR and FSAT4W transmission requires almost zero CPU

Yes, but that's for a standalone beacon (the QRP Labs U4B (https://www.qrp-labs.com/u4b.html) is a great example, and it includes a GPS receiver.  But the QDX uses an audio input and output (via USB), and at each end that's a bit more complicated.  You need a program like WSJT-X to generate the tx (and decode the rx) audio signals.

This is where the RPi comes in.   I think that the Pi-Zero will do that job.  I'm currently using RPi-Bs running JS8-Call for receive-only internet gateways at 7 and 10 MHz, and I'm using RTL-SDR dongles for the receivers (using SDR direct-sampling mode, so there's no I/Q output, just a single phase) .  The RPi has to run the DSP demodulator code and a bunch of other stuff to send the demodulated audio to JS8-Call.  So if the RPi only needs to host WSJT-X and perhaps a USB-GPS and/or ethernet for internet interface that's not too tough.

The critical thing that the RPi provides is a Linux OS (and a PC provides a Win OS), so we can run a wide variety of WSJT-X-style programs.  Most of these programs assume a soundcard audio interface and serial radio-control interface, and the QDX provides these.  This is why I like the decoupling of functions -- it gives us easy flexibility.

If you're curious about my SDR/RPi gateways, here's my ham-club presentation: http://wb6cxc.com/wp-content/uploads/2019/04/Presentation-1-0.pdf

--
Paul Elliott - WB6CXC

if a STM32F4xx can do it then a RPI-0 can.  Both being 32bit they have an advantage
for memory and math intensive operations.

An Arduino (atmega328 or atmega4809) is both 8bit and 20mhz max so its going to struggle at that
kind of task.

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

Stand alone, solar powered WSPR and FST4W beacon mode is the application of interest to me.
As you say, for all the many other applications of the QDX, its current implementation which utilizes a Pi or other SBC is of course the optimal architecture.

I've compiled jtdx on my large dev machine and jtdx is a dependency pig. I'll need to try
and figure out what it needs (lots of QT5 stuff). I haven't cross compiled it for the Pi Zero W
yet. I'll also need to see if compiling it static is reasonable.

I'll try to write up my notes on this as I go.

--
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

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. 

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

Rob,

Define solar powered?  That is what power level what source
power any battery backup for the dark hours/days?

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

I have been running several solar powered WISP relay sites in Maui and in Northern California which each consume about the 10W which would be roughly what I expect a remote QDX solar powered WSPR beacon site to consume. Assuming worst case cloudy winter days, the battery system would need to supply 16 hours * 10W == 160 WH, which is half of the capacity of the $75 12V/35AH AGM batteries I have used without needing maintenance (or even a site visit!) for 2+ years.
So that is the kind of power supply system which I envision for the QDX.

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

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.

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