Not sending all the data to FrSky Rx

[LTMNO]

Hello, Great solution... and I know the solution works as I had tried it a few days ago with the help of Yaapu and then today, I finally got around to doing two test flights and no data was coming thru... other than VFAS, Fuel @ 99% and RSSI and RxBt.

Here is the Radio Log...

Thoughts?

just remove the .xlsx from the file below to load.
DART450-2018-07-18.csv.xlsx

Question... when you compile in Arduino.. what settings did you choose?

I have read that Fast is the default....

Also, does your program use Mavlink1 or Mavlink2 or Agnostic?

[zs6buj]

Hey Pino

I use the Mavlink 1 libraries. Mavlink 2 adds nothing the this solution.

Oh, and I have "fastest" ticked in the Arduino IDE.

From the log it seems that no Frsky telemetry is reaching the Taranis input pin, so it is likely not reaching the receiver in the air. If remember correctly you are using Air Mode together and a Pixhawk. Could you expand on the detail a bit? Pixhawk running APM PX4 firmware, or something else? I assume you know if you are running APM 3.5 or later, you can get S.Port Passthru telemetry straight out of the Pixhawk without this converter.

Can you do a desk check with the solution again using some of the debug features ?

[LTMNO]

Hello Eric. Thx for the response. Running 3.2.1 APM 2.6 Have to use Teensy. I will use debug when I get back home late tonight. Don’t know why I didn’t just do that and send to ya. 😁 I originally did so and everything was working. I will report back. Thx.

…

Sent from my iPhone

On Jul 19, 2018, at 1:56 AM, Eric Stockenstrom ***@***.***> wrote: Hey Pino I use the Mavlink 1 libraries. Mavlink 2 adds nothing the this solution. Oh, and I have "fastest" ticked in the Arduino IDE. From the log it seems that no Frsky telemetry is reaching the Taranis input pin, so it is likely not reaching the receiver in the air. If remember correctly you are using Air Mode together and a Pixhawk. Could you expand on the detail a bit? Pixhawk running APM PX4 firmware, or something else? I assume you know if you are running APM 3.5 or later, you can get S.Port Passthru telemetry straight out of the Pixhawk without this converter. Can you do a desk check with the solution again using some of the debug features ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[LTMNO]

Hello Eric, I have found what the problem is...
I am not sure how the solution is setup or where the code is for the polling but the APM doesn't send the Telem Data automatically from what I understand until requested. Once and a while I get data sending to the Converter by chance and most times it does not.
I was monitoring the Debug Console via USB to Teensy and noticed that when I turn the system on and that is including the Quad(power by Batt) --> APM 2.6--> Teensy --> FrSky Rx (X8R) --> Air --> QX7S . I would get no data sent consistently. But when I introduce the Telemetry Radio and establish Link to other Telemetry Radio, the data is flowing and the yaapu/zs5buj solution is working nicely.

What is the trick to have the Teensy poll or pull data from the APM to Initiate Data Stream?

Many thanks...

Pino.

[zs6buj]

Hi Pino

You must setup the SRx fields in Mission Planner, where x is the serial port you are using. This tells your APM flight controller to send out the appropriate telemetry types regularly.

https://imgur.com/0HIKh8g

http://ardupilot.org/copter/docs/common-telemetry-port-setup-for-apm-px4-and-pixhawk.html

If all else fails you can un-comment this line in the source, which will cause the Teensy to request the data streams every so often. Should you go this route, you must wire the Teensy tx pin to the APM rx pin (this connection is not needed otherwise).

//#define Data_Streams_Enabled // Rather set SRn in Mission Planner

Let me know how it goes. :)
Eric

[LTMNO]

Good day Eric,
I have implemented the SR1 changes and happy to report that data is flowing.
I am going to take it out for a test flight and record the data log.
At a quick glance, it all seems to be coming down the pipe. ;-)
Just to note, I have the Tx/Rx/5v/Gnd from the Telemetry Port connected to my Teensy and then have the Teensy Signal Wire and Ground connected to the X8R. (see below)

