|
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.
-- Rob Robinett AI6VN mobile: +1 650 218 8896
|
|
|
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.
-- Rob Robinett AI6VN mobile: +1 650 218 8896
|
|
|
No problem for me. Alternatively, you could transmit 4W using my AI6VN which would lead any listener back to your through me.
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.
-- Rob Robinett AI6VN mobile: +1 650 218 8896
-- Rob Robinett AI6VN mobile: +1 650 218 8896
|
|
|
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.
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.
-- Rob Robinett AI6VN mobile: +1 650 218 8896
--
Rob Robinett AI6VN mobile: +1 650 218 8896
|
|
|
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
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.
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.
-- 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.
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.
-- Rob Robinett AI6VN mobile: +1 650 218 8896
--
Rob Robinett AI6VN mobile: +1 650 218 8896
|
|
|
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
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.
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.
--
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.
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
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.
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.
--
Rob Robinett
AI6VN
mobile: +1 650 218 8896
--
Rob Robinett
AI6VN
mobile: +1 650 218 8896
|
|
|
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:
toggle quoted message
Show quoted text
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.
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
|
|
|
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
|
|
|
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
toggle quoted message
Show quoted text
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
toggle quoted message
Show quoted text
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
|
|
|
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
toggle quoted message
Show quoted text
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
|
|
|
