FST4W transmissions should limit call signs to 6 characters and maidenheads to 4 characters if they are going to be decoded by WD


Rob Robinett
 

Hi Stu,

I have cc'd the forum because this will be an ongoing issue as we experiment with FST4W.

In another thread I have tried to explain why WD will not decode 1/2 of the transmissions of Glenn's N6GN and Stu's WS6YRW/6  FST4W spots generated by WSJT-x.
In Stu's case it is because his tx call sign WB6YBW/6  is longer than 6 characters.  As a result, WSJT-x first sends a type 2 packet with his full callsign and power level which is immediately followed by a type 3 packet which carries a hash of his call sign followed by the maidenhead.  
That type 3 packet is not decodable by WD, and because WD uploads only a type 2 spot for you, perhaps wsprnet.org doesn't record it.

In Glenn's case he has entered a 6 character maidenhead, so at time 02:15 his WSJT-x sent a type 2 spot which contained his 6 character callsign N6GN/6 and his power level '0'.  That packet ended at 01:30 and was decoded and uploaded to wsprnet.org:

Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0215   0  -17   0.4   1405.   0  
N6GN/F 0                              FST4
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W type 2 spots:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() FST4W found some mode 16 spots after 2 seconds:
0215   0  -17   0.4   1405.   0   N6GN/F 0                              FST4
Which were formatted into uploadable lines:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16

At 2:30 his WSJT-x started transmitting a type 3 packet which carried the 16 bit hash of his call sign followed by the 6 character call sign he specified to WSJT-x.
That type 3 packet was decoded by jt9 at 02:45, but because jt9, unlike wsprd' doesn't save the callsign hashes to a file, jt9 doesn't know to associate that hash with N6GN/F, so jt9 inserts the call "<...>" in the spot line.
Since wsprnet.org appropriately rejects uploaded spots with the call  "<...>",  WD flushes that spot.

Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0230   0  -19   0.4   1405.   0  
<...> DN70LL                          FST4
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found one or more  '<...>' FST4W spots.  Filtering them out
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found no FST4W spots after filtering out '<...>' FST4W spots


So I would be much better if all FST4W beacons were to change the callsign in their wsjt-x to one 6 characters or less and use only 4 character maidenheads.

73,

Rob

=========  From another thread ======


Entering a 6 character tx grid causes WSJT-x to send a pair of packets for each transmission.

If the call sign is 6 characters or less, the first packet is a type 1 which is decodable by WD, but the second type 3 packet which is not decodable by WD, only by WSJT-x

So I suggest FST4W beacons shorten the grid specification in their WSJT-x to 4 characters so that every packet sent can be spotted by WD since WSJT-x will transmit only type 1 packets.

This behavior differs from that of WSPR packets where WD can decode type 3 packets.

More information can be found here:  https://dxplorer.net/wspr/msgtypes.html



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


Stuart Ogawa
 

Hi Rob,

ok.

i plan on changing my call sign to help the cause and applying for a 4 digit call sign; this will take 18ish days to perform...or sometime by mid/end of july.

in the mean time...you have any issue if i abbreviate my call sign to wb6y/6 with my 4 char maidenhead?

On Tue, Jul 5, 2022 at 9:38 PM Rob Robinett <rob@...> wrote:
Hi Stu,

I have cc'd the forum because this will be an ongoing issue as we experiment with FST4W.

In another thread I have tried to explain why WD will not decode 1/2 of the transmissions of Glenn's N6GN and Stu's WS6YRW/6  FST4W spots generated by WSJT-x.
In Stu's case it is because his tx call sign WB6YBW/6  is longer than 6 characters.  As a result, WSJT-x first sends a type 2 packet with his full callsign and power level which is immediately followed by a type 3 packet which carries a hash of his call sign followed by the maidenhead.  
That type 3 packet is not decodable by WD, and because WD uploads only a type 2 spot for you, perhaps wsprnet.org doesn't record it.

In Glenn's case he has entered a 6 character maidenhead, so at time 02:15 his WSJT-x sent a type 2 spot which contained his 6 character callsign N6GN/6 and his power level '0'.  That packet ended at 01:30 and was decoded and uploaded to wsprnet.org:

Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0215   0  -17   0.4   1405.   0  
N6GN/F 0                              FST4
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W type 2 spots:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() FST4W found some mode 16 spots after 2 seconds:
0215   0  -17   0.4   1405.   0   N6GN/F 0                              FST4
Which were formatted into uploadable lines:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16

At 2:30 his WSJT-x started transmitting a type 3 packet which carried the 16 bit hash of his call sign followed by the 6 character call sign he specified to WSJT-x.
That type 3 packet was decoded by jt9 at 02:45, but because jt9, unlike wsprd' doesn't save the callsign hashes to a file, jt9 doesn't know to associate that hash with N6GN/F, so jt9 inserts the call "<...>" in the spot line.
Since wsprnet.org appropriately rejects uploaded spots with the call  "<...>",  WD flushes that spot.

Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0230   0  -19   0.4   1405.   0  
<...> DN70LL                          FST4
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found one or more  '<...>' FST4W spots.  Filtering them out
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found no FST4W spots after filtering out '<...>' FST4W spots


