Hi Saku,

this is not really a defect. If you have "CQ Only" checked then non-CQ decodes are discarded and cannot be recovered. Un-checking the option causes the decoder to redo the decode on the sample buffer. The same applies to checking the "CQ Only" option except that CQ decodes are discarded. If you do not want duplicated UDP Decode messages nor duplicates in the ALL.TXT file then all I can suggest is that you do not use the "CQ Only" option. BTW it is possible that the repeated decode passes may have different results if the Rx audio offset, decode depth, waterfall width, or AP settings have been changed.

Pressing the "Decode" button can have similar effects.


On 06/04/2018 17:05, Saku wrote:

To what I previously said  I will add to that bug report also that:

Not only UDP datagrams get replayed without new flag set to false, but also ALL.TXT will get it's content added again with this replay's decodes. Both can happen so many times as one can do change of "CQ only" checbox state during ongoing receive period.

Now tested with r8603.

Saku kirjoitti 04.04.2018 klo 11:48:
Hi !

I'm currently testing with r8576 and it seems that today svn either do not response at all, or if it does it is very slow so I can not test with the very latest version. But when browsing commits there is no indication of this bugfix.

One minor issue with "CQ only":

If checkbox state is changed while period is running the previous decode is replayed to get just CQs, or all traffic, to Band Activity window.
This causes also replay on UDP side.

But this UDP replay has status flags set as "new decode". That is causing "doubles" in cooperating program as it assumes it is all new data.

Could this be fixed so that change in "CQ only" checkbox state (to any direction) could reset "new decode" boolean in UDP retransmits?

Thank you !

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
wsjt-devel mailing list

Reply via email to