Had to register in order to get this head scratcher sorted out. I am reading BMX160 gyro+acc data from FIFO (burst read, headerless). Both sensors are configured to 0b00100110 and the PMU status shows them as normal (0b00010101). This configuration says on the manual to be 25hz for both.
- System checks whether there is data available. When no data is available, UART is allowed to send latest frame out to terminal.
- When data is available, 40ms is increased on the timer for each FIFO buffer data chunk (ACC+GYR = 12 bytes) (no communications on UART window) FIFO is read out at 12 bytes at a time and analyzed separately, until it is empty. No timekeeping is done other than this fixed, data based increments. Timestamp is not used from the IMU.
- Everything is isolated at this point, only uart message and FIFO read are happening, no calculations etc.
UART FIFO is flushed before the routine starts infinite loop.
Problem: Resulting time is about 2.5 times too slow. So as if the readout happens at something like 8 hz. Strangely enough this timing will result in somewhat correct gyroscopic angle calculations if calculations are allowed, but that could be just a result of lucky bug somewhere. FIFO gets emptied out, there is no UART transmissions unless buffer indicates 0x0000 data bytes.
Suspicion: This feels that FIFO loses data (is unable to write during read and forgets or something like that).
Solved! Go to Solution.
I am watching the increments live on terminal for 10 seconds (variable which accumulates the FIFO ticks). That is how i noticed it, because everything seems to work just fine. This timer comes directly from the process of FIFO data available -> Read single FIFO frame-> Increment counter -> Read next when available.
IF this were to be a bug in the FIFO process, i can see how it might've been missed previously. This is not a typical use case, manual suggests reading the complete 1024 bytes in single burst. Also if you drop out couple of messages from a batch of 160 (during complete readout process), it is not easily noticed. My end goal is to move for the traditional high-speed approach eventually, but right now i am building up the latency bank for processing and solidfying the readout process.
**bleep** it i am a fool. At some point i switched the time display from IMU ticks (39uS) to 10ms true time. Just forgot to remove the translator which calculated that on terminal side. Seems like i have the problem in the opposite direction now, but that is most likely due to all the tinkering around this issue.
You can record the time stamp of the host to see whether the data frame matching the ODR is received within one second.
I also uploaded an example of running on STM32 for your reference.