Telemetry - OpenLRS and APM - Discussions

Replies

Andrew Dankers February 26, 2014 at 4:57pm

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:

Configure your TX via CLI (done in the same fashion as with original openLRSng):
- Set telemetry baud rate (Default for ArduPilot is 57600)
- Set RFM module datarate, recommended to be set to 2 (19200), inorder to be able to have decent update frequency (packet interval) and telemetry data size.
- Set wanted telemetry packet size:
Value of this param will vary depending on your application.

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...

Cheers,

A
- Pedro > Andrew Dankers March 7, 2014 at 4:34am
  
  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.
- Andrew Dankers > Andrew Dankers February 26, 2014 at 5:16pm
  
  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.
  
  A
  - Tim V > Andrew Dankers March 15, 2014 at 5:22pm
    
    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
Andrew Dankers February 25, 2014 at 9:09pm

Hi Martin,

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).

Regards,

Andy

FYI, my Gitsly/OpenLRSng CLI params are as follows (all default), and I set 9XR/OpenTX baudrate to 57600:

RF_POWER 7

CARRIER_FREQUENCY 435000000

CHANNEL_SPACING 5

HOPLIST 22,10,19,34,49,41

DATARATE 2

BAUDRATE 57600

SERIAL_DOWNLINK 29

MAVLINK extension broken · Issue #754 · opentx/opentx

Issue replication: Upgraded 9XR to latest OpenTX using latest Companion9X with MAVLINK extension ticked only. OK. Upgraded the APM 2.5 to latest vers…
- Andrew Dankers > Andrew Dankers February 26, 2014 at 5:01pm
  
  PLEASE NOTE - REPLACE "57600" with "19200" in my post above to get operational! OOPS!!
- Martin > Andrew Dankers February 26, 2014 at 12:39am
  
  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?:
  
  https://github.com/opentx/opentx
  
  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...
  
  opentx/opentx
  
  OpenTX custom firmware for Transmitters. Contribute to opentx/opentx development by creating an account on GitHub.
  - Andrew Dankers > Martin February 26, 2014 at 1:31am
    
    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?
    - Martin > Andrew Dankers February 26, 2014 at 4:38am
      
      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.
      - Andrew Dankers > Martin February 26, 2014 at 7:48am
        
        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

of 8