10-14-2019 09:55 PM
I have been acquiring data from the BHI160 for a while, and I am patching up some issues I've had with the timestamps. I am using the BHI160 timestamps to synchronize between my local processor's timestamps and those recorded by the BHI160, so I look at the current time on my processor, and read the current_timestamp data on the BHI160, and do some math to synchronize the two. The exact procedure is a bit more complicated to avoid delays from interrupts.
I am seeing two potential issues. The big issue is that I can see the timestamps freeze and not update. I get an interrupt, check the timestamp data, clear the fifo, then I get the next interrupt about 500 ms later, I get the same timestamp, both IRQ and current time, I read again and get the same timestamp a 3rd time. Is this a known issue? Any way to work around it?
A second issue I see is that I need to do this because it appears the 32000 Hz clock is off by maybe 100 Hz, which means I need to resynchronize the timers. Is there any spec on the BHI160 clock, or way to adjust the timing?
10-16-2019 11:29 AM
Could you provide the following information with details ?
10-21-2019 03:16 PM
There are a couple ways to look at this, depending on how much precision you need. Assuming that we can neglect the small processing overhead of the FuserCore, you can simply parse the timestamp packets in the FIFO, and assume that the IRQ timestamp is equal to the last timestamp.
Doing so with our sample code, you could simply set a timestamp callback to automatically update a global variable. Once all the bytes are processed, you are good to go.
If you want this delay taken into account, you can read it 2 ways: either through registers 0x6C to 0x6F, or via Page 1, Parameter 30, bytes 0-3. Both values should be equal.
For data consistency, I recommend that you read the Host IRQ register after clearing the iterrupts, or to wait 1ms after the interrupt to read it so make sure all 4 bytes are written to the registers.