MLINK protocol analysis, CRC ?

More
12 Dec 2013 21:15 #16565 by PhracturedBlue
Replied by PhracturedBlue on topic MLINK protocol analysis, CRC ?
sorry, sweeping all channels together isn't helpful. I need each channel swept individually. Basically I need what you did in inc3 but for every channel, and for channels 1,2,3,4,5,6 and 13,14,15,16 it's be useful to follow the entire range, but again, one channel at a time.

Please Log in or Create an account to join the conversation.

More
13 Dec 2013 18:32 #16585 by heligator
Replied by heligator on topic MLINK protocol analysis, CRC ?
Now I have generated tons of data:
  • inc-lsb-full: sweeps the LSB over the full range (and a bit more) from 0x800 to 0x8ff for the well known servo channels 4, 5, 7, 13 ;)
  • inc-msb1: sweeps the MSB from 0x100 to 0xb00 (after this the LSB toggles from 00 to 01)
  • inc-msb2: to continue it, sweeps the MSB from 0x900 to 0xf00
  • inc-col1/2/3: sweep all servo channels that are in the same column

From time to time some bytes seem to get lost. Even the index counter gets out of sync after half a Megabyte or so.
Attachments:

Please Log in or Create an account to join the conversation.

More
13 Dec 2013 18:52 #16587 by heligator
Replied by heligator on topic MLINK protocol analysis, CRC ?
In 'Fast response mode' and 'France mode' checksum is different for the same data. This is visible in the first data line in the three files in inc3.zip from my earlier post.

I have checked binding with a second TX. It looks like each TX has an individual DATA_CODE (DSSS "chip") and RF channel list (FHSS table). The DATA_CODE and channel list is sent during binding on RF channel one. Even in 'France mode' where only lower channels are used, the same channel list is transfered during binding. In binding data 'Fast response mode' and 'France mode' and can be recognized by some flag bytes.

During binding, I assume the RX stores the binding data. Multiple RX (without telemetry) can be bound to a single TX. When switched on (in normal mode), the TX simply broadcasts its data whether or not there are RX's.

Please Log in or Create an account to join the conversation.

More
14 Dec 2013 09:27 #16615 by kreidler
Replied by kreidler on topic MLINK protocol analysis, CRC ?
If the France mode helps to analyse the protocol than it is ok. I would not implement this feature anymore because the complete channel range is meanwhile accepted by France law also. So there is no need to have this function anymore.

If you switch the Tx to 'Fast Response Mode' a Rx bound before will not work anymore. New bind is required.

How do you checked this issue with the DATA_CODE? Have you used an additional HFMG module or have you used a different Tx? The modules do have a different version numbering which might be transmitted. Besides the new SmartTX these are the actual firmware numbers:
  • M-Link HF-Module HFMGx 0.41
  • M-Link HF-Module HFM3 u. HFMx V2 0.43
  • M-Link HF-Module HFM4 u. Cockpit SX 0.44
HFM4 is for the Royal / Evo Tx. You just can check with the MPX Launcher which version you have. There have been earlier versions with factory installed firmware without data output on the COM port of the module. Might be that there have been some other changes also.

Yes, you can bind multiple RX to a single TX. MPX does not have a model match yet (but they have some kind of a patent for this feature).

Please Log in or Create an account to join the conversation.

More
14 Dec 2013 16:17 #16621 by PhracturedBlue
Replied by PhracturedBlue on topic MLINK protocol analysis, CRC ?
I'm not going to look at France mode. The smaller channel count doesn't really help, and now that we know the checksum is different it is even less interesting.

Thanks heligator for the data it looks good. Now to see if I can actually make anything meaningful from it.
One note: your new format of writing the channel and index, doesn't actually work. It appears you are just counting as far as the index goes, but every once in a while you miss the channel change and then your index is wrong. The code I use to reformat the packets checks the channel sequence and finds and fixes this though, so it isn't an issue for me.

I think there is enough data now to figure out the algorithm. Now the question is whether I'm capable of actually doing it...

Please Log in or Create an account to join the conversation.

More
16 Dec 2013 19:00 #16721 by heligator
Replied by heligator on topic MLINK protocol analysis, CRC ?
Yes, I have two HF modules HFMGx with Version 0.41. Maybe the module type is transmitted during binding, but I can't check that with two modules of the same kind. I looks like module IDs (serial numbers) are not transmitted. RX's can distinguish different TX modules by DATA_CODE and hopping table (channel list) instead of serial numbers.

Anyway, before implementing MLINK protocol the checksum issue needs to be resolved. If this checksum was intentionally implemented as a security feature to protect the MLINK protocol, it will be very hard to decode. Hope, that this was only meant to provide data integrity.

