FST4W with v3.0.4 on Pi4


Alan G4ZFQ
 

Hi,

I recently setup v3.0.4 on a Raspberry pi4, 2GB to use with my Kiwi.
For the last week it has run well on 7 bands.

I decided to add some FST4W
which was accepted and -s showed
G4ZFQ_1,2200,W2:F5:F15: G4ZFQ_1,2200 recording Pid = 11376

G4ZFQ_1,630,W2:F5: G4ZFQ_1,630 posting Pid = 11017
G4ZFQ_1,630,W2:F5: G4ZFQ_1,630 decoding Pid = 11092
G4ZFQ_1,630,W2:F5: G4ZFQ_1,630 recording Pid = 11537

G4ZFQ_1,160,DEFAULT: G4ZFQ_1,160 posting Pid = 11127
etc

W2 decoded, no FST4. I sent a local F5 transmission, it decoded on separate RX but not on Kiwi.
I reduced .conf to just one F5 but still no decodes.

Probably something I missed?
The pi does not seem too stressed, can it decode FSTW?

73 Alan G4ZFQ


Rob Robinett
 

Hi Alan,

I better reply before the groups.io goes down for an hour ;=)

Yes, your Pi4 has plenty of CPU for your configuration.  I have been working on a high resolution SNR and frequency enhancement which could have broken 4W decoding, but I have only two 4W test signals on 20M: 5W N6GN from Colorado and .02W KD2OM from New York and 20M is not yet open to either of them from here in California.

If I haven't broken the current 3.0.4, are you sure of your Kiwi's oscillator accuracy?  It is much less critical at 2200 and 630, but tracking 8 or more GPS satellites gets the Kiwi accurate and stable to .015 Hz at 14 MHz.

Rob



Glenn Elmore
 

In case this beats the .io server downtime...

If you are also able to spot yourself on an instance of WSPT-X, you can arrange to have it report the spreading it sees. to the console. -300 will want a  total system spreading budget below ~700 mHz, or so in order to decode. The total  upconversion LO (tx), path and downconversion LO (rx) components need to keep your spreading budget below this value. Across the bench path value should be essentially zero but either of the LOs may be high.

A quick check might be to simply drop back to -120 where the budget limit is more like that of WSPR to see if this is the problem.

See http://wsprdaemon.org/ewExternalFiles/FST4W_on_HF_bands_V1-3.pdf for details.

Glenn n6gn

On 10/22/22 07:53, Rob Robinett wrote:

Hi Alan,

I better reply before the groups.io goes down for an hour ;=)

Yes, your Pi4 has plenty of CPU for your configuration.  I have been working on a high resolution SNR and frequency enhancement which could have broken 4W decoding, but I have only two 4W test signals on 20M: 5W N6GN from Colorado and .02W KD2OM from New York and 20M is not yet open to either of them from here in California.

If I haven't broken the current 3.0.4, are you sure of your Kiwi's oscillator accuracy?  It is much less critical at 2200 and 630, but tracking 8 or more GPS satellites gets the Kiwi accurate and stable to .015 Hz at 14 MHz.

Rob



Glenn Elmore
 

