Hi Joe
Some feedback on r5865. Some of this might be in the "cleaning up category" that you might prefer to fix at a later stage. JT9 Fast Modes We are still seeing the problem of frequency jumps on JT9 fast modes. Below shows the frequency set in the TX freq box compared to what is actually transmitted for JT9f fast mode. TX Freq setting (Hz) Freq Transmitted (Hz) 300 1800 400 1900 500 1500 600 1600 700 1700 800 1800 900 1900 1000 1500 1100 1600 1200 1700 1300 1800 1400 1900 1500 1500 1600 1600 1700 1700 1800 1800 1900 1900 2000 1500 You will see that it does TX on the correct frequency for TX settings between 1500 and 1900 (in fact up to 1999 Hz). I wonder if you use it at 1500 Hz and that this explains why you don't see the problem that we see. While we can overcome this by TXing on 1500 Hz (lowest frequency tone) it means the wider bandwidth fast JT9 modes go outside the passbands of our transceivers. I would be interested to know if anyone else has this problem or do they get the correct output if they set the TX frequency to say 700 Hz. I did wonder if this problem resulted from some legacy settings that we have used in the past but it seems to be there even if I delete all settings before downloading the latest version. JTMSK One thing to note is that when receiving, JTMSK reports the centre of the tones between 1000 and 2000 Hz as 1500 Hz which is a different convention to other WSJT-X modes that report the lowest frequency tone. The simulator gives either full output with no noise or only noise depending on whether the setting is +ve dB or -ve dB such as between #1 or #-1. In this respect it differs from the JT9 fast modes which work as expected with the simulator. I would be interested in your views on the relative sensitivity of JTMSK compared to say JT9f fast as we might use for EME echoes. JT4 I see that you have fixed a bug to overcome the problem that JT4 did not TX in r5865. I wonder if we could have an official windows version with this fixed so we can encourage all microwave EME users to use it. We have run into a problem with the use of the signal report format in conjunction with compound callsigns since G3WDG started going portable to Hungary and using HA/G3WDG. The basic problem, as you know, is that one cannot send both the compound part and a report in the same message as both use the same field. This is overcome, I think acceptably, by both stations exchanging compound callsigns before sending reports with just the non-compound part of the callsign. The problem then is that the correlation decoder does not recognise the non-compound part with a report. Would it be possible that if a compound callsign is used in either the settings or To radio boxes for the correlation decoder to search for reports in conjunction with the non-compound part of the callsign? In fact what this would mean is that under all circumstances (whether a compound callsigns is used or not) the correlation decoder would only look for the non-compound part of the message when looking for reports so it should not take any extra decoding time. The earlier exchange of the compound callsigns both ways should, I think, meet both the regulatory requirement and the QSO requirement to exchange both callsigns both ways. I would be reluctant to go back to the JT65 method of sending OOO with a # sync as I much prefer a report which conveys unknown information. Rex VK7MO
------------------------------------------------------------------------------
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
