jks

About

Username
jks
Joined
Visits
29,786
Last Active
Roles
Member, Administrator, Moderator
Points
203

Reactions

508Helpful462Awesome

  • GPS Admin screen

    jksjks
    v1.60, to be released tomorrow, will fix a GPS bug that I finally understood today. Apparently, since v1.38 the GPS acquisition process has not been restarting after active users disconnect like it's supposed to. That will lead to the situation where the admin GPS page says "acq yes" (instead of "acq paused"), but there is no refresh icon shown in the "acq" column next to an incrementing PRN as is typically the case. The satellites that are already acquired and being tracked will be be fine until they drift out-of-range and are dropped. So eventually the GPS page will show nothing even though new satellites should be getting acquired.

    M0TAZWA2ZKDKA7U

  • GPS Admin screen

    jksjks
    Quick comment about the GPS page.

     Bottom row:
    "acq" Acquisition state, "yes" is acquiring new sats, "paused" if active SDR connections prevent acquisition of new sats.
    "tracking" Number of sats being tracked and appearing in one of the 12 GPS channel slots.
    "good" Of the sats tracked, then number of those that are considered good enough to compute a solution from (min 4 for a solution).
    "fixes" Total number of GPS position and time fixes computed.
    "run" How long the GPS has been running (H:M:S)
    "TTFF" Time-To-First-Fix, how long it took to get the very first solution after startup.
    "ADC clock" The GPS-measured true frequency of the ADC clock (nom 66.666600 MHz) In parens after are the number of computed corrections.

    Channel display: (this is a 12-channel receiver currently)
    "acq" Shows which channel the acquisition process is working with.
    "PRN" Sat identifier.
    "SNR" Signal-to-Noise-Ratio at time of acquisition. Min 16 to begin tracking.
    "gain" Goes negative if RSSI > about 1500 and software attenuation needs to be applied.
    "hold" How many bits in the current frame, out of 300, have been decoded.
    "wdog" Watchdog that will timeout and free tracking channel if bits are not being decoded. Different timeout values depending on channel state.
    "err" U = tracking loop unlocked. P = parity error. Momentary errors are not necessarily a bad thing.
    "subframe" Colored when GPS subframe correctly received. Blinks grey when updated. Subframes 1-3 required for position solution.
    "novfl" Number of holding register overflows (a debugging aid).
    "RSSI" Relative Signal Strength Indicator. Above 250-350 means sat actually present. Above 1000 is an excellent signal.

    M0TAZ

  • GPS Admin screen

    jksjks
    The GPS time displayed is the time computed when the last position solution was calculated. This can be arbitrarily delayed for a bunch of reasons. Maybe I should call it something else.

    First of all GPS time is offset from UTC by, what, 17 to 20 seconds now because of UTC leap second adjustments? So keep that in mind.

    Second, the GPS code I use, which is from Andrew Holme's wonderful Homemade GPS Receiver project (http://www.holmea.demon.co.uk/GPS/Main.htm), while excellent is not as sophisticated as what you'll find in a cellphone or modern GPS receiver. The maximum rate at which solutions are calculated is every 4 seconds under the best conditions. Not 10 times a second +/- like most GPSs. Modern GPSs also have better software & firmware algorithms that do better tracking and thus have better sensitivity. That's why they perform better even though we use the same front-end chip (and if you factor out the antenna differences).

    The GPS process of searching (acquiring) new satellites is stopped when there are active SDR connections on the Kiwi. Existing sats will continue to be tracked (and timing solutions calculated) until they eventually drift out-of-range. This is because the acquisition process uses an expensive FFT which cannot run simultaneously when there are multiple SDR connections. The Beagle doesn't have enough CPU to do all this work and still meet the realtime deadlines.

    So all these reasons are why the displayed GPS time will lag UTC, sometimes significantly. The GPS isn't used for anything except calibrating the ADC clock. And for that the timeliness of the GPS time measurement doesn't matter (only the difference between the last two GPS time calculations is used). Things like WSPR time presume accurate time is being received over the network (Internet) via NTP.

     
    M0TAZ

  • new WSPR decoder in release v1.54

    jksjks
    Okay, I see now what the problem is. The callsign hash table used for the new type 2 and 3 messages is allocated in an unfortunate way for the limited physical memory (500 MB) of the Beagle. I'll release a fix for that today. Until then please only run one instance of the decoder to keep it from crashing.

    WA2ZKD

  • Local Timeout

    jksjks
    For the next release I've changed it to ignore the inactivity timeout for local network connections.

    Ignoring it for password-required connections is a little more complicated because you can imagine people wanting that behavior to be configurable.

    WA2ZKD