I should add that if you are using GPS-aiding on the Kiwi and also a version of SW newer than 1.556 ( I think that's when the fix went in, but just use the newest and you should be fine) then I would suspect your transmitter LO first. FST4W doesn't have either the long term (drift) or short term (higher offset phase noise) tolerance of WSPR2. Unwanted phase noise (lumping it all together) can break the budget.

On 10/22/22 08:17, Glenn Elmore wrote:
The total  upconversion LO (tx), path and downconversion LO (rx) components need to keep your spreading budget below this value.


Glenn Elmore
 

Furthermore (I am just now discovering it)  make sure you use a legitimate callsign in your transmitter (WSJT-X) setup.  Do NOT use anything like "G4ZFQ/4"  but only straight "G4ZFQ" in order to prevent splitting the message into two transmissions.  Decoding these Type2  presently doesn't seem to be working in WD.

Glenn n6gn

On 10/22/22 08:22, Glenn Elmore wrote:
I should add that if you are using GPS-aiding on the Kiwi and also a version of SW newer than 1.556 ( I think that's when the fix went in, but just use the newest and you should be fine) then I would suspect your transmitter LO first. FST4W doesn't have either the long term (drift) or short term (higher offset phase noise) tolerance of WSPR2. Unwanted phase noise (lumping it all together) can break the budget.


On 10/22/22 08:17, Glenn Elmore wrote:
The total  upconversion LO (tx), path and downconversion LO (rx) components need to keep your spreading budget below this value.


Alan G4ZFQ
 

On 22/10/2022 13:53, Rob Robinett wrote:
are you sure of your Kiwi's oscillator accuracy?  It is much less critical at 2200 and 630,
Rob,

This is on 630.
I will try -120

73 Alan G4ZFQ


Rob Robinett
 

After starting WD it can take up to 3 WSPR cycles before a decode is first posted. 

On Sat, Oct 22, 2022 at 7:48 AM Alan G4ZFQ <alan4alan@...> wrote:
On 22/10/2022 13:53, Rob Robinett wrote:
>are you sure of your Kiwi's
> oscillator accuracy?  It is much less critical at 2200 and 630,

  Rob,

This is on 630.
I will try -120

73 Alan G4ZFQ








--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Bo, OZ2M
 

Hi

Question about type 2 messages - Steve, KD2OM, recently asked if I could implement Type 2 in FST4W for the RFzero. Erwin, PE3ES/F4VTQ, was lukewarm about the idea. Personally, I don't have strong feelings about it. Should og shouldn't I do it?

Bo
www.rudius.net/oz2m :: www.rfzero.net


Rob Robinett
 

type 2 messages carry tx call signs which are longer than 6 character or include '/' and perhaps some other special characters.  As such, they are potentially useful but since they don't carry a maidenhead locator they depend upon a subsequent type 3 for that information.  But WD has problems with FST4W type 3 messages due to limitations in the jt9 decode command included in WSJT-x and used by WD.

Since the type 3 message includes only the hashed version of the tx station's call sign and the way WD is forced to use jt9 means that jt9 can't resolve the call for hashed call signs.  So those type 3 packets are tossed by WD and wsprnet.org appears to toss type 2 messages unless they are followed by a type 3 report.

So because of those decode problems with FST4W type 2 and type 3 messages, I suggest that tx sites avoid generating them


On Sat, Oct 22, 2022 at 7:55 AM Bo, OZ2M <groups.io@...> wrote:
Hi

Question about type 2 messages - Steve, KD2OM, recently asked if I could implement Type 2 in FST4W for the RFzero. Erwin, PE3ES/F4VTQ, was lukewarm about the idea. Personally, I don't have strong feelings about it. Should og shouldn't I do it?

Bo
www.rudius.net/oz2m :: www.rfzero.net







--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Glenn Elmore
 

I'd put having type2 transmission support on FST4W pretty far down on the list of things to do. Bo, you've already got *so* much code in the RFZero already!   Also I did have a look at the code and also  found in measurement that the step transition between symbols wasn't causing much extra spreading on 20m FST4W -300  .  I think the RFZero is quite usable on FST4W HF as it stands.

I'd only suggest that anyone transmitting FST4W use only a valid amateur call sign and we should all be aware of the problem(s) created when that isn't done.  I suppose this limits people from identifying their particular transmitter, in the case of several on a same band, and requires the use of frequency or reported power field to ID them. 

As long as we all know about it, I don't think the lack of transmitter and WD support for Type2 on FST4W  is too big a problem.  I'd say work on something more vital 😁

Glenn n6gn

On 10/22/22 09:09, Rob Robinett wrote:

type 2 messages carry tx call signs which are longer than 6 character or include '/' and perhaps some other special characters.  As such, they are potentially useful but since they don't carry a maidenhead locator they depend upon a subsequent type 3 for that information.  But WD has problems with FST4W type 3 messages due to limitations in the jt9 decode command included in WSJT-x and used by WD.

Since the type 3 message includes only the hashed version of the tx station's call sign and the way WD is forced to use jt9 means that jt9 can't resolve the call for hashed call signs.  So those type 3 packets are tossed by WD and wsprnet.org appears to toss type 2 messages unless they are followed by a type 3 report.

So because of those decode problems with FST4W type 2 and type 3 messages, I suggest that tx sites avoid generating them


On Sat, Oct 22, 2022 at 7:55 AM Bo, OZ2M <groups.io@...> wrote:
Hi

Question about type 2 messages - Steve, KD2OM, recently asked if I could implement Type 2 in FST4W for the RFzero. Erwin, PE3ES/F4VTQ, was lukewarm about the idea. Personally, I don't have strong feelings about it. Should og shouldn't I do it?

Bo
www.rudius.net/oz2m :: www.rfzero.net







--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Bo, OZ2M
 

Indeed there is a lot of code available for the RFzero. I am in front of my PC right now working on the RFzero Manager and a WSPR GUI. I do have ideas for at least two more programs for the RFzero. I can't help it. Besides those programs I have also identified

- FST4W type 2 message. Should not be a big deal either since I have already done it for WSPR

- Erwin, PE3ES/F4VTQ, asked me some time ago about the FST4W symbol hard FSK vs. Gaussian FSK. I have already done something similar for the DB0HRF beacon on 2 m for PI4. So it shouldn't be to difficult even if it is an Si5351A synthesizer instead of an AD9912 DDS. As far as I remember Bill, G4WJS, wrote that FSK into the WSJT-X FST4W GFSK decoder is not an issue. So I took the fast track, which was good enough in the days, when FST4W was new and seldom used

- FST4W GUI, will await the WSPR GUI

I have experienced the issues associated with the Type 2 and Type 3 messages in WSPR. Type 2 will work with a database. But Type 3 should never have been invented.

Bo
www.rudius.net/oz2m :: www.rfzero.net


KD2OM
 

My only reason for bringing up the type 2 message is that the FST4W configuration shows it and it wasn’t working. There is no need to implement it and certainly no priority to fix it. 

73
Steve KD2OM

.
 

On Oct 22, 2022, at 11:31, Glenn Elmore <n6gn@...> wrote:



I'd put having type2 transmission support on FST4W pretty far down on the list of things to do. Bo, you've already got *so* much code in the RFZero already!   Also I did have a look at the code and also  found in measurement that the step transition between symbols wasn't causing much extra spreading on 20m FST4W -300  .  I think the RFZero is quite usable on FST4W HF as it stands.

I'd only suggest that anyone transmitting FST4W use only a valid amateur call sign and we should all be aware of the problem(s) created when that isn't done.  I suppose this limits people from identifying their particular transmitter, in the case of several on a same band, and requires the use of frequency or reported power field to ID them. 

As long as we all know about it, I don't think the lack of transmitter and WD support for Type2 on FST4W  is too big a problem.  I'd say work on something more vital 😁

Glenn n6gn

On 10/22/22 09:09, Rob Robinett wrote:
type 2 messages carry tx call signs which are longer than 6 character or include '/' and perhaps some other special characters.  As such, they are potentially useful but since they don't carry a maidenhead locator they depend upon a subsequent type 3 for that information.  But WD has problems with FST4W type 3 messages due to limitations in the jt9 decode command included in WSJT-x and used by WD.

Since the type 3 message includes only the hashed version of the tx station's call sign and the way WD is forced to use jt9 means that jt9 can't resolve the call for hashed call signs.  So those type 3 packets are tossed by WD and wsprnet.org appears to toss type 2 messages unless they are followed by a type 3 report.

So because of those decode problems with FST4W type 2 and type 3 messages, I suggest that tx sites avoid generating them


On Sat, Oct 22, 2022 at 7:55 AM Bo, OZ2M <groups.io@...> wrote:
Hi

Question about type 2 messages - Steve, KD2OM, recently asked if I could implement Type 2 in FST4W for the RFzero. Erwin, PE3ES/F4VTQ, was lukewarm about the idea. Personally, I don't have strong feelings about it. Should og shouldn't I do it?

Bo
www.rudius.net/oz2m :: www.rfzero.net







--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Glenn Elmore
 

"uforbederlig"?  😁

The present RFzero must be pretty good on FST4W as-is. I think I may have already mentioned that I streamed audio from Steve's Kiwi at KD2OM, receiving his local RFzero on a Kiwi, then used it here with a GPSDO upconverter to locally regenerate the 20m signal in real time - followed by examination of the 33rd harmonic as well as a FST4W decode and found it to not have hurt the reported spreading number.  Gaussian shaping will probably reduce the "key clicks" from the sudden transitions such that locals might no longer hear them (if they even can) but unlikely to be much of a big deal. That's my guess anyway. Paul, WB6CXC did an analysis to show the expected effect.  I don't think it is going to matter much to anyone.


On 10/22/22 09:58, Bo, OZ2M wrote:

Indeed there is a lot of code available for the RFzero. I am in front of my PC right now working on the RFzero Manager and a WSPR GUI. I do have ideas for at least two more programs for the RFzero. I can't help it. Besides those programs I have also identified

- FST4W type 2 message. Should not be a big deal either since I have already done it for WSPR

- Erwin, PE3ES/F4VTQ, asked me some time ago about the FST4W symbol hard FSK vs. Gaussian FSK. I have already done something similar for the DB0HRF beacon on 2 m for PI4. So it shouldn't be to difficult even if it is an Si5351A synthesizer instead of an AD9912 DDS. As far as I remember Bill, G4WJS, wrote that FSK into the WSJT-X FST4W GFSK decoder is not an issue. So I took the fast track, which was good enough in the days, when FST4W was new and seldom used

- FST4W GUI, will await the WSPR GUI

I have experienced the issues associated with the Type 2 and Type 3 messages in WSPR. Type 2 will work with a database. But Type 3 should never have been invented.

Bo
www.rudius.net/oz2m :: www.rfzero.net







Alan G4ZFQ
 

On 22/10/2022 14:17, Glenn Elmore wrote:
See http://wsprdaemon.org/ewExternalFiles/FST4W_on_HF_bands_V1-3.pdf for details.
Glenn, Rob,

Thanks, I've had a look at that and find it interesting.
I did update my Kiwi so RX may be possible.

However, so far the Kiwi/Daemon has yet not decoded any FST4W on the lower bands when several locals were giving good SNRs. My ordinary WSPR decode SNRs compare well with locals.

I have done more checks on 630m, no FST4W F2 or F5 decodes. It does RX WSPR on 10m, so I would think that shows the Kiwi oscillator should be good enough for 630m?

If somehow the installation has been corrupted would updating to 3.0.5 rectify it?
As a newcomer to Linux innards I have to find out how to do a git pull:-)

73 Alan G4ZFQ


Gwyn Griffiths
 

Hello Alan
These are the FST4W spots I've received from you over the last 10 days - just these four this morning.
The mode=3 spots are FST4W-120 and the mode 6 is FST4W-300.
The good news is that your transmitter's spectral width is low, such that when added to the small spectral spreading of the KiwiSDR with external mini-Bodnar GPSDO the spectral width is under 24 milliHz. Your transmissions are fine.

tutorial=# select time,rx_id, mode, freq, "SNR", metric as "spectral width (mHz)" from wsprdaemon_spots_s where tx_call='G4ZFQ'   and mode >2 order by time desc limit 15;

        time         | rx_id | mode |   freq    |  SNR  | spectral width (mHz) 

---------------------+-------+------+-----------+-------+----------------------

 2022-10-24 10:24:00 | G3ZIL |    3 | 0.4757139 | -24.6 |                   16

 2022-10-24 10:20:00 | G3ZIL |    3 | 0.4757139 | -24.3 |                   15

 2022-10-24 10:18:00 | G3ZIL |    3 | 0.4757139 | -24.1 |                   19

 2022-10-24 10:05:00 | G3ZIL |    6 | 0.4757139 | -32.2 |                   24

(4 rows)


Is your wsprdaemon.config file set up to upload to wsprdaemon.org? Check the SIGNAL_LEVEL lines in the config file. I ask because I can't see any entries in the wsprdaemon_spots_s from you of your own transmissions. 
By the way, nice to see the frequency consistent to 0.1 Hz, and SNR to 0.1 dB thanks to Rob's updates in v3.0.5

best wishes

Gwyn G3ZIL


Alan G4ZFQ
 

On 24/10/2022 12:23, Gwyn Griffiths via groups.io wrote:
These are the FST4W spots I've received from you over the last 10 days - just these four this morning.
Gwyn,

Thanks for your comments. I have not transmitted much, I have left that for those with better setup antennas. I was using a LF Softrock with an Si570, good to know how it works.

Is your wsprdaemon.config file set up to upload to wsprdaemon.org?
No, I have not enabled upload to there, I did not know if it would be welcomed. I'll do that.
I am still getting around Linux and wsprdaemon, realising that the only brief record of spots on the pi (apart from the briefer pre upload one) was a record of wsprnet's accepted spots.
My tests of reception this morning have been using FST4W with a false call into a dummy load. You may have seen a WSPR report of G9ZFQ from me, but no FST4W modes.

I did set SIGNAL_LEVEL_LOCAL_GRAPHS="yes", package scipy was installed but it looks as if I need to do more.

73 Alan


Alan G4ZFQ
 

If your wsprdaemon install was done per the instructions then 'cd
~/wsprdaemon' should move you its directory and then 'git pull'
Thanks Glenn, easy, quick, v3.0.5:-)