So I would be much better if all FST4W beacons were to change the callsign in their wsjt-x to one 6 characters or less and use only 4 character maidenheads.

73,

Rob

=========  From another thread ======


Entering a 6 character tx grid causes WSJT-x to send a pair of packets for each transmission.

If the call sign is 6 characters or less, the first packet is a type 1 which is decodable by WD, but the second type 3 packet which is not decodable by WD, only by WSJT-x

So I suggest FST4W beacons shorten the grid specification in their WSJT-x to 4 characters so that every packet sent can be spotted by WD since WSJT-x will transmit only type 1 packets.

This behavior differs from that of WSPR packets where WD can decode type 3 packets.

More information can be found here:  https://dxplorer.net/wspr/msgtypes.html



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


Rob Robinett
 

No problem for me.
Alternatively, you could transmit 4W using my AI6VN which would lead any listener back to your through me.

On Tue, Jul 5, 2022 at 9:48 PM Stuart Ogawa <stuartogawa@...> wrote:
Hi Rob,

ok.

i plan on changing my call sign to help the cause and applying for a 4 digit call sign; this will take 18ish days to perform...or sometime by mid/end of july.

in the mean time...you have any issue if i abbreviate my call sign to wb6y/6 with my 4 char maidenhead?

On Tue, Jul 5, 2022 at 9:38 PM Rob Robinett <rob@...> wrote:
Hi Stu,

I have cc'd the forum because this will be an ongoing issue as we experiment with FST4W.

In another thread I have tried to explain why WD will not decode 1/2 of the transmissions of Glenn's N6GN and Stu's WS6YRW/6  FST4W spots generated by WSJT-x.
In Stu's case it is because his tx call sign WB6YBW/6  is longer than 6 characters.  As a result, WSJT-x first sends a type 2 packet with his full callsign and power level which is immediately followed by a type 3 packet which carries a hash of his call sign followed by the maidenhead.  
That type 3 packet is not decodable by WD, and because WD uploads only a type 2 spot for you, perhaps wsprnet.org doesn't record it.

In Glenn's case he has entered a 6 character maidenhead, so at time 02:15 his WSJT-x sent a type 2 spot which contained his 6 character callsign N6GN/6 and his power level '0'.  That packet ended at 01:30 and was decoded and uploaded to wsprnet.org:

Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0215   0  -17   0.4   1405.   0  
N6GN/F 0                              FST4
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W type 2 spots:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() FST4W found some mode 16 spots after 2 seconds:
0215   0  -17   0.4   1405.   0   N6GN/F 0                              FST4
Which were formatted into uploadable lines:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16

At 2:30 his WSJT-x started transmitting a type 3 packet which carried the 16 bit hash of his call sign followed by the 6 character call sign he specified to WSJT-x.
That type 3 packet was decoded by jt9 at 02:45, but because jt9, unlike wsprd' doesn't save the callsign hashes to a file, jt9 doesn't know to associate that hash with N6GN/F, so jt9 inserts the call "<...>" in the spot line.
Since wsprnet.org appropriately rejects uploaded spots with the call  "<...>",  WD flushes that spot.

Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0230   0  -19   0.4   1405.   0  
<...> DN70LL                          FST4
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found one or more  '<...>' FST4W spots.  Filtering them out
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found no FST4W spots after filtering out '<...>' FST4W spots


So I would be much better if all FST4W beacons were to change the callsign in their wsjt-x to one 6 characters or less and use only 4 character maidenheads.

73,

Rob

=========  From another thread ======


Entering a 6 character tx grid causes WSJT-x to send a pair of packets for each transmission.

If the call sign is 6 characters or less, the first packet is a type 1 which is decodable by WD, but the second type 3 packet which is not decodable by WD, only by WSJT-x

So I suggest FST4W beacons shorten the grid specification in their WSJT-x to 4 characters so that every packet sent can be spotted by WD since WSJT-x will transmit only type 1 packets.

This behavior differs from that of WSPR packets where WD can decode type 3 packets.

More information can be found here:  https://dxplorer.net/wspr/msgtypes.html



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


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


Stuart Ogawa
 

temp call sign is now:

wb6y/6 
cm97 maidenhead

updated wsjt x preferences

restarted wsjt x with temp call sign and cm97 maidenhead

resuming fst4w 40m beacon tx

11PM FCC web server system maintenance completes and i submit the proposed new call sign

On Tue, Jul 5, 2022 at 9:56 PM Rob Robinett <rob@...> wrote:
No problem for me.
Alternatively, you could transmit 4W using my AI6VN which would lead any listener back to your through me.

On Tue, Jul 5, 2022 at 9:48 PM Stuart Ogawa <stuartogawa@...> wrote:
Hi Rob,

ok.

