Hi Gary,
Because this reponse to your email may be useful to others, I am copying
it to the wsjt-devel ("WSJT Developers") email list.
AG0N wrote:
> If I am interpreting what I've done in testing correctly, the MSK144 tones
> center around 1500. Again, from what I've seen, if you double click an
> incoming
> signal, the tone shifts to the incoming (desirable). But if you call CQ after
> doing that double click, the tone stays at that shifted frequency, rather than
> resetting to 1500. I found that it WOULD reset by closing the program and
> reopening it again. I did not try switching modes and coming back to do it,
> so
> perhaps that would have done the same thing. I'm wondering if it would be
> good
> to reset to 1500 anytime the CQ line were triggered or an initiating call was
> made??? You've probably got a built-in limit to how far from 1500 it will go,
> but I like to know that I start at the same frequency every time.
By convention, the frequency of any of the FSK modes in WSJT-X is taken
to be that of its lowest tone. For MSK144, which actually uses an OQPSK
(Offset Quadrature Phase-Shift Keying) waveform, frequency is defined as
the center or "carrier" frequency. The transmitted frequency is always
1500 Hz.
At present, any decode in MSK144 mode (whether or not you double-click
on the decode) will set the "Rx Freq" spinner control to the frequency
of the received signal. Tx Freq always stays fixed at 1500 Hz. In code
revision 7076 these two controls are invisible. Probably we should
change this; making them visible, with the Tx control disabled so you
can't change its value from 1500 Hz, would be more informative.
> In contest mode, myself and a few others have found a small glitch. I realize
> this contest mode was probably a last minute addition when Steve talked to you
> about it and the immediate need for it for the contest over the weekend. With
> that in mind, I assume it will be expanded to accommodate different report
> requirements for the normal batch of contests during the year. But, regarding
> the way it worked this last weekend, there is a problem that can be overcome
> by
> the user if he is aware of it.
>
> Scenario: Two guys make arrangements via PJ or whatever to meet on MSK144.
> W1ABC calls K1XYZ. K1XYZ calls W1ABC but isn't heard by W1ABC. K1XYZ hears
> W1ABC, auto-sequence flips to TX4 and sends RRR. Per rules, W1ABC has not
> received the grid of K1XYZ, but upon hearing RRR, he flips to 73. QSO done,
> even though one grid was not exchanged. I hope I haven't confused myself in
> typing that up. Regardless, there is a method of having an auto QSO completed
> without full info transferred. Perhaps sending automated RRR can be inhibited
> without knowing the other stations call and grid? Currently, the workaround
> is
> for at least one of the two stations to call CQ, instead of calling the other
> station.
The User Guide will need to explain that "Contest mode" QSOs put some
extra onus on operators to be sure that they have received all required
information for the contest exchange. Of course you can always send a
message like "GRID?", or "PSE UR GRID?", or some such. But better
still, one should make sure that contest-mode QSOs start with someone
calling CQ or "running a frequency", as in HF-style contests.
> A few of us have been playing with QRA64a on 160/80m. I was amazed last night
> to see how it did through the wall of static crashes on those two bands. Both
> stations were 100% first time decode, even with one of them running 1W in New
> York on 80m.
Yes, QRA64 can be impressive with very weak signals! More work on QRA64
(and especially its wider submodes) is currently underway, and is
especially relevant for use of QRA64 for microwave EME.
Users should keep in mind that we consider the precise definition of the
protocol not yet frozen. We might change the sync pattern, for example,
in a way that is not backward-compatible. If this should happen, we'll
be sure to make suitable announcements about the need to upgrade. Old
versions would not be able to communicate with new versions. in that case.
-- Joe, K1JT
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
