Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large amount of corrupt IMU data #23

Closed
jonnew opened this issue Oct 6, 2020 · 3 comments
Closed

Large amount of corrupt IMU data #23

jonnew opened this issue Oct 6, 2020 · 3 comments

Comments

@jonnew
Copy link

jonnew commented Oct 6, 2020

I noticed that there is a filter to check whether or not BNO data is corrupt before it is processed:

if (bnoBuffer[f*5+4] < 0.05) { // Checks to see if norm of quat differs from 1 by 0.05

This issue seems to persist in the Miniscope V4 Bonsai Package I'm working on. Its root cause seems to be some type of synchronization issue in firmware or currupt I2C packets over the SERDES back channel. I do see a large degree of toggling of quaternion elements correct values but wrong array positions, which strongly suggests a synchronization issue:

image

Do you think I'm experiencing the same behavior as the DAQ-QT software or are you using some type of qauternion_ready flag that I'm missing? If this is the current nominal behavior, is there a route to fix this? In bonsai, the proper way to handle such a thing (aside from fixing the actual data stream issue) would be to filter it using a downstream node, but it seems a bit weird that the default stream emitted by the Miniscope v4 would be in large part corrupt.

@daharoni
Copy link
Member

daharoni commented Oct 6, 2020

There are a subset of V4 Miniscopes from the first production run from OEPS that show this BNO instability. This was a known issue in some of our previous V4 Miniscope prototypes but did not have a large enough sample size to know if it was a systematic issues.

It turns out that the BNO's I2C is very temperamental and about 50% of them on the V4 show some level of instability. In our experience the issue shows up as BNO registers returning 0x00's at some point within a burst I2C read. Checking for new data flag in the BNO doesn't help and this issue shows up even when burst reading the first 8 fixed registers of the BNO. In most cases this is minor and can be filtered out using a threshold on the norm.

That being said, we have found that all unstable BNO V4 Miniscopes can be fixed by adding a very small capacitance between the I2C_SCL and GND. All V4 Miniscopes produced from this point on will have a 12pF capacitor added to I2C_SCL and should fix any instability. Interestingly, if we add a small capacitance to I2C_SDA as well, or on its own, it doesn't fix the issue.

It is possible to hand solder an 0201 capacitor across pin 18 and 19 of the BNO to add this fix to currently unstable BNOs.

@jonnew
Copy link
Author

jonnew commented Oct 6, 2020

OK, thanks for the explanation. So I suppose that NACKs on the I2C are leading to e.g. registers not being updated and therefore multiple reads of the same value? Glad to hear its fixed on newer versions of the scope!

@daharoni
Copy link
Member

This seems to be fix on all future V4 Miniscopes by placing a small ~12pF cap on the I2C_SCL line. I think OEPS and LabMaker are both doing this now on all Miniscopes. The Miniscope software does display when BNO values are not correct as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants