Yes. And no. 
This is going to be a SMOP issue. i.e. a Small Matter Of Programming
You will need a piece of software that can read the time from the GPS and then call the SetTheTime() function for the OS the tablet runs. Similar to how an NTP client can take the time from a time server over the internet and set the clock.
I didn’t find one in a quick search. Must exist. Must!
I searched for “android gps time sync” and got some good hits. A Stack Overflow article pointed out this app.
https://play.google.com/store/apps/details?id=net.sourcewalker.gpstime
Also, this article.
wunder
fwiw, without ROOT access, you’re only going to get GPS Time displayed (not sync’d), and the GPS Test app does a great job of this.
OK, thanks guys - if tablets (and other devices suitable for running FT8) could be locked to GPS time sync, this would remove one big hurdle when out of cellular coverage. Now to bite the bullet and pick up a windoze tablet or small laptop for portable data use.
Matt
VK1MA
Matt, fwiw there’s an inexpensive USB GPS dongle available on eBay. Try searching under “VK-172”, “u-blox 7”, and “GPS/GLONASS”. I have it working well on my Windows 7 laptop (with free BktTimeSync software), not yet quite there on my Windows 10 tablet.
Barry N1EU
I am also trying to get this going in W10. The BktTimeSync software wants to see a GPS. The u-blox 7 GPS/GLONASS shows up in device manager as a sensor not a GPS. Havent worked this bit out yet.
Compton
Compton, you might do a Web search for “ublox_a4_u5_usb_drv3264_install_ui” and download/install this driver.
On my W10 tablet, BktTimeSync starts and does a successful initial sync with the VK-172 dongle. But then it doesn’t seem to initiate any succeeding syncs, even though I configured it for 1 minute syncing. And if I try and initiate a manual sync, BktTimeSync hangs. It does this sequence every time I restart it. And as I said, under Windows 7 it does syncs every minute as expected and runs fine.
Barry N1EU
Thanks Barry, that was helpfull.
That gave me a com port to use so BktTimeSync is now happy. Syncs OK at 1 min intervals. Time.is isnt happy though as it says the time is 1.4secs out.
Compton
Compton, how big are the corrections that you see each minute when it resyncs? Are they all close (<0.1sec) or are you seeing a lot of large corrections on syncs?
Barry,
It is quite strange. Dimension 4 runs on the W10 laptop at start up and syncs at start up. Time.is is happy and reports time is exact. Then when I run the BktTimeSync with GPS it corrects by 0.5 to 1.4 seconds from what Dimension 4 has set it as. Time.is then reports that the clock is out by 0.5 or 1.4 or what ever seconds. I cant believe that the GPS clock is out by that much compared to a time server in my country plus I assume that Time.is is correct.
The 1 minute updates with BktTimeSync are around the 0.02 mark. Its just the first sync that seems very much out.
Compton
Its been quite some time since I transmitted in FT8 as my work load got crazy,
Is the propagation ok at the moment for QRP FT8 work? Only one guy in the Midlands heard me… (10W long wire on FishingPole)
I think it always is. Have a look at PSK Reporter to see. Display Reception Reports
Compton
This is where I realised that no station was coping me… 
Usually with 10w I hit EU well. (Thats months ago though)
A man with two watches… hahaha
Thanks all for this tread. It has been immensely helpful. I will likely try an FT-8 activation very soon. I am still not 100% clear on the “syntax” of an FT-8 SOTA QSO, but the ideas here have made things a lot better. I will give it a whirl.
FT8 Operating Procedures. I have been planning to do activations with the sensitive new FT8 mode in WSJT-X. With the compact and lightweight Microsoft Surface Pro computers, it should be quite possible to run my KX3 in VOX mode, per the arrangement used by ON7DQ and to use the single USB port for GPS time setting, Given the fact that this mode is more sensitive than CW, and may be easier for logging and sending CW during extreme cndx, I can’t help but think FT8 will become increasingly popular for SOTA.
I am curious how other people structure their standard FT8 messages. Certainly one could forego sending the grid locator and send a “random text message” such as “CQ W7GJ SOTA” (which is less than the maximum of 13 allowable characters). But a random text message is not decoded as readily as a “standard message” when signals are weak.
It also is possible call CQ as a standard message with a “directional CQ” using 2 letters between AA and ZZ. Using the standard messages provides more sensitivity and better reliable decoding. Since I figure I will be QRP anyway with my KX3 and battery power, it seems this might be the better option. Is there already an agreed-upon format for calling CQ SOTA in FT8? If not, I propose using “ST” as the directional CQ, so a standard CQ message would be “CQ ST W7GJ DN27”. I suppose that COULD be misinterpreted as a directional call for only stations in Sudan, but it seems that such instances would be rare, particularly if the ST were adopted by all SOTA users.
I have seen other comments about how to send the summit identifier and agree that it is best to send it at the end of the contact in a random text 73 message. An example would be “73 W7M/LM-099”, which meets the limit of 13 characters, and seems to be sent and decoded successfully with the current version of WSJT-X…
Does anybody have any comments of other ideas regarding the above and how we might go about setting an accepted standard to be used for FT8 during SOTA activations?
I think it would be good the have two letters to indicate that a CQ is for SOTA. I have activated 12 summits using JT-65 and two using FT8. Most of those were without posting alerts or spots. Even when spotted, few QSO have been entered in the database by chasers. I have found FT8 activations to be both fast and reliable, and not dependent on beeing spotted. I use a small ASUS transformer book laptop/tablet, running Linux. If I make sure the clock is in sinc, using ntp, when I leave home, the clock is ok on summit. When I did not do this, I was able to sync the clock using my phone to provide internet as a portable wifi hotspot, on the summit.
Hello,
for information : the new version of WSJT-X 2.0.0 (GArelease) is now available for windows, linux and macOS
for FT8, JT4, 9 and 65, QRA64, ISCAT, MSK144, WSPR and Echo.
here : https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
with documentation
good dx
73,
de Bruno F6HHK
I have not had a chance to work with WSJT-X 2.0.0 yet, but I have heard that it has some additional features added to the communications protocol needed for the upcoming ARRL RTTY (really mixed-mode keyboard-to-keyboard) Round-up and also that it is backwards-incompatible with older WSJT-X versions. First, will these updates make it easier, or more straight-forward to use FT8 for a SOTA activation compared to previous versions? And second, if it is incompatible with older versions, will it be better to still with the older version in the short-term for contacts to maximize the chance of completing an activation until more people have had a chance to upgrade?
Hmm, there are a couple of interesting mentions of SOTA in the WSJT-X guide for 1.9.1:
https://www.physics.princeton.edu/pulsar/K1JT/FT8_Operating_Tips.pdf
However, it seems to indicate that FT8, at least prior to 2.0.0, does not have enough bits to store the SOTA reference in place of the existing grid square field used in the first two messages of an exchange. It’s specifically encoded with the limited alphabet needed for a 4-character maidenhead grid square, but a SOTA summit reference is a bit longer. The final 73 message exchange, however has a little more room since there’s not much information content like first several messages have.
I wonder exactly how this’ll change with the newest release.
Hi Loren,
This has all been discussed on other threads on this reflector at length. A method of using the earlier FT8 was worked out but was not perfect. Your assumption is correct that with the extensions in version 2.00 which was officially relweased yesterday, there is now support for various contest exchanges, which could probably be used for SOTA as well. We do need the community to agree a model for SOTA for WSJT-x v 2.00 FT-8 communications however, otherwise it will get somewhat confusing if the format varies between Ops.
We also need to decide a few points about which mode should be used etc. this is being discussed at present on a different thread. 20m FT8 DX S2S event / attempt ? (which you are already part of I think).
73 Ed.