Good Morning Rex, Thank you for the reply, it is useful to know I am looking at an actual problem.
Started digging into the protocol specification and the code last night. I am quite a ways from understanding the code completely but did get the general outline and have added some comments. Now that I know I am looking for an actual issue I have a bit more focus. One of the things I did notice, which is obvious from how it is reported, is that the decoder is only putting the strongest decode into the files. This is significant as the strongest decode may not be the best decode. I can understand why the choice was made but think the decision on what should be reported needs to be moved up to a higher level in the code. What I am up to is there is a group of us who have started playing with short sequence ISCAT-B to take advantage of short Es openings on 6m. While JT65 (HF style) is getting popular on 6m it is not unusual for an attempt to fail either because the opening closed or because meteor scatter pings hosed the decode. ISCAT gets around this by having shorter sequences and being somewhat immune to ms pings, at times even taking advantage of them. Using ISCAT to best advantage on 6m involves a few changes to ISCAT which you might be interested in: 1. Added 5 and 10 second sequences so now supports 5, 10, 15 and 30 second sequences. 2. Added support for alternate messages (Cntl-G) which adds both calls to TX3 - TX5 3 Added an auto sequencer to step through the TX sequencing based on received messages. The auto sequencer is very particular about when to advance. On messages containing the calls they must match exactly. On messages containing reports the structure is checked exactly and I am in the process of adding bounds checking. RRR and 73 must match exactly. These detail put the auto sequencer in a position to walk through multiple decoded messages finding the one that is both the correct decode and the strongest and then both acting on and reporting that one. Consequently I was already planning an expedition into the decoder code. This just pushes me along. Again, thank you for the feedback. I will be looking hard for the RRR issue. If you are interested in the work we are doing there is a Yahoo group where the current EXE is distributed and information distributed, WSJT_SS_ISCAT. 73 de Bill ND0B From: Rex Sent: Wednesday, June 17, 2015 4:53 PM To: Bill Ockert - ND0B ; WSJT software development ; David Smith Subject: Re: [wsjt-devel] ISCAT RRR Decode Hi Bill I have noticed similar problems with sending just RRR on its own on 10 and 24 GHz aircraft scatter where RRR often comes out as RRT or RRS. We have also tried sending R R R as you did and this does seem to solve it but at the expense of extra time which we often don't have on very short aircraft scatter bursts. Your finding that SSS works well is useful and might give a clue as to what is causing this and what might be the solution but as it does not happen all the time it will be worthwhile your testing that the SSS result is always consistently good. David VK3HZ and I commented as below in a DUBUS article 2015 vol 1 (it might have been 2014 vol 4 as I don't have it with me) on 10 and 24 GHz aircraft scatter. It would certainly be good to find out the reasons and any solution that still allows the use of the shortest messages. 6. Decoding of RRR We often see RRR decoded with only two of the Rs correct such as RRS. It seems this error is due in some way to having three of the same tones in a row together with Doppler shift in the signal. In addition to the RRR one also sees the length of the message in the first column as 4. As it is unlikely that any message with two RRs and a length of 4 would be other than RRR (i.e. beginning-of-message plus 3 characters) we have taken the view that two RRs in a message of length 4 is sufficient to confirm that RRR is being transmitted. It is also possible with some experience to decode RRR and 73 by ear. 73 Rex VK7MO On 18/06/2015 5:30 AM, Bill Ockert - ND0B wrote: Good afternoon, Several of us playing with ISCAT on 6m have noticed that it has a difficult time decoding the RRR message regardless of signal strength. This is occurring both with the standard RRR message in WSJT 10 and with alternate messages in an experimental version of WSJT we are using. Typical non decode is as follows, note the consistency 180545 4 -3 3.1 -43 0 * ND0B W5LDA -6 14 10 10 2.2 180615 3 -2 11.5 -43 0 * ND0B W5LDA RRT 15 5 10 1.1 180645 6 -2 12.6 -43 0 * ND0B W5LDA RRT 15 5 10 2.2 180715 3 -2 11.5 -43 0 * ND0B W5LDA RRT 15 5 10 1.1 180745 2 -5 2.6 -43 0 * ND0B W5LDA RRR 15 6 10 2.2 180815 6 -2 14.3 -43 0 * ND0B W5LDA RRT 15 5 10 2.2 180845 2 -3 4.2 -43 0 * ND0B W5LDA 73 14 10 10 1.1 As an experiment we put spaces between the Rs, this decoded every time 181045 8 -2 9.8 -43 5 * ND0B W5LDA R R R 17 5 10 4.5 181115 8 -2 9.3 -43 5 * ND0B W5LDA R R R 17 5 10 4.5 181145 8 -2 11.5 -43 5 * ND0B W5LDA R R R 17 4 10 4.5 As a further experiment we changed it to SSS... again decoded every time 182115 3 -2 9.8 -43 0 * ND0B W5LDA SSS 15 9 10 1.1 182130 0 -20 0.0 0 0 0 0 0 0.0 182145 3 -2 2.0 -43 0 * ND0B W5LDA SSS 15 10 10 1.1 182200 0 -20 0.0 0 0 0 0 0 0.0 182215 3 -2 1.5 -43 0 * ND0B W5LDA SSS 15 10 10 1.1 Any thoughts on where I might start looking for this issue would be greatly appreciated. This is happening on 10.0 5490 release as well as the experimental version I developed. It also happens with just the RRR message. Thank you! 73 de Bill ND0B ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
