Hi Joe I think we are getting closer to understanding the problem with the JT9 tone shifts Rex and I have been seeing.
The issue is, that for operating EME with Doppler control enabled, we have to use Split or Fake it (the latter in my case). Else I get rig control errors. This was the mode you recommended we use when we started looking at WSJT-X, and have used it ever since, including my JT9 fast echo tests when this tone frequency "offset" became evident. With Doppler control off, and Split set to none, the tones are indeed on the correct frequency and I don't get Rig control errors, but can't properly use it for EME! 73 Charlie > Hi Rex, > > Many thanks for your helpful comments on code revision 5865. > > VK7MO wrote: > >> 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 > ... > > You must be set up to use Split (or "Fake it") mode? The fast JT9 modes > need up to 1800 Hz of bandwidth, so the intent is that the lowest Tx > audio tone should always be 700 Hz. For the fast JT9 modes, don't use > Split. > > >> 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 frequency of individual tones is a less useful concept with MSK > modulation at the speed used in JTMSK. There are hardly any real > "tones": for each symbol interval the Tx waveform is either half a cycle > at 1000 Hz or one cycle at 2000 Hz. As you can see in the average > spectrum, the resulting signal is smoothly peaked at 1500 Hz. > > True, specifying 1500 Hz as the Rx frequency is a different convention > than that used for other modes in WSJT-X. But arguably it makes better > sense than 1000 Hz, a frequency is well below the spectral peak of the > signal. > >> 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've given no attention to the simulator behavior in JTMSK mode. The > built-in simulator does not generate simulated pings, and JTMSK is made > for communication with very short pings. > >> 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. > > You can always try. I would be surprised if 10 GHz EME echoes ever have > enough coherence over 0.1 s to yield a decodable JTMSK signal. > >> 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. > > You may expect another alpha release very soon. > >> 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. > > Yes, it should not be too difficult to modify the correlation decoder in > this way. > > Thanks again for your help! > > -- 73, Joe, K1JT > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
