{5} Accepted, Active Tickets by Owner (Full Description) (3 matches)

The current logging setup for ogpsd logs lots of verbose ubx packet processing details at the DEBUG level and very little higher level information about the state of the SVs and the fix process.

I have attached a patch which attempts to make a start at fixing this with several changes: 1) All UBX packet parsing and processing is controlled by a separate logger under ogpsd.ubx to allow it to be controlled separately to the rest of ogpsd. 2) Add a message at INFO every time the "fix status" of the chip changes. 3) Add a message a DEBUG every time an SV changes state. 4) Add a message at INFO every X seconds with the state of every channel. X is configurable by the new svprint_interval parameter (defaults to 60 seconds). The state of every channel includes which SV is tracked, the state and other data from the NAV-SVINFO message, eg:

ogpsd    2008-09-07 21:54:04,909 INFO     ========
ogpsd    2008-09-07 21:54:29,874 INFO     SV State (3D Fix)
ogpsd    2008-09-07 21:54:29,881 INFO     ========
ogpsd    2008-09-07 21:54:29,889 INFO      SV11 *OE on Ch00 (Code lock) at 15 dbHz, Elev 40, Azim 138
ogpsd    2008-09-07 21:54:29,896 INFO      SV23 -OE on Ch01 (Searching) at 0 dbHz, Elev 43, Azim 169
ogpsd    2008-09-07 21:54:29,903 INFO      SV20 *OE on Ch02 (Receiving data) at 40 dbHz, Elev 77, Azim 80

The three characters after the SV name are the state (* if the SV is used for the current fix, - if not), orbital data present (O if almanac data is available for this SV, - otherwise), ephemeris data present (E if ephemeris data is available for this SV, - otherwise).

The patch also improves the use of UBX protocol values in several places by creating constants and lookup maps.

you can't call methods with an a{sv} signature

It looks like the argument string is splitted at " " before being parsed by GLib.Variant.parse