Hi Tridge,
this is just to confirm that I had it working in UART mode on an X4R and a pixhawk1 by using serial4 with an inverter (classic max3232 inverter).
The general setup instructions if someone wants to try your fport code in UART mode is:
set some serial port with SERIALn_PROTOCOL=23 to enable RCIN
set SERIALn_OPTIONS=0 and use an s.port inverter for boards that do not have built in inversion/half duplex
set SERIALn_OPTIONS=7 for boards that support inversion and half duplex
Eric, I would not call your project “modest little protocol translator”, it turned out into way much more than that!
The above ID explanation is for f.port which does not use physical IDs, but in the bidirectional s.port implementation we should stick to that standard as well.
Tridge is doing a great job (as usual) at keeping the rc protocol f.port implementation separated from the telemetry code so it won’t be too hard to plug the bidirectional stack on top of f.port
Dragonlink has been so kind to send me one unit too so we will both be able to do end to end testing!
I’ll update the parameters API to also use parameter ID, I agree it’s a good choice and will speed things up quite a bit.
After parameters I would like to give a try at mavlink command_long messages
Alex, I’ve posted v2.46i which includes foundation support for Mavlite. It’s NOT properly tested, mainly because I don’t have a TX or a proper test mule here.
End-to-end testing
Um, ok, I’ll be looking for a very, very high-gain UHF antenna in the meantime. Or we could try EME (moon bounce). But this got me thinking. We could perhaps try a tcp socket. With full feedback to Mission Planner, and fly remote. UHF repeaters on each end.
OK, I’ll take a look at it.
I’d like to publish the lua scripts but I still cannot find a good name for the project, some candidates:
ardupilotlua
luagcs
??
same for the “mavlite” library classes, some candidates:
mavsport
frskymav
??
Mavlite gives a rough idea of what this is but I really am open to suggestions
hahaha, you got me laughing loud this morning…but after reading it you also got me thinking that since we share the same timezone we might eventually put something together to have you fly one of my birds or viceversa over tcp + uhf repeaters, would be cool actually, technically one of us would have direct sight and would make this kind of legal, no idea of the latency at my flying field tough…
LUA_GCS seems to capture the purpose pretty well I would say. Or perhaps FRS_LUA_GroundControl. As for the class libraries, I already think of them as Mavlite.
Alex, it looked a bit tricky to integrate the S.Port send and my scheduling using the class libraries. As discussed before, my scheduling is a little different than scheduling in the FC, because my translator is simply a link in a bigger timing chain. So I pop messages through fifo except for status message chunks, which take up the slack. I would love to simplfy and use those classes.
Well, I hooked up a Dragonlink TX and RX, and got them talking to each other on the desk.
Being on vacation, we have been out and about a lot, but I couldn’t help imagining Mavlite on this link, rather than Mavlink Grande. We could push the telemetry range out considerably by improving the link budget, but would need to cater for all crucial telemetry.
An alternative would be to send FrSky Passthru instead. Since Passthru/DIY is in the public domain FrSky shouldn’t object (but who knows?). I could translate FrSky back to Mavlink Grosse at the receiving end for use by MP et al, and pipe PT to LUA. Just a thought.
Mavlink is already quite compact, but by designing a custom “stripped down” version we could sure save a few bytes, quite a task tough
In the end we’ll probbaly end up with something similar to what you describe at least for the paramenters and command messages, as fa as telemetry goes it’s hard to beat passtrough lightness.
We do have examples of semi-transparent mavlink: TBS and QCZEK both provide a subset of mavlink in/out and internally use a proprietary protocol.
true, this would actually work quite well. The “real” bandwidth used by passtrough is surprisingly low, around 1200bps.
by removing the tight timing and defining some kind of framing we would end up with something similar to LTM (recentely added to the ardupilot supported telemetry protocols)
I remember adding LTM to my tracker a while back. If I’m not mistaken they determine that GPS coordinates are Northern or Southern hemisphere by “N” or “S”. But perhaps that has changed.
There is a huge amount of redundancy in Mavlink, but of course it is massively rich in function. Good for everything, but maybe not the special case of very long distance limited bandwidth telemetry.
FrSky PT is enough to drive a nice HUD, and report mission progress, especially on long distance flights, like you do.
Hello Alex, I’m back. What would you like to do next with bi-directional? I tested Ground Mode with the Horus today and it seems to be ok. Tomorrow I’ll test Air Mode. Do you have any more transaction types you would like the try?
Parameters are organized in pages, you toggle pages by pressing the PAGE up/down button.
Tuning pages are shown first right after the scripts detects the frame type.
After the tuning pages you get the parameters defined in the lib/default_params.lua file, these are shown for all models and all vehicle types.
You can have per model and per vehicle parameters defined in the YAAPU\CFG folder params<1|2|3|…|n>.lua
<copter|plane|rover>params<1|2|3…|n>.lua
Format is the same for all parameter files, it’s pretty simple just take a look at one of the examples.
I’ve merged in FPort support in master. Please see this post for details:
Note that the changes for FPort support should also help a lot of people using SPort. We have new BRD_ALT_CONFIG options, plus I have improved the handling of half-duplex mode to work on a wider variety of boards.
