I am using rfd900 radio for communication between my drone and system, Firstly on both sides I used rfd900 and was able to get the data correctly on the system. I was manually serializing and sending the data from transmitter side and reading it on Putty on the receiver side. Now I am using plutoSDR on the receiver side and to get the IQ data. I am running a MATLAB code that generates a CSV file which then I give input to URH and generate a binary data file, Now I am checking the binary file manually to verify Whether I am getting the data correctly, So yes there were Sik frames present in the binary file and was able to extract preamble, sync1, sync2, netID, length fields correctly but the payload of it contains different data then MAVLink. but the Sik payload contains an MAVLink packet. Does anyone have any idea of it? I am sharing a sample packet below that I extracted from the binary file
[0101010101010101010101, 2d, d4, ff f8, 10, 9a 10 8c 33 25 e4 7d d0 24 70 97 6f 08 5a c7 83, ff, ff ff]
[preamble(22 bits), Sync1(1 byte), Sync2(1 byte), NetID(2 bytes), Payload_length(1 byte), Payload, Trailer(1byte), CRC(2 Bytes)].
Very interesting!
I have tried something similar in the past with another SDR and got more or less the same result. My conclusion was that there are some data whitening being performed on the payload part. I haven’t pursued it further but it would be interesting to know if/when you solved it.
For interest I just picked the Si4030 transceiver, as I am not sure which transceiver is used in the EZR32 chip (used in the RFD900). In that datasheet they give more details about the data whitening and as you can see it only affects the payload section. Also explains why we can decode the preamble and sync words but not the payload:
Hi @copilot
Thanks for the information.
I looked at the documents of the transceiver chip and found about data whitening, did de-whitening using the pn9 sequence, and was able to get data fields correctly up to MAVLink msgID correctly, but it now got stuck at its payload.
Have any idea of it?
Hi, did you make any progress in the meantime?
One thing that came to mind is that the order in which the fields in the payload are transferred does not necessarily match that of the definitions, as they are packed for optimal memory alignment.
Take for example the heartbeat message, in the message definition the first field is ‘type’, while if you look at the C struct it’s ‘custom_mode’ :
typedef struct __mavlink_heartbeat_t {
uint32_t custom_mode; /*< A bitfield for use for autopilot-specific flags*/
uint8_t type; /*< Vehicle or component type. For a flight controller component the vehicle type (quadrotor, helicopter, etc.). For other components the component type (e.g. camera, gimbal, etc.). This should be used in preference to component id for identifying the component type.*/
uint8_t autopilot; /*< Autopilot type / class. Use MAV_AUTOPILOT_INVALID for components that are not flight controllers.*/
uint8_t base_mode; /*< System mode bitmap.*/
uint8_t system_status; /*< System status flag.*/
uint8_t mavlink_version; /*< MAVLink version, not writable by user, gets added by protocol because of magic data type: uint8_t_mavlink_version*/
} mavlink_heartbeat_t;
So maybe just double check that you are decoding the correct fields.
Hi, I haven’t found any solution for it yet, will let you know once found.
Also is there any doc for above information as want to know if it is there then how they order it during transfer.
Previously I was using Gazebo for flight controller but right now I am using JSBSim to see whether I can find an alternative. but getting mavlink v1 packets only from JSBSim. Any Idea on that?
Most of the info I got from reading through the mavlink source code and this Introduction · MAVLink Developer Guide
Looks like they pack the messages starting with the largest data types as described here: Serialization · MAVLink Developer Guide
I am not so familiar with the different simulators. When I need simulation data I normally just use SITL and bind telemetry to a UDP port.
This is the order they are using, and currently I’m interested in GLOBAL_POSITION_INT data,
So my guess is the order should remain as injected.
Below is my packet data:
sample.txt (3.0 KB)