proper support for MAX31850, fault detection, and fixed overrun for temps in excess of 256C #183
Conversation
|
much better.
|
|
@karlg100 |
|
@karlg100 |
Sparkfun for $5. https://www.sparkfun.com/products/13715 Agreed it's a bit out of spec in a coal fire, but still impressive it survived and got any reading without failing, and it still works and reading accurately. Not sure how to get it any hotter than this to push the MAX31850? Volcano maybe? 🤔🤣 |
Torch - go to your local blacksmith? |
|
Did you test the thermocouple in a fridge yet? |
|
Yes, did that this morning. Have another patch for that. This one should fix <0C for all devices. |
|
Also adding checks for set/getResolution as that's not supported on this chipset. (But is supported on other devices with the same family ID, sigh) Also, looking at that code, I think there may be a bug that if the A0-3 IDs are not all default/1, then the getResolution may break. But that may not be the case for all devices. I'll open another issue to investigate that. |
|
Let me know when you guys are confident we can merge this in without introducing any bugs. Good work @karlg100 for this fairly extreme experimentation! |
|
oops. Looks like my code cleanup patch has a conflict. sorry about that. 😬 |
|
All tested and working. There's more I could do here, but is fully functional and a good .0 release for direct support of the MAX31850. I believe compatibility has been preserved with other devices. I believe this is ready to be merged. |
|
@milesburton - you're welcome to use the photos for the library's wiki for the shock value. ;) |
|
fixed conflict. sorry that took a while. |
The existing values are within the operating range of the MAX31850.
The MAX31850 maintains data from the fault detection circuit in the scratchpad, which indicates these conditions.
|
Consolidated commits. hope this helps. |
There were a bunch of problems with using high range/high temp thermocouples with this library. Temps in excess of 256C would overrun the int16_t when marshaling the scratchPad data bytes 0 and 1, causing corruption in the data stream.
Patch set was tested with an Adafruit MAX31850 sensor.
I've attempted to preserve functionality of all other non-MAX31850 devices by double checking data sheets. However, I do not have other devices here to test. (especially in < 0C temps)
Also detection between DS1825 and the MAX31850 was added. They share the same family byte in the ROM address. There is one reserved flag difference in the CONFIGURATION byte. Otherwise, it's not easy to tell the difference and the temp/fault bytes 0 and 1 are slightly different.
Also the fault flag and a reserved flag in byte 0 were being read as precision in the temperature data. Where as when there's no fault, the temp data is not corrupted. Gowever, when a fault occurs, temp data (even though small) is corrupted. With the MAX31850, you may still get temp data and a valid CRC when there is a fault.
With a MAX31850 only, this patch set will now detect the fault flag, then determine the reason for the fault, and return the right fault code temperature. (F values estimated, recommend using C values)
Also adjusted the DEVICE_DISCONNECTED values to be outside of the MAC31850 temp range.
Lastly, added/fixed support for Particle devices and one minor typecasting compile time issue.