synchronization of the ADIS16488 with GPS

I am interested in an integrated IMU/GPS system using the ADIS16488 and a GPS device such as Novatel's OEMStar low cost GPS receiver. A key requirement is that the IMU and GPS data be precisely synchronized. The GPS receiver produces a TTL timing signal at the exact time when the GPS data was measured -- accurate to nanosecs. Typically a once-per-sec (1PPS) receiver data output is requested from the receiver -- although higher data rates may be used such as 20Hz. Also, using the OEMStar we can generate a second higher-rate timing signal using the OEMStar receiver. For example a 100Hz signal synched to the 1PPS can be produced by the receiver specifically for synchronizing other measurements. The serial GPS data (raw per satellite data) from the GPS receiver comes out a few msecs after the 1PPS signal.

An integrated IMU/GPS system will use a high-rate IMU datastream to interpolate the lower rate GPS data for wide bandwidth motion scenarios. Also, the integrated IMU/GPS data will produce an estimate of the attitude as well as the position that results from GPS alone.  The key is that the IMU serial data and the GPS serial data must be synchronized -- to <msec accuracy.

The ADIS16488 seems to have anticipated this (see page 30/36 of the specification) where a "Input Synch/Clock Control" is described. However, there is little descriptionof this functionality. Ideally, we need to keep the internal IMU sampling at a high rate (9.84KHz) and use the decimation (figure 20) to result in an output rate that matches the input synch rate. The output deltaV and deltaTheta should represent sums over the requested synch interval. This is the way a conventional IMU (e.g., Honeywell HG1700) works. From the note on the bottom of Fig 20; it appears that the input synch command triggers a single 4-sample measurement burst at the 9.84KHz -- so that the sums do not persist at the high rate.  We only get 4-sample averages at the high rate and then no further sampling until the vext synch pulse is received.

The integrating microcontroller for the IMU/GPS should work by receiving the 1PPS and higher-rate signal (e.g., 100Hz) from the GPS as interrupts. The IMU data-read is performed  in the Interrupt Service Routine for the higher-rate GPS signal. This allows us to form a table for each second (or each complete raw measurement interval) where the IMU data is tagged from 0-99 where the 0-tag represents the time-of-validity of the GPS raw data. What would be most desirable would be to simply input a command synch signal on the IMU DIOx line and have the IMU output the delta-V and deta-theta at this input same rate. 

Is there any way to set this up using the current ADOS16488?

  • 0
    •  Analog Employees 
    on May 11, 2012 12:54 AM

    Hello Jekain314!

    It looks like you have done a great job in studying the ADIS16488 datasheet and made correct assessments in its function. The ADIS16488 cannot be setup to start sampling on a single sync input, but I appreciate you offering that as an idea. Here are some thoughts and questions, which may help us move down a valuable path for your system:

    • If we let the ADIS16488 free-run, the largest time difference between the GPS clock and a data point would be ~0.2ms.  You mention "<msec" above, but I wasn't sure if this could be quantified any further.
    • You mention 100Hz as an example sample rate. Do you have a desirable sample rate for the inertial data?
    • Can you envision developing a 2.4kHz clock circuit, that is synchronized with the 1Hz GPS signal from your unit?  The faster sample rate will allow you to over-sample the 330Hz sensor bandwidth and will give you the maximum frequency resolution for filtering out any undesirable inertial response (noise, vibration, etc).
    • If you desire slower update rates, the decimation filter provides an opportunity to lower the output data rate, while also reducing out-of-band influences.

    Very best regards,

    NevadaMark

  • NevMk ..

    The IMU will likely be used for motion control where its accels and rotation rates are used for stabilization; e.g., a UAV or a pointing antenna -- or maybe just for monitoring vehicle motion. Generally a 100-200 Hz rate for the deltaV and deltaTheta is suitable for most motion applications. Really a bit of overkill for vehicle systems that have dominant motion bandwidths in the 10Hz range. But the benefits of the high-rate internal summations to achieve the deltaV and deltaTheta is the elimination of any high-rate vibration-type of motion -- sometimes called coning/sculling. Not compensating for this oscillatory motion destroys the ability to get good attitude. This is really why we like a high internal sample rate with the decimation to get to a lower output rate more manageable by the computer. Historically this is this the way the mil devices have worked.

    The deltaV and deltaTheta go into a "Strapdown Navigation Algorithm"  that mathematically integrates the reduced-rate decimated samples, but because of the internal high-rate sums, the processing compensates for the vibration/oscilation motion (> 100Hz). This is necessary to get a good attitude solution by the inytegration of GPS and the IMU. So to your question -- 100-200 Hz is a good target output for most motion sensing work.

    The extra circuit that you describe as a separate clock system that is PLLed to th 1PPS is exactly the way we do it now. But this demands a separate microcontroller that does this. Not a big deal -- but we would like a higher level of design. Why should we pay to develop this simple circuit when it can be so easily included in your device?. I want to buy a GPS receiver part and an IMU part and wire them together to a real computer (e.g., a COM or DSP) and just do high-level navigation software. The details of this synch process should be in your stuff and out of sight -- with specs on the relative accuracy of the timing/synch.

    The IMU is a motion interpolation device used to stabilize something else that has other types of events. In our case its precisely triggered digital cameras and GPS measurements that occur based on some other system criteria. We would like to feed to your device a discrete signal (e.g., on your existing DIOx pins) and have you generate the fast deltaV and deltaTheta  data (but not too fast  -- 200-Hz or so). We would send in a discrete (or maybe more than one) that is an "event" mark.  We would provide a preferred output rate for the decimated data as a part of the setup. You would report back, as a part of the data message, a counter that gives us the time since the event (in 200Hz clock units). Thus for a GPS 1PPS event and a requested output rate of 200Hz, we would get a full IMU data report every 5msec that includes a counter that goes from 0-199. We read the GPS data in our high-lever computer and we now know exactly how to synch the information. We just read the two independent serial data streams and we have the relative timing of all the motion measurements and external events. The GPS serial data will have some latency wrt the "0" event mark just cause of the serial message delay -- but we can deal with that in the software.

    To complete the use of the IMU as the timing/synch brain of all this, we would need to input separate events for "time synch" and "external events". In our case the "time synch" would be GPS -- indeed this may become a standard input option. The out-rate is then synchronized to this DIO line to XX usec and the counter gves the relative time to this mark. But we also need to another input discrete (e.g., a camera trigger event) and you would also mark this in the output. So your output would make use of a spare byte somewhere   to give us the counter as well as the occasional occurrence of the othe external event. The good news is that all this is simply a firmware update on your end -- you already have the inputs and the setup functionality.

    To the question of how good does the synch need to be: The GPS event pulse is good to nanosecs. For commercial stuff, the translation velocities are on the order of 50m/sec and the rates can be several 100 deg/sec. The key here is that GPS carrier phase can now be provided to an accuracy of 1mm -- even for the $100 class GPS receivers. If you are matching the integrated accel from the IMU with the GPS carrier phase to get the attitude, you will need to maintain a <1mm integrated velocity accuracy to get the full benefits of the GPS carrier phase integration. With a 1msec timing error at 50 m/sec, this would result in a giant 50mm error!  So as we look to the future, GPS can easily give a event mark to 100nanosec accuracy so you may want to give us synched IMU samples to the order of usec.

       --- Jim

  • 0
    •  Analog Employees 
    on May 30, 2012 4:31 AM

    Thank you again for this feedback.  We appreciate your insights and as discussed, will give this added functionality consideration in our next generation IMUs, which are based on the ADIS16488 architecture. Many thanks and best wishes on your design efforts. We look forward to hearing of your progress.