[time-nuts] Ublox 6T receiver, noisy PPS.

[Azelio Boriani]

Now I suggest to wait for the next noisy event and try to force the
position hold mode using the CFG-NAV5 message, dynModel= 2. Actually
the UBX protocol description is not very clear about how to set (that
is force) the position hold mode. The GPS has a static hold (see 2.4
page 3 of the G6-SW-10018-C manual) that says "until there is evidence
of movement again", so it is possible to jump out of position hold if
something strange is seen by the navigation input and output filters
(see 2.2 and 2.3 on page 2 and the staticHoldThresh parameter in the
CFG-NAV5 message). Maybe that playing with the staticHoldThresh
parameter (increasing it) can solve the issue. The default setting of
the parameter is 0.00m/s (see appendix A.3 page 196).

On Fri, Jan 23, 2015 at 4:10 AM,  <dan at irtelemetrics.com> wrote:
>     Azelio, Tom and Bob,
>
> A test with hold mode turned off was/is a good idea. I tried that for a few hours afternoon, See attached image. By eye it looks a little more erratic than the 'noisy' data, but the errors were pulling the EFC up and down a bit here too. My guess is that the wander is exaggerated a bit by the control loop. For this data the EFC moves around about two or three times worse than what HVAC cycles would do, but at noticeably shorter periods.
>
>  I would tend to think the guess is correct that the GPS dropped out of position hold mode. It's very curious that is was not reported back to the u-center application upon polling the fields. It would be nice to have more GPS related data in the log file. The possibility of adding more data is not out of the realm of reason.
>
>  As for Bob's suggestion to log more stuff, currently a bunch of data is being recorded. I just omitted most of it here. No reason to expose everyone to the results of data dysentery! ;)  Things like OCXO oven monitor volts, OCXO case temp, system supply voltage, EFC DAC volts, room temp are being logged to uV levels every 20 seconds with a 24bit DAQ card. The GPSDO is also logging it's own on board temp sensor, phase comparisons, GPS saw tooth, UTC, and EFC DAC value, and a few other internal goodies every second. It sounds like more GPS related stuff needs to be added to this list somehow...
>
>  The bottom line is, it looks like something happened to the GPS. Unless any of you have suggestions on improving the GPS configuration/settings, the plan is to continue to run as is. If anything else weird shows up at least I know what to start looking at.
>
>
>  Thanks all,
>
>  Dan
>
>
>
>
>
>> OK, my opinion is that the GPS was not in position hold mode during
>  > the noisy period. Maybe due to an internal error or whatever, the GPS
>  > quitted the position hold mode. Try to add to the software the ability
>  > to log the GPS actual status so that if this error will return you are
>  > able to see what happened to the GPS. In order to confirm (or not) my
>  > opinion, you can try to run a test where the GPS operates in the
>  > standard navigation mode and see if the wander is the same as the
>  > noisy period.
>
>
>
>> I echo what Azelio is saying. During the time when you are
>  "evaluating" a GPS receiver it is important to collect as much data as
>  possible, just in case you need to go back and correlate unusual
>  events. I tend to turn on all possible binary messages and collect tens
>  or hundreds of MB. You never know what you will uncover hidden in the
>  data.
>  >
>  > But even collecting as little info as date, time, number of SV
>  visible and locked, signal strengths, and solution mode (3D, 2D, 0D)
>  once a second is a good enough summary for most purposes. I also log
>  lat/lon/alt because if that varies then you know you're no longer in
>  position hold mode.
>  >
>  > You can confirm Azelio's prediction below by manually forcing it to
>  3D for a while and see if that suddenly matches your "noisy" data.
>  >
>  > /tvb
>
>
>  >
>  > Hi
>  >
>  > I think I would add a few things to the logging list as well:
>  >
>  > 1) Filter state in the the controller (if it’s multi state).
>  > 2) EFC voltage, either directly with a DVM , or as a DAC setting.
>  > 3) Temperature, even as an once a minute output from a cheap USB
>  temperature gizmo.
>  >
>  > That’s not to say that any of the above is likely to be a big
>  issue in solving the current problem. You never know what will come up
>  next …
>  >
>  > Bob
>  >
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.