- Posts: 13
MLINK protocol analysis, CRC ?
05 Dec 2013 16:12 #16300
by heligator
Replied by heligator on topic MLINK protocol analysis, CRC ?
Hi PhracturedBlue,
yes, I had a closer look at the SPI interface using some microcontroller.
Attached is some data. I have already extracted TX packet data and channel changes in the .TXT file and the servo data in the CSV file.
> Where is the chipping code transferred?
It is written in the DATA_CODE_ADR register and the TX transmits it to the RX during binding. The SOP_CODE_ADR keeps the default value. Preamble is 33 33 04. MFG_ID doesn't appear in the packet data.
> What do you mean by hopping index?
The line in the channel list. Every time it hops it changes the channel (frequency). But every channel is present two times in the channel list. Btw. only odd channels from 3 to 79 are used. On each channel two or three packets are sent before hopping to the next channel.
> Are the channels packed, or did they just use 12 of every 16 bits?
They just use 12 of every 16 bits.
> what indicates which channel is being transmitted?
The first byte shows what the packet contains:
For this I fed in some PPM data with ascending pulse length for 16 servos.
It is mainly the CRC thing which remains unclear. I guess that there is a counter from 0 to 77 to access the channel list (= hopping table). After this counter reaches 77, it goes back to 0 and everything repeats, including the CRC (with same counter value, same data gives same CRC). So I think this counter is included in the CRC.
If needed, I can try to get more data samples.
yes, I had a closer look at the SPI interface using some microcontroller.
Attached is some data. I have already extracted TX packet data and channel changes in the .TXT file and the servo data in the CSV file.> Where is the chipping code transferred?
It is written in the DATA_CODE_ADR register and the TX transmits it to the RX during binding. The SOP_CODE_ADR keeps the default value. Preamble is 33 33 04. MFG_ID doesn't appear in the packet data.
> What do you mean by hopping index?
The line in the channel list. Every time it hops it changes the channel (frequency). But every channel is present two times in the channel list. Btw. only odd channels from 3 to 79 are used. On each channel two or three packets are sent before hopping to the next channel.
> Are the channels packed, or did they just use 12 of every 16 bits?
They just use 12 of every 16 bits.
> what indicates which channel is being transmitted?
The first byte shows what the packet contains:
1 2/3 4/5 6/7 => packet bytes
hex s s s => s=servo number
01 12 10 8
02 - 16 14
09 11 9 7
0a - 15 13
80 6 4 2
88 5 3 1For this I fed in some PPM data with ascending pulse length for 16 servos.
It is mainly the CRC thing which remains unclear. I guess that there is a counter from 0 to 77 to access the channel list (= hopping table). After this counter reaches 77, it goes back to 0 and everything repeats, including the CRC (with same counter value, same data gives same CRC). So I think this counter is included in the CRC.
If needed, I can try to get more data samples.
Please Log in or Create an account to join the conversation.
05 Dec 2013 18:32 - 05 Dec 2013 18:34 #16302
by kreidler
....Every transmitter has fail-safe function. Many of them do have two receiver integrated and also many of them do have telemetry ability with MSB sensors connected (Multiplex Sensor Bus). The protocol for this sensor bus is open available on request from Multiplex. Multiplex is offering ground displays for older TX or if you wish to have a bigger display. A small BT adaptor connected to this port could be used e.g. by
https://play.google.com/store/apps/details?id=de.ubitrc.souffleuse
(sorry seems to be German only at the moment).
BTW: You know this: http://www.stoeckli.net/?p=37 for communication between Tx and HF?
Please continue +1
Replied by kreidler on topic MLINK protocol analysis, CRC ?
Jepp, more expensive than an OrangeRX R615FDR wrote: Jeez!
Their receivers are from 50€ to even 210€...
....Every transmitter has fail-safe function. Many of them do have two receiver integrated and also many of them do have telemetry ability with MSB sensors connected (Multiplex Sensor Bus). The protocol for this sensor bus is open available on request from Multiplex. Multiplex is offering ground displays for older TX or if you wish to have a bigger display. A small BT adaptor connected to this port could be used e.g. by
https://play.google.com/store/apps/details?id=de.ubitrc.souffleuse
(sorry seems to be German only at the moment).BTW: You know this: http://www.stoeckli.net/?p=37 for communication between Tx and HF?
Please continue +1
Please Log in or Create an account to join the conversation.
09 Dec 2013 19:00 - 09 Dec 2013 19:01 #16452
by heligator
Replied by heligator on topic MLINK protocol analysis, CRC ?
I have upgraded PPM input with an exact 8MHz timer and hardware-controlled PWM output. But it appears, that PPM input of the TX module isn't sampled that exact. I cannot control the least significant bit precisely and there seems a dependency betweeen the servo channels.
In the appended data, I incremented one value per line (=> servo channels 4, 5, 7 & 13) and set other set servo data to 0x0800. Maybe this helps.
Unfortunately in this data some bits are appearing wrong, especially in the first column, sorry. I'm looking for the reason.
Additionally, I have appended CYRF6936 initialisation in the style as in dsm2.c.
In the appended data, I incremented one value per line (=> servo channels 4, 5, 7 & 13) and set other set servo data to 0x0800. Maybe this helps.
Unfortunately in this data some bits are appearing wrong, especially in the first column, sorry. I'm looking for the reason.
Additionally, I have appended CYRF6936 initialisation in the style as in dsm2.c.
Please Log in or Create an account to join the conversation.
Time to create page: 0.108 seconds
-
Home
-
Forum
-
Development
-
Protocol Development
- MLINK protocol analysis, CRC ?