A Dsec would be useful where time is perfectly well synchronised but the
system incorporates a fixed and known delay, such as might exist on a
remote station where the audio stream is decoded locally.
Regards, Mark
On 06/05/2019 12:36, Bill Somerville wrote:
On 06/05/2019 11:49, Jay Hainline
Having just watched another station sending a "CHK TIMING" message in
FT8, which is obviously not likely to succeed...
I was wondering if a non-timing-critical "message" could be added to the
protocol, e.g. four continuous tones - or some such combination that is
unlikely to happen randomly,
Hi Bob,
could you also look at the scenario where Tx5 is being used to send qrz,
e.g. "QRZ EI3KD". A reply to this isn't handled well by auto-sequencing.
In fact, when doing this, it didn't even seem to be possible to
double-click on a caller to fill the fields, without halting tx first?
Hi Jim,
I concur re habitually unchecking "Lock Tx=Rx" when sending Tx6 ("CQ") -
I curse myself when I've forgotten to do it and someone calls me split,
consequently finding myself dragged off to their qrg. Calling cq and
then accidentally leaving the original qrg seems to be considerably
Bill,
I'm currently trying to capture some examples where the WSJT-X waterfall
appears to become corrupt with multiple images of signals, along with
multiple decodes - I see this fairly frequently when using FT8, and have
also seen it very rarely with JT65, including on older versions of
+/- 1.5s shouldn't present a problem to anyone, even, just about, for
people (e.g. some dxp) that rely on crude GPS NMEA serial data time
synchronisation.
In the (unlikely?) event that an even shorter DT window is ever
considered, I'd like to request that a small range of DT adjustment be
Hi Bill,
could it be implemented it such that, if set, "Skip Tx 1" is simply
ignored if the dx call is a compound callsign?
In fact the whole Tx1/RR73 thing might be boiled down to a more generic
option, like "minimal", or "optimise", or similar - i.e. attempt to use
the least number of
