I have been trying to get telemetry to work with my OpenLRS RX and TX. Been trying out different setups and baud rates but not got it to work.
The transparent serial bridge is working perfectly but when I try to connect the RX to the APM Telemetry port (port 3) I cannot connect via Mission Control. Running a serial monitor I can see traffic - ascii in the beginning saying something like "<startup_mode: ground>" and then binary. Seems to be ok... but not good enough to connect.
I think the problem might be related to bandwidth. OpenLRS supports 750 byte/seconds from the RX to TX. After looking at the documentation and source code I have not figured out how much data MAVLink protocol is configured to send per second.
Does anybody know?
OK, I just tried setting all baud rates to 19200 (rather than 57600), and of course it works now. Except mode display seems to display wrong mode.
I misinterpreted this README text:
I should have changed APM S1 Telem param to 19200 baud, not change Gitsly/OpenLRSng serial baud to 57600. Oops. :)
Just wrong mode display problem lingers now...
Thanks you for great work Andrew, I get link stats very good at default config (57600), but my problem is I not can access to CLI for configure the TX, I read the entire procedure (put the TX in BIND mode and press ENTER in 115000bps) and I not can access to CLI. ¿can you help me?
Regards from Spain, Pedro.
PS - I get Link stats of 100% in mission planner at 19200 (and 9XR display works). I was only getting 64% at 57600, but data throughput was much greater (~3x datarate, less ~60% dropout = better data throughput, and it showed in Mission Planner), and 9XR display didn't work.
Considering adding this as a wiki page, do you think it's matured enough for general use?
Will run tests of my own with OrangeRX gear
Thanks for your work on your Gitsly branch of OpenLRSng. It really speeds up data transfer between my APM ArduPlane 2.78b and Mission Planner (57600 baud). I use OrangeRX modules in a 9XR. Great!
The problem is that I just updated to your latest release and updated my 9XR firmware to the latest OpenTX firmware with MAVLINK display extension (using latest Companion9x by ticking MAVLINK extension box only), and it seems to have broken MAVLINK info display screens on the 9XR. Serial passthrough still works fantastic, Mission Planner plays very nicely, impressively fast.
I have opened an issue on the OpenTX GitHub ( https://github.com/opentx/opentx/issues/754 ), as I believe it may be because OpenTX uses outdated MAVLINK defs. Would you agree?
I thought I'd mention this issue here as well, just in case I have made a setup error (in which case I'd close the OpenTX Github issue).
FYI, my Gitsly/OpenLRSng CLI params are as follows (all default), and I set 9XR/OpenTX baudrate to 57600:
PLEASE NOTE - REPLACE "57600" with "19200" in my post above to get operational! OOPS!!
Hi, cool that you've found usage for my branch of openlrsng. The assumption you've made about outdated MAVLINK defs could be right. Did a quick diff and there are some differences in the xml message definitions between what I've been using in my latest code, and the one for OpenTx AND the one for latest ardupilot.
I guess the problem could be solved if everyone updated to diydrones latest... I will try this once I get to it (time constraints). Note I'll also welcome any pull requests =)
Have you used the latest openTx stuff from here?:
or some stable version, in which case what version did you use?
Im still using er9x for myself so Im kinda outdated, and haven't wired up the serial lines for my T9X yet, but I might try this out in the near future, and gear up inorder to resolve this issue...
FYI: The only difference between straight transparent serial and mavlink is that I inject radio status packets in the middle of the stream, no other types of packets...
Also I've had made a mistake with the latest master version of my branch, where I've started developing sampling of background noise (RSSI) and mistakenly pushed the changes ahead of time to the master branch. I've reset the branch to correctness now, but this shouldn't have anything todo with the MAVLINK issue described (or cause any other problems either).
This feature could come in handy when flying over RF intense environments...
I first tried OpenTX with MAVLINK extenstion provided as binary (rev 2940) using latest Companion9x (Ver 1.52, rev 2381). Next I tried the OpenTX master branch from source ("current - rev 2834 - 2013-10-29"). Neither worked.
I have not tried the Github OpenTX "next" branch. Don't really want to run my UAV on bleeding-edge code not knowing its features/hacks, but I'll at least do a compile, burn and test of that branch shortly (today). Looking through the change logs it seems MAVLINK files have not been touched anyway.
I am using your Gitsly/OpenLRSng code downloaded yesterday. Even if you are a little out of date with the MAVLINK library, I don't think the issue lies in your code - it speaks nicely to Mission Planner. I think you are only injecting a link info packet into the serial stream, so chances are you are only using one or two MAVLINK defs that have not changed (hmmm... couldn't you remove most of the MAVLINK lib and just use a handmade link info packet to save flash memory?).
Anyway, this is why I felt the problem lies within the OpenTX's MAVLINK extension. (I also tried Kha's trunk binary (flashed from his Chrome configurator), but am pretty sure I got same broken display result).
I'll get the latest version of your code so as to avoid the RSSI background changes, but I am interested to use that in the future!
Hey, a quick question - How does Kha's trunk openLRSng code perform in comparison to yours? I mean, what kind of approx data bandwidth improvement do you get over that code? I'm not sure if he has ever included any of your optimisations in his main trunk?? For bench test under same conditions I suspect you are getting a significant improvement, like 50-100%, right?
Hmm, I got it wrong in my last post, been a while I was looking into the code and too many projects going on =). I already do make up the radio info packet from standalone code (to save flash and SRAM), and have my own parsing of mavlink 1.0 packets to determine where to insert them without an additional buffer needed for storing the content of the packets being sent, saves up some SRAM too...
I removed the GCS_Mavlink library now from my repo (it was used in earlier versions).
Too isolate my code as a potential problem, you could set
#define MAVLINK_INJECT 0
in openLRSng.ino. This will in effect stop the injection of mavlink into the stream, yet allow you to run higher telemetry packet sizes.
Regarding the performance of my branch versus the original, I would guess that it can increase the overall bandwidth by about the double, I did some early testing regarding this (when I started the project) but I've forgot the actual results... Then it of course depends on the parameters configured in the radio modem.
Nothing has been merged back into Kah's branch unfortunately. I have actually not sent him any pull-requests either, since I believe he's in the opinion that not many users would need the mavlink functionality. Also I've made the addition of using libraries into the code (like using FastSerial) whereas he has some code snippets of his own for handling serial data properly...
I find his code design kinda confusing sometimes and it's hard to make any changes without breaking stuff since there is very little separation of concern and modularity in the code. Although he's done a superb job with openLRSng as a whole.
Edit: Thanks Martin!
- I have updated to your current code, and the serial bridge seems to work well (No 9XR display due to OpenTX's outdated GCS_Mavlink lib, I believe).
- I agree it's at least twice as fast data bandwidth as Kha's main trunk, at least with bench testing.
- Please ignore a pull request I sent you on Github, I had an IDE env error. oops!!
I think Rienk was working on the OpenTX Mavlink extension last time I spoke to him. It should be easy enough to update OpenTX master tree to use a copy of the latest GCS_Mavlink lib. Might have a go myself if current devs are not interested.
Thanks again, Andrew