i plan on changing my call sign to help the cause and applying for a 4 digit call sign; this will take 18ish days to perform...or sometime by mid/end of july.

in the mean time...you have any issue if i abbreviate my call sign to wb6y/6 with my 4 char maidenhead?

On Tue, Jul 5, 2022 at 9:38 PM Rob Robinett <rob@...> wrote:
Hi Stu,

I have cc'd the forum because this will be an ongoing issue as we experiment with FST4W.

In another thread I have tried to explain why WD will not decode 1/2 of the transmissions of Glenn's N6GN and Stu's WS6YRW/6  FST4W spots generated by WSJT-x.
In Stu's case it is because his tx call sign WB6YBW/6  is longer than 6 characters.  As a result, WSJT-x first sends a type 2 packet with his full callsign and power level which is immediately followed by a type 3 packet which carries a hash of his call sign followed by the maidenhead.  
That type 3 packet is not decodable by WD, and because WD uploads only a type 2 spot for you, perhaps wsprnet.org doesn't record it.

In Glenn's case he has entered a 6 character maidenhead, so at time 02:15 his WSJT-x sent a type 2 spot which contained his 6 character callsign N6GN/6 and his power level '0'.  That packet ended at 01:30 and was decoded and uploaded to wsprnet.org:

Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0215   0  -17   0.4   1405.   0  
N6GN/F 0                              FST4
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W type 2 spots:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() FST4W found some mode 16 spots after 2 seconds:
0215   0  -17   0.4   1405.   0   N6GN/F 0                              FST4
Which were formatted into uploadable lines:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16

At 2:30 his WSJT-x started transmitting a type 3 packet which carried the 16 bit hash of his call sign followed by the 6 character call sign he specified to WSJT-x.
That type 3 packet was decoded by jt9 at 02:45, but because jt9, unlike wsprd' doesn't save the callsign hashes to a file, jt9 doesn't know to associate that hash with N6GN/F, so jt9 inserts the call "<...>" in the spot line.
Since wsprnet.org appropriately rejects uploaded spots with the call  "<...>",  WD flushes that spot.

Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0230   0  -19   0.4   1405.   0  
<...> DN70LL                          FST4
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found one or more  '<...>' FST4W spots.  Filtering them out
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found no FST4W spots after filtering out '<...>' FST4W spots


So I would be much better if all FST4W beacons were to change the callsign in their wsjt-x to one 6 characters or less and use only 4 character maidenheads.

73,

Rob

=========  From another thread ======


Entering a 6 character tx grid causes WSJT-x to send a pair of packets for each transmission.

If the call sign is 6 characters or less, the first packet is a type 1 which is decodable by WD, but the second type 3 packet which is not decodable by WD, only by WSJT-x

So I suggest FST4W beacons shorten the grid specification in their WSJT-x to 4 characters so that every packet sent can be spotted by WD since WSJT-x will transmit only type 1 packets.

This behavior differs from that of WSPR packets where WD can decode type 3 packets.

More information can be found here:  https://dxplorer.net/wspr/msgtypes.html



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


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


Stuart Ogawa
 

wsjt x  preferences did not like "wb6y/6"

impact: no transmission decoding

changed temp call to "w6yr".  

impact: successful transmission and receiving decoding:
Screen Shot 2022-07-05 at 11.26.30 PM.png


resuming 40m fst4w tx overnight.

----

lots of peculiar issues when learning and operationaling wsjt x for fst4w tx beaconing.

----

submitted and paid for my vanity 4 character call sign to the FCC a few minutes ago.  waiting to hear back if the requested new call sign authorized and issued to me.


-stu 







On Tue, Jul 5, 2022 at 10:13 PM Stuart Ogawa via groups.io <stuartogawa=gmail.com@groups.io> wrote:
temp call sign is now:

wb6y/6 
cm97 maidenhead

updated wsjt x preferences

restarted wsjt x with temp call sign and cm97 maidenhead

resuming fst4w 40m beacon tx

11PM FCC web server system maintenance completes and i submit the proposed new call sign

On Tue, Jul 5, 2022 at 9:56 PM Rob Robinett <rob@...> wrote:
No problem for me.
Alternatively, you could transmit 4W using my AI6VN which would lead any listener back to your through me.

On Tue, Jul 5, 2022 at 9:48 PM Stuart Ogawa <stuartogawa@...> wrote:
Hi Rob,

ok.

i plan on changing my call sign to help the cause and applying for a 4 digit call sign; this will take 18ish days to perform...or sometime by mid/end of july.

in the mean time...you have any issue if i abbreviate my call sign to wb6y/6 with my 4 char maidenhead?

On Tue, Jul 5, 2022 at 9:38 PM Rob Robinett <rob@...> wrote:
Hi Stu,

I have cc'd the forum because this will be an ongoing issue as we experiment with FST4W.