Please Log in or Create an account to join the conversation.

More
22 Feb 2014 19:54 #20755 by th9xer
Replied by th9xer on topic MLINK protocol analysis, CRC ?
I may have found a clue, see here:
www.deviationtx.com/forum/protocol-devel...cks-oh-wise-pb#20754

I'll leave it to the mods to sort my potential cross posting mess, sorry.

Cam.

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 01:41 - 23 Feb 2014 01:51 #20772 by th9xer
Replied by th9xer on topic MLINK protocol analysis, CRC ?
Quick update. With the help of Perl I automated the scanning of the log files @heligator provided and things are holding up pretty well. On one of the 513kb logs only two hits for CRC's that couldn't be reversed.

Will post the Perl script once it's had a bit more tweaking. At first glance it doesn't appear as though the relationship between the initial CRC register value and the RF channel number is a stationary one, any one channel seems to switch between two initial CRC register values.

Cam.
Last edit: 23 Feb 2014 01:51 by th9xer.

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 02:16 #20776 by PhracturedBlue
Replied by PhracturedBlue on topic MLINK protocol analysis, CRC ?
Are you using the indexed channels or the raw channel numbers? I'll be interested to see your perl script when you have it working.

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 10:38 - 23 Feb 2014 10:46 #20786 by th9xer
Replied by th9xer on topic MLINK protocol analysis, CRC ?
In your notation of: seven byte packet -- chksum (channel-channel-index) I am using what you refer to as "channel"

In this case it's 3b:
01 07 91 07 91 07 91 -- 8a (3b-0001)

To input this into reveng rearrange it as 3b 01 07 91 07 91 07 91 8a so channel first, then the packet, then the checksum.

Off indoor flying now, will continue with the script and post it upon my return. It's a bit slow mind due to the many calls to reveng but quick enough not to warrant integrating the code of the script into reveng etc.

Cam.
Last edit: 23 Feb 2014 10:46 by th9xer.

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 16:14 #20790 by PhracturedBlue
Replied by PhracturedBlue on topic MLINK protocol analysis, CRC ?
This should work for all cases.
It uses index rather than channel number, and I just mapped each index to the proper init value.
It uses the format I posted my data in
#!/usr/bin/perl
use strict;
use warnings;

use Digest::CRC qw(crc8);

my @map = (0xf1, 0x09, 0x89, 0x49, 0xc9, 0x29, 0xa9, 0x69, 0xe9, 0x19, 0x99, 0x59,
           0xd9, 0x39, 0xb9, 0x79, 0xf9, 0x05, 0x85, 0x45, 0xc5, 0x25, 0xa5, 0x65,
           0xe5, 0x15, 0x95, 0x55, 0xd5, 0x35, 0xb5, 0x75, 0xf5, 0x0d, 0x8d, 0x4d,
           0xcd, 0x2d, 0xad, 0x6d, 0xed, 0x1d, 0x9d, 0x5d, 0xdd, 0x3d, 0xbd, 0x7d,
           0xfd, 0x03, 0x83, 0x43, 0xc3, 0x23, 0xa3, 0x63, 0xe3, 0x13, 0x93, 0x53,
           0xd3, 0x33, 0xb3, 0x73, 0xf3, 0x0b, 0x8b, 0x4b, 0xcb, 0x2b, 0xab, 0x6b,
           0xeb, 0x1b, 0x9b, 0x5b, 0xdb, 0x3b);

