Hi,

I've been recording some accelerometer data with my Open IMU300ZA connected to a Teensy over SPI and have noticed an intermittent spike in the data being produced by the accelerometers. I'm struggling to find a cause for it, but it's nonphysical - it occurs even with the device sat still on the bench. Because it affects all three channels simultaneously I'm wondering if it's an SPI related issue?

I'm currently ignoring the Data Ready pin (7) and just reading from the IMU300ZI on a loop, do you think this is likely to cause a problem? It's not clear from the datasheet whether I need to obey the Data Ready pin or not.

Please see the attached plot for an example of the bad behavior, with the state of the Data Ready pin shown in blue. The value that the accelerometer data spikes too is fairly random (not always the same, and each accelerometer can spike to different values in the same instance of the spike).

If you have any other suggestions for trouble shooting please let me know.

Cheers,
Tim

Hi cek,

I can confirm that firmware was the issue in the end, that FW update has got it going nicely! Thanks very much for the help, hopefully this paper trail will be useful for other IMU300ZA owners.

Cheers,
Tim.

Hi cek,

quick update - I've built the compass example firmware on windows and flashed it to the 300ZA as per the Top Topics thread. I think this should mean we can rule out firmware as the issue - presumably all the examples now support SPI.

When I connect the 300ZA to the Teensy, SPI still doesn't work. Hooking up the oscilloscope to the SPI Clock Input on the 300ZA (when the Teensy is disconnected) we still see that the pin is being periodically driven. My best theory is that the 300ZA is in UART mode even though Pin 7 is not grounded on startup. It doesn't seem to matter if Pin 7 is driven high, low or left floating, it's always the same behavior.

Does this sound like a reasonable theory to you? I've had a quick look through the FW to see if I can force SPI mode in code but not managed yet. Do you know which files I might need to change?

Cheers,
Tim.

Hi cek,

thanks for getting back to me. I've backed up my FW by connecting the 300ZA to a computer using an ST-link V2 and wiring up SWCLK and SWDIO like this.

However, I don't seem to be able to connect to the Aceinna Developer site using this setup: if I download the IMU Server Ready To Run (Windows) and run it, the program starts a websocket server but never finds my device. I tried downloading the python version but there doesn't seem to be a server.py file in the downloaded folder as per the instructions? Do I need the evaluation kit to use ANS web? I can't get NavView to work either, I presume it also needs the EVK?

Perhaps you could tell me what version my FW is by looking at the binary? I've uploaded it here.

I can confirm that I've tried pin 7 both disconnected and driven high, neither work.

Could you provide me with the latest stock FW for the 300ZA for me to install, or if I build an example from the OpenIMU Platform in VSC will that work with SPI, assuming FW version is the issue?

Cheers,
Tim

Hi,

I'm attempting to read some accelerometer values out of the 300ZA using SPI. The 300ZA was connected to a Teensy 3.6 (wiring checked and checked again) but no registers could be read successfully. After further checking, an osciliscope was deployed, and strange behaviour on the CLK line was discovered. Further digging showed that this line seemed to be being driven by both the 300ZA and the Teensy.

In the following screengrabs, Yellow = clock, Blue = chip slect, Green = MOSI, Red = MISO. Please disregard the fact that MOSI (Green) is far too small, this is a fault on the probe.

As we can see, the Teensy puts chip select low then a read command is sent over MOSI. The 300ZA makes no attempt to respond, presumably because the clock is not behaving properly?

With the 300ZA disconected from the Teensy, we see that the clock oscillates between 0 and 3.3V as you'd expect.

With the 300ZA connected to the Teensy, the clock oscillates between 1 and 3.3V.

If we disconnect the teensy clock out from the 300ZA clock in (leaving all other pins connected), then measure the 300ZA's clock in pin, we see the clock line is held high and occasionally oscillated.

Is it normal for the SPI clock pin (pin 3) on the 300ZA? It seems like odd behavior to me since this pin is supposed to be an input? I am assuming it's an input from the 300ZI datasheet, as I was told in this thread that the 300ZA is identical to the 300ZA. This issue has caused me to dig even deeper for a 300ZA datasheet, and I was eventually able to find an archived one here. It seems to imply that the SPI clock pin (pin 3) on the 300ZA is in fact an output?!

Any help on this issue would be much appreciated.

Cheers,
Tim

Great cheers for clarifying!

Hey cek,

That's a super helpful reply and clears a lot up, cheers! I'm just wiring the 300ZA up to a uC using SPI and I want to confirm that I'm understanding the pinout diagram correctly as it doesn't seem that clear to me. What is the device orientation in the picture?
When I first read the datasheet I interpreted it as follows:

But my colleague interpreted it as:

Which seems equally valid. I think it would be clearer is the pinout diagram showed more of the device. I would just try it but don't want to connect power to gnd and visa versa and fry the IMU.

Thanks again,
Tim.

Hi,

I have an OpenIMU300 (without EVK) and am hoping to connect it to a Teensy which will read out raw IMU readings over SPI. I have an ST-Link V2 that I was planning to use to update the OpenIMU300ZA's firmware if necessary. To achieve this task I need to see the docs for the 300ZA (pinout etc) but I can't seem to find them anywhere, and any forum link to the docs are dead.

Are the docs available anywhere? What's the difference between the ZA and the ZI? They seem pretty similar on the face of it, and docs for the ZI are still available.

Cheers,
Tim.