CubeBlack can not detect its baro

I plugged my cubeBlack into my laptop via USB, but got no bootup beeps. I gave the pixhawk external power and then it initialized, but got these messages:

30.11.2021 14:04:19 : Check BRD_TYPE: Failed to init CubeBlack - sensor
30.11.2021 14:04:15 : Initialising APM
30.11.2021 14:04:15 : Frame: HEXA
30.11.2021 14:04:15 : RCOut: PWM:1-12
30.11.2021 14:04:15 : CubeBlack 0040002A 594B5012 20383557
30.11.2021 14:04:15 : ChibiOS: d4fce84e
30.11.2021 14:04:15 : ArduCopter V4.0.7 (0bb18a15)

After this I tried to update to 4.1.1, but now I get these messages:

30.11.2021 13:52:20 : T Failed
30.11.2021 13:52:20 : Config error: Board Validation $CHECK_BARO1_PRESEN
30.11.2021 13:52:20 : Config Error: fix problem then reboot
30.11.2021 13:52:18 : motors not allocated
30.11.2021 13:52:18 : RCOut: Initialising
30.11.2021 13:52:18 : CubeBlack 0040002A 594B5012 20383557
30.11.2021 13:52:18 : ChibiOS: 08877972
30.11.2021 13:52:18 : ArduCopter V4.1.1 (01d1aa1e)

What is going on?

Hey @proficnc @bugobliterator @tridge
Recently one of my friends faced with similar issue on CubeOrange. Might be something to look at?

@Hoehenarbeit is this issue reproducible? Are you getting this error at every boot?

Yes, I´m getting this on every boot.

And this goes away if you roll back the version to older one?

No, than I get the first set of messages.

Can you try resetting the parameters by flashing Plane and then copter, please ensure that you backup parameters/missions before that.

Have already tried flashing PX4 onto it and then back to ArduCopter. PX4 did not seem to report such issues.

Are you available on Discord, maybe we can setup a debugging session to get at the bottom of this.

Guess i have had same prob few days ago on cube orange:

rebooted it and worked.

Sorry, I don´t have discord.

I am having the same issues on a Cube Orange. I have done what was recommended but I still have the error. @bugobliterator I have discord if you would like to have a chat.

2022-01-19 14:50:39 : T Failed
2022-01-19 14:50:39 : Config error: Board Validation $CHECK_BARO1_PRESEN
2022-01-19 14:50:38 : Config Error: fix problem then reboot
2022-01-19 14:50:37 : motors not allocated
2022-01-19 14:50:37 : RCOut: Initialising
2022-01-19 14:50:37 : CubeOrange 00250030 3039510D 30333533
2022-01-19 14:50:37 : ChibiOS: 45395b6a
2022-01-19 14:50:37 : ArduCopter V4.1.3 (2fb939a1)

I am back at it, trying to figure out what is happening. I have actually found out that the barometer is probably the first that is being check, but in reality, something is wrong with the sensor drivers. No sensor appears to be read. PX4 works on this board. I have opened a issue here.


Thanks for the report. Do you have any other Cubes around to test? I suspect that the board’s barometer is malfunctioning (which is quite rare) and this is how 4.1 is handling it.

FYI @bugobliterator

PX4 not discovering a broken sensor, unfortunatly doesn’t surprise me at all, we strongly reccomend against PX4 for this reason.

ignoring broken sensors on takeoff is a very bad thing to do.

I suggest getting an RMA, I have tested that virsion of firmware here and have had no issues, however, once I can load your parameters into the cube, I will try again, just in case.

May I ask what else is connected?

Sorry about the log access. I updated it now. We have other boards already installed with 4.1.3 and all is fine. This board was functioning just fine with 4.0.5 before. I checked the flight log out of curiosity and I do not think there is a way to distinguish between the barometers but at least the pressure seemed to be read correctly.
I installed PX4 and tried to see if there was a second baro that I could somehow verify it’s conditions but I was not able. I will get to the workshop in a few h and check with a board that is fine to see if that one sees 2 barometers or PX4 just uses one baro with the CubeOrange. I got lost in their code trying to figure out if for this board both barometers are used.
A snippet of what I tried

nsh> ms5611 status
INFO [SPI_I2C] Running on SPI Bus 1
ms5611: read: 18231 events, 229629us elapsed, 12.60us avg, min 9us max 59us 1.462us rms
ms5611: com_err: 0 events
device: ms5611
nsh> ms5611 stop
nsh> ms5611 start -I
WARN [SPI_I2C] ms5611: no instance started (no device on bus?)
nsh> ms5611 start -X
WARN [SPI_I2C] ms5611: no instance started (no device on bus?)
nsh> ms5611 start -s
ms5611 #0 on SPI bus 1
nsh> ms5611 start -S
WARN [SPI_I2C] ms5611: no instance started (no device on bus?)
nsh> uorb top
e[0Jupdate: 1s, num topics: 114

sensor_accel 0 5 401 8 48
sensor_accel 1 4 409 8 48
sensor_accel 2 4 409 8 48
sensor_baro 0 2 75 1 32

If any of you want to test anything on the board we could arrange a remote desktop session.

@proficnc Nothing else is connected now. Parameters are default. I guess if we can verify the autopilot hardware is the issue we will send if for RMA if you’ll have it since maybe we voided the warranty. I did not do the best job with the transparent plastic clips when opening the cube but was careful with the board and wore a antistatic wristband.

dataflash log and telemetry log for each of non-working and working setups
would be great!

Thanks for the log.

It looks like Copter 4.1.0 is on the board but I can’t imagine that 4.1.3 would make a difference. If the parameters have been reset and this error is coming up and other cubes seem fine then I think it is safe to assume that it is a hardware issue – namely the baro has been broken.

4.0.5 shows no prearm errors.
PX4 shows two barometers on another CubeOrange.

nsh> listener sensor_baro
TOPIC: sensor_baro 2 instances
Instance 0:
timestamp: 160713441 (0.009276 seconds ago)
timestamp_sample: 160713428 (13 us before timestamp)
device_id: 3997730 (Type: 0x3D, SPI:4 (0x00))
error_count: 0
pressure: 986.8000
temperature: 50.5200
Instance 1:
timestamp: 160723961 (0.007678 seconds ago)
timestamp_sample: 160723951 (10 us before timestamp)
device_id: 3997706 (Type: 0x3D, SPI:1 (0x00))
error_count: 0
pressure: 987.9300
temperature: 50.3700

Here is the log prior to update. I enabled LOG_DISARMED, on 4.1.3, but did not get any log.
I think @rmackay9 was right. It looks like something is wrong when it comes to the second barometer. Autoanalysis of the above log says

Test: NaNs = FAIL - Found NaN in POS.RelOriginAlt Found NaN in CTUN.DSAlt
Test: Pitch/Roll = UNKNOWN - ‘BarAlt’

Later Edit: Autoanalysis of the second log shows the above lines so I do not know how relevant they are.


It’s on our to-do list to fixup the autoanalysis (it has fallen out of date) so I wouldn’t worry about that.

Each new version tends to have some additional safety checks so 4.1 complaining (even if 4.0.x did not) is probably a good thing. The new version is alerting you to a problem that would have otherwise gone unnoticed.

In the dev team we’ve discussed changing the error so it’s a pre-arm error instead of a startup error but it seems like it is a hardware issue so I think an RMA is in order.