On 19/01/2014 12:13, Edson W. R. Pereira wrote:
Hello Bill,
On Sun, Jan 19, 2014 at 8:52 AM, Bill Somerville
<[email protected] <mailto:[email protected]>> wrote:
On 18/01/2014 12:47, Edson W. R. Pereira wrote:
Hi Edson & All,
Hello Joe,
Compiled clean and running without issues on Ubuntu 12.04. I
had to add a few missing entries to lib/CMakeLists.txt.
I've added a call to PSK_Reporter::sendSpots() in
MainWindow::on_bandComboBox_activated() to flush spots to
PSKReporter before changing bands. This should prevent spots
being reported on the wrong band.
I'm not sure this change achieves the desired behaviour in all
cases. Decodes are effectively buffered in the audio input buffers
so there is nothing to flush from the current period when a band
change is made.
That is very true indeed.
Looking at the PSKReporter spot queue in WSJT-X it seems that queue
entries contain a frequency so I believe there is no implicit problem
with entries in the queue so long as they are added with a correct
frequency.
It may also be necessary to discard all spots destined for
PSKReporter that are decoded in a period where the Rx dial
frequency has changed either by the band dropdown or by the rig
VFO knob.
Yes. I am wandering how to best (read easier) way to implement this.
One possibility is to flag the audio detector object when there is a
band change. In this case when the buffer is full, it will discard the
buffer -- by not calling the detector. This way we could assure that a
corrupt buffer will not cause issues. What do you think?
I'm not sure that disabling decoding is a good thing, spots are
transient information and discarding a few doubtful ones is not an issue
for me, but discarding decodes is another matter. For example if that
rare one gets decoded, just as I arrive on a band or just after a leave
a band, I want to know about it even if I have moved. It may not be
feasible to give the correct frequency for a decode but it is still
useful information. Not having certainty about frequency makes it poor
spot information, but I know I've just moved, I can use the decode
information.
I would keep a "valid" flag that is set at the start of each period and
reset whenever a band/dial frequency is detected. Then only add new
decodes to the PSKReporter spot queue when the flag is set.
Unfortunately the decoding process is asynchronous and can continue into
the subsequent period to that which the message was sent. This last
fact makes it quite difficult to time the setting and resetting of any
such flag :(
The situation with Hamspots via JTAlert is more complex since the
decodes are used for more than just spotting so it would be rather
unhelpful to block all decodes going to JTAlert from a period that
the dial frequency changed in.
I am not familiar with JTAlert -- Lnux user here. One thing that has
crossed my mind is that the band info could be written along with each
spot to ALL.TXT and decoded.txt. This way the spots could be post
processed and the band info would be readily available. What do you think?
As discussed above, the frequency of a decode is not always certain. If
we were to export the state of the "valid" flag I suggest above along
with each decode; then JTAlert or any other user of the decoded info
could know the certainty of the frequency.
73,
-- Edson PY2SDR
73
Bill
G4WJS.
_______________________________________________
Wsjt-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/wsjt-devel