In another thread I have tried to explain why WD will not decode 1/2 of the transmissions of Glenn's N6GN and Stu's WS6YRW/6  FST4W spots generated by WSJT-x.
In Stu's case it is because his tx call sign WB6YBW/6  is longer than 6 characters.  As a result, WSJT-x first sends a type 2 packet with his full callsign and power level which is immediately followed by a type 3 packet which carries a hash of his call sign followed by the maidenhead.  
That type 3 packet is not decodable by WD, and because WD uploads only a type 2 spot for you, perhaps wsprnet.org doesn't record it.

In Glenn's case he has entered a 6 character maidenhead, so at time 02:15 his WSJT-x sent a type 2 spot which contained his 6 character callsign N6GN/6 and his power level '0'.  That packet ended at 01:30 and was decoded and uploaded to wsprnet.org:

Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0215   0  -17   0.4   1405.   0  
N6GN/F 0                              FST4
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W type 2 spots:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() FST4W found some mode 16 spots after 2 seconds:
0215   0  -17   0.4   1405.   0   N6GN/F 0                              FST4
Which were formatted into uploadable lines:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16

At 2:30 his WSJT-x started transmitting a type 3 packet which carried the 16 bit hash of his call sign followed by the 6 character call sign he specified to WSJT-x.
That type 3 packet was decoded by jt9 at 02:45, but because jt9, unlike wsprd' doesn't save the callsign hashes to a file, jt9 doesn't know to associate that hash with N6GN/F, so jt9 inserts the call "<...>" in the spot line.
Since wsprnet.org appropriately rejects uploaded spots with the call  "<...>",  WD flushes that spot.

Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0230   0  -19   0.4   1405.   0  
<...> DN70LL                          FST4
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found one or more  '<...>' FST4W spots.  Filtering them out
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found no FST4W spots after filtering out '<...>' FST4W spots


So I would be much better if all FST4W beacons were to change the callsign in their wsjt-x to one 6 characters or less and use only 4 character maidenheads.

73,

Rob

=========  From another thread ======


Entering a 6 character tx grid causes WSJT-x to send a pair of packets for each transmission.

If the call sign is 6 characters or less, the first packet is a type 1 which is decodable by WD, but the second type 3 packet which is not decodable by WD, only by WSJT-x

So I suggest FST4W beacons shorten the grid specification in their WSJT-x to 4 characters so that every packet sent can be spotted by WD since WSJT-x will transmit only type 1 packets.

This behavior differs from that of WSPR packets where WD can decode type 3 packets.

More information can be found here:  https://dxplorer.net/wspr/msgtypes.html



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


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


KD2OM
 

Rob,
I have changed my MF beacon to use 4 character grid but must note that ZKD does detect my full grid.
Stuart,
What about the legality of only using a partial call?

73
Steve KD2OM


.
 

On Jul 6, 2022, at 01:13, Stuart Ogawa <stuartogawa@...> wrote:


temp call sign is now:

wb6y/6 
cm97 maidenhead

updated wsjt x preferences

restarted wsjt x with temp call sign and cm97 maidenhead

resuming fst4w 40m beacon tx

11PM FCC web server system maintenance completes and i submit the proposed new call sign

On Tue, Jul 5, 2022 at 9:56 PM Rob Robinett <rob@...> wrote:
No problem for me.
Alternatively, you could transmit 4W using my AI6VN which would lead any listener back to your through me.

On Tue, Jul 5, 2022 at 9:48 PM Stuart Ogawa <stuartogawa@...> wrote:
Hi Rob,

ok.

i plan on changing my call sign to help the cause and applying for a 4 digit call sign; this will take 18ish days to perform...or sometime by mid/end of july.

in the mean time...you have any issue if i abbreviate my call sign to wb6y/6 with my 4 char maidenhead?

On Tue, Jul 5, 2022 at 9:38 PM Rob Robinett <rob@...> wrote:
Hi Stu,

I have cc'd the forum because this will be an ongoing issue as we experiment with FST4W.

In another thread I have tried to explain why WD will not decode 1/2 of the transmissions of Glenn's N6GN and Stu's WS6YRW/6  FST4W spots generated by WSJT-x.
In Stu's case it is because his tx call sign WB6YBW/6  is longer than 6 characters.  As a result, WSJT-x first sends a type 2 packet with his full callsign and power level which is immediately followed by a type 3 packet which carries a hash of his call sign followed by the maidenhead.  
That type 3 packet is not decodable by WD, and because WD uploads only a type 2 spot for you, perhaps wsprnet.org doesn't record it.

In Glenn's case he has entered a 6 character maidenhead, so at time 02:15 his WSJT-x sent a type 2 spot which contained his 6 character callsign N6GN/6 and his power level '0'.  That packet ended at 01:30 and was decoded and uploaded to wsprnet.org:

Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0215   0  -17   0.4   1405.   0  
N6GN/F 0                              FST4
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W type 2 spots:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() FST4W found some mode 16 spots after 2 seconds:
0215   0  -17   0.4   1405.   0   N6GN/F 0                              FST4
Which were formatted into uploadable lines:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16

