ADIS16505 Scaled Sync Mode with GNSS PPS Signal Reports DIAG_STAT = 0x8000 (Clock Error)

Hi, thank you for posting this question.

In IMUs like the ADIS16505, the external clock signal, such as a 1 Hz PPS from a GNSS, is scaled internally to synchronize sensor data sampling. This ensures that data sampling remains consistent with the external clock, maintaining accurate timing across data sets. The IMU also monitors the integrity of this clock signal, setting error flags like the 0x8000 in the DIAG_STAT register if it detects deviations due to noise or signal drop, indicating synchronization issues. 

Even if the PPS signal appears stable, high-frequency noise or short-duration anomalies might not be visible without specialized equipment. Consider using a high-bandwidth oscilloscope to check the signal more thoroughly for precision and repeatability (Share these measurements). 

Another suggestion is to test the system with a different clock source to see if the issue persists.

Second Querry: Clear error flags in the DIAG_STAT register require specific action, such as writing to a register or power-cycling the device, as burst reading doesn't achieve this.

   I will try to get an oscilloscope capture of the PPS signal as close to the IMU as possible to see if there are any anomolies.

re: clearing the DIAG_STAT during a burst read - Are you sure it is the case that the burst read function doesn't internally trigger the DIAG_STAT flags to be cleared? I ask as I have evidence to the contrary. My code currently does not explicitly perform a read of the DIAG_STAT register between burst reads to clear the flags - I skip this step because I can see that the flags are clearing themselves after some time. Is there perhaps a timeout or some other logic that would explain the flags being reset to 0 if they are not being reset by the burst read?

This distinction matters because my current interpretation is that the clock errors are occurring frequently. If the behaviour is as you stated then the occurrence may be much rarer and I will have to do a deeper investigation to produce conclusive evidence.

  

This is the 1 PPS signal input to the IMU. Both of these were captured with infinite persistence over several minutes. During this measurement I observed hundreds of thousands of clock errors in the DIAG_STAT register.

In this capture I've set a GPIO to output high whenever the DIAG_STAT 0x8000 error is received from a burst transfer (blue trace). You can see the PPS signal (yellow trace, very faint from the large horizontal scale) is present during all the error periods.

Zooming in on one of these pulses immediately prior to the error flag being set (with limited resolution from the large capture) it appears to have no spurious artifacts


I tried injecting an external 1 Hz signal into the SYNC pin (3.3V, positive pulse polarity, 10% duty cycle) however I get the same errors.

Hi BHillam, your symptoms match almost exactly to what I am experiencing.

I am frequently getting clock sync errors when I read the diag stat part of the data burst read.

My setup:

ADIS16507

GNSS module 1Hz PPS -> Sync pin of IMU

Up scale factor 2000

Decimation set to give 200 Hz ODR (although I have tried many differentz )

No filtering set.

IMU in scaled Sync mode

32Bit Burst reads

Noteworthy about my setup is

1) I communicate with the IMU via a FT4222 (USB to SPI converter)

2) I am polling the IMU (I do not have data ready connected) (yes I know not ideal!)

    I have tested varying polling rate, and I see the clock sync error in all configs. However i get fewer errors if polling below the output data rate.

(eg if I configure decimation to give 200 Hz ODR but poll at 100 Hz.)

I have been able to inspect the 1Hz PPS signal on the oscilloscope and its squeaky clean and stable, as one would expect from a GNSS receiver.

I have also monitored the DR signal on the oscilloscope. This is reasonably stable, however suffers outages and stutters occasionally

(eg the min/max statistic shows min 192.3 Hz max 217.4 Hz mean 206.4 Hz)

(I presume this correlates to when I get a flood of "clock synchronisation" errors, however I haven't correlated the two things so directly as you have with your test where you trigger a GPIO when you see the clock sync error in the diag stat register.

In a separate side experiment, I switched to direct sync mode, and fed a 2000 Hz signal into the sync pin (my GNSS allows a reconfiguration of the PPS to higher freqs)

In this mode when I monitor the data ready pin with the oscilloscope it's rock steady to whatever I have configured the ODR to be. I also get not clock sync errors of course, as this error is not applicable in direct sync mode.

I have also done a little investigation into the differences in the Diag stat... what you get when you read it in a burst and what you get if you do a direct read of the diag stat register only, and have found  that the error bit for "clock sync error" does seem to be more "sticky" in the burst read. Ie it hangs around stuck/latched for longer. However the error bit does eventually clear from burst reads, even if Im not additionally polling the diag stat register directly.

This sounds like it matches up a bit with what "FormerMember" said ie...
"Second Querry: Clear error flags in the DIAG_STAT register require specific action, such as writing to a register or power-cycling the device, as burst reading doesn't achieve this."

Questions to you

1) Are you triggering your reads based on the data ready signal, or do you poll like I do?

2) have you managed to make progress on this error?

I'm sorry to hear that you are experiencing the same problem.

1. We are using the data ready signal to trigger an interrupt - no polling.

2. We did not find any solution to this problem. It's disappointing that Analog never treated this issue as important enough to warrant deeper investigation.