But still no FST4W decodes. W2 fine.
Note there is a F5 signal to decode, and I have also provided one from a local TX.

declare WSPR_SCHEDULE=(
"00:00 G4ZFQ_1,2200,W2:F5:F15 G4ZFQ_1,630,W2:F5 G4ZFQ_1,160 G4ZFQ_1,80 G4ZFQ_1,40 G4ZFQ_1,30 G4ZFQ_1,22 "
)

Seems to be the only entry concerning FST4W, I've tried various configurations including 630 on its own.

I shall rename /wsprdaemon and install again unless someone has a better suggestion.

73 Alan G4ZFQ


Rob Robinett
 

Hi Alan,

If you want me to look at your WD through WD's remote access connection, then email me and I'll send you instructions.

Rob

On Wed, Oct 26, 2022 at 1:45 PM Alan G4ZFQ <alan4alan@...> wrote:
 > If your wsprdaemon install was done per the instructions then 'cd
 > ~/wsprdaemon'  should move you its directory and then 'git pull'
Thanks Glenn, easy, quick, v3.0.5:-)

But still no FST4W decodes. W2 fine.
Note there is a F5 signal to decode, and I have also provided one from a
local TX.

declare WSPR_SCHEDULE=(
     "00:00 G4ZFQ_1,2200,W2:F5:F15 G4ZFQ_1,630,W2:F5 G4ZFQ_1,160
G4ZFQ_1,80 G4ZFQ_1,40  G4ZFQ_1,30 G4ZFQ_1,22 "
)

