Closed cranefist closed 9 months ago
Will think over it what could be done.
Here the 3839 is mentioned:
Yes, it seems to be some sort of default output in case of an error.
In my case, if i stream readings from the sensor.. it simply outputs this randomly amongst the correct readings. So everything works well, but there are just random fails.
I think its either my wiring, or noisy power. Or the fact that i have several I2C sensors connected to this same port. Because the sensor has its own LDO i think, and it has some decoupling capacitators on the board. And the other AS5600 i have in this system, has no other devices connected to the same port. They do all share the same power source.
But i already successfully filtered this reading out in one use case where i'm just reading the raw output, and it worked perfectly. Simply ignoring the reading if its 3839. But as i'm also using the linear output of your library, where i cant filter it out at least not easily. And as i have two of these sensors, the other is more important as its closed loop motor control where i cant use any filtering as it might cause me to miss rotations or something like that.
The other is just a menu/adjustment dial, but this one was hopping around because of the random error reading.
But if this is not something you want to implement, ill just do the linear tracking myself. But it might be good to add this number in to your readme, so people understand that its an error reading.
Here is an example of a readout, don't mind the 0s.. they are something else. It has the normal tiny noise, and then the 3839s.
some notes: 3839 is binary 1110 1111 1111 so almost all 1's as if there is no signal
@cranefist Can you change the AS5600.cpp file and replace the existing readReg2() by this one?
As I do not get the 3839 reproduced, so I want to have a look at the low level I2C. Need to improve error handling here I guess. That does not solve it right away but allows one to catch it (maybe).
uint16_t AS5600::readReg2(uint8_t reg)
{
_wire->beginTransmission(_address);
_wire->write(reg);
_error = _wire->endTransmission();
if (_error != 0)
{
Serial.print("\nreadReg2 (1): ");
Serial.println(_error);
}
uint8_t n = _wire->requestFrom(_address, (uint8_t)2);
if (n != 2)
{
Serial.print("\nreadReg2 (n): ");
Serial.println(n);
}
uint16_t _data = _wire->read();
_data <<= 8;
_data += _wire->read();
return _data;
}
@cranefist Created a develop branch + PR with a first level error handling/detection.
With the function int lastError() one can see if the low level I2C functions failed. The 3839 error might be caused by such failure (assumption).
If you have time, please give the develop branch a try.
I will try it out, i will report back in few days.... my project is quite complex for testing stuff.
I was running the I2C at 400khz, and dropping it to 100khz lowered the number of errors a lot, as i had several devices on this one port. The other AS5600 seems to run just fine at 400khz, on its own I2C line.
OK,
I was running the I2C at 400khz, and dropping it to 100khz lowered the number of errors a lot, as i had several devices on this one port.
Sounds like noise?
Can you see the signal with an oscilloscope?
I will try it out, i will report back in few days.... my project is quite complex for testing stuff.
Any progress?
@cranefist I merged the develop branch into the master and released version 0.6.0 It adds (experimental) error checking, mainly for I2C, so you can investigate if there is a relation between I2C and 3839 readout. I could not reproduce it.
For now I close this issue as there are no new insights, feel free to reopen when needed. Anyway thanks for reporting the issue.
At some point i posted here about the weird hiccups i had with this sensor, i have now noticed that it will always output 3839 on error.
This can also be confirmed from other posts, like this:
https://forum.arduino.cc/t/analogwrite-causes-i2c-encoder-lockup/674080/13
"Sadly, after a couple of minutes running, the encoder stops communicating, and returns the value 3839, which is the same as you would see if you unplugged it."
So every time the encoder fails to get a reading, it outputs 3839.
For me, it simply occasionally outputs 3839. And this causes these weird hiccups in the linear reading.
It would be good if there was a possibility to filter for this, mainly in my case this is an issue in the linear output. As on other cases i can filter this out easily.
Even though i expect this is a problem on my wiring/power filtering, as im running two of these and the other has 0 of these hiccups. But still, it might be wort while having a possibility of filtering this one readout out.