while(<>) {
    chomp;
    #my($chksum, $idx, $data, $chan) = (/^(..) -- (....): (.. .. .. .. .. .. ..) \((..)\)/);
    my($data, $chksum, $chan, $idx) = (/^(.. .. .. .. .. .. ..) -- (..) \((..)\s*-\s*(....)/);
    next if(! defined $idx);
    my @vals = map {hex($_)} split(/ /, $data);
    my $valstr = join("", map {chr($_)} @vals);
    $chksum = hex($chksum);
    $chan   = hex($chan);
    my $tstcrc = Digest::CRC::crc($valstr, 8, $map[$idx], 0, 1, 0x31, 1, 0);
    printf "$data: %02x : %02x\n", $chksum, $tstcrc;
}
For reference here is the index -> channel map
my @chan_order = (
21, 59, 35, 43, 9, 65, 33, 71, 7, 77, 9, 41, 31, 45, 19, 71, 15, 51, 33, 47, 11, 63,
17, 73, 13, 57, 39, 59, 3, 65, 13, 75, 5, 79, 5, 55, 23, 61, 31, 79, 37, 63, 11, 55,
23, 45, 3, 77, 25, 57, 19, 67, 37, 49, 27, 75, 15, 67, 17, 53, 35, 51, 29, 53, 7, 73,
41, 69, 29, 61, 27, 43, 21, 69, 25, 47, 39, 49);

Thanks th9xer!

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 16:20 #20791 by PhracturedBlue
Replied by PhracturedBlue on topic MLINK protocol analysis, CRC ?
For reference, here is the re-formatted data I used. I changed the order to be:
crc -- index: data (chan#)
The crc1.pl I included reads this syntax.

File Attachment:

File Name: mlink_data.zip
File Size:346 KB
Attachments:

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 17:08 #20793 by PhracturedBlue
Replied by PhracturedBlue on topic MLINK protocol analysis, CRC ?
And lastly, here is a shift-register implementation of the CRC that can be used in Deviation:
sub crc8_le {
    my($_result, @d) = @_;
    my $poly = 0x8c;  #x^9 + x^5 + x^4 + 1
    my $result = 0;
    foreach (0 .. 7) {
        $result = ($result << 1) | ($_result & 0x01);
        $_result >>= 1;
    }
    foreach (@d) {
        $result = $result ^ $_;
        foreach my $j ( 0 .. 7) {
            if($result & 0x01) {
                $result = ($result >> 1) ^ $poly;
            } else {
                $result = $result >> 1;
            } 
        }       
    }       
    return $result & 0xff;
}   

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 19:58 #20801 by th9xer
Replied by th9xer on topic MLINK protocol analysis, CRC ?
You got there much quicker and neater than I would have, well done !!

What did you use to generate the channel to init table, another little script ?

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 20:46 #20803 by PhracturedBlue
Replied by PhracturedBlue on topic MLINK protocol analysis, CRC ?
if you run reveng on the results from any index (just the data, not the index or channel) you'll get the 'init' value for the crc. I just cycled through data from the 78 indexes and grabbed each one.

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 21:28 - 03 Mar 2014 01:01 #20807 by th9xer
Replied by th9xer on topic MLINK protocol analysis, CRC ?
Good old manual approach then. I'm relieved it's not just me that resorts to it on occasion.

So the data the CRC is calculated on doesn't include any channel or index reference then, the channel is just used to set the initial CRC register. I suppose including the channel data is irrelevant as it never changes given the window we are looking at, so including will just give a different init table.

Another one gets closer to biting the dust then.

Cam.
Last edit: 03 Mar 2014 01:01 by th9xer.

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 21:49 #20808 by heligator
Replied by heligator on topic MLINK protocol analysis, CRC ?
Congratulations th9xer ! Finding reveng and decoding this CRC is really great !

In the next days I'm going to sort captured data and write down my insights in binding sequence and packet timing. For that we see the overall picture of this protocol, so we can implement it into Deviation.

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 22:11 #20810 by PhracturedBlue
Replied by PhracturedBlue on topic MLINK protocol analysis, CRC ?
My guess is they don't have a table for initializing the CRC. if we rotate the indexes, we may find an exact match where index + data ==> CRC. As for the channel number, either the channel uses a lookup table, or there is simple math to derive the channel from the index. There isn't much benefit to trying to tease the last bit out of it though. It is easiest to just keep 2 tables around and run with those. Unless someone ereally likes the math side, in which case go for it :)

Please Log in or Create an account to join the conversation.

More
23 Feb 2014 23:37 - 24 Feb 2014 00:06 #20816 by th9xer
Replied by th9xer on topic MLINK protocol analysis, CRC ?
It did cross my mind that something more direct than a table would be linking the two, I didn't look hard, and I failed to find anything, figures.

@heligator Thanks for the thanks, but yourself and PB are more to credit I think. I just stumbled across reveng and the rest was history, dumb Google luck.

Although it's use has passed attached is my perl script for the reference of others.

Cam.

File Attachment:

File Name: mpxcrc.pl.txt
File Size:2 KB
Attachments:
Last edit: 24 Feb 2014 00:06 by th9xer.

Please Log in or Create an account to join the conversation.

More
15 Jul 2014 12:16 #24593 by FriedSky
Replied by FriedSky on topic MLINK protocol analysis, CRC ?

heligator wrote: In the next days I'm going to sort captured data and write down my insights in binding sequence and packet timing. For that we see the overall picture of this protocol, so we can implement it into Deviation.


@heligator
Please can I ask which Tx / Rx setup you are using for your testing.
I have a Royal Pro 7 which i'm doing some multiprotocol stuff with ATM.

Please Log in or Create an account to join the conversation.

Time to create page: 0.079 seconds
Powered by Kunena Forum