Seems to be the only entry concerning FST4W, I've tried various
configurations including 630 on its own.

I shall rename /wsprdaemon and install again unless someone has a better
suggestion.

73 Alan G4ZFQ







--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Gwyn Griffiths
 

Hello Alan
It may be useful to run a test in isolation of the jt9 program that decodes FST4W.

Any of these steps may fail, but that will tell us something:

1. A successful installation of wsprdaemon should install the jt9 executable. If you have installed as userid wsprdaemon I'd expect to find it at

/home/wsprdaemon/wsprdaemon/bin/jt9

First thing to check is that it is there.
If it isn't then it'd be worth trying to find it. I prefer the utility locate rather than find, it can be installed with
sudo apt-get install mlocate 

then it is simply
locate jt9

2. I've attached a wav file with an FST4W-120 signal of mine. Assuming the jt9 is in the default location, if you download the wav file into your Pi's home directory for user wsprdaemon then execute the following:

/home/wsprdaemon/wsprdaemon/bin/jt9 --fst4w -p 120 -f 1500 -F 100 ~/220719_1418.wav


It should produce a decode

1418  11  1.1 1511 `  G3ZIL IO90 30                                   

<DecodeFinished>   0   1        0

where 1418 is the UTC time, 11 the SNR, 1.1 the delta time, 1511 the frequency, and 30 the power in dBm.

regards

Gwyn G3ZIL


Alan G4ZFQ
 

On 27/10/2022 08:33, Gwyn Griffiths via groups.io wrote:
It may be useful to run a test in isolation of the jt9 program

Gwyn,

Thanks! Yes jt9 is there I'll give it a try this afternoon.

73 Alan