Re: [wsjt-devel] 7 Digit Callsigns

2020-02-20 Thread Reino Talarmo
Hi Matt, You should be possible to send CQ message without grid square locator and make contacts with the help on hashed call sign using automatic message generation. There strong limits what can be included into a single message, when the basic call sign is 7 characters long. As a workaround y

Re: [wsjt-devel] TImes being incorrectly recorded in ALL.TXT

2020-02-20 Thread Reino Talarmo
Martin and Bill, Yes, decoding do continue after the start of next transmission period. I do see sometimes many decodes after my transmitter has put full power out. I also do prefer that this issue is corrected as timestamps in ALL.TXT provide a nice comparison possibility e.g. for reception by two

[wsjt-devel] 7 Digit Callsigns

2020-02-20 Thread Matt VK3FDLL
Hi there, I'm using WSJT-X (WSPR Mode) for quite a while for receiving and now I've attempted to transmit. I am a Foundation Licence holder in Australia (VK), which means I have a 7 digit callsign - VK3FDLL With various tests, I can hear my WSPR transmissions away from my station and WSJT-X can e

Re: [wsjt-devel] Band change

2020-02-20 Thread Rich Zwirko - K1HTV
Christoph , Do we know for a fact that band change decodes (those following a dashed line w/o a band indicated) are actually submitted to PSKReporter? Maybe one of the Development Group can verify this. If this is actually happening, it should be corrected in a future update of WSJT-X. 73, Rich

Re: [wsjt-devel] TImes being incorrectly recorded in ALL.TXT

2020-02-20 Thread Martin Davies G0HDB
On 20 Feb 2020 at 23:10, Bill Somerville wrote: > Hi Martin, > > I suspect the ALL.TXT rows you are referring to were decoded after the > following period started. The algorithm for allocating to the Rx period > is simplistic and probably unchanged since times when changeover periods > were su

Re: [wsjt-devel] TImes being incorrectly recorded in ALL.TXT

2020-02-20 Thread Bill Somerville
Hi Mike, I'm not sure without reviewing the code, but it probably happens because the ALL.TXT writing has been abstracted into a common routine so as to make the format more consistent. 73 Bill G4WJS. On 20/02/2020 23:42, Black Michael via wsjt-devel wrote: Why aren;t the times for ALL.TXT t

Re: [wsjt-devel] TImes being incorrectly recorded in ALL.TXT

2020-02-20 Thread Black Michael via wsjt-devel
Why aren;t the times for ALL.TXT taken from the jt9 decode process which has to get them right since it's got the wav filename to work with? de Mike W9MDB On Thursday, February 20, 2020, 05:16:06 PM CST, Bill Somerville wrote: On 20/02/2020 22:01, Martin Davies G0HDB wrote: I'm r

Re: [wsjt-devel] TImes being incorrectly recorded in ALL.TXT

2020-02-20 Thread Bill Somerville
On 20/02/2020 22:01, Martin Davies G0HDB wrote: I'm running WSJT-X v2.1.2  0068f9 on a PC with Win 7 (Pro). Back in late January I posted a message, #5852, on ws...@groups.io about a 15-second discrepancy I'd observed between the times of FT8 decodes displayed in the Band activity window and t

Re: [wsjt-devel] TImes being incorrectly recorded in ALL.TXT

2020-02-20 Thread Black Michael via wsjt-devel
I just noticed the same thing today.  I had two decode periods that both showed the same time in ALL.TXT when I was debugging problem with JTAlert.  I confirmed they were two separate periods by decoding the WAV files manually. So the question is where does time for ALL.TXT come from and/or how c

Re: [wsjt-devel] TImes being incorrectly recorded in ALL.TXT

2020-02-20 Thread Martin Davies G0HDB
On 20 Feb 2020 at 16:12, Ron WV4P wrote: > The TX entry is probably because you hit the Watchdog timer.. set it short > and let it hit it a few times to duplicate. Sorry Ron, but I can't see how the watchdog timer figures in this at all, and in any event I know for certain that the timer wasn't

Re: [wsjt-devel] TImes being incorrectly recorded in ALL.TXT

2020-02-20 Thread Ron WV4P
The TX entry is probably because you hit the Watchdog timer.. set it short and let it hit it a few times to duplicate. On Thu, Feb 20, 2020, 4:06 PM Martin Davies G0HDB wrote: > I'm running WSJT-X v2.1.2 0068f9 on a PC with Win 7 (Pro). > > Back in late January I posted a message, #5852, on ws.

