-
Notifications
You must be signed in to change notification settings - Fork 53
-92 degrees celsius randomly returned from imu's temperature field #58
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
Comments
@snowpuppy Does it always return the same wrong value? From what you're saying it seems like it will sometimes return -92, sometimes -93; is that correct? |
@siddacious That's correct. I've only observed the same wrong values of -92 and -93. It's interesting to note though that the transition of random spikes from -93 to -92 aligns with the transition of the normal temperature reading from 35 to 36 degrees. Output filtering out 35 and 36 degrees celsius:
|
So, I tested this and was able to replicate it. I'm pretty sure the issue has something to do with reading the buffer. 35 in binary is: 00100011 Not entirely sure what the best way to fix this mathematically is (I could always just do a check for a temperature change of more than n degrees since the last reading but I really don't want to do that) but I'm working on it. |
Looks like it could have something to do with clock stretching: @siddacious Any thoughts on what strategy I should take? I'm currently thinking it could make sense to make an overriding __get__ method for ROUnaryStruct (called _ReadOnlyUnaryStruct() in adafruit_bno055.py) that only runs when it detects it's running on a Pi. If the last 6 bits of the current byte and previous bytes are the same, then it would return that instead. I'm not a huge fan of this solution, but I don't think there's a way to do it purely mathematically while still allowing for negative numbers. |
Another thing I'm thinking of would be to just throw an error when the last and current temperatures are exactly 128 apart and then have the user handle it. |
@dherrada I think you're likely correct that this has to do with clock stretching, however I don't think that the Register lib is the place to address the issue, since it's shared by every platform and this issue only pertains to one. I think https://github.com/adafruit/Adafruit_Blinka is a more appropriate place, as it is the glue between code written to the CircuitPython API and the hardware, so it would probably be the place to fix discrepancies between the two. |
@siddacious Sounds good. Do you think I should close the PR I made (#64)? |
@dherrada I think so, yes. |
Closing. Most likely related to clock stretching and nominal fix is here: More info and options here: |
While graphing this data, it was noticed that there were arbitrary dips to a negative value in the range of -92 degrees Celsius. Upon writing a simple test script, it was noticed that the library is indeed returning these large negative temperature values.
Sample Script:
The output was redirected to a file like so:
python3 imu_test.py > read_imu.txt
Then ran grep for Temperature values:
cat read_imu.txt | grep Temperature
The output shows that temperature arbitrarily drops to -92/-93 degrees:
The text was updated successfully, but these errors were encountered: