Post by ianh on Apr 18, 2024 17:39:58 GMT
Hi All
First post. I've been making some custom changes to Arduino and have run across an anomaly in the data. Before I stick my head down a rabbit hole...
I appreciate that this code is relatively stable, so probably working as intended, but... is anyone away of any anomalies in the behaviour of encoding and decoding low value float values?
Long story short. I have added some custom data types. One in particular is a cumulative float. It starts at 0.0, then slowly increments, say in 0.005 increments.
I would expect it to start slowly with small 'decimal' value. Then when integer part gets to 127, it then reverts to integer, and I lose the decimal precision, which is probably fine over a 30 minute duration.
But what I see is initially large increments in integer value, until it hits a (as decoded) value around 100 (not sure what internal float is at that point, but likely to be cumulative around 0.005 every 250ms), at which point, it increments as I would expect, ie 1.00, 1.02 etc when output every second.
If helpful I can get a dump of data, but this is more of a 'does anyone know of an anomaly with small floating point numbers' before I go tracking things down. Doesn't really need any in depth response, other than 'yea, it doesn't cope with such small numbers etc', or, 'that's weird, I've not seen that before, you have a problem...'
I thought at first my custom decoder was at fault (we don't plan on using the Android app so not locked into current implementation), but it shows exactly the same behaviour as the python decoder.
It may simply be a limitation in the data sizes that can be sent (ie does not cope with very small floats, which looking at the code, without checking in debug, is a possibility due to the casting and how the 'integer' and 'decimal' is encoded), but, it looks like I am seeing similar in wheel speed too (when triggering the hall effect transistors manually by hand so very slow speed, but being reported initially as many tens of m/s), and that not been touched so am surprised that I am not seeing comments on that behaviour - unless wheel interrupts are too slow to expect a valid speed!
Another change is that this is being build in VS Code, but that uses the official Arduino extensions.
Whilst C++ and Arduino is not my primary background, I do have background in this field, so do not mind getting my hands dirty, but would rather not have to stick my head down that rabbit hole in the first place.
Many thanks in advance
-Ian
First post. I've been making some custom changes to Arduino and have run across an anomaly in the data. Before I stick my head down a rabbit hole...
I appreciate that this code is relatively stable, so probably working as intended, but... is anyone away of any anomalies in the behaviour of encoding and decoding low value float values?
Long story short. I have added some custom data types. One in particular is a cumulative float. It starts at 0.0, then slowly increments, say in 0.005 increments.
I would expect it to start slowly with small 'decimal' value. Then when integer part gets to 127, it then reverts to integer, and I lose the decimal precision, which is probably fine over a 30 minute duration.
But what I see is initially large increments in integer value, until it hits a (as decoded) value around 100 (not sure what internal float is at that point, but likely to be cumulative around 0.005 every 250ms), at which point, it increments as I would expect, ie 1.00, 1.02 etc when output every second.
If helpful I can get a dump of data, but this is more of a 'does anyone know of an anomaly with small floating point numbers' before I go tracking things down. Doesn't really need any in depth response, other than 'yea, it doesn't cope with such small numbers etc', or, 'that's weird, I've not seen that before, you have a problem...'
I thought at first my custom decoder was at fault (we don't plan on using the Android app so not locked into current implementation), but it shows exactly the same behaviour as the python decoder.
It may simply be a limitation in the data sizes that can be sent (ie does not cope with very small floats, which looking at the code, without checking in debug, is a possibility due to the casting and how the 'integer' and 'decimal' is encoded), but, it looks like I am seeing similar in wheel speed too (when triggering the hall effect transistors manually by hand so very slow speed, but being reported initially as many tens of m/s), and that not been touched so am surprised that I am not seeing comments on that behaviour - unless wheel interrupts are too slow to expect a valid speed!
Another change is that this is being build in VS Code, but that uses the official Arduino extensions.
Whilst C++ and Arduino is not my primary background, I do have background in this field, so do not mind getting my hands dirty, but would rather not have to stick my head down that rabbit hole in the first place.
Many thanks in advance
-Ian
