|
Post by w9mdb on Jun 14, 2022 16:05:10 GMT
Doing a band change towards the end of a decode cycle (top of the minute) The band does not get displayed for the last decode This code will never execute the "> 14" clause as the decode line is printing out at 13 seconds So perhaps this should be changed to > 12? if (m_jtdxtime->currentMSecsSinceEpoch2() / 1000 - m_secBandChanged > 50 || (m_jtdxtime->currentMSecsSinceEpoch2() / 1000 - m_secBandChanged > 14 && m_mode == "FT8") || (m_jtdxtime->currentMSecsSinceEpoch2() / 1000 - m_secBandChanged > 6 && m_mode == "FT4")) { band = ' ' + m_config.bands ()->find (m_freqNominal) + ' '; }
|
|
|
Post by Arvo ES1JA on Jun 14, 2022 16:37:37 GMT
In general after doing band change in middle of period next decode may have decodes from both bands, in other words is not clear to which band decodes belongs, so it is safe not showing band in separation line.
|
|
|
Post by w9mdb on Jun 14, 2022 16:46:49 GMT
13 seconds since epoch and band change is not in the middle of the decode period at all. You definitely will not be decoding the old band.
Let's say Epoch = 0 Band change a bit after 0 m_secBandChanged = 13 (end of decode period) Matter of fact that could be > 12 or > 11 and you would still be decoding the new band....not enough info on the old one. So if you change band in the first few seconds of the decode period the new band wins.
Another related problem...the pskreporter call is using the "current" freq when the call is made instead of the freq at the start of the decode period which could be 1-3 seconds or so after the deocode starts. I think the freq at the start of decode should be saved and then used for PSKReporter. We are getting some false band reporting now when doing band changes related to all of this timing.
|
|