You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Traceback (most recent call last):
File "./test1.py", line 6, in <module>
adxl345 = i2c_adxl345.i2c_adxl345(0)
File "/home/pi/projectfolder/i2clibraries/i2c_adxl345.py", line 100, in __init__
self.setActivityThreshold()
File "/home/pi/projectfolder/i2clibraries/i2c_adxl345.py", line 178, in setActivityThreshold
self.setOption(self.ActivityThreshold, intervals)
File "/home/pi/projectfolder/i2clibraries/i2c_adxl345.py", line 230, in setOption
self.bus.write_byte(register, options)
File "/home/pi/projectfolder/i2clibraries/i2c.py", line 14, in write_byte
writing_bytes(self.addr, *bytes))
File "/home/pi/projectfolder/quick2wire-python-api/quick2wire/i2c.py", line 97, in writing_bytes
return writing(addr, bytes)
File "/home/pi/projectfolder/quick2wire-python-api/quick2wire/i2c.py", line 108, in writing
buf = bytes(byte_seq)
ValueError: bytes must be in range(0, 256)
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.
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.
The text was updated successfully, but these errors were encountered: