values of KX132 accelerometer are for x,y,z axis still at 255,000g

[problem00]

Hello everybody,
I connected the ESP32 with the KX132 accelerometer. While measuring with the accelerometer, the values of x,y,z axis are still 255,00g. While compiling, there are following mistakes/warnings:

In file included from C:\Users\prename.name\Documents\Arduino\libraries\SparkFun_KX13X_Arduino_Library\src\SparkFun_Qwiic_KX13X.h:23:0,
from C:\Users\prename.name\Documents\Arduino\libraries\SparkFun_KX13X_Arduino_Library\src\SparkFun_Qwiic_KX13X.cpp:18:
C:\Users\prename.name\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.6\libraries\Wire\src/Wire.h: In member function 'KX13X_STATUS_t QwiicKX13xCore::readMultipleRegisters(uint8_t, uint8_t*, int16_t)':
C:\Users\prename.name\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.6\libraries\Wire\src/Wire.h:102:13: note: candidate 1: uint8_t TwoWire::requestFrom(int, int, int)
uint8_t requestFrom(int address, int size, int sendStop);
^
C:\Users\prename.name\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.6\libraries\Wire\src/Wire.h:98:13: note: candidate 2: uint8_t TwoWire::requestFrom(uint16_t, uint8_t, uint8_t)
uint8_t requestFrom(uint16_t address, uint8_t size, uint8_t sendStop);
^
C:\Users\prename.name\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.6\libraries\Wire\src/Wire.h:102:13: note: candidate 1: uint8_t TwoWire::requestFrom(int, int, int)
uint8_t requestFrom(int address, int size, int sendStop);
^
C:\Users\prename.name\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.6\libraries\Wire\src/Wire.h:100:13: note: candidate 2: uint8_t TwoWire::requestFrom(uint8_t, uint8_t, uint8_t)
uint8_t requestFrom(uint8_t address, uint8_t size, uint8_t sendStop);

I loaded up following code:

/*********************************************************
Author: Elias Santistevan @ SparkFun Electronics
Date: 5/2021
Library repository can be found here:
https://github.com/sparkfun/SparkFun_KX13X_Arduino_Library

Basic example for reading back accelerometer values using I2C.

This code is released under the MIT License.

Please review the LICENSE.md file included with this example. If you have any questions
or concerns with licensing, please contact [email protected].

Distributed as-is; no warranty is given.
*******************************************************/

#include <Wire.h>
#include "SparkFun_Qwiic_KX13X.h"

QwiicKX132 kxAccel;
//QwiicKX134 kxAccel; // Uncomment this if using the KX134 - check your board
//if unsure.
outputData myData; // This will hold the accelerometer's output.

void setup() {

while(!Serial){
delay(50);
}

Serial.begin(115200);
Serial.println("Welcome.");

Wire.begin();
if( !kxAccel.begin() ){
Serial.println("Could not communicate with the the KX13X. Freezing.");
while(1);
}
else
Serial.println("Ready.");

if( !kxAccel.initialize(DEFAULT_SETTINGS)){ // Loading default settings.
Serial.println("Could not initialize the chip.");
while(1);
}
else
Serial.println("Initialized...");

// kxAccel.setRange(KX132_RANGE16G);
// kxAccel.setRange(KX134_RANGE32G); // For a larger range uncomment

}

void loop() {

myData = kxAccel.getAccelData();
Serial.print("X: ");
Serial.print(myData.xData, 4);
Serial.print("g ");
Serial.print(" Y: ");
Serial.print(myData.yData, 4);
Serial.print("g ");
Serial.print(" Z: ");
Serial.print(myData.zData, 4);
Serial.println("g ");

delay(20); // Delay should be 1/ODR (Output Data Rate), default is 50Hz

}
I hope somebody can help me, I dont know what I do wrong.

[ahermida69]

Do you have the latest version of the library?

[problem00]

Yes, i tried it with different versions. Is there a problem with following function?
When I change the address, there are different unchanged values.

outputData QwiicKX134::getAccelData(){

if( getRawAccelData(&rawAccelData) &&
convAccelData(&userAccel, &rawAccelData) )
return userAccel;

userAccel.xData = 0xFF;
userAccel.yData = 0xFF;
userAccel.zData = 0xFF;
return userAccel;
}

[nishi10000]

i dont really know the library, but i tried on my m5stack and i have the same problem, do have any solution yet

[problem00]

I got the problem, it has to be in function getRawData.
If getRawData = 1, Serial.println("getRaw = true"),
if getRawData = 0, Serial.println("getRaw = false")
--> false!

outputData QwiicKX132::getAccelData()
{
if(getRawAccelData(&rawAccelData))
{
Serial.println("getRaw = True");
if(convAccelData(&userAccel, &rawAccelData))
{
return userAccel;
}
}
else
{
userAccel.xData = 0xFF;
userAccel.yData = 0xFF;
userAccel.zData = 0xFF;
Serial.println("getRaw false");
return userAccel;
}
}
@ahermida69 did you have any problems with getRawAccelData function?

[ahermida69]

Which boards are you using? Do they have the kx132 or kx134? I only have the kx134.

[problem00]

I use the NodeMCU-32S µC and the KX13X board(KX132) from sparkfun.

[edspark]

Sorry I, for whatever reason, don't have a KX132/4 at my desk. However I did push a release to fix the compiler warnings you all are seeing. I'll take a look at the getRawAccelData function as soon as I'm able.

[problem00]

That sounds good! Thanks! Looking forward.

[nixternal]

