Bill N6WS wrote: > the purpose of FT8 and any other WSJT operating mode is to communicate.
Of course you're correct, the purpose is to communicate, and to do that with any of the time-synced modes we have to have a reference. This subject, IMHO, is the most important usability item for the success of these modes; see my previous comments, below. I addressed these concerns to this list back on July 23rd and offered up 3 solutions, none of which were warmly greeted: --QUOTE-- "I was pondering this very subject this morning. Perhaps for the very tightly time-constrained modes a simple computation comparing the received delta-T's of all received signals could be made. If everyone else's clocks seem consistently wrong, maybe it's you! An indication of that made by turning the time readout red, perhaps, or by having an option to allow that derived time offset to be used to correct the clock time. A bit more convoluted solution would be to have a new 'time set' mode that DSPs one of the WWV signals. We're dsp and radio nerds, right? :-) A simple C/C++ ntp client could also be included either as an ancillary program that could be exec'd or built in to the GUI. There are some that are quite simple - less than 100 lines of code. They're crude, yes, but we're not looking for sub-mS precision here." --END QUOTE-- The reply I received from Bill G4WJS on the list was not enthusiastic about needing/wanting a time sync option and in fact relegated it to the realm of the absurd: > Hi David, > > there are many such set up issues that could be detected but we have to set > the boundaries of where one application manages. I certainly think time > accuracy is in the operating system domain or maybe a third-party utility and > not the responsibility of WSJT-X. Another out of domain example might be > seeing all signals are weak and suggesting that an aerial may not be > connected or maybe even to go and purchase a bigger one! Time sync is part of > building a station these days and as important as transmitting a clean signal > or many of the other things operators are responsible for when undertaking > this hobby. My direct reply was (in part, Bill's quotes from above in blue, indented): --QUOTE-- > > Time sync is part of building a station these days and as important as > transmitting a clean signal or many of the other things operators are > responsible for when undertaking this hobby. Only with the advent of the WSJT modes has good timekeeping been even remotely important. No other Amateur two way mode, digital or otherwise, is tied to the clock. > I certainly think time accuracy is in the operating system domain or maybe a > third-party utility and not the responsibility of WSJT-X. Since WSJT depends on such accurate timekeeping, wouldn't you want your program to guard against such a debilitating error? The program is essentially useless without an accurate clock, yet it's not in its purview to make sure that an accurate idea of the time is known? That would be like a browser not telling the user that the internet is not accessible. Consider this - frequency accuracy is in no way required by any of the WSJT modes - as long as you can hear a signal, you can decode it and reply to it, regardless of what my dial says. Why, then, is there a dedicated mode, along with a special frequency category to perform such exquisitely accurate frequency calibration? I think you'll agree that there have been many questions asked on the lists that fall under the category of 'set your clock'. I'm sure you also see signals on the air that are horribly off in time, causing QRM, frustration, and probably causing new users of the program to abandon the mode/program. I posit that having a way to set the time accurately (or at least warn the user that their clock is woefully off) is much more important and actually much more fundamental to the proper operation of WSJT-X than frequency accuracy. I think it would help usability (and it certainly wouldn't hurt) to have a startup option to check the system time against the NTP pool and use that offset when deciding when to tx/rx - as I said, I saw a C++ example that was < 100 lines (see URL, below). Since we already know the users grid square, we can easily map the closest regional NTP server for best accuracy. There are algorithms to eliminate network hop delay, and supposedly you can get very good accuracy -->https://en.wikipedia.org/wiki/Network_Time_Protocol#Clock_synchronization_algorithm NTP Client Example: http://www.mydailyhacks.org/2014/11/14/get-the-ntp-time-in-c-programm-via-a-simple-socket/ --END QUOTE-- Those are my two cents. Your mileage may vary. -- David Tiller Sr. Architect/Lead Consultant | CapTech (804) 304-0638 | dtil...@captechconsulting.com On Nov 11, 2017, at 7:54 PM, Bill Shell <n...@n6ws.com> wrote: > 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 ------------------------------------------------------------------------------ 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
