i2c_t3 | Enhanced I2C library for Teensy 3.x devices
kandi X-RAY | i2c_t3 Summary
kandi X-RAY | i2c_t3 Summary
Enhanced I2C library for Teensy 3.x & LC devices. This is an enhanced I2C library for Teensy 3.x/LC devices.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of i2c_t3
i2c_t3 Key Features
i2c_t3 Examples and Code Snippets
Community Discussions
Trending Discussions on i2c_t3
QUESTION
I have an arduino based device (Teensy 3.2) and I am trying to read data from a H3LIS331DL accelerometer breakout board. I can write to the control registers on the accelerometer and read from the data registers, but I'm having trouble getting stable, useful data.
First, useful data. The data sheet for the acclelerometer chip just says for the data registers "X-axis acceleration data. The value is expressed as two’s complement." The SparkFun LIS331 library says "The data that comes out is 12-bit data, left justified, so the lower four bits of the data are always zero." If the data is 12 bits per axis I would guess that the output (properly conditioned) should be 0-4095 with zero Gs being at something like 2048, but this doesn't match what I'm getting. With the accelerometer sitting still at my desk right now the X and Y axes are giving readings at the high and low end (either 0-19 or 4063-4095) and the Z axis is giving readings from 9-80 (always below 2048 in any orientation).
Are my expectations for the data wrong, or am I doing something to not be getting the correct data?
Second, stable data. The low setting on this accelerometer is +/- 100G range. My current bench testing is at -1G to +1G (1% of the full range), so I would expect the output data to have proportionally small range, but the output range just from a constant position is already almost 2% of the full scale.
What can I do to get more stable output data?
...ANSWER
Answered 2019-Jun-26 at 03:28I mostly found the answer to my question. The data register bytes do need to be combined the way I did and have a right shift, but it needs to be a signed right shift whereas my code was amounting to an unsigned right shift. The sign bit was being misinterpreted as being a value bit and was sending the resulting value to the top of the range whenever the number was supposed to be negative. Casting the combined unsigned bytes as a signed int before shifting solved that issue and made the output data make much more sense.
xAccel = (int16_t)(data[0] | data[1] << 8) >> 4;
The good news is that all 3 axes now spit out meaningful data with the same linear slope based on the orientation.
The bad news is that each axis has a different offset from 0 at 0G, and each axis still has a variance/jitter of about +/- 18 from the mean value (which is higher than I would like).
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install i2c_t3
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page