Maybe Pavan means what I also have noticed. When starting the FC it always assumes a full charged battery (99%) no matter what voltage the Battery has.
Hi Roland,
yeah this is totally possible because battery % is calculated from mAh consumed and not from battery voltage.
mAh consumed is sent by the FC and at boot is always zero.
Battery % from voltage would require a custom discharge curve per battery type, lion,lipo, and would also have to be based on battery C rating, so quite a challenge both memory wise and accuracy wise
Hi Alex,
I’m having a strange problem with one of my quad. Occasionally I can hear “sensor lost”, but it seems to me that the script is working.
What could be causing it?
Hi, I guess that’s more OpenTx related.
What is your setup?
Hi @Cipta and @Pavan
I did some more testing and I think I can provide a decent battery percentage based on voltage by using linear interpolation and a “pilot provided” discharge curve of 11 points from 0 to 100 %.
Supposedly the remaining capacity of a LiPo can be approximated with the at-rest cell voltage. The math is pretty simple. The hard part is that the cell voltage “sags” under load and determining what the at-rest voltage will be after the battery recovers is about impossible.
But at controller boot with a rested battery, if the system knows the voltage and number of cells the approximate remaining capacity should be able to be estimated from this:
3.7=0%
3.8=20
3.9=40
4.0=60
4.1=80
4.2=100%
Hello Alex (Привет из России). Thank you for your work! After installing your script, I am fortunate to watch all the telemetry on my Horus X10 screen, which together with the telemetry data on my smartphone makes the flights safer. I use the configuration with FRSKY R9M long range module and everything works fine (i’m using Widget). In the near future I will try to replace R9M with Dragonlink V3. Еще раз Спасибо!
Hello Alex,
I don’t know for sure if it’s important to change the % calc because in general I and probably most pilots use full charged Batt and in this case the actual calculation is the most accurate I think. Maybe a combination of both would be worth thinking about. I mean when Batt is detected at start with >4,1V then FC gives percentage if lower cell Voltage detected some kind of calculation like Chris suggested. Or just a warning if Cell at start < 4V that % display is not correct or just hide or fade the % display.
Again - for me its ok like it works at the moment because there is still the Voltage display and that’s more important.
The hard part is that the cell voltage “sags” under load and determining what the at-rest voltage will be after the battery recovers is about impossible.
correct but there are ways around it.
A possible approach is to log a pack discharge during a typical flight and write down let’s sat 20 voltages (under load) at regular intervals, plot them and find the non linear zones, typically near full charge and discharge, choose no more than 10 points (dense where the discharge curve is non linear) and apply linear polynomial interpolation.
I tried this and works pretty well, it’s a generic approach since it does not make assumptions on battery type and it’s accuracy can be improved over time by the user by providing new sample sets, it’s not perfect though 
Edit: these method requires per “pack type” discharge curves, so it’s accurate as long as one uses similar battery packs, a truly generic solution, as @ChrisOlson pointed out, I’m afraid does not exist
Hi Roland,
mhmm I see, there are two different faces of this “issue”
- partially charged battery shows at 99%
- battery % never changes cause there’s no current sensor
Hi @Skywallker thanks for the kind words, glad it works for you.
Soon I will release a new Horus version so “stay tuned” 
does this happen when flying or just when your standing next to the model
yeah, this is a good point, sensor lost is common if tx is close to rx
It happened when I was near the quad, but usualy I got the “telemetry lost” voice message, this was the first time ever I got this one that’s why I got confused. On second thought I just upgraded my radio to the 2.2.2, so maybe it’s a new feature 
Thanks for the help anyway!
Alex,
I have a question if I may. On my biggest quad I am using two batteries, one for the FC and the motors (4S) and one for the gimbal/2xcameras/video transmiter (3S). I would like to have the info about the second battery with flvss sensor. How would the script behave regarding alarms as there are 2 different voltages? I already tried the combination, but I got 5.something voltage from the FC, so I quickly shutdown everything… This was probably because I left the +5 volts from the second battery connected
Hi Igor, you have a power monitor and an FLVSS sensor?
If so just rename the FLVSS sensor to something different from Cels and my script will ignore it, like Cel1 (not Cel2 because I track that too).
Then add a custom telemetry page to show the voltage from the Cel1 sensor and perhaps add alert to it with OpenTX.
If the script detects 2 voltages it assumes they are of the same battery, one from the FC and one from a FLVSS sensor. The user can choose which one to use from the config menu or by pressing [ENTER] on the taranis.
For supported battery configurations you can also check the docs on github
Did I answer your question? if not feel free to ask for more info
Hi Alex,
Yes, I have the power monitor and the FLVSS sensor.
That was exactly the info I asked for, thank you!
Will try it in a few days when I get back to my quad.
Hello Alex,
I have been trying to get your telemetry script working correctly for some time now, but have been running into problems: “no telemetry data” is displayed on Taranis. My assumption is that this has to do with the serial port.
I have the script v1.7.0 setup correctly (as far as I am aware), in combination with Pixhawk 2.1 Cube (running APM:Copter v3.5.7):
-
Script is installed on Taranis X9D+ (running OpenTX 2.2.2)
-
TELEM1 port is configured as SERIAL1_PROTOCOL with value “1” (=MAVLink1), and has a 3DR radio modem connected
-
TELEM2 port is configured as SERIAL2_PROTOCOL with value “10” (=FrSky Sport passthrough); a C&T cable connects the X8R receiver from TELEM2 to the SPort
-
No other serial ports protocols have the value “10” assigned
-
SERIAL5_PROTOCOL has a value of “1” (intend to use it for MinimOSD - if possible)
In this setup, when entering the telemetry page on the Taranis, the script reports audibly with “yaapu telemetry ready” - but shows a “no telemetry data” error (on top of the Taranis telemetry page).
If I REVERSE the two connections above (and also assign TELEM2/SERIAL2_PROTOCOL value “1”, and instead assign TELEM1/SERIAL1_PROTOCOL the value “10”), - Voila - the telemetry arrives at the Taranis as expected.
That would likely mean that
- My setup is correct as such
- The telemetry cable is working
- The Taranis and receiver are working
How come then, that the initial “default” setup is not working, and I have to switch the TELEM/SERIAL ports around for the sensor data to arrive properly?
EDITED: corrected MinimOSD connection to say SERIAL5_PROTOCOL
Hi,
I have no experience with Pixhawk 2.1 cube, but what do you mean by
- SERIAL2_PROTOCOL has a value of “1” (intend to use it for MinimOSD - if possible)
haven’t you assigned SERIAL2_PROTOCOL=10 to enable frsky telemetry?
Anyway from the wiki
SERIAL1 and SERIAL2 are marked as telemetry ports by default so should both work
to recap
doesn’t work:
SERIAL1_PROTOCOL=1
SERIAL2_PROTOCOL=10
works
SERIAL1_PROTOCOL=10
SERIAL2_PROTOCOL=1
correct?
Hi Alex,
sorry that was a typo late at night (which I fixed just now to say SER…5 , for the MinimOSD connection).
Yes, I had assigned SERIAL2_PROTOCOL=10 to enable frsky telemetry, as per the Wiki. But this displayed no telemetry on the Taranis.
Your recap is correct.
When I switch the ports and values around, telemetry is displayed.
Can you think of any reason why the default setup does not work?