-
Notifications
You must be signed in to change notification settings - Fork 28
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
Comments
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. |
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! |
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. |
I noticed that there is a filter to check whether or not BNO data is corrupt before it is processed:
Miniscope-DAQ-QT-Software/source/miniscope.cpp
Line 519 in cfecd42
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:
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.The text was updated successfully, but these errors were encountered: