Discussions

Trigger Radio Status Message Injection

Posted by Tom on November 19, 2015 at 11:12pm

Hello my friends, i have modyfied my TH9X (openTX now) and added 3DR radio inside the TX so now i have telemetry on my TX screen. I also have a pinout on my TX and if i want to connect to MP, i use an FTDI cable to my laptop and this works great (Blue tooth module is on the way from china). 

i have read on this forum that: 

http://diydrones.com/xn/detail/705844:Comment:1796162

"Currently the RSSI is added to the heartbeat packet when the GCS sends an outgoing MAVLink heartbeat packet to the drone.  In order to go get the RSSI you either need to send out a MAVLink heartbeat message with MAVLink enabled on the radios or modify the firmware on the radios so that you get it another way." 

So if i wanted to make 3dr radios start injecting RADIO_STATUS messages without connecting to GCS what is the "simplest" HEARTBEAT message i could send through the FTDI connection (with a terminal/arduino/openTX custom code etc) to make it think its connected to GCS? I dont want to send any other command or modify anything on the pixhawk, just make it start sending RADIO_STATUS.

i have searched the codes on github but im not so much of a programmer and i get lost inside the code

and one last question, if i succesfully trick the 3rds into sending these messages with a "fake" heartbeat and then, for some reason, after X minutes  want to connect to GCS will there be a problem? Must i send a "fake" *GCS disconnected* message?

thank you!

You need to be a member of diydrones to add comments!

Join diydrones

Tags: 3dr, mavlink, radio, remrssi, rssi, status
Email me when people reply –
Follow