At 2:30 his WSJT-x started transmitting a type 3 packet which carried the 16 bit hash of his call sign followed by the 6 character call sign he specified to WSJT-x.
That type 3 packet was decoded by jt9 at 02:45, but because jt9, unlike wsprd' doesn't save the callsign hashes to a file, jt9 doesn't know to associate that hash with N6GN/F, so jt9 inserts the call "<...>" in the spot line.
Since wsprnet.org appropriately rejects uploaded spots with the call  "<...>",  WD flushes that spot.

Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0230   0  -19   0.4   1405.   0  
<...> DN70LL                          FST4
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found one or more  '<...>' FST4W spots.  Filtering them out
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found no FST4W spots after filtering out '<...>' FST4W spots


So I would be much better if all FST4W beacons were to change the callsign in their wsjt-x to one 6 characters or less and use only 4 character maidenheads.

73,

Rob

=========  From another thread ======


Entering a 6 character tx grid causes WSJT-x to send a pair of packets for each transmission.

If the call sign is 6 characters or less, the first packet is a type 1 which is decodable by WD, but the second type 3 packet which is not decodable by WD, only by WSJT-x

So I suggest FST4W beacons shorten the grid specification in their WSJT-x to 4 characters so that every packet sent can be spotted by WD since WSJT-x will transmit only type 1 packets.

This behavior differs from that of WSPR packets where WD can decode type 3 packets.

More information can be found here:  https://dxplorer.net/wspr/msgtypes.html



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


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


Glenn Elmore
 

Stu and all,

FOr those of us trying to generate beacon transmission for testing and improving things, I suggest we consider something like the following:

I think we should

  • avoid any special call longer than 6 characters - use our legal call only
  • use only 4 character grid, never 6
  • use *frequency* to distinguish modes

This should

  • get everyone into only type 2 beacons
  • help identify a mode when the reporting doesn't
  • help identify a transmitter when it doesn't decode (it may show up on a waterfall, this used to be very useful on VHF/UHF where we each 'claimed' a different frequency in 10 Hz steps)

I'm thinking of moving up/down to position trasnmissions 10 Hz, rather than 5 Hz above/below the WSP band edge.  I'm still not sure what WSJT-X does, it appears to decode a full 'tolerance' beyond the WSPR band but I don't think WD is doing that is it|?  As we go to longer,narrower modes I think transmit/receive accuracy and drift may become an issue, e.g. do we yet know that a Kiwi's onboard GPS is good enough for mode30?  We do know that it wiggles around when we look at WWV, part GPS stabilization and part ionosphere. At what point does this get in the way of decodes?

I'm going to change my FST4W to 10 Hz above WSPR band edge, 14.097010 MHz on 20m and my WSPR to 14.097190 in order to give inaccurate rx sites a better chance of finding me. Although I can stay under 7 characters with my particular call and the /F and /W extension I've been using I'm going to drop them in favor of plain "N6GN" everywhere.

As mentioned above, as we push into these longer and narrower modes we may find frequency accuracy, stability more important - just as it is on VHF/UHF WSPR2.


Glenn n6gn



On 7/6/22 00:33, Stuart Ogawa wrote:
wsjt x  preferences did not like "wb6y/6"

impact: no transmission decoding

changed temp call to "w6yr".  

impact: successful transmission and receiving decoding:
Screen Shot 2022-07-05 at 11.26.30 PM.png


resuming 40m fst4w tx overnight.

----

lots of peculiar issues when learning and operationaling wsjt x for fst4w tx beaconing.

----

submitted and paid for my vanity 4 character call sign to the FCC a few minutes ago.  waiting to hear back if the requested new call sign authorized and issued to me.


-stu 







On Tue, Jul 5, 2022 at 10:13 PM Stuart Ogawa via groups.io <stuartogawa=gmail.com@groups.io> wrote:
temp call sign is now:

wb6y/6 
cm97 maidenhead

updated wsjt x preferences

restarted wsjt x with temp call sign and cm97 maidenhead

resuming fst4w 40m beacon tx

11PM FCC web server system maintenance completes and i submit the proposed new call sign

On Tue, Jul 5, 2022 at 9:56 PM Rob Robinett <rob@...> wrote:
No problem for me.
Alternatively, you could transmit 4W using my AI6VN which would lead any listener back to your through me.

On Tue, Jul 5, 2022 at 9:48 PM Stuart Ogawa <stuartogawa@...> wrote:
Hi Rob,

ok.

i plan on changing my call sign to help the cause and applying for a 4 digit call sign; this will take 18ish days to perform...or sometime by mid/end of july.

in the mean time...you have any issue if i abbreviate my call sign to wb6y/6 with my 4 char maidenhead?

On Tue, Jul 5, 2022 at 9:38 PM Rob Robinett <rob@...> wrote:
Hi Stu,

I have cc'd the forum because this will be an ongoing issue as we experiment with FST4W.

