Obtaining date/time from the Kiwi's GPS [fixed in v1.417]

rrobinetrrobinet
edited October 2020 in Configuration and Operation
A number of us are building Kiwi + Pi running wsprdaemon systems which will be solar powered and located at remote locations where there is no, or only intermittent, connection to the Internet.
In those installations the Pi's ntp service will have no notion of the current date and time.
Since the Pi has no hardware clock nor, I believe, does the Kiwi, we need a way for wsprdaemon running the Pi to accurately learn the time after a cold start.
I wonder if the GPS section of the Kiwi has or could learn the time from the GPS signal so the kiwirecorder recordings can be synchronized with the 2 minute WSPR cycle.
Of course there are hardware clock accessories for the Pi, but it would be very elegant and almost certainly more accurate if there where a way to obtain the time from the Kiwi GPS system.

Comments

  • rrobinetrrobinet
    edited October 2020
    That is a great solution. Thanks
    But I now realize that the date/time of the cycle is part of each spot posted.
    I'm sure I can work around that limitation, and there is always the Pi hat approach.
  • jksjks
    edited October 2020 
    v1.410,411  October 7, 2020
    GPS time-of-day (TOD) correction now works even if the Kiwi date is set incorrectly.
        Previously the Kiwi week day number had to match GPS for TOD correction to work.
        The GPS code currently does not know how to set the Kiwi date because it does
        not parse the GPS almanac.
    UR5VIBPowernumpty
  • rz3dvprz3dvp
    Hi, on the Internet lots of guides how config stratum 1 NTP server on Raspberry Pi with GPS board supporting PPS. I using this server for many years and it’s works good without Internet connection.
  • W6DRZW6DRZ
    Rob,
    Here are some notes regarding decoding WWV time code http://don.fed.wiki.org/view/decode-wwv
    Craig, W6DRZ
  • jksjks
    edited October 2020
    The Kiwi has an existing timecode extension that decodes a number of time station signals (not WWV-HF, but WWVB AM and PM, CHU, in EU: MSF, DCF77-AM, TDF, EFR)
    However the extension cannot currently set the Kiwi date/time and there is no automation, i.e. an admin setting that would cause the extension to run automatically occasionally (like WSPR autorun). But these things could be added. I'd have some interest in doing this.

    This may or may not make sense depending on where the Kiwis are located. The timecode extension is more of a demo and is not optimized for weak signal reception, error correction etc.
  • jksjks
    edited October 2020
    About the WSPR app supplying the date in its upload information: I was surprised by this too when I looked. I thought for sure the date information would be filled-in by the wsprnet.org database server. The uploaded date is probably error checked for reasonableness at least.

    Uploading the time I could understand because there might be a delay between when the spot was observed and when it was successfully uploaded. I suppose that argument could apply to the date as well if wsprnet.org were down for a period of time (which has happened).
  • WA2ZKDWA2ZKD
    I have had a old Pi as a Stratum 1 ntp server for years. I used an Adafruit module and all the computers in my house use it as the primary server.
  • n6gnn6gn
    Last night I took my portable wpsrdaemon/RPI3/Kiwi system with v1.412 out to a semi-remote site and collected WSPR and noise data. Previously (without GPS) it had been necessary to set the Kiwi clock so that WSPR spots would be nearly the correct frequency and also set the RPI3 date and time, since neither the Kiwi, the BB or the RPI have real-time clocks native to their hardware. This time I included a GPS antenna and I'm happy to report that the Kiwi seems to have done everything correctly. Not only did it get its own frequency correction correct but the BB also reported the correct date and time.

    Of course, the (remoted) RPI3 still had no idea when or where it was so that system date/time still had to be manually set in order for wsprdaemon to correctly frame wspr time slots and properly upload the correct ones to wsprnet.org and wsprdaemon.org. As John, suggests, date and time must be included in those uploads in order to qualify and properly add unique time stamps to the incoming data. I didn't try the on-board KiwiSDR WSPR extension but I have every reason to believe that it too would operate correctly off-Internet.

    I'm awaiting arrival of a real-time-clock add-on for the RPI so that the whole system can operate correctly without so much operator intervention (and usual screw-up!).

    Thanks John!

    Glenn n6gn
    Fort Collins, CO
  • rrobinetrrobinet
    wsprnet.org expects the spot's cycle date/time in each spot uploaded
    It is unclear to me what validation wsprnet.org applies to uploaded spots. The wsprnet API I use to scrape their site returns lists with gaps of up to 250 raw spot IDs, so they appear to be dropping some spots. In WD batch uploads, sometimes a few of the spots are rejected for reasons unclear to me.
    In any case, in this portable, battery-powered, Internet-connectionless application I will need the Pi running WD have a reasonably good idea of the current date/time to the second. Getting the minute/seconds accurate is the most difficult, and John's change in 410 addresses that well. I can work around getting the date from the user or other source.
  • jksjks
    edited October 2020
    This doesn't matter much because it isn't supported, but the BBB, BBG et al PMIC actually contains an RTC since it has provisions for running from, and charging, a battery source (hence the battery can run the RTC). But there has never been any standard Beagle distro software support for this, especially not in the old Debian 8 version the Kiwi uses. There are even empty pins on the BBB PCB (not sure about BBG) for adding the battery connector.
  • rrobinetrrobinet
    Is there any easy way to remotely access the Kiwi's date?
    I can run 'ssh root@kiwi.local date', but I'll need to set up the WD user on the Pi to auto-ssh-login to the root account on the Kiwi.
  • jksjks
    I could add it to the information returned by the /status URL. That's probably the easiest way.
  • rrobinetrrobinet
    yes, please do
  • n6gnn6gn
    I gathered remote off-Internet data again today and this time remembered to try out the Kiwi's WSPR extension with the new GPS additions.
    It appears to work correctly in the absence of any (functioning) RTC.
    Only a GPS antenna is required to properly decode WSPR though of course, to get it uploaded to wsprnet or wsprdaemon at a later time is another matter entirely.

    Even if/when wsprnet.org does acquire the data, only the map/table display reveals it since the API does not work properly. I haven't checked but I suppose it will also exist in the archive if one can wait for it.

    Data uploaded to wsprdaemon.org OTOH does seem to be available after the fact and the available tool sets that use that database can work on delayed data.

    Glenn n6gn
  • jksjks
    edited October 2020
    Okay, in v1.413 just released. See last line returned. Should always be in UTC. Parse with strptime() or equivalent in whatever language you're using. 
    kiwi# curl http://stucapon.plus.com:8073/status
