Flight Core V2 Magnetometer and Barometer Issues
-
@Eric-Katzfey Hi Eric, I believe I solved the Magnetometer sensor failure issues. Extreme interference from my radio transmitter was causing issues. I swapped it out to a different radio and that issue is no longer happening. I am still getting barometer issues though. It seems as if every other time I boot the drone on the barometer says its missing. Usually a reboot will solve this, but even when it isn't missing, the barometer seems to be having issues. I am getting close to 5ft in elevation variance when in Altitude and Position flight modes. Even when the gps is disconnected I am still getting these errors. Could it be a faulty or damaged flight controller?
@linmur02 The barometer should come up every time. Can you test your FCv2 separately from the drone? Do you have any other FCv2 units, or just that single one? It would be good to isolate it as much as possible and then verify that you see it very single time. Do a complete power cycle between each attempt.
-
@linmur02 The barometer should come up every time. Can you test your FCv2 separately from the drone? Do you have any other FCv2 units, or just that single one? It would be good to isolate it as much as possible and then verify that you see it very single time. Do a complete power cycle between each attempt.
@Eric-Katzfey I could not get the barometer issues to show while strictly isolating the flight core v2, but I also have another FCv2 unit that I just completed assembling... after several hours of intermittent ESC connection issues (VOXL FPV ESC) the Baro 0 Missing error started displaying on the second flight core unit as well. Please advise.
-
@Eric-Katzfey I could not get the barometer issues to show while strictly isolating the flight core v2, but I also have another FCv2 unit that I just completed assembling... after several hours of intermittent ESC connection issues (VOXL FPV ESC) the Baro 0 Missing error started displaying on the second flight core unit as well. Please advise.
@linmur02 So you are saying that the original unit with failures stops failing when run in isolation. And that the second FC v2 is failing but it is assembled into a drone like the first unit when it was failing? If that's the case then you have some interference that is causing errors on the i2c lines to the barometer.
-
@linmur02 So you are saying that the original unit with failures stops failing when run in isolation. And that the second FC v2 is failing but it is assembled into a drone like the first unit when it was failing? If that's the case then you have some interference that is causing errors on the i2c lines to the barometer.
@Eric-Katzfey Yes, that is what appears to be happening. However I cannot properly isolate the FCv2 because other errors are present in QGroundControl due to the other missing components when trying to run the board in isolation. (GPS errors, RC Input Errors, etc.)
-
@Eric-Katzfey Yes, that is what appears to be happening. However I cannot properly isolate the FCv2 because other errors are present in QGroundControl due to the other missing components when trying to run the board in isolation. (GPS errors, RC Input Errors, etc.)
@linmur02 Even with those other errors you should still be able to check whether barometer has been detected and is providing data.
-
@linmur02 Even with those other errors you should still be able to check whether barometer has been detected and is providing data.
@Eric-Katzfey Yes, I would agree. So what is the path I need to take to fix these issues? The entire setup consists of a Modal AI FCv2, a Modal AI FPV 4-in-1 ESC (over UART), a Mateksys SAM-M10Q into the "J10" port, a Spektrum FPV Racing Serial Receiver into the "J12" port, an RF Design 900x US Telemetry radio into the "J1" port, a USB to serial adapter (for connection to QGROUNDCONTROL) into the "J3" port, and I am powering my VTX system from the 5V and Ground out of the "J7" PWM port. There is nothing in my system that should be causing interference with the barometer, especially if the barometer is over I2C, because I am connected to all my other basic components via serial connections.
-
@Eric-Katzfey Yes, I would agree. So what is the path I need to take to fix these issues? The entire setup consists of a Modal AI FCv2, a Modal AI FPV 4-in-1 ESC (over UART), a Mateksys SAM-M10Q into the "J10" port, a Spektrum FPV Racing Serial Receiver into the "J12" port, an RF Design 900x US Telemetry radio into the "J1" port, a USB to serial adapter (for connection to QGROUNDCONTROL) into the "J3" port, and I am powering my VTX system from the 5V and Ground out of the "J7" PWM port. There is nothing in my system that should be causing interference with the barometer, especially if the barometer is over I2C, because I am connected to all my other basic components via serial connections.
@linmur02 You need to figure out what is causing the interference. Start adding one thing at a time or if starting with the full drone, removing one item at a time and see if you can figure out what is causing the trouble.
-
@linmur02 You need to figure out what is causing the interference. Start adding one thing at a time or if starting with the full drone, removing one item at a time and see if you can figure out what is causing the trouble.
@Eric-Katzfey Hello I am also getting "barometer 0 missing" occasionally, a reboot or two also usually fixes it for me. I get it occasionally even when I'm powering the flight core V2 only on my drone (nothing else on my drone is powered), using J3 USB connector. I also just tested it with another flight corev2 unit, one that is fresh and not on any drone and also just powered with J3, it also gets this error. It seems that whenever It's initially powered, the barometer won't be detected until I reboot.
I did some further debugging using the MAVlink Console in QGC, it seems when the "barometer sensor 0 missing" occurs the icp driver doesn't actually start.nsh> icp201xx status INFO [SPI_I2C] Not running nsh> icp201xx start -I icp201xx #0 on I2C bus 4 (external) address 0x63 nsh> listener sensor_baro TOPIC: sensor_baro sensor_baro timestamp: 253700745 (0.020062 seconds ago) timestamp_sample: 253698133 (2612 us before timestamp) device_id: 12084001 (Type: 0xB8, I2C:4 (0x63)) pressure: 96713.71094 temperature: 51.86063 error_count: 0 -
@Eric-Katzfey Hello I am also getting "barometer 0 missing" occasionally, a reboot or two also usually fixes it for me. I get it occasionally even when I'm powering the flight core V2 only on my drone (nothing else on my drone is powered), using J3 USB connector. I also just tested it with another flight corev2 unit, one that is fresh and not on any drone and also just powered with J3, it also gets this error. It seems that whenever It's initially powered, the barometer won't be detected until I reboot.
I did some further debugging using the MAVlink Console in QGC, it seems when the "barometer sensor 0 missing" occurs the icp driver doesn't actually start.nsh> icp201xx status INFO [SPI_I2C] Not running nsh> icp201xx start -I icp201xx #0 on I2C bus 4 (external) address 0x63 nsh> listener sensor_baro TOPIC: sensor_baro sensor_baro timestamp: 253700745 (0.020062 seconds ago) timestamp_sample: 253698133 (2612 us before timestamp) device_id: 12084001 (Type: 0xB8, I2C:4 (0x63)) pressure: 96713.71094 temperature: 51.86063 error_count: 0@emarcphera It won't be running because when it was initially started it failed and exited. What version of PX4 are you using?
-
@emarcphera It won't be running because when it was initially started it failed and exited. What version of PX4 are you using?
@Eric-Katzfey
Hello, thank you for responding, the PX4 version is 1.14nsh> ver all HW arch: MODALAI_FC_V2 HW type: V2003000 HW version: 0x003 HW revision: 0x000 PX4 git-hash: 5e6a8c257371b6c45e55662daac5fe9fbd08040b PX4 version: 1.14.0 0 (17694720) Vendor version: 2.0.94 0 (33578496) OS: NuttX OS version: Release 11.0.0 (184549631) OS git-hash: 3f77354c0dc88793a47ff3b57595195ab45f7ba9 Build datetime: Feb 20 2025 01:58:47 Build uri: localhost Build variant: default Toolchain: GNU GCC, 9.3.1 20200408 (release) PX4GUID: 0006000000003333363031315106002b0036 MCU: STM32H7[4|5]xxx, rev. V nsh>I noticed that /etc/init.d/rc.board_sensors is where icp201xx -I start is ran:
nsh> cat /etc/init.d/rc.board_sensors | grep -nE 'icp201|bmp388' board_adc start voxlpm -X -b 3 -k -T VBATT start voxlpm -X -b 3 -T P5VDC start icm42688p -s -b 1 -R 12 start icm42688p -s -b 2 -R 12 start icp201xx -I start if param greater VOXL_ESC_CONFIG 0 then usleep 1500000 voxl_esc start fiI didn't want to mess with the file (not sure if I can), so I just installed a microsd card to the flight core and created this file:
nsh> cat /fs/microsd/etc/extras.txt usleep 2500000 icp201xx stop usleep 300000 icp201xx start -I -b 4 -a 0x63 -q nsh>just icp201xx start -I should also work, but I have repowered this flight core and used it on other flight cores multiple times and this issue no longer occurs. My guess is it's just a timing issue, icp201xx start is probably failing in rc.board_sensors because the barometer rail isn't fully up at that moment.
-
@Eric-Katzfey
Hello, thank you for responding, the PX4 version is 1.14nsh> ver all HW arch: MODALAI_FC_V2 HW type: V2003000 HW version: 0x003 HW revision: 0x000 PX4 git-hash: 5e6a8c257371b6c45e55662daac5fe9fbd08040b PX4 version: 1.14.0 0 (17694720) Vendor version: 2.0.94 0 (33578496) OS: NuttX OS version: Release 11.0.0 (184549631) OS git-hash: 3f77354c0dc88793a47ff3b57595195ab45f7ba9 Build datetime: Feb 20 2025 01:58:47 Build uri: localhost Build variant: default Toolchain: GNU GCC, 9.3.1 20200408 (release) PX4GUID: 0006000000003333363031315106002b0036 MCU: STM32H7[4|5]xxx, rev. V nsh>I noticed that /etc/init.d/rc.board_sensors is where icp201xx -I start is ran:
nsh> cat /etc/init.d/rc.board_sensors | grep -nE 'icp201|bmp388' board_adc start voxlpm -X -b 3 -k -T VBATT start voxlpm -X -b 3 -T P5VDC start icm42688p -s -b 1 -R 12 start icm42688p -s -b 2 -R 12 start icp201xx -I start if param greater VOXL_ESC_CONFIG 0 then usleep 1500000 voxl_esc start fiI didn't want to mess with the file (not sure if I can), so I just installed a microsd card to the flight core and created this file:
nsh> cat /fs/microsd/etc/extras.txt usleep 2500000 icp201xx stop usleep 300000 icp201xx start -I -b 4 -a 0x63 -q nsh>just icp201xx start -I should also work, but I have repowered this flight core and used it on other flight cores multiple times and this issue no longer occurs. My guess is it's just a timing issue, icp201xx start is probably failing in rc.board_sensors because the barometer rail isn't fully up at that moment.
@emarcphera It's quite possible. In older versions the ESC driver was started before the barometer driver. In newer releases it has been moved after the barometer driver so the barometer driver is being started earlier in the timeline. You can see our vendor version is 2.0.94. That is where that change was made. In version 2.0.93 it has the ESC start before the barometer.
-
@Eric-Katzfey
Hello, thank you for responding, the PX4 version is 1.14nsh> ver all HW arch: MODALAI_FC_V2 HW type: V2003000 HW version: 0x003 HW revision: 0x000 PX4 git-hash: 5e6a8c257371b6c45e55662daac5fe9fbd08040b PX4 version: 1.14.0 0 (17694720) Vendor version: 2.0.94 0 (33578496) OS: NuttX OS version: Release 11.0.0 (184549631) OS git-hash: 3f77354c0dc88793a47ff3b57595195ab45f7ba9 Build datetime: Feb 20 2025 01:58:47 Build uri: localhost Build variant: default Toolchain: GNU GCC, 9.3.1 20200408 (release) PX4GUID: 0006000000003333363031315106002b0036 MCU: STM32H7[4|5]xxx, rev. V nsh>I noticed that /etc/init.d/rc.board_sensors is where icp201xx -I start is ran:
nsh> cat /etc/init.d/rc.board_sensors | grep -nE 'icp201|bmp388' board_adc start voxlpm -X -b 3 -k -T VBATT start voxlpm -X -b 3 -T P5VDC start icm42688p -s -b 1 -R 12 start icm42688p -s -b 2 -R 12 start icp201xx -I start if param greater VOXL_ESC_CONFIG 0 then usleep 1500000 voxl_esc start fiI didn't want to mess with the file (not sure if I can), so I just installed a microsd card to the flight core and created this file:
nsh> cat /fs/microsd/etc/extras.txt usleep 2500000 icp201xx stop usleep 300000 icp201xx start -I -b 4 -a 0x63 -q nsh>just icp201xx start -I should also work, but I have repowered this flight core and used it on other flight cores multiple times and this issue no longer occurs. My guess is it's just a timing issue, icp201xx start is probably failing in rc.board_sensors because the barometer rail isn't fully up at that moment.
@emarcphera If you want to try an earlier version you can get v1.14.0-2.0.85 here: http://voxl-packages.modalai.com/dists/fc-v2/sdk-1.4/modalai_fc-v2_1.14.0-2.0.85.px4
-
@Eric-Katzfey
Hello, thank you for responding, the PX4 version is 1.14nsh> ver all HW arch: MODALAI_FC_V2 HW type: V2003000 HW version: 0x003 HW revision: 0x000 PX4 git-hash: 5e6a8c257371b6c45e55662daac5fe9fbd08040b PX4 version: 1.14.0 0 (17694720) Vendor version: 2.0.94 0 (33578496) OS: NuttX OS version: Release 11.0.0 (184549631) OS git-hash: 3f77354c0dc88793a47ff3b57595195ab45f7ba9 Build datetime: Feb 20 2025 01:58:47 Build uri: localhost Build variant: default Toolchain: GNU GCC, 9.3.1 20200408 (release) PX4GUID: 0006000000003333363031315106002b0036 MCU: STM32H7[4|5]xxx, rev. V nsh>I noticed that /etc/init.d/rc.board_sensors is where icp201xx -I start is ran:
nsh> cat /etc/init.d/rc.board_sensors | grep -nE 'icp201|bmp388' board_adc start voxlpm -X -b 3 -k -T VBATT start voxlpm -X -b 3 -T P5VDC start icm42688p -s -b 1 -R 12 start icm42688p -s -b 2 -R 12 start icp201xx -I start if param greater VOXL_ESC_CONFIG 0 then usleep 1500000 voxl_esc start fiI didn't want to mess with the file (not sure if I can), so I just installed a microsd card to the flight core and created this file:
nsh> cat /fs/microsd/etc/extras.txt usleep 2500000 icp201xx stop usleep 300000 icp201xx start -I -b 4 -a 0x63 -q nsh>just icp201xx start -I should also work, but I have repowered this flight core and used it on other flight cores multiple times and this issue no longer occurs. My guess is it's just a timing issue, icp201xx start is probably failing in rc.board_sensors because the barometer rail isn't fully up at that moment.
@emarcphera I'll try to recreate the issue. If I can reproduce it I can then test a fix. Most likely would just need to add a small delay before the icp201xx start command.
-
@Eric-Katzfey
Hello, thank you for responding, the PX4 version is 1.14nsh> ver all HW arch: MODALAI_FC_V2 HW type: V2003000 HW version: 0x003 HW revision: 0x000 PX4 git-hash: 5e6a8c257371b6c45e55662daac5fe9fbd08040b PX4 version: 1.14.0 0 (17694720) Vendor version: 2.0.94 0 (33578496) OS: NuttX OS version: Release 11.0.0 (184549631) OS git-hash: 3f77354c0dc88793a47ff3b57595195ab45f7ba9 Build datetime: Feb 20 2025 01:58:47 Build uri: localhost Build variant: default Toolchain: GNU GCC, 9.3.1 20200408 (release) PX4GUID: 0006000000003333363031315106002b0036 MCU: STM32H7[4|5]xxx, rev. V nsh>I noticed that /etc/init.d/rc.board_sensors is where icp201xx -I start is ran:
nsh> cat /etc/init.d/rc.board_sensors | grep -nE 'icp201|bmp388' board_adc start voxlpm -X -b 3 -k -T VBATT start voxlpm -X -b 3 -T P5VDC start icm42688p -s -b 1 -R 12 start icm42688p -s -b 2 -R 12 start icp201xx -I start if param greater VOXL_ESC_CONFIG 0 then usleep 1500000 voxl_esc start fiI didn't want to mess with the file (not sure if I can), so I just installed a microsd card to the flight core and created this file:
nsh> cat /fs/microsd/etc/extras.txt usleep 2500000 icp201xx stop usleep 300000 icp201xx start -I -b 4 -a 0x63 -q nsh>just icp201xx start -I should also work, but I have repowered this flight core and used it on other flight cores multiple times and this issue no longer occurs. My guess is it's just a timing issue, icp201xx start is probably failing in rc.board_sensors because the barometer rail isn't fully up at that moment.
@emarcphera I cannot reproduce the issue with v1.14.0-2.0.94 nor one of our most recent builds v1.14.0-2.0.105.
-
@emarcphera I cannot reproduce the issue with v1.14.0-2.0.94 nor one of our most recent builds v1.14.0-2.0.105.
@Eric-Katzfey That is strange, I just upgraded the firmware to v1.14.0-2.0.98 on one of my flight core units, I got rid of the micro sd and the extras.txt file as well and I don't seem to get the "barometer sensor 0 missing" error anymore. Interestingly /etc/init.d/rc.board_sensors is the exact same so something else may be going on instead.
nsh> cat /etc/init.d/rc.board_sensors | grep -nE 'icp201|bmp388' board_adc start voxlpm -X -b 3 -k -T VBATT start voxlpm -X -b 3 -T P5VDC start icm42688p -s -b 1 -R 12 start icm42688p -s -b 2 -R 12 start icp201xx -I start if param greater VOXL_ESC_CONFIG 0 then usleep 1500000 voxl_esc start fi nsh: cat: open failed: No such file or directory nsh> -
@emarcphera I cannot reproduce the issue with v1.14.0-2.0.94 nor one of our most recent builds v1.14.0-2.0.105.
@Eric-Katzfey One more update, I ended up upgrading the firmware to v1.14.0-2.0.98 for all the flight core units that I have and I'm confident the barometer missing issue is gone now. Thank you for your help and your quick responses.
-
@Eric-Katzfey One more update, I ended up upgrading the firmware to v1.14.0-2.0.98 for all the flight core units that I have and I'm confident the barometer missing issue is gone now. Thank you for your help and your quick responses.
@emarcphera Huh, interesting. Okay, thanks for posting the update!
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login