DIY-Multiprotocol-TX-Module
DIY-Multiprotocol-TX-Module copied to clipboard
pascallanger
Protocol Mark300 M1, XN297L
Here is recaptured and repacked TX SPI in Logic 1.2.18 with description and support files...
Pascal, thank you for the opportunity to break up the Mark300 M1 protocol... If there is anything more you would need to send, please, let me know. I'm going to look on the protocol too, but with my less experienced eyes...
Zeret
P.S. Archive is twice packed because of comprimation and git compatibility(rar,zip).
I've looked at the captures. I'm not sure about what you call "bind" since for me the bind happens in the file RX_DronePowerUp. As soon as the TX receives the RX, it exits bind and starts to send data and hop on frequencies. The file TX-RX_Bind is when the RX starts to send telemetry to the TX.
1Mb, Scramble enabled, 16 bytes TX & RX address: EE DD CC BB 11
Bind
RF Channel: 0x46 Packets every 33670µs Payload:
| 0xAA | 0x16 | 0x02 | 0x02 | 0x02 | 0x80 | 0x80 | 0x80 | 0x80 | 0x20 | 0x20 | 0x40 | 0x40 | 0xAA | 0x55 | 0x1C |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Bind packet | Bind_ID? | Bind_ID? | Bind_ID? | Bind_ID? | THR 01..80..FF | RUD 01..80..FF | ELE 01..80..FF | AIL 01..80..FF | -- | -- | -- | -- | Bind indicator? | Bind indicator? | Checksum |
Checksum calculation is different from normal mode. Needs to be checked...
Bind ends when the TX receives this answer from the RX:
| 0xAA | 0x16 | 0x02 | 0x02 | 0x02 | 0x65 | 0x97 | 0x41 | 0x31 | 0x00 | 0x00 | 0x00 | 0x00 | 0x00 | 0x55 | 0x34 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Bind packet | Bind_ID? | Bind_ID? | Bind_ID? | Bind_ID? | RX_ID | RX_ID | ?? | ?? | -- | -- | -- | -- | -- | -- | Checksum |
Checksum calculation is different from normal mode. Needs to be checked...
Normal
2 RF Channels 0x46, 0x3D chaging every 10 packets Packets every 9180µs Payload:
| 0x55 | 0x67 | 0x95 | 0x43 | 0x27 | 0x80 | 0x80 | 0x80 | 0x80 | 0x00 | 0x20 | 0x40 | 0x40 | 0x00 | 0x00 | 0x5B |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Normal packet | RX_ID | RX_ID | ?? | ?? | THR 01..80..FF | RUD 01..80..FF | ELE 01..80..FF | AIL 01..80..FF | -- | -- | -- | -- | -- | -- | Checksum |
P[3]=0x43 and P[4]=0x27 are not equal to the previous RX answer 0x41 and 0x31... From where are they coming???
Checksum=P[15]=sum(P[0..14])&0xFF The 4 0x80 are most probably the 4 channels but more dumps are required to find out. The 0x20 and 2 0x40 are most probably trims but more dumps are required to find out.
The RX starts to send telemetry when it receives:
| 0x55 | 0x67 | 0x95 | 0x43 | 0x27 | 0x80 | 0x80 | 0x80 | 0x80 | 0xAA | 0x20 | 0x40 | 0x40 | 0x00 | 0x00 | 0x05 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Normal packet | RX_ID | RX_ID | ?? | ?? | THR 01..80..FF | RUD 01..80..FF | ELE 01..80..FF | AIL 01..80..FF | Ready to receive telem? | -- | -- | -- | -- | -- | Checksum |
Is it the arming sequence? Since I see that P[5] switching from 0x80 to 0x01 and progressively back to 0x80 which looks like a centered Throttle going down and then up...
The RX sends:
| 0x55 | 0x67 | 0x95 | 0x43 | 0x27 | 0x0 | 0x71 | 0x0 | 0x0 | 0x0 | 0x0 | 0x0 | 0x8 | 0x0 | 0x0 | 0x34 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Normal packet | RX_ID | RX_ID | ?? | ?? | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | Checksum |
The 0x71 fluctuates between 0x71 and 0x78 Checksum=P[15]=sum(P[0..14])&0xFF
Next step is to identify Aileron, Throttle, Elevator, Rudder and any special features of the radio. I need one dump where you touch only one thing at a time. For example you move aileron left, right then save the capture and name the file ail_left_right. Same for all the other stuff.
Pascal
Here are main functions... The other functions I'll prepare in while... MARK300_cap2.zip
This is strange. In these dumps the TX is using only 1 RF channel in normal mode. The packets are also being sent with a not fixed timing. This part doesn't match what I've seen in the first dump... Something is not right somewhere.
I've identified AETR locations and added them to my previous post.
What's your suggestion? I can make another complete batch of captures during one bind session... Or capture of one function in multiple binds?
What tool do you use for packet analyse? I can try to analyse other captures myself.
I've written the following powershell script: nrf24l01.zip To use it, open the capture, click on SPI and select CSV export. Then run the script on this file, you can either give the script the filename by the command line or edit line 3 of the script. The script will output the decoded data on the screen which you can redirect to a file using "> filename.txt". Then I load it in excel, on the Data tab select "Text to Columns" and finally apply filters to see what you are looking for. Pascal
That's very nice and powerfull tool. Thank you... To the strange behavior of TX. Do you mean situations when TX sometimes sends payload only once and sometimes even didn't receive RX? And timings of these messages are irregular in compare to previous? I think I have possible explanation. Due to testing and capturing packets, the TX battery was exhausted and for next batch of captures I have to connect the charger. And because the charger is ordinary 5V USB switching power supply, I think, that MCU had serious trouble to keep the right clock. Battery was low so it cannot hold the voltage spikes... I'll try to take some new captures and compare them with wrong ones, but I think it may make sence, don't you think? I apologize myself for this mistake, but I didn't realize it...
Do you mean situations when TX sometimes sends payload only once and sometimes even didn't receive RX? And timings of these messages are irregular in compare to previous?
No answer from RX is fine but what I'm puzzled about is the lack of frequency hopping and unstable timing in all the latest dumps that you have done compared to the first one. The first series of dump makes total sense with frequency hopping and stable timing.
I think I have possible explanation. Due to testing and capturing packets, the TX battery was exhausted and for next batch of captures I have to connect the charger. And because the charger is ordinary 5V USB switching power supply, I think, that MCU had serious trouble to keep the right clock. Battery was low so it cannot hold the voltage spikes... I'll try to take some new captures and compare them with wrong ones, but I think it may make sence, don't you think? I apologize myself for this mistake, but I didn't realize it...
May be that's the case. Can you redo a dump with the battery charged?
I've done new captures. Battery charged, no wifi or bt in air, but it seems similar to previous ones... Captures_2.zip
| P[13] HEX | BIN | Type | Fnc |
|---|---|---|---|
| 0x02 | 00000010 | btn | headless |
| 0x04 | 00000100 | btn | camera up |
| 0x08 | 00001000 | btn | camera down |
| 0x10 | 00010000 | btn | geom. calibration |
| 0x20 | 00100000 | switch | speed 2 (0 = speed 1) |
| P[14] HEX | BIN | Type | Fnc |
|---|---|---|---|
| 0x04 | 00000100 | btn | takeoff / land |
| 0x08 | 00001000 | btn | fly around |
| 0x10 | 00010000 | btn | take photo |
| 0x20 | 00100000 | btn | take video |
| 0x80 | 10000000 | fnc | gyro calibration |