pr-bmp388 updates - measurement improvements from field testing #13128
Conversation
Improvements added after field testing. Now using oversampling which has smoothed out the data. Using the max measurement times from the Bosch datasheet instead of 'expected' to play it safe. Removed 'sleep' from task and instead use the task poll rate for collect/measure cycle.
Fix build issue as master_v5x_sensors is a little behind master
| @@ -45,13 +45,16 @@ | |||
| BMP388::BMP388(IBMP388 *interface, const char *path) : | |||
| CDev(path), | |||
| ScheduledWorkItem(px4::device_bus_to_wq(interface->get_device_id())), | |||
| _px4_baro(interface->get_device_id()), | |||
| _px4_baro(interface->get_device_id(), ORB_PRIO_MAX), | |||
There was a problem hiding this comment.
Why ORB_PRIO_MAX? You might want to choose a slightly lower priority that still achieves what you want/need. Then if someone optionally connects a higher quality external barometer it can become the primary.
There was a problem hiding this comment.
Good catch, I'll move to ORB_PRIO_DEFAULT
|
hey @dagar , so I'm getting close to submitting a PR for our FMU v5m board, but it uses this driver (which is currently in the master_v5x_sensors branch), and I'm looking to get the v5m board into master... What do think the best approach is? |
Let's get these into master directly. |
PR here: #13190 |
Describe problem solved by the proposed pull request
Improved measurement quality by oversampling, cleaned up task removing use of
sleepin the taskTest data / coverage
Bench test comparison against Pixhawk 4 Mini showed equal or better measurement stability. Field testing showed large improvements with altitude hold compared to first pass at this driver.
Describe your preferred solution
Followed (most) of the settings defined by Bosch datasheet
Describe possible alternatives
N/A
Additional context
N/A