Bad baro health

Have you tried the latest beta, Copter-3.5.4-rc2?

not yet, will test it today and let you know.

Mission planner this morning told me there is a new 3.5.4, is it the latest stable? Can i try that?

thanks for your help.


Just tested, as soon as i enable Canbus i start getting bad baro health messages.

That is using a Zubax canbus ext gps.

Magnetometer and Gps look like they work no prob, just keep getting bad baro health messages.

I tried can 1,2 and both. Tried main baro 0,1,2. Still bad baro health.

Tried uavcan.pubp-pres = 0 to disable barometer driver on zubax, still bad baro health.

As soon as i disable canbus, everything back to normal.

All this on a Pixhawk 2.1 on latest 3.5.4 stable (i guess this includes 3.5.4 rc2 fixes as adviced).

I wonder if someone has this canbus gps working or not on 3.5.x firmware.



Guess it just doesn’t work.

Anything else to try?


Hello corrado
Having same issue. So i am supporting you.
Did you load the appropriate extra code

Power off the Pixhawk, extract its microSD card and mount it on a computer. Create a file etc/rc.txt on the card and put the following script in it:

uORB will be started again by the main init script later, it’s OK

if uorb start
echo "ext: uORB started"
if uavcan start 1
echo "ext: UAVCAN started"
echo "ext: Could not start UAVCAN"
echo "ext: Could not start uORB"

This delay allows UAVCAN to pick external sensors before internal ones

sleep 8
Insert the card back into Pixhawk.

Done, now the Pixhawk will be using barometer installed on Zubax GNSS, provided that Zubax GNSS was connected to the bus at the time of boot; otherwise it will fall back to internal barometer.

Thank you very much. Is this safe to do on 3.5.4?

I’ll try it tomorrow.

Let me get this straight, i need to create a /etc directory or there is already an /etc directory?

This trick should get rid of the bad baro health message?

I guess sleep 8 goes in the file too…



Please read following

my theory is based on data publication frequencies. I think data s are either published with frenquency rate too high or too slow. It is just theory…
So i would like zubax users to share zubax config to compare…

read it, thanks.

I guerss i have to re-enable barometer and see.

You did this and baro bad health disapperead?


but Barometer need to be enabled on Zubax GNSS.
If baro “bad health” appear, on my opinion it means that pixhawk is receiving data raw’s from 2 differents sources which are not consistent.

First reaction could be to disable internal baro but it looks impossible.
Second reaction could be not to use external baro. That is too bad. Zubax GNSS baro is better.
Third reaction, a question : is there any data publication frequencie issues? ==> I would like to tune as best as possible f rate of external flow data’s
Fourth reation, another question : Is UAVCAN stack an issue ? As u Know uavcan improvement would be for 3.6

Looks like us, uavcan users, are a bit on our own. Not much comunication about what issues are and if there is a solution to it now. Probably will wait for the releae of the new uavcan stack (hope soon) and in the mean time i’ll ground my 2 zubax units.



Actually I’m using my two Zubax with Arduplane.

I 'm not receiving any baro health error but I’m not even sure what baro the system use, hope it is the Zubax baro since the GND_PRIMARY parameter is set to 1 to enable the Zubax baro.

Mag seems to work since it is detected as external.