X8R SPort S <–- TX1 Pin 1
APM Tx (Mavlink) --> RX2 Pin 9
APM Rx (Mavlink) <-- TX2 Pin 10
APM Vcc 5V (not 3.3V) <--> Vin
APM GND <--> Gnd

[LTMNO]

Well, clearly i am getting the data. The Fuel, CURR, GAlt, seem to not be working... i will start to test them with debug logging.
The battery voltage is 11.6V Full Charge was 12.6.
The Altimeter was acting up... very windy outside this morning here in Toronto Area. Alt-Hold wasn't working well until later in the flight. ;-)
Either way, making progress here. ;-)

DART450-2018-07-21.csv.xlsx

[zs6buj]

In yaapu`s LAU app you need to go into the menu, space down to voltage source and select the FC or your sensor

[LTMNO]

Hi Eric, that option is enabled... ;-)

[zs6buj]

Did you click on it and select the correct source? Yry the available sources to fix your low battery reading.

[LTMNO]

Hello Again, the only source that gives data is FC. I connected my FrSky Voltage Sensor that connects to Balance Charger, did the discovery and then it added another sensor reading called CELLS. Now I see the correct voltage at 11.6v and 3.88v/cell under the VS option.

What doesn't change is the GAlt, Hdop and the Fuel @99% or the mAh Consumed.

The rest seems to be working...

DART450-2018-07-21.csv.xlsx

[master-of-desaster-88]

Hi togehter,
I have observed one issue wiht could be helpfull.
I also testing the long range R9 receifer from FrSky with the FCC 180329 firmware.
After a minute the mavlink will be get interupted and no trafic between receifer and Pixhawk is possible.
The sensor values from the hard wired sensors will be still working.
This never happen with the X8R receifer on 2,4 GHz.
Maybe with a new firmware from FrSky this issue will be solved.
Cheers,
Markus

[LTMNO]

Hello Markus, I will check if there is a new firmware for my X8R Rx.
Thanks for the post...

[master-of-desaster-88]

With the X8R RX everthing is fine.
The interrupt happen with the R9 RX and use of the Mavlink protokoll.
If I use the FrSky S.Bus pass trough also everything working well with the R9 RX.
But then is no Teensy involved.

[LTMNO]

Ah, sorry for the misunderstanding. There seems to be one update for Horus feature on the X8R.. not relevant for me. ;-)

I think there are some APM SR1 Settings that need to be tweaked...

Here are some logs of testing with Debug Mode Enabled...

#define Use_Local_Battery_mAh @5400
BatteryLogc.txt

//#define Use_Local_Battery_mAh
Batt_Commented_Out.txt

Strangely, GPS showing Lock but nothing else
GPSLog.txt

Detailed GPS Data
GPS_Detail_Log.txt

and the Radio Log
remove the '.xlsx'
[DART450-2018-07-22.csv.xlsx]
(https://github.com/zs6buj/MavlinkToPassthru/files/2217143/DART450-2018-07-22.csv.xlsx)

[zs6buj]

Good morning Gentlemen

I see you had a busy weekend.

R9:

I'm afraid I know nothing about the R9 RX and will need to do some reading. It may or may not pass the 0x5000 range of telemetry. What you can do is un-comment //#define Frs_Debug_All and let's look at how the Teensy is interacting with the R9 firmware.

Battery - volts, amps and mAh :

From the log you posted it is clear that the output routine for 0x5003 Battery 1 is not receiving any data. This data comes from Mavlink message # 1 SYS_STATUS. So our next step is un-comment //#define Debug_Batteries. I expect you might then confirm that the record is arriving from your APM with zero in those fields. If that is so, then we need to determine why APM is not configured to send them. Have you
set up your power module properly? http://ardupilot.org/copter/docs/common-power-module-configuration-in-mission-planner.html[](url) If you run Mission Planner live with a usb connection to your APM, can you see the voltage and current, and are they correct?

GPS Status:

Similar to above, we appear to not be receiving GPS data from APM. You can check if it is coming in by un-commenting these two lines:

//#define Mav_Debug_GPS_Raw // #24
//#define Mav_Debug_GPS_Int // #33

Heartbeat: ID #0

The heartbeat is very important for several reasons, one of which is it tells us what type of craft (or GCS or Tracker etc) is sending the mavlink telemetry. Flight modes and other things are determined according to ap_type. Please could you un-comment //#define Mav_Debug_Heartbeat

Regards
Eric

[LTMNO]

Good morning. I agree with all your assessments. I will test asap.
Un/fortunately family life gets in the way of the hobbies. Off for a 7 day vacation. Back following Monday. Will test then. 😁
Thank you all. Enjoy your week.

[LTMNO]

Hello Eric, back again... ;-)
Well, I plugged everything in and started the logs.... but I have also decided to try to connect my Telemetry Radios (900Mhz) system and see what happens.
I have deducted that when these radios are connected, that all information is pushed thru to the system from Quad to Radio.
When this is not connected, I miss some information.

So I think I need to work on the SR1 settings... Thoughts?
I think your code and yapuu is working fine...even for my setup.

When connected you can see it works here...
Radio Screen

DroidPlanner Screen

Can also see that I switched the HDOP to 3D Lock Display

Also, the FC is Off compared to the VS...

[LTMNO]

p.s. #define Data_Streams_Enabled // Rather set SRn in Mission Planner

Won't Compile...?

[LTMNO]

Debug_Heartbeat.txt
Debug_Batteries.txt
Debug_GPS.txt
Debug_GPS_Cont'd.txt

[zs6buj]

Hi LTMNO

The Srx settings work for everyone else, so I don't think you need to #define Data_Streams_Enabled. However, I will make sure it compiles in future in case.

[zs6buj]

Hi again Markus

If you want to patch , could you make this change: Note missing comma!

WAS:
const uint16_t mavRates[] = { 0x04, 0x0a, 0x04, 0x0a, 0x04, 0x04 0x04};

MUST BE:

const uint16_t mavRates[] = { 0x04, 0x0a, 0x04, 0x0a, 0x04, 0x04, 0x04};

I added in MAV_DATA_STREAM_EXTRA3 but missed the comma. :(

I'm working with Alex on v0.05 of Plus, so I'll patch that one also

[master-of-desaster-88]

Hello Eric,
Hot weeks in Germany - feeling like South Africa.
Kind of body barbeque.

Alex send me the new version from his program witch is now working as a widget.
Very convinient and also easy to enter the other sensors in additional widgets.

He also wrote that he will add the transport from the senors to the Horus telemtrie.
But he need also a modfied version from You.
I think v0.05 Plus will be the solution.
So I have to wait until the new script from Alex is finish before testing.

Cheers,
Markus

[zs6buj]

Oops. Hi Markus. It's 23 C here today. Mid winter :)

I meant to address the previous post to LTMNO.

Sorry guys.

[LTMNO]

Hello... Thanks for the reply... I will continue to play with the SRx values until I get a favourable result.
I wonder if I can trap packets that are being sent when I connect the Telem Radios... this could perhaps tell us what we need in order to get the full messaging? As I mentioned before, that seems to be the only way to get all the messaging... but it would defeat the purpose to have my tablet and my radio receiving the same information. ;-)

Thanks again,

Pino (LTMNO)

[zs6buj]

Hi Pino

I patched Plus v0.04 Try #define Data_Streams_Enabled again

[master-of-desaster-88]

Hi Eric,
I have tested the new version Plus_v04 - Plus_v06 on my Teensy 3.2 board.
I set the variables to select the Teensy board and for airmode.
The "mavlinkgood" LED is constant, but only the hard sensors like RSSI, Cels or RxBt get copy to the telemetrie on the Horus. No GPS for the start of the YAAPU telemetrie.
If I use Your Plus_v03 version all working well.
Some smal bug?

Cheers,
Markus

[zs6buj]

BHi Marcus

Thanks for the 'heads up'. Plus is very much a work-in-progress I'm afraid. I re-jigged the options from v0.04 to support the Maple Mini. It's a lovely little STM32 board, affordable, boot-loader works properly through USB, and it has 3 additional serial ports. Anyway, please carefully check the options you have un-commented. Don't use auxilliary (bluetooth) option for now as I'm working on it. If you could check v04 again carefully I would appreciate the help.

Thanks and regards
Eric

[master-of-desaster-88]

Hi Eric,
Yes the Maple Mini is nice :-)
I have check the version v04 & v05 release from today - carefully.
But no change.
Still same behavior.
Seems the mavlink get running but no valid information on the FrSky side.
I am not used to debug modes. But if you have a small how to I could try.
For the upload to the Teensy 3.2 I use the Visual Studio 2017 with the vMicro Arduino.

Cheers,
Markus

[LTMNO]

Hello Eric, I tried to use the : "Plus v0.04 Try #define Data_Streams_Enabled again" version, it compiled for me but I was getting no data TELEMETRY on the radio side.. I am not sure what is the diff between the Plus and the v1.01 as I have been using the v1.0.1 this whole time.
I tried to load Plus_v05 that would install but wouldn't compile for me in Arduino.

I have put the v1.0.1 back on and I am back to where we started.. i didn't have time today to test different Mhz rates in APM for SRx. I will tomorrow.

[99]

Hey @LTMNO, can you please remove "@ 99" from your initial message? Not interested in receiving that many emails for the tread I don't really care. Thx.
Please note that @ + username in the GitHub will mention users and automatically subscribe them to all the related messages.

[LTMNO]

DART450-2018-08-20.xlsx
Should the Ctot be sent thru via the MavlinkToPassthru

[zs6buj]

Hello Markus

Yes total mAh is sent back to the Taranis/Horus. I suggest that we trace the data through the system. You could un-comment in the Teensy

//#define Debug_Batteries

and monitor the output. Monitor for a while to see the mAh increasing over time. Once we know it is transmitted, we can look further.

Regards

[LTMNO]

Hello Again... okay, will do... I will report back shortly...

[LTMNO]

Debug_Batteries.txt
Here is the debug log with Debug_Batteries enabled.
I also removed the hardcoded option to set batteries in Teensy vs setting on Yaapu Script.
5400Mah Batt is being used.

[zs6buj]

Ok Markus, the record type BATTERY_STATUS ( #147 ) is not coming in from Mavlink. I will post a quick alternative for you, where I accumulate mAh by addition of di/dt. i.e. sum of all the instantaneous current measurements over time.

I'll look more closely tomorrow,. In the meantime please try v1.0.3b. Be sure to set all the #defines as per your requirements.

[LTMNO]

Hey Thank you Eric... I will test now...

Pino. ;-)

[LTMNO]

Okay, had to fix this in the code to compile... was missing a comma

//const uint16_t mavRates[] = { 0x02, 0x05, 0x02, 0x05, 0x02, 0x02};
const uint16_t mavRates[] = { 0x04, 0x0a, 0x04, 0x0a, 0x04, 0x04, 0x04};
 // req_message_rate The requested interval between two messages of this type

here is the output...
Debug_Batteries_v1.0.3b.txt

Here is the screenshot of the Radio... Ah is showing up now and Fuel has changed...

This is great news...
Now the question now is it accurate? ;-)

[master-of-desaster-88]

Hello Eric,
was not my issue :-)
But nice that you are thinking on me.
Cheers,
Markus

[LTMNO]

Yup, was me Pino aka LTMNO... I just didn't want to correct you... all good! ;-)

[zs6buj]

Oops, very sorry Pino

[zs6buj]

Pino, I would appreciate if you could give me feedback on its accuracy. The theory is sound, but when you add up an infinite number of small measurements, I'm not sure. We could tweak it if necessary. I'll also check up tomorrow to see why Mavlink did not pass down the APM measurement.

[LTMNO]

All good. 😁 I will use my amp meter and measure tomorrow am. Thank you. Pino

…

Sent from my iPhone

On Aug 21, 2018, at 3:35 PM, Eric Stockenstrom ***@***.***> wrote: Pino, I would appreciate if you could give me feedback on its accuracy. The theory is sound, but when you add up an infinite number of small measurements, I'm not sure. We could tweak it if necessary. I'll also check up tomorrow to see why Mavlink did not pass down the APM measurement. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[zs6buj]

It seems there was a short burst of activity on Battery Status #147, but then trickled out and I can't see where to activate it.

ArduPilot/ardupilot#3133

[LTMNO]

Interesting…I am away on business… unfortunately, I can't test till tomorrow afternoon upon my return… sorry for the delay.

…

On Aug 23, 2018, at 2:31 AM, Eric Stockenstrom ***@***.***> wrote: It seems there was a short burst of activity on Battery Status #147, but then trickled out and I can't see where to activate it. ArduPilot/ardupilot#3133 <ArduPilot/ardupilot#3133> — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEVRrkb8m2VCWAXp-EV43iZndjCciYvdks5uTkxfgaJpZM4VVTRt>.

[LTMNO]

Alright.. here are the test results of this morning...
Full Charge Battery at 12.6V @ 5400mAh

Then I ran the motors with inverted props to draw some amps. These are the readings...
Actual draw in AMPS is 5.37A vs Script reading at 4.8A and Volts a 12.3V vs 12.0V respectively...

Then another reading....
1.58A/12.34V vs 0.8A/12.2V . (Granted the sensors don't work well under 1A)
Please note that we are at 2360mAh Consumed at this point at @ 56% Fuel (5min in)

Then another...
2610mAh Consumed at 51% Fuel

Then the last one.. at 3000mAh @ 44% Fuel

The Actuals from the Battery via recharging and reading the graph is...
419mAh Consumed

In conclusion the mAh Consumed calculation is not accurate. ;-)

I hope this testing information helps.

[yaapu]

Hi Pino ideally to get all data we need the current reading from mission planner in same setup to determine if the power module is well calibrated or not Il sab 25 ago 2018, 19:46 LTMNO <notifications@github.com> ha scritto:

…

Alright.. here are the test results of this morning... Full Charge Battery at 12.6V @ 5400mAh [image: img_1577] <https://user-images.githubusercontent.com/4542894/44620883-47d5e500-a86a-11e8-9f3a-72c31ca7458b.jpg> [image: img_1578] <https://user-images.githubusercontent.com/4542894/44620900-9be0c980-a86a-11e8-8f2c-a98c8ac54410.jpg> Then I ran the motors with inverted props to draw some amps. These are the readings... Actual draw in AMPS is 5.37A vs Script reading at 4.8A and Volts a 12.3V vs 12.0V respectively... [image: img_1579 1] <https://user-images.githubusercontent.com/4542894/44620908-db0f1a80-a86a-11e8-860d-822339260d10.jpg> [image: img_1580] <https://user-images.githubusercontent.com/4542894/44620915-f9751600-a86a-11e8-8959-1de2a1c3fd24.jpg> Then another reading.... 1.58A/12.34V vs 0.8A/12.2V . (Granted the sensors don't work well under 1A) Please note that we are at 2360mAh Consumed at this point at @ 56% Fuel (5min in) [image: img_1581] <https://user-images.githubusercontent.com/4542894/44620985-44435d80-a86c-11e8-9f1f-8adab2b7bcf1.jpg> [image: img_1582] <https://user-images.githubusercontent.com/4542894/44620986-460d2100-a86c-11e8-935f-4f8ef3be060f.jpg> Then another... 2610mAh Consumed at 51% Fuel [image: img_1586] <https://user-images.githubusercontent.com/4542894/44621010-e105fb00-a86c-11e8-9bf9-29b008e313e5.jpg> [image: img_1587] <https://user-images.githubusercontent.com/4542894/44621011-e6634580-a86c-11e8-92bf-d2b4403bd3db.jpg> Then the last one.. at 3000mAh @ 44% Fuel [image: img_1588] <https://user-images.githubusercontent.com/4542894/44621020-fed36000-a86c-11e8-8c0d-d95d796ce8d7.jpg> [image: img_1589] <https://user-images.githubusercontent.com/4542894/44621022-009d2380-a86d-11e8-8a35-6ade3b938b79.jpg> The Actuals from the Battery via recharging and reading the graph is... 419mAh Consumed [image: img_1590] <https://user-images.githubusercontent.com/4542894/44621029-21657900-a86d-11e8-8711-4f80c9643e8b.jpg> [image: img_1591] <https://user-images.githubusercontent.com/4542894/44621030-24f90000-a86d-11e8-8987-d48a6ae93025.jpg> [image: img_1592] <https://user-images.githubusercontent.com/4542894/44621032-27f3f080-a86d-11e8-8489-9be97fb2e6aa.jpg> [image: img_1593] <https://user-images.githubusercontent.com/4542894/44621033-2aeee100-a86d-11e8-8ffc-6a496b08ab4b.jpg> In conclusion the mAh Consumed calculation is not accurate. ;-) I hope this testing information helps. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ac5AylfF2WhMPzJ5a_F76DiCyBbU9nkIks5uUY2SgaJpZM4VVTRt> .

[zs6buj]

Hi Pino

Thank you for all this information. It helps fill in the picture, but the critical numbers for me are the average current during the 7 odd minutes that you did the test. If the average current was 3.591A over 7 minutes, then the mAh over that period = 3.591 * 7 / 60 *1000 = 419 mAh, which correlates with the energy you had to put back. So the 3.59A looks like it could be roughly correct, and the approximately 3000mAh on the Taranis can't be correct, especially after only a few minutes at 5A.

Let me go back and do some more work. I want to look harder at how to get the APM mAh out of the FC remotely, second I'll do some current consumption tests of my own and see if I can calibrate the calculation with a correction-factor. Third, I want to look at the Mission Planner code.

As Alex points out, everything is based on the current reading determined by the Pixhawk, in conjunction with the chosen power module, and its calibration.

[LTMNO]

Hello Eric/Alex...
I have configured/calibrated the APM 2.6 Power Module on the APM as well.
Last night around 11pm (wife wasn't too happy) decided to run the quad indoors with inverted props and run the motors at about 12-15Amps. As I was doing that, i was getting my output reading from the Amp Meter and then entering the parameters to the APM Battery Advanced Configuration screen. The higher the Amps Reading for Calibrations, the better Calibrated it is... so i have read.
That beings said, i did that last night. So this morning I am going to charge the batts.. do a simple draw again and see how calibrated it is. On that APM side.. excluding the PassThru Code.

Stay tuned...

Thanks again for your feedback and help.

Pino

[zs6buj]

Hi Pino

Please use the latest firmware on Github. Hope I'm not too late :)

I did a lot of work on this today, and I believe it is fixed. I suspect the reason you are not getting the #147 record is because you are on an APM 2.6 FC, which only supports APM 3.2.1 and earlier firmware. So you have to use the di/dt method. The good news is that it now tracks very well with the one in Mission Planner (and APM 3.5.5).

Go easy on your poor wife. :)

Regards
Eric

[zs6buj]

So please un-comment this line if you are not getting the #147 record type through

//fr_bat1_mAh = Total_mAh1(); // If record type #147 is not sent by FC

in this function

void Send_Bat1_5003()

I'll make this automatic in future

[LTMNO]

Hello Eric,
I put in the update...
I changed to :

APM 
Teensy
Air_Mode
bat1_Capacity = 5400

I then ran and didn't see message #147 fr_bat1_mAh=0

> Frsky out Bat1 0x5003:  fr_bat1_volts=124 fr_bat1_amps=1 fr_bat1_mAh=0
> Frsky out Params 0x5007:  fr_param_id=4 fr_bat1_capacity=5400

then I un-commented fr_bat1_mAh = Total_mAh1();
and it started to come down the wire.

> Frsky out Bat1 0x5003:  fr_bat1_volts=123 fr_bat1_amps=1 fr_bat1_mAh=73
> Frsky out Params 0x5007:  fr_param_id=4 fr_bat1_capacity=5400

Question?
would it be possible to increase the fr_bat1_volts to 2 decimal points?
And for fr_bat1_mAh to increase to 2 digits?
I know that in the Debug that there are 1 decimal point and 2 decimal points recorded respectively.
I know that in the Yaapu display that only 1 decimal digits come thru on the qx7 display on CURR and 2 for VFAS.

I have done some serious attempts to calibrate my Power Module in APM... and it seems that based off of the Turnigy Amp Meter that I am off by 0.40 amps from the reading being sent down by FrSky.

Perhaps putting a parameter in place to increase the value might be an easy fix?
I know MikeB does that for er9x.

p.s. I am not sure if it is working at this point.. the counter.. i will have to charge again and start over and then record a flight to determine.. the increment is definitely slower... but the Fuel is not changing at all.

[LTMNO]

Hello Again, I made a change in the debug to output this with the Battery Output.

Frsky out Bat1 0x5003:  fr_bat1_volts=121 fr_bat1_amps=174 fr_bat1_mAh=40
Mavlink in #1 Sys_Status:  Bat volts=12.118  Bat amps=1.7  mAh=0.066500  Total mAh=40.971  Bat1 cell count= 3
Mavlink in #1 Sys_Status:  Bat volts=12.131  Bat amps=1.7  mAh=0.074583  Total mAh=41.045  Bat1 cell count= 3
Mavlink in #1 Sys_Status:  Bat volts=12.128  Bat amps=1.8  mAh=0.070000  Total mAh=41.115  Bat1 cell count= 3
Mavlink in #1 Sys_Status:  Bat volts=12.141  Bat amps=1.8  mAh=0.087014  Total mAh=41.202  Bat1 cell count= 3
Mavlink in #1 Sys_Status:  Bat volts=12.147  Bat amps=1.8  mAh=0.064900  Total mAh=41.267  Bat1 cell count= 3
Mavlink in #1 Sys_Status:  Bat volts=12.152  Bat amps=1.8  mAh=0.067850  Total mAh=41.335  Bat1 cell count= 3
Mavlink in #1 Sys_Status:  Bat volts=12.153  Bat amps=1.5  mAh=0.010000  Total mAh=41.345  Bat1 cell count= 3
Mavlink in #1 Sys_Status:  Bat volts=12.164  Bat amps=1.2  mAh=0.000000  Total mAh=41.345  Bat1 cell count= 3
Mavlink in #1 Sys_Status:  Bat volts=12.163  Bat amps=0.9  mAh=0.000000  Total mAh=41.345  Bat1 cell count= 3

With this I was able to record the starting and finishing point of the Amp meter output from a start and stop of consumption.
For a period of time like 30 seconds...
I recorded a delta of 7.0 mAh
29 mAh consumed o the Amp Meter vs 22 mAh Consumed on the Mavlink Status # 1 log.

now this is a short period of time... i will do a longer test tomorrow AM...

[zs6buj]

Good sleuthing Pino! Yes you should try to emulate real-life conditions, higher currents and longer times. I have not built in a conversion factor, just increased float to double for the timing calc. So the method is still "pure", if you know what I mean? For you next FC consider getting a Pixhawk mini. They are now around the price of an APM 2.6 board, but support the latest APM firmware. The one catch is that the firmware (and Mission Planner) is modified by RadioLink (the vendor) first.

[LTMNO]

DART450-2018-08-27.xlsx

Hello Eric, after extensive testing and calibration at higher amps... ~10A-14A
I believe that I have the CURR set correctly. I completed a test and the battery recorded at 76% remaining on the Amp Meter... the APM recorded 77%.
With the 1 Decimal point of margin... I believe this to be good! ;-)

77% is 1242mAh used @ 5400 Batt
76% is 1296mAh used @ 5400 Batt

I charged the Batt and put back in...1320mAh

I have also noticed that in APM config Param there is an Offset for Amps... I didn't use it, but its there ;-)

p.s I have a PixHawk Full Size board that I could put in this quad.. but that is for another build. ;-)

[LTMNO]

69-12-31_19-00-00_9.bin.txt

[zs6buj]

Your log reflects the numbers you mentioned above. That's as close as you need Pino! Is the same number appearing on your Taranis now?

[LTMNO]

Morning Eric. Yes sir. We are in business 😜👍 I believe to be whole now on the radio front. Many thx!

…

Sent from my iPhone

On Aug 28, 2018, at 2:32 AM, Eric Stockenstrom ***@***.***> wrote: Your log reflects the numbers you mentioned above. That's as close as you need Pino! Is the same number appearing on your Taranis now? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.