status=active
offline=no
name=0.1-30 MHz Kiwi, M0AQY, England. (Wellbrook Loop) | Somerset, UK
sdr_hw=KiwiSDR v1.413 ? ? GPS ? ? LIMITS ? ? DRM ?
op_email=sdr@stucapon.plus.com
bands=100000-30000000
users=0
users_max=4
avatar_ctime=1602294579
gps=(51.180000, -2.550000)
gps_good=9
fixes=592
fixes_min=30
fixes_hour=254
tdoa_id=M0AQY
tdoa_ch=2
asl=165
loc=Somerset, UK
sw_version=KiwiSDR_v1.413
antenna=Wellbrook ALA1530
uptime=1281
date=Sat Oct 10 02:11:18 2020
  • jksjks 
    v1.417  October 30, 2020
    Allow GPS to set date/time. See admin page, GPS tab, new setting on top bar.
        Defaults to false.
        
        Before this can happen the GPS-to-UTC correction must be received from the GPS
        navigation message stream. This can take from zero to 12.5 minutes depending on
        the sat page/subframe transmission phase. The date correction has been tested
        using navigation data streams from Navstar, QZSS and Galileo.
        
        Only one date correction is performed per restart. However the previous constant
        correction of the system time (but not date) whenever it differs more than
        2 seconds from GPS time is still in effect.

    Added FAX extension frequencies for CN stations XSQ and an UNID per forum user Fabrys.

    So in the log you might see something like this which shows a date/time update via PRN-N02 (Navstar) from Oct 25 00:01:40 to Oct 30 04:56:07 
    
Sun Oct 25 00:01:38 00:01:33.488 ....        GPS/UTC +18 sec
Sun Oct 25 00:01:40 00:01:35.080 ....      L GPS correcting date: PRN-N02  weeks=2129(81+1024*2) weekSec=449767.5
Sun Oct 25 00:01:40 00:01:35.081 ....      L GPS correcting date: gps    Fri Oct 30 04:56:07 2020 UTC
Sun Oct 25 00:01:40 00:01:35.081 ....      L GPS correcting date: system Sun Oct 25 00:01:40 2020 UTC
Fri Oct 30 04:56:07 00:01:35.089 ....      L GPS correcting date: date/time UPDATED
    UR5VIB
Sign In or Register to comment.