In another thread I have tried to explain why WD will not decode 1/2 of the transmissions of Glenn's N6GN and Stu's WS6YRW/6  FST4W spots generated by WSJT-x.
In Stu's case it is because his tx call sign WB6YBW/6  is longer than 6 characters.  As a result, WSJT-x first sends a type 2 packet with his full callsign and power level which is immediately followed by a type 3 packet which carries a hash of his call sign followed by the maidenhead.  
That type 3 packet is not decodable by WD, and because WD uploads only a type 2 spot for you, perhaps wsprnet.org doesn't record it.

In Glenn's case he has entered a 6 character maidenhead, so at time 02:15 his WSJT-x sent a type 2 spot which contained his 6 character callsign N6GN/6 and his power level '0'.  That packet ended at 01:30 and was decoded and uploaded to wsprnet.org:

Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0215   0  -17   0.4   1405.   0  
N6GN/F 0                              FST4
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W type 2 spots:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() FST4W found some mode 16 spots after 2 seconds:
0215   0  -17   0.4   1405.   0   N6GN/F 0                              FST4
Which were formatted into uploadable lines:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16

At 2:30 his WSJT-x started transmitting a type 3 packet which carried the 16 bit hash of his call sign followed by the 6 character call sign he specified to WSJT-x.
That type 3 packet was decoded by jt9 at 02:45, but because jt9, unlike wsprd' doesn't save the callsign hashes to a file, jt9 doesn't know to associate that hash with N6GN/F, so jt9 inserts the call "<...>" in the spot line.
Since wsprnet.org appropriately rejects uploaded spots with the call  "<...>",  WD flushes that spot.

Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0230   0  -19   0.4   1405.   0  
<...> DN70LL                          FST4
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found one or more  '<...>' FST4W spots.  Filtering them out
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found no FST4W spots after filtering out '<...>' FST4W spots


So I would be much better if all FST4W beacons were to change the callsign in their wsjt-x to one 6 characters or less and use only 4 character maidenheads.

73,

Rob

=========  From another thread ======


Entering a 6 character tx grid causes WSJT-x to send a pair of packets for each transmission.

If the call sign is 6 characters or less, the first packet is a type 1 which is decodable by WD, but the second type 3 packet which is not decodable by WD, only by WSJT-x

So I suggest FST4W beacons shorten the grid specification in their WSJT-x to 4 characters so that every packet sent can be spotted by WD since WSJT-x will transmit only type 1 packets.

This behavior differs from that of WSPR packets where WD can decode type 3 packets.

More information can be found here:  https://dxplorer.net/wspr/msgtypes.html



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


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


KD2OM
 

Received N6GN at 1945Z -20 FST4W 20 Meters.

Steve KD2OM 

.
 

On Jul 6, 2022, at 10:13, Glenn Elmore <n6gn@...> wrote:



Stu and all,

FOr those of us trying to generate beacon transmission for testing and improving things, I suggest we consider something like the following:

I think we should

  • avoid any special call longer than 6 characters - use our legal call only
  • use only 4 character grid, never 6
  • use *frequency* to distinguish modes

This should

  • get everyone into only type 2 beacons
  • help identify a mode when the reporting doesn't
  • help identify a transmitter when it doesn't decode (it may show up on a waterfall, this used to be very useful on VHF/UHF where we each 'claimed' a different frequency in 10 Hz steps)

I'm thinking of moving up/down to position trasnmissions 10 Hz, rather than 5 Hz above/below the WSP band edge.  I'm still not sure what WSJT-X does, it appears to decode a full 'tolerance' beyond the WSPR band but I don't think WD is doing that is it|?  As we go to longer,narrower modes I think transmit/receive accuracy and drift may become an issue, e.g. do we yet know that a Kiwi's onboard GPS is good enough for mode30?  We do know that it wiggles around when we look at WWV, part GPS stabilization and part ionosphere. At what point does this get in the way of decodes?

I'm going to change my FST4W to 10 Hz above WSPR band edge, 14.097010 MHz on 20m and my WSPR to 14.097190 in order to give inaccurate rx sites a better chance of finding me. Although I can stay under 7 characters with my particular call and the /F and /W extension I've been using I'm going to drop them in favor of plain "N6GN" everywhere.

As mentioned above, as we push into these longer and narrower modes we may find frequency accuracy, stability more important - just as it is on VHF/UHF WSPR2.


Glenn n6gn



On 7/6/22 00:33, Stuart Ogawa wrote:
wsjt x  preferences did not like "wb6y/6"

impact: no transmission decoding

changed temp call to "w6yr".  

impact: successful transmission and receiving decoding:



resuming 40m fst4w tx overnight.

----

lots of peculiar issues when learning and operationaling wsjt x for fst4w tx beaconing.

----

submitted and paid for my vanity 4 character call sign to the FCC a few minutes ago.  waiting to hear back if the requested new call sign authorized and issued to me.


-stu 







On Tue, Jul 5, 2022 at 10:13 PM Stuart Ogawa via groups.io <stuartogawa=gmail.com@groups.io> wrote:
temp call sign is now:

wb6y/6 
cm97 maidenhead

updated wsjt x preferences

