I added an external barometer (MS5611) to the wingtip of a plane. It is just meant to act as a temperature sensor and works fine in that regard. Using BARO_PRIMARY,0 I assumed prevents the external baro from being used for altitude calculation.
But after a 2-3 failed launches and looking for the cause, I discovered in the log that I now have a zig-zagging altitude value instead of the smooth curve I had before installing the external baro. So it almost seems like the two baros are both used - and alternatingly, not merged�
Is this supposed to be like that and if yes, is there any way to really use external baro only for temperature measurements?
On the same plane I had added an external magnetometer as the GPS with compass is too close to a magnetic hatch. Itâs out on the wingtip together with the baro. I had overlooked that setting COMPASS_ORIENT is no longer necessary, and as the compass (QMC5883) was mounted vertically and pointing to the front (I guess), I set COMPASS_ORIENT,20.
when pitching the vehicle down, the X component should increase in value
when rolling the vehicle right, the Y component should increase in value
But these values all only showed 0 in MP (while magfield was constantly changing).
I thought Iâd try it anyway, assuming a magnetometer could only ever make things go wrong during automated flight (TKOFF, WP, RTLâŚ) and even then it could only cause heading problems. My question: Is that assumption even correct? Because I have a feeling itâs not.
One or both of those two new sensors totally prevented a successful launch today - the plane wouldnât gain altitude and crashed. Before installing them, it worked perfectly.
Watching the FPV now I realized that there was a lot of crazy stuff going on, like the (synthetic) windspeed for example. On previous attempts it was stuck to 52 km/h even before launch, and there was barely a breeze.
Isnât this just a logging problem? APM planner does not cope with instance numbers but instead puts all the data on the same format type. Try looking at the log with mission planner or mavexplorer.
Thanks, I shouldâve guessed that myself from the fact that the baros were not selectable separately. So far I always used APM for logs as I found it much more intuitive than MPâs log viewer. I hadnât heard of MAVExplorer, so I just tried it now but unfortunately it throws an error on trying to create any kind of graph.
Either way, Iâm still not sure where to find information on how to make sure baro 2 is used as temp sensor only and not for altitude calculation, and if the second baro contributed to the crashes on launch - or if it was the compassâŚ
I donât want to try again before solving this, this already cost me a 128GB U3 SD card, which was ejected from the RunCam Hybrid on impact and is now no longer formattable.
Ok, at least I finally found out where to do the compass check described here. The values in question cannot be displayed on MP HUD (those are static offsets, hence they never change), instead MAVLink Inspector is the place to look for the X, Y, Z components:
Maybe this helps someone looking for the same thing.
Those are all correct for northern hemisphere, at least now after calibrating again.
Another update: The cheap compass module turned out to be broken/DOA. It was a âGY-273 QMC5883â, which actually is a clone of a former product by Honeywell that sadly is no longer in production.
So beware of those, the fact that they can be addressed and provide data doesnât mean they really work. No matter how many times it was calibrated, this one randomly jumped by up to 180 degrees. I installed a LIB3MDL by Adafruit in its place which instantly worked.
As I wasnât able to find out how to prevent the second barometerâs readings from being used for altitude calculation (and only as a temp sensor), I removed it for now and will give the plane another try.
have you managed to get the secondary temperature displayed correctly by now?
I got some BMP280s and connected it to the Ardupilot using a Racerstar F405 Wing Nano FC, to the DA1 and CL1 connections, supplying it with 3,3V, but without success.
On the OSD I can display the IMU temperature, but the other two options ATEMP and BTEMP display only âââ and â0â respectively. When I connect the BMP280 the A- and B-Temp display does ot change, instead the board / IMU temperature gives crazy with numbers like -137 degrees. Also the displayed altitude suddenly is something stupid like -2237 meters, changing constantlyâŚ
I also tried the supply with 5V. Then tried to switch the DA and CL lines. Also tried the DO and CS connections in my frustration, but nothing works. Also tried another BMP280, in case the one I used was faulty, no luck.
I use VTX on 5,8G.
On another plane I used a simple temperature sensor with INAV on the Matek 405 sucessfully, with the same VTX setup.
I use Arduplane 4.1.6. I also tried all possible combinations of the parameters âBARO_PROBE_EXTâ, âBARO_PRIMARYâ and âBARO_EXT_BUSâ, no success.
And I guess âGND_PROBE_EXTâ does not exist and is actually âBARO_EXT_BUSâ
Would you have tips to get it to work please - thank you!
I never fly in winter, so itâs been about 3 months since I did anything with AP, so my reply might not be 100% qualified. Yes, I got that working on both AP and AC, as far as I can remember.
Things to check:
Racerstar F405 Wing Nano doesnât seem to be listed at ArduPilot firmware : /Plane - is it a clone of Matek F405 Wing?
Are you using âlatestâ firmware available at ArduPilot firmware : /Plane/latest ? Iâm pretty sure I was using 4.2.0-DEV already in July. Might also explain the absence of GND_PROBE_EXT in your setup.
To check if sensors work, itâs best to check values via Mission Planner or MAVLink Inspector when connected via USB. That way you donât even need to plug a battery to power the VTX.
Yes the Racertar is a clone using the Matek F405 Wing.
I think you must be right about the firmware, I hesitate to use a âdevâ firmware though, as it might not be stable they say. But I will definitely try it! Have you had any issues with the â4.2.0-DEVâ at all?
Oh - just read your earlier note again. I guess that is still an unsolved issue, as I also only want to use the baro to display the temperature? Did you come across any other issues using the using 4.2.0-DEV?
As far as I can remember, I ended up using 2 baros, one just to display temperature, and never had any issues with it. Just select the internal one as BARO_PRIMARY and check the values according to Barometer (external) â Copter documentation.
The latest/dev version changes every day, Iâve been using it for years now and never had any critical issues, neither did I hear of any. The only thing that can happen, especially on older boards, is that features suddenly disappear due to memory limitations. You can use https://custom.ardupilot.org to build a firmware to your liking (always based on âlatestâ).
By the way, Iâd recommend investing in a real Matek and avoid Racerstar.
I am using the âreal Matekâ on the bigger planes and am very happy with it. There I also have a temperature sensor which is working, but with INAV.
BTW, are you using the baros with Copter or planes? I flying a plane on this occasion, just loaded the 4.2dev and had no luck so far, but need to do more checks first, before I can judge progperly if I get it to run as well. Canât get the bound receiver to go through the FC for a startâŚ
And, still this command âGND_PROBE_EXTâ is missing Attached a screen shot after doing a search
Since GND_EXT_BUS is also missing in Complete Parameter List â Copter documentation I assume itâs obsolete. Sometimes the documentation hasnât caught up with the latest changes (of which there are a lot in AP). I just checked one of my configs, and itâs also missing there.
Hereâs how I have set it on one of my planes (all of my planes so far are running Matek F405-WING):
thank you for going through the trouble checking your configs!
Just flashed to 4.1.6 version back and had normal connection from radio to receiver to the outputs in AP. Then I flashed 4.2dev back and same again - radio and receiver were connected, but nothing seems to come through to the FC when looking at the calibration radio screen, see attached.
I tried several times, once without any mods to the configs of 4.2dev, once with all pre-saved parameters from 4.1.6 uploaded to the new 4.2dev FW - same result, no signals coming through from the radio/receiver.
Do I have a thinking error in my head, have I missed a step maybe after flashing the new FW to get the radio signals going? I have a Taranis X9 plus and an R9 receiver, the binding light is green and I also re-bound the receiver successfully
Or is it something else in the 4.2dev FW? But it works for you, so I assume I am doing something wrong⌠Maybe the temperature is not so important after all
And yes, you are right, I do use and also love ArduPilot, it seems a lot more versatile than INAV, which I use on another plane.
Have a great sunday, bad rainstorms here today all day - so just right to do somthing for the hobby
Hi there, Iâm a bit short on time, so for now Iâd just recommend trying another latest/dev version (a day or a week earlier) - sometimes (very rarely) there are daily versions that miss some functions.
The working 4.2.0 versions I have on my craft all date back to October or September, but I think a problem with RX data coming through would have been noticed pretty quickly.
As I switched to Crossfire in 2020 after two broken (going insane, actually) R9 modules, Iâm a bit out of touch with R9. But I guess itâs just SBUS?
Spending hours, I also compared all my working versionâs (4.1.6) parameters to do with FRSKY and e.g. RCin / SBUS, but they are all the same , nothing obvious. The âSERIAL1_PROTOCOLâ is set on 2, which is MAVLink2 and working perfectly in 4.1.6., although I use FRSKY. Why should it not work with the dev version I wonder. Did you have to set yours on 29 = Crossfire VTX?
Another thought, is it to do with the actual barometer - I used a bmp280 and you got it to work with the MS5611? I think the FC also has a bmp280 on board, maybe they clash somehow Iâll just buy some MS5611and try them.
Btw, what trouble did you have with the R9 module? I never had any issues so far, they worked for years very reliably Only trouble is, that I cant get any âoldâ receivers without the OTA protocol anywhere anymore
Check here: Serial Port Configuration Options â Plane documentation : The serial port that the receiver is connected to has be set to protocol 23 = RC IN. I have no idea why it would be working set to MAVLink, as the R9 module is certainly not sending that.
Check Mateksys F405-Wing â Copter documentation for recommended UARTs and especially UART numbering (on some boards SERIAL number does not correspond to UART number). In this case itâs simple though, I always used UART1/SERIAL1 for the receiver (and telemetry) on F405.
Thanks for the tips! Iâll get the baro you use first and then try againâŚ
I checked my other setups and the serial protolos are in fact all either MAVLink 1 or 2 and everything is working fine for some time now I have never changed anything in the original setup so far. I just connect the receiver to the connection marked âSBUSâ, going to the FrSKY R9 Mini receiver.
Did you come across any other issues using the using 4.2.0-DEV?
and am very happy with it. There I also have a temperature sensor which is working, but with INAV.
, nothing obvious. The âSERIAL1_PROTOCOLâ is set on 2, which is MAVLink2 and working perfectly in 4.1.6., although I use FRSKY. Why should it not work with the dev version I wonder. Did you have to set yours on 29 = Crossfire VTX?
Only trouble is, that I cant get any âoldâ receivers without the OTA protocol anywhere anymore 
I have never changed anything in the original setup so far. I just connect the receiver to the connection marked âSBUSâ, going to the FrSKY R9 Mini receiver.