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

dan at irtelemetrics.com dan at irtelemetrics.com
Thu Jan 22 22:10:09 EST 2015


    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
 > 

  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GPSPosHoldOff.jpg
Type: image/jpeg
Size: 160671 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20150122/9175dfa5/attachment-0001.jpg>


More information about the time-nuts mailing list