restarted wsjt x with temp call sign and cm97 maidenhead

resuming fst4w 40m beacon tx

11PM FCC web server system maintenance completes and i submit the proposed new call sign

On Tue, Jul 5, 2022 at 9:56 PM Rob Robinett <rob@...> wrote:
No problem for me.
Alternatively, you could transmit 4W using my AI6VN which would lead any listener back to your through me.

On Tue, Jul 5, 2022 at 9:48 PM Stuart Ogawa <stuartogawa@...> wrote:
Hi Rob,

ok.

i plan on changing my call sign to help the cause and applying for a 4 digit call sign; this will take 18ish days to perform...or sometime by mid/end of july.

in the mean time...you have any issue if i abbreviate my call sign to wb6y/6 with my 4 char maidenhead?

On Tue, Jul 5, 2022 at 9:38 PM Rob Robinett <rob@...> wrote:
Hi Stu,

I have cc'd the forum because this will be an ongoing issue as we experiment with FST4W.

In another thread I have tried to explain why WD will not decode 1/2 of the transmissions of Glenn's N6GN and Stu's WS6YRW/6  FST4W spots generated by WSJT-x.
In Stu's case it is because his tx call sign WB6YBW/6  is longer than 6 characters.  As a result, WSJT-x first sends a type 2 packet with his full callsign and power level which is immediately followed by a type 3 packet which carries a hash of his call sign followed by the maidenhead.  
That type 3 packet is not decodable by WD, and because WD uploads only a type 2 spot for you, perhaps wsprnet.org doesn't record it.

In Glenn's case he has entered a 6 character maidenhead, so at time 02:15 his WSJT-x sent a type 2 spot which contained his 6 character callsign N6GN/6 and his power level '0'.  That packet ended at 01:30 and was decoded and uploaded to wsprnet.org:

Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0215   0  -17   0.4   1405.   0  
N6GN/F 0                              FST4
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() Found FST4W type 2 spots:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16
Wed 06 Jul 2022 02:30:21 UTC: decoding_daemon() FST4W found some mode 16 spots after 2 seconds:
0215   0  -17   0.4   1405.   0   N6GN/F 0                              FST4
Which were formatted into uploadable lines:
220706 0215 -17 0.4   14.097005    N6GN/F 0                      0 0 0 0 0 0 0 0 0 16

At 2:30 his WSJT-x started transmitting a type 3 packet which carried the 16 bit hash of his call sign followed by the 6 character call sign he specified to WSJT-x.
That type 3 packet was decoded by jt9 at 02:45, but because jt9, unlike wsprd' doesn't save the callsign hashes to a file, jt9 doesn't know to associate that hash with N6GN/F, so jt9 inserts the call "<...>" in the spot line.
Since wsprnet.org appropriately rejects uploaded spots with the call  "<...>",  WD flushes that spot.

Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found FST4W spots. These spot log lines have the format  NUM_FIELDS : SPOT_LINE:
9: 0230   0  -19   0.4   1405.   0  
<...> DN70LL                          FST4
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found one or more  '<...>' FST4W spots.  Filtering them out
Wed 06 Jul 2022 02:45:10 UTC: decoding_daemon() Found no FST4W spots after filtering out '<...>' FST4W spots


So I would be much better if all FST4W beacons were to change the callsign in their wsjt-x to one 6 characters or less and use only 4 character maidenheads.

73,

Rob

=========  From another thread ======


Entering a 6 character tx grid causes WSJT-x to send a pair of packets for each transmission.

If the call sign is 6 characters or less, the first packet is a type 1 which is decodable by WD, but the second type 3 packet which is not decodable by WD, only by WSJT-x

So I suggest FST4W beacons shorten the grid specification in their WSJT-x to 4 characters so that every packet sent can be spotted by WD since WSJT-x will transmit only type 1 packets.

This behavior differs from that of WSPR packets where WD can decode type 3 packets.

More information can be found here:  https://dxplorer.net/wspr/msgtypes.html



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


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


Glenn Elmore
 

Per my records for the day, that would have been mode15. I've been mode hopping most of the day while Rob and others try to sort out decoding and posting. Here's my earlier schedule.

UTC Mode Note
1545 M15

1600 M30
through


1800 M30 Actually ran until 1820 when I interrupted and moved to M2



1820 M2
1835 m5
1915 m15
naptime M15 continuing

Currently I'm simultaneously transmitting WSPR2 and FST4W mode2  and violating my own suggestion of only legal calls for tx ID since FST4W is IDin as N6GN/0  (technically true since I live in Colorado and the "0" call area)

Rob is trying to sort out when and how same-txID spots get filtered - probably a good idea for same protocol but not so for different protocol as I am doing now.

On 7/6/22 16:40, KD2OM wrote:
Received N6GN at 1945Z -20 FST4W 20 Meters.

Steve KD2OM 


KD2OM
 

Glenn yes I believe it is mode 15. WSJT-X doesn’t tell me but I have the TX set to that. I don’t know if it detects other modes.