[wsjt-devel] TImes being incorrectly recorded in ALL.TXT

2020-02-20 Thread Martin Davies G0HDB
I'm running WSJT-X v2.1.2 0068f9 on a PC with Win 7 (Pro). Back in late January I posted a message, #5852, on ws...@groups.io about a 15-second discrepancy I'd observed between the times of FT8 decodes displayed in the Band activity window and the times recorded in the ALL.TXT file. The full

[wsjt-devel] decodes of old cycle falsely detected/reported as from new band

2020-02-20 Thread Bobby Chandler
Uwe I guess I misunderstood your problem. I thought the colors indicating needed calls etc were not correct after a band change. The adi file should be read when WSJTX starts, but at times I have had to rescan, for some reason, the file to make the colors respond to the needed calls etc. Sorry

Re: [wsjt-devel] Band change

2020-02-20 Thread Bill Barrett
Have the Flex 6700 so have multiple instances open. Found switching profiles just after the decode period works well and turning off the monitor ICON will also assure no decodes from the previous band. Hope this helps; Bill W2PKY On Thu, Feb 20, 2020 at 10:17 AM Rich Zwirko - K1HTV wrote: > Uwe,

Re: [wsjt-devel] Band change @ wsjt-x: decodes of old cycle falsely detected/reported as from new band

2020-02-20 Thread DG2YCB, Uwe
Here is what I mean: http://www.dg2ycb.duckdns.org/wsjt-x_band_change_bug.mp4 IMO band changes make sense most, immediately when one RX cycle has been finished, because of course I don't want to lose the next cycle. However, in practice this means +- 1 second before or after the end of one cycle

Re: [wsjt-devel] Band change

2020-02-20 Thread Christoph Berg
Re: Rich Zwirko - K1HTV 2020-02-20 > If you use the "Blank lines between decode period" option,disregard the > data below the separating dashed line which does NOT show the band on the > right side of the line. The point is, if wsjtx knows there was a band change with possibly mixed decodes, why

Re: [wsjt-devel] Band change @ wsjt-x: decodes of old cycle falsely detected/reported as from new band

2020-02-20 Thread DG2YCB, Uwe
To be more precise: The point is, that when doing a band change and the decoding process is still running, from the millisecond of the band change on, wsjt-x seems to allocate IMMEDIATELY all decodes to the NEW band, and not to the old band from which the wav file has been recorded. 73 de Uwe, DG2

Re: [wsjt-devel] Band change

2020-02-20 Thread Rich Zwirko - K1HTV
Uwe, Remember that for FT8 WSJT-X records a WAV file for 13 seconds then decodes it. If you switch bands in the middle of the receive cycle, you will record a mix of stations from both bands into the WAV file. When it is decoded, you will see a mix of decodes from both bands which you can't rely

[wsjt-devel] Band change @ wsjt-x: decodes of old cycle falsely detected/reported as from new band

2020-02-20 Thread Bobby Chandler
Did you rescan the adi file under the colors tab? Settings>Colors>Rescan ADIF File. Bobby/N4AU -- bob...@bellsouth.net n...@arrl.net ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Band change @ wsjt-x: decodes of old cycle falsely detected/reported as from new band

2020-02-20 Thread DG2YCB, Uwe
Hi Reino, Makes no sense for me. Would be an easy task to let wsjt-x remember the old cycle's band while decoding. In the past, JTAlert showed the same misbehavior, but then it was fixed. Is working well since then, and false-spotting due to band changes are successfully prevented. 73 de Uwe, DG2

Re: [wsjt-devel] Band change @ wsjt-x: decodes of old cycle falsely detected/reported as from new band

2020-02-20 Thread Reino Talarmo
Hi Uwe, That is feature and it is recommended to stop monitoring for the duration of band change and erase Band activity display. 73, Reino oh3mA From: DG2YCB, Uwe [mailto:dg2...@gmx.de] Sent: 20. helmikuuta 2020 12:20 To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] Band change @

[wsjt-devel] Band change @ wsjt-x: decodes of old cycle falsely detected/reported as from new band

2020-02-20 Thread DG2YCB, Uwe
Hi Joe, Steve, Bill et al., I don't know if it's already known: At WSJT-X v2.1.2 0068f9 after changing the band, remaining decodes of the old cycle are still falsely detected as from the new band. And likely, these decodes are then also reported to PSK Reporter or HamSpots for the wrong band. Woul