Closed jimwhitelaw closed 9 months ago
Could possibly fix by doing the following:
uint32_t ELM327::supportedPIDs_1_20()
{
processPID(SERVICE_01, SUPPORTED_PIDS_1_20, 1, 4);
return (((uint32_t)responseByte_3) << 24) |
(((uint32_t)responseByte_2) << 16) |
(((uint32_t)responseByte_1) << 8) |
((uint32_t)responseByte_0);
}
What do you think?
Alternatively, it could be simpler to fix by doing this:
uint32_t ELM327::supportedPIDs_1_20()
{
processPID(SERVICE_01, SUPPORTED_PIDS_1_20, 1, 4);
return (uint32_t)response;
}
Yes, I think the second method is the easiest way to fix these methods (isPidSupported() just uses "response" ignoring the conditioned output). However, it feels like a band-aid and I wonder if other methods that undergo a similar cast might also be affected? I'll need to do some more testing to see. Now that I think about it, I bet that the same thing happens with monitorStatus() but it goes unnoticed because we are only interested in the most significant byte and ignore the rest.
Fixed in 3.2.1
Describe the bug Value returned by supportedPIDS_xx_xx() methods is off by one bit compared to the value that is actually returned by the ELM327 device.
To Reproduce Snippet of sample code used:
Expected behavior The received response, conditioned response, and value returned from the method should all be the same. They are not. Debug output:
Potential cause I believe the issue arises in conditionResponse() either where the _uint64t response is multiplied by float scaleFactor or when the conditioned value (float) is returned. I think that one of those implicit casts to float is causing the LSB of the response to be dropped. I'm not sure how to fix at the moment, perhaps someone else knows the answer.