Skip to content

Bug in setRange #19

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

Closed
PaulZC opened this issue Jan 16, 2023 · 4 comments · Fixed by #20
Closed

Bug in setRange #19

PaulZC opened this issue Jan 16, 2023 · 4 comments · Fixed by #20

Comments

@PaulZC
Copy link
Contributor

PaulZC commented Jan 16, 2023

Hi Eli @edspark ,

Just a heads-up that I've found a bug in setRange. Long story short: I added support for the KX134 to the OLA; @VancouverUmbrella tested it in his glider and was seeing the accel data max out at 8g with 64g-mode selected.

sparkfun/OpenLog_Artemis#144 (comment)

The bug is two-fold: setRange isn't doing a read-modify-write; and the wrong bits are being set (0&1 instead of 3&4):

//////////////////////////////////////////////////
// setRange()
//
// Sets the operational g-range of the accelerometer.
//
// Parameter:
// range - sets the range of the accelerometer 2g - 32g depending
// on the version.
//
bool QwDevKX13X::setRange(uint8_t range)
{
int retVal;
if( range > 3 )
return false;
retVal = writeRegisterByte(SFE_KX13X_CNTL1, range);
if( retVal != 0 )
return false;
return true;
}

I've fixed this in the release_candidate branch - but haven't tested it yet. (I've run out of time today.)

Please don't be horrified if you look at the number of commits. I've updated the code so it uses the register bitfields you included (thanks!), instead of having 'duplicate' hard-coded bit definitions in the .cpp. It's a big change but makes the code a lot nicer.

Just FYI, there were other gremlins in there too, mostly to do with data being OR'd into the registers. That sets bits, but can't clear them. The bitfields allow setting/clearing in a single call.

I've also updated getRawAccelData so it can cope with data in the buffer being 8-bit as well as 16. In my mind the new code works, but is currently untested.

I'll test this tomorrow - probably by sticking the OLA and KX134 in an electric drill and taking it for a spin! - and then ask you to review the changes.

Thanks!
Paul

@PaulZC
Copy link
Contributor Author

PaulZC commented Jan 17, 2023

What could possibly go wrong?!

image

@PaulZC
Copy link
Contributor Author

PaulZC commented Jan 17, 2023

So, after I'd retrieved everything from the darkest corners of my office (the SD card had been flung out of the OLA and up onto a top shelf), I got this:

image

I think we can safely say we're in 64-g mode...

@PaulZC PaulZC mentioned this issue Jan 17, 2023
@PaulZC PaulZC linked a pull request Jan 17, 2023 that will close this issue
@VancouverUmbrella
Copy link

Looking good. You're a brave tester, I see!

@PaulZC
Copy link
Contributor Author

PaulZC commented Jan 17, 2023

It went a bit like this:

https://youtu.be/dEU7ocjEza0

:-D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants