Adding MAVLINK support

[RCHH]

Mike,
Further info on what I was seeing earlier this morning with the modified Mavlink.cpp file you supplied,

"Edit 2: Mike, when I disconnect the GPS cable from the APM, the ALT_BARO debug codes drop to 0000. On reconnecting said cable, the values as above with FFF* instantly return."

Today, I gave this another go to see at what point the Debug readings for ALT_BARO changed from 0000 to FFF* with the GPS module connected. (Compass module NOT connected)
I noticed that until the Red LED on the GPS module began flashing, indicating GPS locks, those codes remained at 0000. As soon as the GPS LED began flashing, the codes changed to those in the FFF* range.

[MikeB]

OK, I've spent some time today sorting out various problems with the Arduino code. I think I've got all the major bugs sorted. The "rate request" wasn't being sent at the correct time and there was a problem with reading the data from the APM where I 'lost' some bytes.
I've posted a new set of source files on the test versions thread. I'm hopeful the GPS data will now get to the Tx, although it may be in the wrong format!
Some other items may also be scaled incorrectly, but if we can at least get the data transferred these should be fairly easy to sort out!

I think the Baro-Alt value may get replaced by the GPS Alt if/when it becomes available!

Mike.

[RCHH]

Am on it now Mike.

[RCHH]

Progress ... code loaded fine.
Now have 2D/3D Fix, sat 4 (am indoors), hdop35 to 54.6 (flashing) and gAL 89 TO 91 showing.

Central compass needle working, dth showing 0, Cur 0.0A as nothing is running of course. Top 'battery' icon showing 99% and batt voltage correct at 11.4v (needs a recharge!) also Rcq showing 86.

Arm/Diisarm and flight mode readings working fine. When 'Armed', dth varies +/- 15 or so. 'alt' also works and resolves the 8 feet I can cover in the living room from floor to ceiling. Giving a -6 figure when raised to the ceiling, and a +2 figure at the floor. Zeroed at two feet 6 high window sill.

Excellent progress Mike.

[MikeB]

Looks promising then. Do you have values on the LAT/LONG screen?
The default display for FrSky data is DDmm.mmmm. I think the APM format is different. I'll probably need to change the data before it is sent.
There is a new option in the radio setup (General) to select DD.dddddd as the preferred format. This currently just affects the displayed value converting it from DDmm.mmmm to DD.dddddd.

Mike.

[RCHH]

LAT/LONG is indeed populated. Radio>General>GPS Format set to DDmm.mmmm

Lat=00050.4261 N N
Lor=000C-.1425 W W 122 (characters garbled on the Lon line and I have typed as close as they appear)
Alt= 70m
Spd = 0 mph as I am not going running about in the wet and dark! lol!

Very promising indeed genius man! heh heh!

[kaos]

Mike:
just pull out my dusted multiwii quad 450 which already has everything set up with a D8R-XP rx. MP is showing mavlink data.
Just need to hook up the pro mini and rx and FC.
from FC to pro mini, we only need Tx->rx, 5v->vcc, gnd->gnd. Is rx->tx needed at all?
from pro mini to D8R-XP serial port, just need D5-> rx, gnd->gnd
Are these correct?
I have Arduino IDE 1.6.5, will this compile today's code ok? or can you provide a hex file for pro mini 328p?

[RCHH]

from FC to pro mini, we only need Tx->rx, 5v->vcc, gnd->gnd. Is rx->tx needed at all? - Yes. rx-tx is required.
from pro mini to D8R-XP serial port, just need D5-> rx, only

Not sure of your IDE. I use 1.0.5-r2 as anything higher breaks compiling the sonar enabled MultiWii sketches I have.

[MikeB]

I've just posted another version of the Arduino code. This might sort the GPS Lat/Long format for the hub protocol. When that is correct I'll sort it for the SPort protocol.

My IDE is 1.5.8. I see no reason for 1.6.5 not to work. 1.5.8 compiles to smaller code than 1.0.5.

You should find you have a ground connection via the receiver servo outputs so don't need any extra one for the serial data to the Rx.

Mike.

[kaos]

Mike:
Well, IT WORKS!
your latest code shows GPS lat, lon very close to where I am. actually it showed the same figure with my Hub GPS
ARm/Disarm is correct.
rssi correct
showed 3D fix with 8 saltellite, same as MP reporting
all six modes are correctly displayed.
cell1,2,3 seem correct, i did not check with a voltmeter but number is about right.

what is hdop 23.7 and flashing after a while change to nonhighlighted steady 16.3

edit: I see MP show hdop: 1.1 while the screen shows11.0 . I think it is one decimal off.
the Mav screen show alt: 0.2 same as MP
heading is the same as MP

What is gAl, dth?

[RCHH]

hdop is GPS 'Horizontal Dilution of Precision' and indicates the relative accuracy of the GPS position in the horizontal plane. You may well have 8 satellites locked in, but if they are close together, the hdop could be higher than say 5 satellites a long distance from each other.

Look for a figure of <1 for good/the best positioning. Keeping the GPS sensor as far away from electrical interference from ESC's etc. can help get the lowest DoP.

If you are indoors, hdop can show as 3 or even higher on the MP. But I think you are correct with the decimal point - as indoors my Neo8 shows hdop on the new screen of 33 plus ...

GPS has several different dop's - Tdop (Time), Vdop (Vertical), Pdop (3D Position) etc.

'gAl' is GPS altitude and 'dth' is Distance to Home

Edit: Thinking about it, I am wondering if what we are seeing is actually 'Pdop rather than 'hdop'? Will look into that later today.

[RCHH]

Confirmed that LAT/LONG formatting is fixed and accurate to my location.
Battery cell voltages are correct reading my 6S pack in accordance with my multimeter readings +/- 0.01v

Sketch will compile with IDE 1.6.7.

Looking good Mike!

[kaos]

RCHH:
Thx for the explanation. I never got those down correctly.
I think hdop is what we see, I observed over a period of time with MP, it changes (I guess because it was cloudy), but I watched the number on MP is exactly one decimal less than the Tx display with last digit rounded.

YES, Mavlink is working.
Congra Mike!!!!!!!!!!! I KNEW you can do it.

edit:
RCHH: I have a question about the lat/lon. the Hub GPS has been reporting the same number as Mavlink of my position in lat as 2959.6954
But I can't find 6954 from google earth. Are they using different unit? the 1st 4 digit: 2959 is perfect match. but the last 4 digits I could not figure it out. on google earth the highest number is 5999. what unit or scale the Frsky hub and mavlink are using?
The lon, if I use the hub gps number last 4 digits, it is about 120 meter away from me on google earth.

[RCHH]

In radio setup go to: Radio>General>GPS Format set to DD.dddddd should give a google earth readable result like 52.12356 etc. Those should be good to go.

Edit: Incidentally, I just entered my coords from the radio display and it now places me somewhere in Belgium! lol Need to look into that one!

[kaos]

I have a question here:
When I mount the 3S lipo on the quad, I have the main core attached, and the balancing core I have a connector to 1st and last wire connected to a BEC to power the FC and other electronics. How in the world the FC/mavlink can figure out the individual cell voltage?

[Kilrah]

Either there is a sense wire between your power distribution board and the flight controller, or you're reading a random reading.

[MikeB]

As I understand it, it never has. All it does is take the battery voltage and divide it by the number of cells. I'm not sure it is actually useful, I just included it as it was already there.
I don't use APM but my personal view would be to remove it so it doesn't lead to confusion. You could clearly have a low cell and you wouldn't know!

The default GPS format is DDMM.mmmm, where DD is degrees, MM is whole minutes and mmmm are fractions of a minute.
I could easily have an error in my conversion to DD.dddddd.

I'll look into the hdop scaling.

Mike.

[RCHH]

It won't monitor individual cells, unless external hardware and additional coding is used.
Never even thought about that and took it for granted that the readings showing for cells were real! lol!
Although with the packs I have used they are well balanced, so that is my excuse! hahaha!!!. Will attach a known unbalanced battery later just to confirm what now seems obvious. durrrrrr ...

Edit: Mike posted the answer as I was typing mine!

Edit 2: Wonder if it is possible for the FrSky FLVSS be used in addition/conjunction to/with this project somehow?

Edit 3: Confirmed cell voltages are 'averaged' as I have just used a pack with a cell almost 0.6V lower than the others. All cell Voltages on the display are the same.

Also, have now stuck the setup outside, have 6 satellites locked (so far) and a 3D fix. But hdop on the TX is showing as 32.6. It should be 3.26 as confirmed by the GCS and by u-blox u-center.

[jhsa]

I don't use APM but my personal view would be to remove it so it doesn't lead to confusion. You could clearly have a low cell and you wouldn't know!

Mike.

I have the same opinion Mike, No information is better than misleading information. You know you will have people complaining if you remove it though, even if it is completely useless..
But I also don't use this equipment at the moment so...

João

[RCHH]

Maybe have it as an option 'if' hardware etc. were available? Probably a lot of work involved to accomplish that for not a lot of users, but possible to do?

[Kilrah]

But then again when that "fake cell voltage" isn't there we get the opposite request to add it, because some people prefer to go by "I need to land at 3.5V/cell" instead of "I have to land at 10.5V". And it kinda makes sense as it's independent of the cell count, i.e. less to remember.

[jhsa]

I see, but the problem is 3.5V per cell might not be really 3.5V per cell. so that voltage reading might be completely OFF if one or 2 cells are too low..

João

[Kilrah]

No but it isn't any worse than relying on total voltage, which is still OK to do.

The only important thing if you use it is to be aware/remember that what you're looking at is not an actually measured cell voltage.

[MikeB]

Edit 2: Wonder if it is possible for the FrSky FLVSS be used in addition/conjunction to/with this project somehow?

If I add an option to the Arduino not to send the VFAS and CELL data, then you could just put a FLVSS on the SPort connection to the receiver.

Edit: Could make that TWO options, one for VFAS and one for CELL. Perhaps the default would be send VFAS but not CELL. Then you may choose what you want.

Mike.

[jhsa]

OK, imagine this extreme situation.

Cell 1 - 3.2V (really unbalanced cell
Cell 2 - 3.5V
Cell 3 - 3.5V
Total Voltage 10.2V, you know that is about time to land, if you monitor the total voltage.
If you see the average cell voltage, it will report 3.4V per cell. You might think you might still be good for a couple more passes, but in reality, one of your cells is already at 3.2V, and it will even discharge faster than the others at this point.

This is the way I see it.. Obviously people do it the way they think it is better. I wouldn't

João

[Daedalus66]

"No information is better than misleading information". Or misunderstood information.

We see this every year at our flight school, where someone comes along saying "I don't need to measure individual cell voltages before and after flying, or time my flights, because I've got telemetry"!

It's good for battery sales at the LHS.


Sent from my iPad using Tapatalk

[Kilrah]

Of course having cell voltage monitoring is ideal but not essential, after all remember we've lived and been able to fly many planes for years with no issues before it was available, or even without any telemetry whatsoever.

The case of a battery with a cell much below the others is not only rare, but when it happens it means your battery is already toast... further damaging isn't much of a worry as it will end in the trash after that flight anyway.

[jhsa]

Most of my batteries (from HK) are all at least 5 and a half years old, and still going.. I wonder why.. Yes, I still didn't buy a battery again since I came back to the hobby, and I fly nearly everyday, at least in summer. winter too when possible, only this year wasn't possible.
I see guys at my field puffing their batteries on the first couple days. No telemetry..
So, sorry but the statement "we've lived and been able to fly many planes for years with no issues before it was available" doesn't really apply to Lithium based batteries, but to the old heavy weight NiCad stuff
As far as I know the lipo technology is widely available for our hobby since only a few years?? Less than 10 maybe??

João

[MikeB]

We don't have a "standard" way in which the Mavlink telemetry values are mapped to FrSky values. Some values are clear where they go, but other, Mavlink specifc, values are not. The Teensy code uses certain values over the SPort connection using SPort IDs. As it happens, the SPort interface will transfer the old hub IDs.
What I shall do is to adjust the Arduino code to send the specific values over SPort using the same, hub, IDs as the hub connection, and then adjust ersky9x to handle the SPort IDs from the Teensy to match this.
This way, it should all just work whether you use the Arduino or the Teensy. As a note, the Teensy doesn't currently seem to send the battery percent anywhere.

Mike.

[kaos]

The default GPS format is DDMM.mmmm, where DD is degrees, MM is whole minutes and mmmm are fractions of a minute.
I could easily have an error in my conversion to DD.dddddd.
Mike.

The number from the actual FrSky Hub GPS is actually the same as this Mavlink reporting. May want to check on the original Frsky hub data too. (may be it is converted by the tx telemetry porgram as of now? )
I was pretty impressed by this old Neo-6M GPS on MP, it placed my quad 10ft from where it is on the MP map.