Let me propose the following for dealing with a valuable DX whose clock, for 
whatever reason, is off.



In the world of Solar Eclipse Photography, a leading piece of software is 
Eclipse Orchestrator.  When photographing a Total Solar Eclipse, timing is 
terribly important.  Some of the events of interest last only for a few seconds 
or less.  In Madras Oregon, I did the following:



I had my FLEX-6500 set up as SWL and had WWV tuned in.  I played the audio over 
the RV speakers so I could hear it.  Then, I visually compared the time of day 
as displayed by Eclipse Orchestrator (which got it from the PC) to the WWV 
signal.  Here’s the key: Eclipse Orchestrator provides a delta-T knob that you 
can adjust to take out small differences between the actual time as you reckon 
it, and the PC’s notion of the time, which in the field, may be off and hard to 
reset.  This works beautifully.  My eclipse photos where on the nose, time-wise.



As I see it WSJT-X could do the same.  A knob could adjust WSJT-X’s notion of 
the time of day to “zero beat” the DX station, both in RX and TX so you can 
communicate, regardless of how far off the DX station’s clock may be.  As was 
said, the point is communication.  There’s no point discussing how he could 
improve his clock.  He’s on DX Expedition and he is what he is.  I want to work 
him.



I would seriously consider this proposal because FT8 is going to become a major 
player in the DX world.  I worked VK9MA last night on 20M, and my feet still 
don’t touch the ground!!!



Dave / NX6D







________________________________
From: Bill Shell <n...@n6ws.com>
Sent: Saturday, November 11, 2017 4:54:58 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] DXPedition System Clock Sync

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! 
> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsdm.link%2Fslashdot&data=02%7C01%7Ckq5stom%40outlook.com%7C0e69135da2bc4a27ec1108d52968375f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636460449933274476&sdata=dv3NAWbn0pG0%2Br13MXGi4hNXjHkj648GlKV%2BS1rVXeU%3D&reserved=0
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-devel&data=02%7C01%7Ckq5stom%40outlook.com%7C0e69135da2bc4a27ec1108d52968375f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636460449933274476&sdata=u18wGCjOUnYLORgQ0BD6WqBCjN7ClbyZhdYl2slS%2BBw%3D&reserved=0
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsdm.link%2Fslashdot&data=02%7C01%7Ckq5stom%40outlook.com%7C0e69135da2bc4a27ec1108d52968375f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636460449933274476&sdata=dv3NAWbn0pG0%2Br13MXGi4hNXjHkj648GlKV%2BS1rVXeU%3D&reserved=0
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-devel&data=02%7C01%7Ckq5stom%40outlook.com%7C0e69135da2bc4a27ec1108d52968375f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636460449933274476&sdata=u18wGCjOUnYLORgQ0BD6WqBCjN7ClbyZhdYl2slS%2BBw%3D&reserved=0
------------------------------------------------------------------------------
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

Reply via email to