Open javl opened 10 years ago
IMHO your 'quick hack' is only hiding the bug, not fixing it ;-) Sounds to me like the real bug is that something in i2c_adxl345.py is passing in the value of -3 to an i2c function when it shouldn't be.
That's why I called it a 'quick hack', not a fix ;) It might help others that run into this problem (I was using the latest NOOBS Raspbian raspberry pi image, like a lot of other people).
Looks like the actual bug is in the way the i2c_adxl345 library handles negative accelerometer values during initialization. I bet if you flipped your accelerometer upside down and ran your code again, it would work ;) At least that's what I found.
I'd say the way the quick2wire API handles this error is great -- the stack trace points out the exact point of failure, once a bit of logging is added to figure out where the rogue value is coming from.
As to the problem you're seeing though, I just ran into the same issue and can offer a couple pointers that may help. I had to set the offset on my accelerometer, since it didn't actually report 1g when sitting on a flat surface. (See the datasheet for the correct register, or the source code of i2c_adxl345.py, though it's not implemented fully.) I also modified i2c_adxl345.py and changed lines from "if intervals < 256" to "if 0 < intervals < 256", which is hacky, but "if intervals < 256" is already a bit hacky...so... there you have it. Hopefully that helps, even if it's totally off topic. ;)
Not sure what causes this problem, but I'd though it might be useful to at least post an issue report. I tried using the quick2wire library with a cheap accelerometer by running the following code:
But immediately I get the following error:
Printing these values, I noticed at least one of them indeed isn't in this range: -3
As a quick hack I changed the function in i2c.py so it clamps the values in byte_seq before returning the message, after which everything works perfectly.