Date
1 - 4 of 4
WD FST4W decoding does not affect WSPR decoding
Rob Robinett
Thanks to Tom WA2TP I have been running an experiment which compares two sets of 20M signals from the same 5 Kiwis at his site.
WA2TP is Tom's production i9 server running WD 3.0.3.1 configured to decode WSPR-2 and most FST4W modes: "MERGE_K123456,40,W2:F2:F5:F15"
WA2TP-2 is Tom's test i5 server running WD 3.0.3.1 configured to decode only WSPR-2: "MERGE_K123456,20"
As you might be able to see from the fuzzy chart below, WA2TP recorded 4308 spots over that period while WA2TP-2 recorded 4156 spots. So adding the FST4W modes did not degrade WSPR-2 decoding.
Some of the additional WA2TP spots many be FST4W-300 spots being transmitted by N6GN, but most of the difference may be due to WA2TP decoding with WSPRD_CMD_FLAGS="-C 10000 -o 4 -d"
while I mistakenly left WA2TP-2 set to WSPRD_CMD_FLAGS="-C 500 -o 2 -d".
I have just changed those settings on WA2TP-2 to match WA2TP, and I expect the next 12 hours to show an even closer correlation in spot counts between them.
You can watch the progress of that test at: http://wspr.rocks/head2head/
So those of you with enough CPU power and RAM to support FST4W decoding should feel confident that adding FST4W to your configurations will not degrade your WSPR-2 decoding performance.
Check out Arne's WSPR Mode Watch' Grafana page at https://wspr.live/gui/d/vhwRxD67z/wspr-mode-watch?orgId=1&refresh=1m to see your and other WD sites FST4W activity.
Ongoing studies by Glenn N6GN and Gwynn G3ZIL suggest that for reasons yet to be determined even the shortest FST4W-120 transmissions on HF bands may not be as effective as WSPR-2.
If our studies lead us to learn that the implementation of FST4W decoding, which differs slightly from that of WSJT-x, is the source of the impaired FST4W performance, then of course fixes will be put into WD.
73,
Rob
WA2TP is Tom's production i9 server running WD 3.0.3.1 configured to decode WSPR-2 and most FST4W modes: "MERGE_K123456,40,W2:F2:F5:F15"
WA2TP-2 is Tom's test i5 server running WD 3.0.3.1 configured to decode only WSPR-2: "MERGE_K123456,20"
As you might be able to see from the fuzzy chart below, WA2TP recorded 4308 spots over that period while WA2TP-2 recorded 4156 spots. So adding the FST4W modes did not degrade WSPR-2 decoding.
Some of the additional WA2TP spots many be FST4W-300 spots being transmitted by N6GN, but most of the difference may be due to WA2TP decoding with WSPRD_CMD_FLAGS="-C 10000 -o 4 -d"
while I mistakenly left WA2TP-2 set to WSPRD_CMD_FLAGS="-C 500 -o 2 -d".
I have just changed those settings on WA2TP-2 to match WA2TP, and I expect the next 12 hours to show an even closer correlation in spot counts between them.
You can watch the progress of that test at: http://wspr.rocks/head2head/
So those of you with enough CPU power and RAM to support FST4W decoding should feel confident that adding FST4W to your configurations will not degrade your WSPR-2 decoding performance.
Check out Arne's WSPR Mode Watch' Grafana page at https://wspr.live/gui/d/vhwRxD67z/wspr-mode-watch?orgId=1&refresh=1m to see your and other WD sites FST4W activity.
Ongoing studies by Glenn N6GN and Gwynn G3ZIL suggest that for reasons yet to be determined even the shortest FST4W-120 transmissions on HF bands may not be as effective as WSPR-2.
If our studies lead us to learn that the implementation of FST4W decoding, which differs slightly from that of WSJT-x, is the source of the impaired FST4W performance, then of course fixes will be put into WD.
73,
Rob
John
Well ! That is a disappointment for my station. I need to study the non FST4W hits.
John
TI4JWC
El viernes, 8 de julio de 2022, 01:51:13 p. m. CST, Rob Robinett <rob@...> escribió:
Thanks to Tom WA2TP I have been running an experiment which compares two sets of 20M signals from the same 5 Kiwis at his site.
WA2TP is Tom's production i9 server running WD 3.0.3.1 configured to decode WSPR-2 and most FST4W modes: "MERGE_K123456,40,W2:F2:F5:F15"
WA2TP-2 is Tom's test i5 server running WD 3.0.3.1 configured to decode only WSPR-2: "MERGE_K123456,20"
As you might be able to see from the fuzzy chart below, WA2TP recorded 4308 spots over that period while WA2TP-2 recorded 4156 spots. So adding the FST4W modes did not degrade WSPR-2 decoding.
Some of the additional WA2TP spots many be FST4W-300 spots being transmitted by N6GN, but most of the difference may be due to WA2TP decoding with WSPRD_CMD_FLAGS="-C 10000 -o 4 -d"
while I mistakenly left WA2TP-2 set to WSPRD_CMD_FLAGS="-C 500 -o 2 -d".
I have just changed those settings on WA2TP-2 to match WA2TP, and I expect the next 12 hours to show an even closer correlation in spot counts between them.
You can watch the progress of that test at: http://wspr.rocks/head2head/
So those of you with enough CPU power and RAM to support FST4W decoding should feel confident that adding FST4W to your configurations will not degrade your WSPR-2 decoding performance.
Check out Arne's WSPR Mode Watch' Grafana page at https://wspr.live/gui/d/vhwRxD67z/wspr-mode-watch?orgId=1&refresh=1m to see your and other WD sites FST4W activity.
Ongoing studies by Glenn N6GN and Gwynn G3ZIL suggest that for reasons yet to be determined even the shortest FST4W-120 transmissions on HF bands may not be as effective as WSPR-2.
If our studies lead us to learn that the implementation of FST4W decoding, which differs slightly from that of WSJT-x, is the source of the impaired FST4W performance, then of course fixes will be put into WD.
73,
Rob
WA2TP is Tom's production i9 server running WD 3.0.3.1 configured to decode WSPR-2 and most FST4W modes: "MERGE_K123456,40,W2:F2:F5:F15"
WA2TP-2 is Tom's test i5 server running WD 3.0.3.1 configured to decode only WSPR-2: "MERGE_K123456,20"
As you might be able to see from the fuzzy chart below, WA2TP recorded 4308 spots over that period while WA2TP-2 recorded 4156 spots. So adding the FST4W modes did not degrade WSPR-2 decoding.
Some of the additional WA2TP spots many be FST4W-300 spots being transmitted by N6GN, but most of the difference may be due to WA2TP decoding with WSPRD_CMD_FLAGS="-C 10000 -o 4 -d"
while I mistakenly left WA2TP-2 set to WSPRD_CMD_FLAGS="-C 500 -o 2 -d".
I have just changed those settings on WA2TP-2 to match WA2TP, and I expect the next 12 hours to show an even closer correlation in spot counts between them.
You can watch the progress of that test at: http://wspr.rocks/head2head/
So those of you with enough CPU power and RAM to support FST4W decoding should feel confident that adding FST4W to your configurations will not degrade your WSPR-2 decoding performance.
Check out Arne's WSPR Mode Watch' Grafana page at https://wspr.live/gui/d/vhwRxD67z/wspr-mode-watch?orgId=1&refresh=1m to see your and other WD sites FST4W activity.
Ongoing studies by Glenn N6GN and Gwynn G3ZIL suggest that for reasons yet to be determined even the shortest FST4W-120 transmissions on HF bands may not be as effective as WSPR-2.
If our studies lead us to learn that the implementation of FST4W decoding, which differs slightly from that of WSJT-x, is the source of the impaired FST4W performance, then of course fixes will be put into WD.
73,
Rob
Glenn Elmore
I'm not prepared to issue an early assessment of WSPR v FST4W. I think that would be premature. There are simply WAY too many variables to make any kind of clear and definitive statement yet - even if we thought we knew.
Until this gets sorted out, I suggest not jumping to any kind of general conclusions.
Glenn n6gn
On 7/8/22 14:29, John via groups.io
wrote:
Well ! That is a disappointment for my station. I need to study the non FST4W hits.
JohnTI4JWC
El viernes, 8 de julio de 2022, 01:51:13 p. m. CST, Rob Robinett <rob@...> escribió:
Thanks to Tom WA2TP I have been running an experiment which compares two sets of 20M signals from the same 5 Kiwis at his site.
WA2TP is Tom's production i9 server running WD 3.0.3.1 configured to decode WSPR-2 and most FST4W modes: "MERGE_K123456,40,W2:F2:F5:F15"
WA2TP-2 is Tom's test i5 server running WD 3.0.3.1 configured to decode only WSPR-2: "MERGE_K123456,20"
As you might be able to see from the fuzzy chart below, WA2TP recorded 4308 spots over that period while WA2TP-2 recorded 4156 spots. So adding the FST4W modes did not degrade WSPR-2 decoding.
Some of the additional WA2TP spots many be FST4W-300 spots being transmitted by N6GN, but most of the difference may be due to WA2TP decoding with WSPRD_CMD_FLAGS="-C 10000 -o 4 -d"
while I mistakenly left WA2TP-2 set to WSPRD_CMD_FLAGS="-C 500 -o 2 -d".
I have just changed those settings on WA2TP-2 to match WA2TP, and I expect the next 12 hours to show an even closer correlation in spot counts between them.
You can watch the progress of that test at: http://wspr.rocks/head2head/
So those of you with enough CPU power and RAM to support FST4W decoding should feel confident that adding FST4W to your configurations will not degrade your WSPR-2 decoding performance.
Check out Arne's WSPR Mode Watch' Grafana page at https://wspr.live/gui/d/vhwRxD67z/wspr-mode-watch?orgId=1&refresh=1m to see your and other WD sites FST4W activity.
Ongoing studies by Glenn N6GN and Gwynn G3ZIL suggest that for reasons yet to be determined even the shortest FST4W-120 transmissions on HF bands may not be as effective as WSPR-2.
If our studies lead us to learn that the implementation of FST4W decoding, which differs slightly from that of WSJT-x, is the source of the impaired FST4W performance, then of course fixes will be put into WD.
73,
Rob
WA2TP - Tom
I agree. I am seeing a very significant degradation in my 20m spotting today and I have changed nothing other than the WD changes made yesterday in adding the test system.
I am unfortunately away from the system to evaluate if there is a new RFI source.
I won’t be able to asses until I return next Wednesday.
On Jul 8, 2022, at 5:24 PM, Glenn Elmore <n6gn@...> wrote:
I'm not prepared to issue an early assessment of WSPR v FST4W. I think that would be premature. There are simply WAY too many variables to make any kind of clear and definitive statement yet - even if we thought we knew.
Until this gets sorted out, I suggest not jumping to any kind of general conclusions.
Glenn n6gn
On 7/8/22 14:29, John via groups.io wrote:
Well ! That is a disappointment for my station. I need to study the non FST4W hits.
JohnTI4JWC
El viernes, 8 de julio de 2022, 01:51:13 p. m. CST, Rob Robinett <rob@...> escribió:
Thanks to Tom WA2TP I have been running an experiment which compares two sets of 20M signals from the same 5 Kiwis at his site.
WA2TP is Tom's production i9 server running WD 3.0.3.1 configured to decode WSPR-2 and most FST4W modes: "MERGE_K123456,40,W2:F2:F5:F15"
WA2TP-2 is Tom's test i5 server running WD 3.0.3.1 configured to decode only WSPR-2: "MERGE_K123456,20"
As you might be able to see from the fuzzy chart below, WA2TP recorded 4308 spots over that period while WA2TP-2 recorded 4156 spots. So adding the FST4W modes did not degrade WSPR-2 decoding.
Some of the additional WA2TP spots many be FST4W-300 spots being transmitted by N6GN, but most of the difference may be due to WA2TP decoding with WSPRD_CMD_FLAGS="-C 10000 -o 4 -d"
while I mistakenly left WA2TP-2 set to WSPRD_CMD_FLAGS="-C 500 -o 2 -d".
I have just changed those settings on WA2TP-2 to match WA2TP, and I expect the next 12 hours to show an even closer correlation in spot counts between them.
You can watch the progress of that test at: http://wspr.rocks/head2head/
So those of you with enough CPU power and RAM to support FST4W decoding should feel confident that adding FST4W to your configurations will not degrade your WSPR-2 decoding performance.
Check out Arne's WSPR Mode Watch' Grafana page at https://wspr.live/gui/d/vhwRxD67z/wspr-mode-watch?orgId=1&refresh=1m to see your and other WD sites FST4W activity.
Ongoing studies by Glenn N6GN and Gwynn G3ZIL suggest that for reasons yet to be determined even the shortest FST4W-120 transmissions on HF bands may not be as effective as WSPR-2.
If our studies lead us to learn that the implementation of FST4W decoding, which differs slightly from that of WSJT-x, is the source of the impaired FST4W performance, then of course fixes will be put into WD.
73,
Rob