Hello Bill,
On Sun, Jan 19, 2014 at 8:52 AM, Bill Somerville <[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. > > 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? > 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? 73, -- Edson PY2SDR
_______________________________________________ Wsjt-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/wsjt-devel
