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!
Replies
A small write-up describing what I have found (probably errors in it!)
Hope RF radio ramblings.pdf
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..
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!
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 ?
Hi Tom,
I'm doing a writing on the stuff and will link here once it is done.
I do a lot of telemetry related stuff, first post (post #16) here shows some of it:
http://www.rcgroups.com/forums/showthread.php?t=2489886&page=2
hello!! nice playground you have there!!! keep us posted!!
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 :)
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:
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);
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 ?