Joe, I updated the users guide pages for WSJT to include a section on the auto sequencer. It includes a pseudo code description of how the iscat auto sequencer works. It is in the doc directory of the latest check-ins.
Thanks for the other comments. I look forward to the FEC version of JTMS. 73 de Bill ND0B -----Original Message----- From: Joe Taylor Sent: Tuesday, August 11, 2015 1:16 PM To: Bill Ockert - ND0B ; WSJT software development Subject: Re: A few JT9 Comments Hi Bill, I'm moving this discussion to wsjt-devel, since others will be interested. Many thanks for the comments. Obviously I need to deal with some issues you had already solved, for ISCAT. > 1. I was calling CQ and W3ZUP answered me while I had the auto sequencer > enable. I would not expect the auto sequencer to do anything in that > instance (I do not respond automatically to CQ replies with what I did > with ISCAT) When W3ZUP answered the auto sequencer jumped to TX1 but > without updating the call so still had call from last QSO. I should have insisted that a message must contain both "MyCall" and "HisCall" for the auto-sequencer to take any action. > 2. I double clicked on W3ZUP to get his call into the next messages. My > next decoded was of both W3ZUP calling me and of KB7IJ calling W3ZUP. > The auto sequencer changed the call to KB7IJ and moved me back to TX1 > calling him. Ditto to above. > It is my thought that the auto sequencer should not answer CQs nor > should it be changing the DX Call. Yes, that's important, too. > I was quite surprised to see the double decode as they were right on top > of each other. They were very similar in signal strength. The decoder looks intentionally for multiple messages -- possibly different stations, possibly a message that was changed in mid-transmission. There's another possibility, too -- not presently implemented in JT9, but in everyday use with WSPR. After one of these tightly defined messages is decoded, we know exactly what the Tx waveform was (up to small shifts in frequency and time, and possibly a small frequency drift). That waveform can be subtracted from the received time-domain data, and then another decoding attempt made. With WSPR, it works like a charm -- and often finds additional good decodes. > Just curious if it would be possible to have variants of JT9G and H with > the same bandwidth but with the nsps dropped down into the 12 (or so) > range so t_msg is short enough to accommodate meteor scatter on 144 and > 222? I understand the s/n advantage would drop accordingly but pings, > especially on 222, tend to be strong but very short. No, because the tones for each submode already have the closest usable spacing -- equal to the baud rate. But I am looking at another possibility: an extension to the JTMS protocol that would include FEC and standard messages like those in JT9. Might be able to try that within a week or so. -- Joe ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
