Readers of the writelog@contest.com list already know: there are lots of
DigiRite comments following the WW Digi Contest. Thank you for all of
those. We are reading them and will respond to them in an order that I
am sure you will find at best mysterious, or maybe even annoying. I
start with this one.
Quoting part of the data from NV6D:
> For radio 1: sample size 202247, mean 0.318, std dev 0.316.
> Radio 2: sample size 121571, mean 0.288, std dev 0.409
> When transmitting, I usually see:
>
> 14:54:29 TX: WT8V NV6D CN80
> 14:54:34 145430 34 0.1 1829 + WT8V NV6D CN80
As you have noticed, in some sound board configurations (i.e. yours) the
DigiRite decoder hears its own transmit audio. And I agree that you
should expect small DT's (i.e. close to zero) when that happens. I do
not know for certain why you are getting your results, but I have some
ideas.
> So does all this data mean anything?
If the DT's trend either longer or shorter during a DigiRite run, it
definitely would mean something is getting systematically distorted
w.r.t. to the FT8/FT4 defined clock. But if they appear scattered
randomly, then its more likely the cause is something external to
DigiRite. Are you seeing a trend in your log file? If so, it might have
something to do with reports of decoding getting less reliable toward
the end of the contest period.
...and I'll ramble about some details....
I expect your results are representative, i.e., I would guess others
would get similar DT results. The "0.1" value that appears typical
happens to be the result of a design choice in DigiRite that was
arbitrary. That is, the exact start time within the 15 sec (or 7.5 sec)
cycle is not particularly well defined by any written standard, but, for
us users of the wsjt-x source, is really set by whatever the wsjt-x
codes happen to do. And even those are not rock solid consistent from
release to release. I quit fiddling with DigiRite's TX timing when its
DT of its own transmitted signals settled at 0.1 because that same
experiment done with wsjt-x 2.1, on the same machine, copying the same
transmitted signal, its DTs were closer to 0.0. This indicates that
DigiRite probably starts its decoder, on average, around 100msec too
early with respect to what wsjt-x does.
"Windows is not a real time system". Numbers in the 100msec range are a
little small to be taking very seriously, and even the wsjt-x decoder
itself appears to have a +/- 100msec precision on its DT printout. But
we can reasonably guess because DigiRite uses Windows to schedule
something at a particular time, but it fails to happen at that time, it
will happen late and not early. DigiRite calls the decoder (which is
taken verbatim from the wsjt-x sources) on such a schedule. And DigiRite
calls its transmit code also on such a schedule. When you see positive
DT's I assume it means the transmit cycle was delayed and when you see
negative DT's I assume it means the decoder was delayed for that
particular cycle
I can think of no particular reason that one or the other would be
delayed more often, so I share your puzzlement that the DTs skew toward
positive values (indicating the TX was delayed w.r.t. the decoder.)
Wayne
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web: http://www.writelog.com/
|