Replies

  • Carsten Groen December 14, 2015 at 11:47pm

    A small write-up describing what I have found (probably errors in it!)

    Hope RF radio ramblings.pdf

    https://storage.ning.com/topology/rest/1.0/file/get/3702144290?profile=original
  • Carsten Groen December 14, 2015 at 4:07am

    I need to send the full frame to the radio in order to get it to respond anything. I'm using Sik 1.9 on both ends (3DR radio at one end (where I inject the message) and a Hope-RF in my own module in the remote end.

    Independent of the remote radio is on or not, I get these:

    (the "-" is just cosmetic to separate the two frames I receive from the radio)

    Receive (remote radio connected):

    FE 09 0A 33 44 A6 00 00 01 00 D9 D7 64 22 2F 52 6A   -  FE 09 0A 33 44 6D 00 00 01 00 D9 D7 64 22 2F 33 18         

    Receive (no remote radio):
    FE 09 0B 33 44 A6 00 00 01 00 C4 00 64 25 00 C2 80   -  FE 09 0B 33 44 6D 00 00 01 00 C4 00 64 25 00 A3 F2  

    So in both cases I get Msg ID 0xA6 and 0x6D

    The 0x6D is RADIO_STATUS, the 0xA6 I have no idea about....

    The RADIO_STATUS is defined like this:

    rssi   uint8_t  Local signal strength
    remrssi  uint8_t  Remote signal strength
    txbuf   uint8_t  Remaining free buffer space in percent.
    noise   uint8_t  Background noise level
    remnoise  uint8_t  Remote background noise level
    rxerrors  uint16_t  Receive errors
    fixed   uint16_t  Count of error corrected packets

    which in this case does not make much sense... (rssi and remrssi=0 etc)

    Seems there just are some differences in the order...

    FE 09 0F 33 44 A6 00 00 01 00 D7 D6 64 26 29 56 E2   -  FE 09 0F 33 44 6D 00 00 01 00 D7 D6 64 26 29 37 90

    From AT&T=RSSI command:

    L/R RSSI: 215/214  L/R noise: 34/45 pkts: 4  txe=0 rxe=0 stx=0 srx=0 ecc=1/1 temp=27 dco=0

    The local/remote RSSI are 0xD6 and 0xD7 which are in the RADIOSTATUS above. Will do some more digging..

    • Carsten Groen > Carsten Groen December 14, 2015 at 4:50am

      Got it now (and as a bonus I found out some things about Mavlink ;)

      I need to send the complete frame to the radio to get it to react:

      FE 09 4E 01 01 00 00 00 00 00 02 03 51 04 03 1C 7F

      The radio answers back with two frames:

      FE 09 0A 33 44 A6 00 00 01 00 D9 D7 64 22 2F 52 6A   

      FE 09 0A 33 44 6D 00 00 01 00 D9 D7 64 22 2F 33 18

      Basically they are a copy of each other (only difference is the MSG ID (0xA6 and 0x6D)

      The fields of the RADIO_STATUS 0x6D are sent in the following order (Mavlink uses re-ordering of data):

      rxerrors  uint16_t  Receive errors
      fixed       uint16_t  Count of error corrected packets
      rssi         uint8_t  Local signal strength 
      remrssi  uint8_t  Remote signal strength
      txbuf       uint8_t  Remaining free buffer space in percent.
      noise       uint8_t  Background noise level
      remnoise  uint8_t  Remote background noise level

      Thanks for input Tom!

      • Tom > Carsten Groen December 14, 2015 at 6:45am

        hello, thanks for the sharing, maybe hopeRF version of sik 1.9 fw is different i did not even look

        but it worked and this is great for other people that maybe want to fiddle with mavlink etc

        if you dont mind what are you using the telemetry for? 

        what are you playing with ? 

  • Tom November 20, 2015 at 8:56am

    hello again, i found a nasty way to make 3drs report radio_status without GCS connected, i sorted RX and TX pins together causing the 3drs to recieve pixhawk heartbeat messages back, this made 3drs to see an incoming heartbeat and started the radio_status messages. In order to keep reporting u have to keep the pins sorted. OpenTX recieves info normaly but i dont know if there will be a problem to keep the pins sorted for as long as i fly.

    An other issue i had was that OpenTX was reporting 80% PC RSSI while GCS was reporting 99% telemetry RSSI even when GCS is connected and radio_Status is transmitted normaly. When i got far enough for GCS to report 94% Telemetry RSSI, openTX was reporting 42%. I looked at the status list in MP and saw that it reported about the same numbers for rssi and remrssi and noise and remnoise so it is not a mater of OpenTX reporting remote RSSI while MP only local. 

    I think this is an issue of openTX but i post it here in case sombody wants to discuss or help :)

    • Tom > Tom November 20, 2015 at 9:27am

      This is the way OpenTX caluclates PC RSSI (telemetry rssi):

      telemetry_data.pc_rssi = (mavlink_msg_radio_get_rssi(msg) * 100) / 255;

      is this correct for 3dr radios?

      how MP calculates telemetry RSSI?

      For these values:

      rssi: 180ish

      remrssi: 180ish

      noise:25

      remnoise:25

      MP reports 98-99% RSSI while OpenTX reports 70%

      what is the correct way to calculate 3dr rssi?

      i found this formula:

      signal_dBm = (RSSI / 1.9) - 127 but how to translate it to a percentage ? 
      for the value of 180 we have  ~ -32dbm

      • Tom > Tom November 20, 2015 at 10:02am

        heh, its nice to reply to myself it like blogging or something, but i think i will help someone else that is in search 

        from Sl1000 datasheet we can see

        max recieve power: -20dbm  -> 200ish RSSI reported

        min recieve power: -120dbm -> 13ish RSSI reported

        so we can do this dirty calculation in OpenTΧ and be very close to reality

        telemetry_data.pc_rssi = (mavlink_msg_radio_get_rssi(msg) / 2);

        • Carsten Groen > Tom December 13, 2015 at 9:21am

          Tom,

          I would be interested in this information too, is there any way you can grab the data sent to the radio that makes it inject the RSSI packets ?

This reply was deleted.

Activity