I’m creating this topic in case there’s a logging issue that needs to be investigated by Devs.
I’m hoping a problem can be identified that will allow accurate voltage logging AFTER failsafe is triggered.
I’ve noticed this in earlier Arducopter firmware, but now in 3.5.3 too.
Hardware is Pixfalcon, generic X quad, Holibro PDB.
3 cell 3000mAh or 5200mAh, nominal 11.1v
Once battery voltage failsafe is triggered the logged battery voltage varies like crazy. The variations are not present before failsafe, and if I actually change the failsafe threshold the variations only start after FS whatever the voltage level actually is. So I can change the FS voltage 11.0 and the variations will kick in once FS is triggered. Or I can set the FS really low (or to be ignored) and the variations in voltage do not show up at all even right down to dangerously low battery voltages. I’m very sure that the variations are NOT due to the PDB or batteries, since the variations are definitely linked to the FS condition. A regulated powersupply and Fluke 85 meter do not indicate any such actual variations at low “battery” voltages either on the regulated supply 5v DC or on the Vsense wire. I’ve used this bench setup to calibrate the Pixfalcon battery voltage scaling, and compared it closely with the battery alarm measurements too.
The pixfalcon internal beeper doesnt seem to interfere either, as mode changes and other noises it makes dont seem to have any effect on the voltage sense, or flight stability. there is also an audible 3 digit voltage alarm on the balance leads - the timing of it’s beeps dont match up with the frequency of vsense fluctuations, and in fact it is set a little more conservative than the AC failsafe voltage, so it usually starts beeping before the failsafe condition is triggered.
Attached is a screenshot and log - it’s a small flight started with an almost flat battery in order to demonstrate the issue. In the screenshot you can see the voltage sensed has “normal” variation of about 0.04 volts and also the big variations linked to actual current drain due to flight, but when it hits FS there’s variations of about 0.3 volts not linked to current drain. In the actual log file, the variations after FS are not reflected in current drain.
I meant to say that also the Vcc (5 volts DC) varies like crazy after failsafe condition too, you’ll be able to clearly see it in logs. The variations in Vcc and battery voltage are aligned when viewed on a graph.
This too seems to be linked to the failsafe condition, and not a real voltage variation from the PDB.
Since I did the FailSafe test to demonstrate the varying battery voltage, it’s now doing it all the time (AGAIN! ) - I used to think it was a wiring problem like a ground loop or something, so I disassembled and reassembled all components and wiring and the voltage measurements were perfect till I did the above FailSafe test.
So now, just powering up the Pixfalcon shows (via USB and QGC) the battery voltage constantly varying by around 4 volts - just arming becomes impossible without disabling the voltage failsafe.
It’s like there’s something in the Pixfalcon that’s remembered there was a failsafe and it’s now affecting the voltage reading all the time. Driving me crazy…
I cant easily fix it easily either, since I’m now fairly sure it’s not a wiring fault and last time I got the condition cleared was rewiring, several reflashes of different firmware (both PX4 and Arducopter/rover/copter), full recalibrations.
So I’m hoping for a fix in firmware if the fault can be identified from logs, or a value in Params that I can clear or change that fixes it after a FailSafe.
Let me know if more logs are required, I’ll go get the latest one from today and upload it.
Here’s a log with strange voltage behaviour, in fact I had to change the voltage scaling to get the arducopter to arm and that didnt work, so I had to disable voltage failsafe, so the CUR/Volt is not technically correct but out by a couple of volts. Although there’s no Failsafe condition here, I believe the behaviour is related.
In this log where you can see:
55 secs POWR/Vcc goes crazy on arming
During flight voltages are sort of normal, except that POWR/Vcc mirrors that of CUR/Volt
Land and disarm at about 280 secs, POWR/Vcc and CUR/Volt return to “normal” and fluctuations stop and measuements look believable for the first time
302 secs, arm and POWR/Vcc goes crazy again then goes back to mirroring the fluctuations of CUR/Volt
Vcc continues to follow Volt for the rest of the flight until Land and Disarm - normally Vcc would be fairly independant of Volt
I’ll check some old logs for more examples of the Failsafe condition.
I’ve only got Holibro PDB but it seems rock-steady when measured with a DVM. I cant fault it so far, and yet at the same time (on the bench) the Pixfalcon/Arducopter is reporting variation in Vcc and battery voltage.
I might need to enable logging while disarmed to gather more info.
Here’s a good demonstration of the FailSafe conditions and Vcc. In the log file CUR/Volt varies in exactly the same way as the POWR/Vcc shown in the screenshot, and returns to “normal” expected voltage readings outside the FailSafe conditions.
You can see that the first FailSafe event is “Radio” as we were testing the FailSafe operation and RTL behaviour before unleashing the quadcopter upon the world.
Maybe if I confine this thread to the POWR/Vcc and CUR/Volt readings that vary after FailSafe, that would help.
I’ll pursue the general voltage variations separately, or under another thread if I must.
Thanks in advance to those the look at this thread and try to help.
I have now fixed my other variable voltage issues with the Pixfalcon connectors and will do test flights over the next few days to gather new logs regarding the strange voltage readings seen at FailSafe events.
Any ideas?
To me it looks like a logging issue, rather than the voltage actually varying. You can see when the craft lands and battery voltage recovers as current goes down, the Vcc is still going crazy.
Here’s a new log with Vcc and Volt “humming” along nicely as expected, then I initiate fail-safe via throttle cut, then later by RC-Loss (now both set correctly and behaving as expected).
After fail-safe is triggered the Vcc and (to a lesser extent) Volt go crazy with cyclic regular variations. The variations go away and behaviour returns to normal only after landing is completed and flight mode is changed and the copter can be rearmed to clear the FS condition.
This screenshot shows just a portion of the log file.
Sorry to be annoying, is anyone going to look into this?
Not sure if it’s a Arducopter firmware issue or a hardware issue, but I’m sure it’d be worth knowing if we should be concerned about it or not.
Even if there was a definitive statement like “don’t worry about it, we investigated this before and it’s caused because of XYZ and cant possibly affect flight” then that’d be great.
I’m not up to contributing to the code myself, but I can sure run more tests and gather logs if needed.
So the board voltage is going up and down by about 0.15 volts (or 3%). It’s noticeable in the logs but it’s not a huge variation really - at least not large enough to cause issues that you’ll notice in flight.
I suspect that the small variations showing up in the battery voltage are actually caused by this variation in the board voltage because the way it measures the battery voltage is by comparing it with the board voltage.
Michael DB told me he suspects it’s the buzzer and that seems very likely to me. The wave in the voltage seems to be at about 1hz and very regular so I suspect if you disconnect the buzzer the wave will disappear.
I’m surprised the buzzer could cause this voltage change. It could be board specific - for example the voltage regulator could be larger/smaller on different boards. I’ll try and test a couple of my boards here (Pixhawk1, Cube, mostly) to see if they exhibit a similar problem.
I used to have the buzzer disabled, and I’m pretty sure the same peculiar voltage readings showed up in the logs.
I’ll do a test with the buzzer disabled and post a new log in a couple of days time. During failsafe condition, the Pixfalcon makes repetitive tones, not a continuous beep, but a new log will show if the tones are having an effect.
I just looked in the log again and the variations are happening from boot time right up until arming (actually to motor interlock) - at times there would be noises from the onboard buzzer but not continuous for the whole 50+ seconds.
I completely understand what you say about the CURR/V varying due to using Vcc as a reference, that makes sense.
It’s not so much the voltage swing of Vcc that I was worried about, since it stays within limits, but the fact that it seems to happen around specific events and was wondering if it’s a cause for concern or indicating some other issue.
OK, if it’s not the buzzer then it is probably the LED. This can also be disabled by setting NTF_LED_BRIGHT to 0.
@WickedShell, here’s why I think the package voltage is also changing:
I suspect that the small variations showing up in the battery voltage are actually caused by this variation in the board voltage because the way it measures the battery voltage is by comparing it with the board voltage.
Here’s 2 logs from one session. Fail-Safes are initiated by throttle cut.
The first log is waiting for arming conditions, flying to ensure everything works normally, Fail-safe and land to set a baseline. Then I disable buzzer setting and reboot for some strange reason, even though these settings take effect immediately.
The second log is arming and flying to fail-safe with Buzzer disabled, disabling LED and flying to fail-safe again.
If I’m looking at this correctly, it seems to me like disabling the LED has the most positive effect on the Vcc - which is unfortunate because we can easily disable the buzzer and live without it, but we NEED the LED to confirm take-off readiness since I don’t have telemetry radios to a ground station.
I’ll wait to hear others conclusions - but I think I’ll be leaving the buzzer and LED enabled unless it actually causes an issue.
To me it still looks a bit like a programmatic issue or possibly related to A/D conversion, since the variations in Vcc don’t match up with the LED or Buzzer activity precisely, and are only present prior to arming and during fail-safe - normal flight is OK.