Using the KX134 from Sparkfun w/ a Sparkfun ESP32 Thing Plus and also reading nothing but 255 using the basic example. Any work around that I haven't come across for this? EDIT: Connected via Qwiic.

[ahermida69]

I don't know if this is still an issue but I had this same problem with a different board. With this snippet both addresses will be checked. Let me know if this works for you.

if( !kxAccel.begin(0x1E) ){
if( !kxAccel.begin(0x1F) ) Serial.println("Could not communicate with the the KX13x.");
}
else Serial.println("KX13x Found!");

I think both the kx134 and kx132 have the same I2C addresses. I used it with the kx134 and it good.

[nixternal]

Thanks for the reply @ahermida69, however that didn't work either. I did find out it seems that 0x1F is the I2C address playing around, but still reading 255 on x, y, & z.

[ahermida69]

have you run a scan code to see which i2c addresses are being recognized? try this:

#include <Wire.h>

void setup()
{
Serial.begin (115200);
Wire.begin (21, 22); // sda= GPIO_21 /scl= GPIO_22
}

void Scanner ()
{
Serial.println ();
Serial.println ("I2C scanner. Scanning ...");
byte count = 0;

Wire.begin();
for (byte i = 8; i < 120; i++)
{
Wire.beginTransmission (i); // Begin I2C transmission Address (i)
if (Wire.endTransmission () == 0) // Receive 0 = success (ACK response)
{
Serial.print ("Found address: ");
Serial.print (i, DEC);
Serial.print (" (0x");
Serial.print (i, HEX);
Serial.println (")");
count++;
}
}
Serial.print ("Found ");
Serial.print (count, DEC); // numbers of devices
Serial.println (" device(s).");
}

void loop()
{
Scanner ();
delay (100);
}

[nixternal]

@ahermida69 I get 0 devices found. Mine is connected via the Qwiic connector, so I don't know if that matter with the Wire.begin(). Edit: If I just do Wire.begin() in setup() and remove the one in Scanner() I get "Found 1 device(s)" with an address of "31 (0x1F)".

[ahermida69]

Looks good. It should be 0x1F. I have a Tiny Pico ESP32 and connected the Sparkfun kx134 board to it. I have the same problem you have.

@edspark
I traced it down to readMultipleRegisters(uint8_t reg, uint8_t dataBuffer[], int16_t numBytes):

The line: i2cResult = _i2cPort->requestFrom(_deviceAddress, uint8_t(numBytes), uint8_t(false));
returns: i2cResult = 0

so the next lines execute:
if( i2cResult == 0 )
return KX13X_I2C_ERROR;

I even tried requesting 2 bytes at a time inside a loop that ran 3 times, but it also failed.

[ahermida69]

Got it working! I read in a forum that there was an issue with the ESP32 (working with Arduino?) when using reSTART while reading multiple registers. I decided to do a simple test ( I2C is used). I commented out the original readMultipleRegisters() and added this one to the code. It only reads 1 register at a time:

KX13X_STATUS_t QwiicKX13xCore::readMultipleRegisters(uint8_t reg, uint8_t dataBuffer[], int16_t numBytes)
{
uint8_t tempRegVal;

readRegister(&tempRegVal, KX13X_XOUT_L); dataBuffer[0] = tempRegVal;
readRegister(&tempRegVal, KX13X_XOUT_H); dataBuffer[1] = tempRegVal;
readRegister(&tempRegVal, KX13X_YOUT_L); dataBuffer[2] = tempRegVal;
readRegister(&tempRegVal, KX13X_YOUT_H); dataBuffer[3] = tempRegVal;
readRegister(&tempRegVal, KX13X_ZOUT_L); dataBuffer[4] = tempRegVal;
readRegister(&tempRegVal, KX13X_ZOUT_H); dataBuffer[5] = tempRegVal;

return KX13X_SUCCESS;
}

Some of the output from my code...
Welcome.
Ready.
Initialized...
X: 0.1194g Y: -0.0125g Z: 1.0474g
X: 0.1201g Y: -0.0103g Z: 1.0493g
X: 0.1189g Y: -0.0107g Z: 1.0481g
X: 0.1179g Y: -0.0112g Z: 1.0488g

I'll leave it to @edspark to integrate a better solution if the processor is an ESP32, maybe #if defined(ESP32) or something like that. I know enough to be dangerous but not enough to do a robust github level piece of code.

@nixternal The problem will show up again when reading the buffer values. At least this allows you to read the immediate xyz values.

[nixternal]

Rock on @ahermida69! Yeah, I'm the same, know enough to be dangerous. Thanks for showing me the I2C scanning at least, I have saved that for future use for sure.

[edspark]

@ahermida69 excellent find! I've been quite busy lately but I've found some time this morning to look at the solution you posed and integrate something ESP friendly. I'll update within the next few hours with a fix and release of the library.

[ahermida69]

@edspark Sounds great! Please remember that reading the buffer would also be different. Not even sure how to approach that one since we only have the address of the buffer pointing to the 1st value.

[edspark]

Thanks again @problem00, @ahermida69 , and everyone else that has contributed to fixing this issue. So it didn't quite sit right with me that the ESP32 I2C driver would not support multiple reads at a time. On a whim I decided to change the boolean parameter of requestFrom() to true instead of false. This fixed the issue. Having that little tidbit of information I was able to specifically google requestFrom() and ESP32, which lead me to this recent post confirming the issue in this thread. This has been fixed in the latest commit.

As for other processors, this change has not affected them at all.