Scott,
I understand your opinions, but the purpose of FT8 and any other WSJT
operating mode is to communicate. I am sure those stations on 160m this
morning trying to work VK9MA on FT8 were quite frustrated with their
inability to communicate with the DX Station.
Try thinking outside the box. If someone wants to activate an IOTA,
SOTA, or rare county on a digital mode using a tablet, the ability to
recover a weighted average of the stations on the air is a obvious means
to set the framing time. Rather than carry a laptop and GPS receiver to
achieve the timing necessary for a WSJT mode, the operator would
probably just use one of the asynchronous digital modes.
VK9MA at Mellish Reef was the first time I copied a DXPedition on 160m
using one of the WSJT modes, and very few contacts were made because of
the timing disparity between the DX station and others calling. Framing
recovery from the received stations at the DX station is probably better
than having everyone turn off Dimension 4 or GPS receiver, and skew
their system clocks to match the DX station's frames.
The proliferation of the use of FT8 as a mode used by DXPeditions is the
reason I suggested the far end frame timing recovery as a DXPedition
OPTION. I hope the WSJT-X developers seriously consider this as an
option within WSJT-X instead of making all DXPeditions carry a GPS
derived timing source for their computers or networks.
73, Bill
N6WS
73, Bill
N6WS
On 11/11/2017 09:53 AM, Scott Bidstrup wrote:
On 11/11/2017 11:11 a.m., Bill Shell N6WS wrote:
Thank you David for your comment. You understand my original point in
asking for the option. All the other comments were trending to the need
for the system clock to be accurate. It is the framing that needs the
accuracy.
The several problems I foresee in using a timing average as a frame -
it's only as accurate as the average, and if the number of decodes is
small, and they don't happen to be particularly close and are off in
the same direction, the average may not be particularly close to the
correct time, so your framing reference gets set to the wrong time.
And before long, someone on the correct time may not get decoded.
The second problem that I can foresee is that, over time, if everyone
were to get lazy and just switch to using that option rather than
dealing with their system clock, sooner or later the average is likely
to drift away from accurate time as there's nothing to correct the
average frame reference other than probability statistics. And if you
come up with a new install, you're not going to get decodes (and a
framing reference) if everyone in your bandpass is six seconds off in
the same direction. So I don't see using average decode timing option
as being particularly wise - it creates a ticking time bomb (no pun
intended) that kinda defeats the whole purpose behind standard time
references.
A third problem comes when you're using a cheap Chinese clone computer
motherboard like I am that has a really terrible clock. It runs VERY
fast (a second and a half per hour) - and I have to set it twice a day
at minimum for decodes to be reliable. How would I set it to the
consensus time frame reference (problem 2) if that reference is no
longer the NBS standard? No way to do that that I can see when my
reference is far enough off that the decodes aren't decoding.
No, I think that sticking to setting the system clock to an NBS
reference, however derived, is a better idea. Just spring for the
twenty bucks and take a GPS dongle with you on your next DXpedition.
In fact, Amazon has one that is on a USB cable, so you can stick the
antenna out of the tent if you need to.
Scott Bidstrup
TI3/W7RI
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
