Hi,
trying to manually correct the voltage monitored by mission planner:
According to http://ardupilot.org/copter/docs/common-power-module-configuration-in-mission-planner.html you can manually adjust the measured voltage to allign with the real voltage, measured by pixhawk compatible power modules like airbotpower. While I have a real voltage (measured by multimeter on lipo) of 15.3 volts for a S4 lipo (not fully loaded, approx 60%), I have a correct power volt measurement output signal of 3.0 volt on the airbotpower to pixhawk measurement input, with aligns with 15.27 volts (which is correct), mission planner does not show the correct voltage. It started with approx. 30 voltage; by adjusting (numerous times!) the Measured battery voltage in the calibration window in the battery monitor of mission planner, I ended up with approx. 21 measured voltage showing up. The calced voltage divider is 50.5.
What can I do to correct this? is this a bug in mission planner?
to be completed, I am using:
mission planner 1.3.39
APMCopter V3.3.3
I had extensive contact with the manufacturer of the airbotpower module, and based on the measurements (also from the output measurement voltage signal) there seem not to be any hardwareproblem with the power module itself.
My understanding is that Mission Planner only reports the voltage that the Pixhawk sees and that it only allow adjustment to the voltage divider value to compensate for that reading. The reading is based on a value between 0 and 3.3 volts so your output reading is too high to give an accurate measurement of the voltage.
Why would the reading be to high? it is giving as a measurement signal 3.0 volts which maps correctly to 15,27 volts on the lipo if you take 3.3V as 100% voltage = 16.8 volts on a 4S lipo…
I am using the standard power port which also contains the voltage and current measurement pins, which I thought were 3.3V according to the documentation…
voltage measurement pin on sensor (airbotpower) is max 3.3V, it that is what you are asking for.
The measurement of 3.0V is consistent with the actual voltage of the used Lipo…
adding a snapshot of mission planner with 4S lipo connected… actual voltage on lipo is 15.3V.
I hop in this discussion to confirm the following:
-I have made Alpa check that Airbotpower provides the correct voltage ouput (between 0-3.3V) on its voltage measurement ouput PIN. This output PIN is part of a DF13 connector that is made specifically to be plug & play into Pixhawk’s power port.
So to my opinion it cannot be a PIN connection error into Pixhawk as long as Pascal used a correct DF13 6 pos cable.
So the next point to check : do you use a valid DF13 6 wires cable (must be point to point without crossing of the 6 wires) ?
-Usually, when electrical readings are ectic, it could be that the ground connection is interrupted or intermittently interrupted : check for good wiring. To be sure, try to use another DF13 6 wires cable between Airbotpower and Pixhawk.
Since voltmeters on all components until Pixahwk power port provide good readings, the only further causes could be:
-a Pixhawk power port ADC failure. But the probability of such thing is really low;
-mission planner strange behaviour (or bug) as i have myself experienced in the past weird voltage calibration sessions where it looks like fuzzy logic to me: you have to enter many times repeatidily the voltage reading in the field “Measured battery voltage” of mission planner to get a correct registration of the voltage (and a correct display). Maybe another thing to try is to use another ground station software to see if it displays the voltage correctly ?
change windows 7 keyboard settings to use “.” as decimal point
changed measured battery voltage to 15.3, MP changed it back to 52…
change different times again, had multiple errors “invalid number entered”
and then suddenly it stayed on 15.3, now changed to 15.5… and until now, it keeps displaying this voltage…
so I would say (based on the hope he will keep this value now), this problem can be linked to the decimal point… but I always entered a “.” instead of “,” before, so it really has to do with the windows setting…
You found it ! that is the cause. A bug correction request is to be posted then for mission planner to be able to manage the european decimal symbol ("." or “,”)
Thank you all for your help.
Concerning posting a bug correction request:
Michael, based on your advice you already suspected something like this; is this already listed as a possible bug or do you want me to log this?
Thanks again,
and something I forgot to add…
although the windows 7 keyboard settings were configured to use “,” as decimal point I am ALWAYS using “.” as a decimal point in all applications (yes, even Microsoft apps), and it never caused a problem before…
