ArduPilot
AP_Baro: Support MS5837-02BA #27787
The changes include differentiation between multiple MS5xxx sensor variants using the PROM Word 0 bits [11:5], enabling automatic initialization and configuration of the correct driver. Additionally, this update includes specific calculations and second-order compensation logic for the MS5837-02BA sensor, making it more viable for shallow water applications.
Key Changes Differentiation Logic:
Extracted product ID from PROM Word 0 bits [11:5] to identify sensor variants: MS5837-30BA26: 0b0011010 MS5837-02BA01: 0b0000000 MS5837-02BA21: 0b0010101 New Sensor Type:
Added a new enum type BARO_MS5837_02BA to differentiate MS5837-02BA sensors. Calculation Logic:
Implemented _calculate_5837_02ba() for MS5837-02BA-specific pressure and temperature calculations, including second-order compensation for temperatures below 20°C. Driver Initialization:
Updated _init() to automatically detect and initialize the appropriate sensor type using PROM data. Added automatic assignment of water pressure type (AP_Baro::BARO_TYPE_WATER) for MS5837 sensors.
fix #27787
hey @ES-Alexander & @Williangalvani, I modified the requested changes kindly review it once again.
Oh, one more thing - I just searched the repository for MS5837, and it looks like you'll also want to add your DEVTYPE changes in Tools/scripts/decode_devid.py :-)
hey @ES-Alexander, do i have to add the changes of this AP_Baro: update MS5837-BA Compensation #29132 in my PR
do i have to add the changes of this AP_Baro: update MS5837-BA Compensation #29132 in my PR
Nope - that's a PR from me, I just linked to this one as some relevant context, because I saw the missing parts of the 30BA variant while comparing the different _calculate_5xxx* functions as part of reviewing this PR :-)
Just one comment left, which I suggested removing before as well.
Remaining review stuff is up to @Williangalvani from here :-)
Thank you for your detailed review and clear explanation. I will go ahead and remove the comment and wait for feedback from the other reviewer.
Hi @ES-Alexander, could you please remind @Williangalvani to review my code? It's been a week since I submitted it. Thanks!
He’s been on break this week and didn’t get to it before that started. I’ll remind him in a couple of days, when he gets back :-)
I'm back! @Shaikimram thank you for the PR. looks good to me and works as expected here. I rebased your branch to get rid of a conflict, I hope you don't mind!
LGTM!
Thank you @Shaikimram and @ES-Alexander !
Tested on bench and works as expected
(let's wait for CI to pass anyway, before merging)
hey @Williangalvani and @ES-Alexander, thank you for reviewing my code and for your feedback
Hi @Williangalvani , could you please remind @tridge to review my code? It's been a week. Thanks!
@Williangalvani and I have been testing this with hardware today, and have found that unfortunately the situation is more complicated than we realised.
In particular, there are more variants of both the 30BA and 02BA sensors (although they're quite difficult to find information about), and there's an overlap between some of the models that likely means the product type designator cannot be assumed to be unique to a given pressure range.
In trying to test our existing 30BA devices we found them to consistently return 0b00000001 for bits 11-4, which is likely a 30BA01 sensor, which is seemingly the only orderable version at the moment[^1], and has an overlap with the documented 02BA01 variant. This project seems to have run into the same problem back in 2023.
[^1]: 30BA26 is apparently no longer manufactured, despite being the only 30BA option with a product type described in available datasheets.
For a little bit of clarity, this 2019 datasheet indicates some additional 02BA variants, and some reasoning behind the naming scheme (and to some extent the product type identification scheme).
If it is relevant, it seems the existing Blue Robotics Bar30 and Bar02 sensor packages could still be differentiated using these IDs (because the Bar02 seems to use the 02BA21 variant), but it feels problematic to create a seemingly general driver that knowingly isn't correct for some cases of the same device series.
As a couple of potential alternatives we're now considering, we could instead:
- try to better understand the effect of the different calibration factors, and see if there's one or a combination of them that create an exclusive range of possible valid values against the sensor specifications
- this could be robust, but may be somewhat unintuitive to do and make sense of
- initialise the sensor as one type, then inspect the first measurements using a plausibility heuristic and swap to the other sensor if the readings don't seem reasonable
- this is reasonably straightforward, but requires performing measurements during initialisation, and may fail problematically at edge cases or where the sensor is damaged
I was thinking I could contribute some code in this PR, but seems like it's more complicated than I expected and you guys already have thorough discussions about this. Happy to be here though
... we could instead try to better understand the effect of the different calibration factors, and see if there's one or a combination of them that create an exclusive range of possible valid values against the sensor specifications
@Williangalvani and I did some more investigation to determine a path forward, and it looks like we can likely estimate board type based on C1, the "Pressure sensitivity" coefficient:
From the sensors we had on hand (and the datasheet example values) it seems to be decently separable, and it makes intuitive sense that a pressure sensitivity factor would correlate well with sensors of different pressure ranges (as compared to reference temperature, for example, which could change independently of sensor type, e.g. coincidentally depending on the manufacturing environment).
Applying a Gaussian separation to the data provides a separation value of 35980, but given
- the datasheet example value for 30BA sensors is somewhat close to that,
- the 02BA sensor support is a new addition, so is less critical to get correct than making sure the 30BA sensors continue being identified correctly (false positives are preferable to false negatives), and
- round numbers are nice
it seems reasonable to bump that up, e.g. to 37000.
@ES-Alexander and I tested his approach and we are happy with it. I'm leaning towards skewing the threshold so we have a higher risk of misidentifying the Bar02 as a Bar30, as that is a new sensor, while we have a significant userbase running on Bar30.
Needs a rather large rebase, though, as the drivers were split.
Merged as agreed on DevCall.
Reminder about the webtools documentation... and there's some stuff in various other places tooo...
It would appear that this has been resolved. However, I myself had to resolve this issue for an internal project using these sensors and reached out to TE Connectivity, who provided more information that might be useful in validating or refining the solution settled upon here - including thousands of sample points from units on the production floor.
Of particular note are:
2025/02/06
Register 0 of PROM is used to differentiate different versions from a same pressure range. Not for differentiating pressure ranges (02bar VS 30bar).
and:
2025/03/07
Please see below information which I could gather from the product team. Kindly review this and let us know if it helps.
We checked with some data we have in production for C1(w1ab) and C2 (w2ab) on the 30BA and 02BA, and it seems very likely to work.
However, we have an occurrence with an overlap in C1 between the 30 and 02 BA. Due to 1 sensor in my sample (every sensor passed the EoL test -> considered good)
For me, this method may give wrong results. So, a proposal could be: When C1 < 35000 : 30BA When C1 > 35000 : most likely 02BA -> need confirmation by (for example) using the 02BA equation at atm so see if applicable
See information bellow:
data on 18470 sensors 30BA01
Value C1 C2 C3 C4 C5 C6 Min 27035 21552 15185 11678 26682 25351 Max 41918 42063 24874 26051 31283 27346 Average 28230.43 26710.7 16909.65 17139.27 28847.82 26208.76 histogram for 30BA
values of all C1 for 30BA
values of C2 for 30BA
data on 8764 sensors 02BA01
Value C1 C2 C3 C4 C5 C6 Min 40238 37862 23690 23764 29505 25503 Max 45033 45058 26992 28654 33446 27293 Average 42734.76 41287.69 25489.99 26169.49 31480.67 26414.19 histogram for 02BA
values of C1 and C2 for 02BA