Steve

.
 

On Jul 6, 2022, at 18:57, Glenn Elmore <n6gn@...> wrote:



Per my records for the day, that would have been mode15. I've been mode hopping most of the day while Rob and others try to sort out decoding and posting. Here's my earlier schedule.

UTC Mode Note
1545 M15

1600 M30
through


1800 M30 Actually ran until 1820 when I interrupted and moved to M2



1820 M2
1835 m5
1915 m15
naptime M15 continuing

Currently I'm simultaneously transmitting WSPR2 and FST4W mode2  and violating my own suggestion of only legal calls for tx ID since FST4W is IDin as N6GN/0  (technically true since I live in Colorado and the "0" call area)

Rob is trying to sort out when and how same-txID spots get filtered - probably a good idea for same protocol but not so for different protocol as I am doing now.

On 7/6/22 16:40, KD2OM wrote:
Received N6GN at 1945Z -20 FST4W 20 Meters.

Steve KD2OM 


Rob Robinett
 

WSJT-x listens to only one band+mode at a time.
That limitation was one of my first motivations to create WD

On Wed, Jul 6, 2022 at 4:22 PM KD2OM <steve@...> wrote:
Glenn yes I believe it is mode 15. WSJT-X doesn’t tell me but I have the TX set to that. I don’t know if it detects other modes.

Steve

.
 

On Jul 6, 2022, at 18:57, Glenn Elmore <n6gn@...> wrote:



Per my records for the day, that would have been mode15. I've been mode hopping most of the day while Rob and others try to sort out decoding and posting. Here's my earlier schedule.

UTC Mode Note
1545 M15

1600 M30
through


1800 M30 Actually ran until 1820 when I interrupted and moved to M2



1820 M2
1835 m5
1915 m15
naptime M15 continuing

Currently I'm simultaneously transmitting WSPR2 and FST4W mode2  and violating my own suggestion of only legal calls for tx ID since FST4W is IDin as N6GN/0  (technically true since I live in Colorado and the "0" call area)

Rob is trying to sort out when and how same-txID spots get filtered - probably a good idea for same protocol but not so for different protocol as I am doing now.

On 7/6/22 16:40, KD2OM wrote:
Received N6GN at 1945Z -20 FST4W 20 Meters.

Steve KD2OM 



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


Glenn Elmore
 

It doesn't and that's part of our overall problem to improve uptake of FST4.  WSJT-X only will tx/rx on one mode at a time, this means that people trying out FST have to agree beforehand. This dilutes the potential population and makes it seem like the entire protocol is vacant - except maybe on bands where there is a de facto mode (630m?, I don't k know).

WD greatly improves this (if we can get everything to decode and post properly which is the active pursuit) by simultaneously handling all modes.

Glenn n6gn

On 7/6/22 17:21, KD2OM wrote:
Glenn yes I believe it is mode 15. WSJT-X doesn’t tell me but I have the TX set to that. I don’t know if it detects other modes.

Steve


KD2OM
 

I will have to move some bands onto the AtomicPi to leave enough horsepower to set WD to decode FST4W on a couple more bands.

Steve KD2OM

On Jul 6, 2022, at 19:25, Glenn Elmore <n6gn@...> wrote:

It doesn't and that's part of our overall problem to improve uptake of FST4. WSJT-X only will tx/rx on one mode at a time, this means that people trying out FST have to agree beforehand. This dilutes the potential population and makes it seem like the entire protocol is vacant - except maybe on bands where there is a de facto mode (630m?, I don't k know).

WD greatly improves this (if we can get everything to decode and post properly which is the active pursuit) by simultaneously handling all modes.

Glenn n6gn

On 7/6/22 17:21, KD2OM wrote:
Glenn yes I believe it is mode 15. WSJT-X doesn’t tell me but I have the TX set to that. I don’t know if it detects other modes.

Steve




WA2TP - Tom
 

Rob,

I will be able to put the I5 test platform back online tomorrow. Will let you know when it’s up.
Sorry for the delay. Been very time limited

On Jul 6, 2022, at 8:33 PM, KD2OM <steve@...> wrote:

I will have to move some bands onto the AtomicPi to leave enough horsepower to set WD to decode FST4W on a couple more bands.

Steve KD2OM
On Jul 6, 2022, at 19:25, Glenn Elmore <n6gn@...> wrote:

It doesn't and that's part of our overall problem to improve uptake of FST4. WSJT-X only will tx/rx on one mode at a time, this means that people trying out FST have to agree beforehand. This dilutes the potential population and makes it seem like the entire protocol is vacant - except maybe on bands where there is a de facto mode (630m?, I don't k know).

WD greatly improves this (if we can get everything to decode and post properly which is the active pursuit) by simultaneously handling all modes.

Glenn n6gn

On 7/6/22 17:21, KD2OM wrote:
Glenn yes I believe it is mode 15. WSJT-X doesn’t tell me but I have the TX set to that. I don’t know if it detects other modes.

Steve