Thread Tools
Feb 11, 2015, 03:34 AM
Just me..
cgroen's Avatar
Thread OP
Yes,
I have tried a bunch of tools that could try all the different ways of doing this, none of the runs produced any meaningfull results.

I have concluded that Spektrum thinks their CRC calculation is so much black magic that they don't want to tell us how its calculated (to bring some more safety to auxiliary equipment connected to their "industry standard SRXL port"). We are putting this notice with the product when it is sold.
Such a shame since the customers for these products are flying highend turbine jets
Sign up now
to remove ads between posts
Feb 11, 2015, 05:06 AM
Registered User
Angelos's Avatar
Quote:
Originally Posted by cgroen
Yes,
I have tried a bunch of tools that could try all the different ways of doing this, none of the runs produced any meaningfull results.

I have concluded that Spektrum thinks their CRC calculation is so much black magic that they don't want to tell us how its calculated (to bring some more safety to auxiliary equipment connected to their "industry standard SRXL port"). We are putting this notice with the product when it is sold.
Such a shame since the customers for these products are flying highend turbine jets
If SRXL was an industry standard Spektrum has ruined it by not following the same rules for CRC check. If it isn't compatible with everything else it shouldn't be called SRXL.
Feb 11, 2015, 05:32 AM
Just me..
cgroen's Avatar
Thread OP
Agree 100% Angelos!
Thats also why I put "industry standard" the way I did
On one side Spektrum wants us to use the SRXL port while at the same time they wont tell us the CRC algorithm. Wonder if they screwed it up somehow and wont admit it....
Feb 11, 2015, 12:46 PM
AndyKunz's Avatar
Quote:
Originally Posted by cgroen
Yes,
I have tried a bunch of tools that could try all the different ways of doing this, none of the runs produced any meaningfull results.
If you fed the bits in reverse order (keeping the seed in the right order), and it still failed, then you screwed up something. That's the secret.

If you're doing it bytewise, reverse the bits in the byte. That is, 0xFA would go into your CRC algorithm as 0x5F. (But don't change the seed value's order!).

Andy
Feb 11, 2015, 02:14 PM
Just me..
cgroen's Avatar
Thread OP
Thanks for input Andy!
Now, instead of me doing even more guessing, can you give the full answer ?
1) I assume its a CRC16
2) What is the polynomial (0x1021) ?
3) What is the initial CRC value ?
4) I also assume that the CRC bytes in the frame are NOT bit reversed, ie sent directly as calculated by the CRC routine

So far I have:

unsigned char reverse(unsigned char b) {
b = (b & 0xF0) >> 4 | (b & 0x0F) << 4;
b = (b & 0xCC) >> 2 | (b & 0x33) << 2;
b = (b & 0xAA) >> 1 | (b & 0x55) << 1;
return b;
}

unsigned short CRC16(unsigned short crc, unsigned char value, int yy) {
unsigned char i;
value=reverse(value);
crc = crc ^ (unsigned short)value<<8;
for (i = 0; i < 8; i++) {
if (crc & 0x8000)
crc = crc << 1^yy;
else
crc = crc << 1;
}
return crc;
}

Calling it with:

crc=0xFFFF;
for (i=0; i<sizeof(buf)-2; i++) crc=CRC16(crc, buf[i], 0x1021);

Where buf[] contains the frame received, the last two bytes are the CRC16 (I guess).

Still not correct CRC calculated.
Feb 11, 2015, 07:49 PM
Registered User
Angelos's Avatar
I took a packet from post #17 and reversed the bit order of every byte with a lashup PHP script...
Before: A2 03 00 01 3C 9E 1C 00 46 57 4C 00 5C 00 63 00 D7 7F
After: 45 C0 00 80 3C 79 38 00 62 EA 32 00 3A 00 C6 00 EB FE

Then I fed it into an online CRC calculator that I have previously used for SRXL packets but it still does not validate.

JR XBUS Mode B -> OK

Spektrum SRXL -> Fail

It is clear that Spektrum use a different polynomial or seeding the shift register. Why, why, why, why, why, why, why, why, why!!! Please give me one barely believable reason why did Spektrum have to do this! Why isn't the industry standard CCITT-CRC16 (which defines a specific poly, shift order and seed) good enough for them? Why did they have to call it SRXL and ruin our hopes for a possible industry standard receiver protocol that just works?
Last edited by Angelos; Feb 11, 2015 at 08:38 PM.
Feb 12, 2015, 02:06 AM
Just me..
cgroen's Avatar
Thread OP
Angelos,
I would _guess_ that the two last bytes in the frame is NOT to be fed into the CRC routines as they are the CRC bytes themself (and not to be reversed?). I think only the first n-2 bytes goes into the calculator, and then compare the result with the last two bytes to check if they match
(but you can still feed them and the result will be 0 if match if they are to be reversed?)
But that still does not validate...

Irritates the $.h.i.t out of me to spend so much energy on a CRC calculation, it is NOT that I need to spend time on when doing a product, its not supposed to be rocket science !
Last edited by cgroen; Feb 12, 2015 at 02:17 AM.
Feb 12, 2015, 07:52 AM
Registered User
Angelos's Avatar
cgroen,
the correct way to validate CRC (shift/xor based) is to shift in the entire message at which point the contents of the shift register should be zero. This works with all industry standard implementations and applies to all other SRXL flavours too.

Checksum (addition based) should also be implemented to give result zero when all bytes of the packet are added. Not that it looses it's effectiveness when implemented differently but it adds extra complexity to handle the last byte differently. Assuming a 4 byte packet with the the last byte being checksum I would do: packet[3]= - packet[0] - packet[1] - packet[2]; Then when the packet is received the result of adding all bytes should be zero.
Feb 12, 2015, 08:11 AM
Just me..
cgroen's Avatar
Thread OP
Agree Angelos,
I was just thinking if they (Spektrum) did the reversing of the data bytes, it was not certain that they also did that (revesing the bits) on the resulting CRC they place at the end of the packet. But it seems there are (still) something that is not quite right even with the reversing of the bits in each byte.
Shame it is such a secret....
Feb 12, 2015, 08:13 AM
Registered User
Geoff_S's Avatar
Angelos, just curious - what is the benefit of checking the CRC calculated across all bytes (including checksums) equals zero, vs just checking the received checksum bytes equal the calculated CRC of the message bytes ?
Feb 12, 2015, 08:25 AM
Registered User
Angelos's Avatar
Quote:
Originally Posted by Geoff_S
Angelos, just curious - what is the benefit of checking the CRC calculated across all bytes (including checksums) equals zero, vs just checking the received checksum bytes equal the calculated CRC of the message bytes ?
It doesn't offer more protection but offers processing simplicity. Also it is particularly useful when the size of the packet is not known beforehand.

Note that the CRC was originally designed to be hardware implemented and thus simplicity was even more desired. Why have extra latches to hold the result of the message bytes, extra shift mechanism to receive the checksum bytes and comparators to validate the result.... when all you had to do is OR all the bits of the shift register to see if the result is zero.
Last edited by Angelos; Feb 12, 2015 at 08:32 AM.
Feb 12, 2015, 10:37 AM
AndyKunz's Avatar
The problem is that the CRC engine in the Cypress part eats the bits backwards.

That's why you need to go (as pointed out what, 2 months ago?) STEP BY STEP and not just look at the end result.

Andy
Feb 12, 2015, 10:43 AM
Just me..
cgroen's Avatar
Thread OP
Yup, message understood that the bits needs to be reversed, did that, and got the T shirt already...
But that is not the whole story, is it ?
As Angelos has pointed out, there is more to it than that. If it is so obvious what we are doing wrong, why not just let the cat out of the bag instead of we have to waste our time figuring a stupid CRC algorithm out ?!?

We just need this algoritm to get some more security in products, and it should NOT be treated like the algorithm is made of diamonds or gold....
And yes, I did go STEP by STEP, but I'm sorry, I did not have 2 months of free time to try and figure this stupid algorithm out, some time has also to be spent on the products and getting some real functionality in them....
End result will be that there will be a big fat warning for Spektrum users if this is not fixed in very short time.
Last edited by cgroen; Feb 12, 2015 at 10:49 AM.
Feb 12, 2015, 11:10 AM
Registered User
Angelos's Avatar
Quote:
Originally Posted by AndyKunz
The problem is that the CRC engine in the Cypress part eats the bits backwards.
I am now even more puzzled why a silicon manufacturer make a CRC engine that eats bits backwords than all standards (example CCITT-CRC16, etc). The PIC24, PIC33, PIC32 and various ARM micros I have used all work the expected way. Even if the hardware module didn't work the correct way it is still no justification for not following the SRXL implementation. It doesn't take a great deal of computational time to handle the CRC in the firmware.

Quote:
Originally Posted by cgroen
...why not just let the cat out of the bag instead of we have to waste our time figuring a stupid CRC algorithm out ?!?
Looks like Andy (or whoever did the firmware) is relying on the hardware CRC engine to produce the result and thus he has no firmware example. I am now starting to think that they have configured the engine wrong and thus it is producing a result that makes no sense to us. By being wrong on both ends they manage to get packet validation between their own products. However, if the poly is configured wrong it will not be anywhere as effective as designed. You can't just use any poly, the standard ones are chosen for their superior error detection properties.
Feb 12, 2015, 11:27 AM
Registered User
Angelos's Avatar
cgroen,
have a look at the Cypress CRC engine documentation. Maybe the secret is in there. Also if you have some firmware handy try seeding it with 0xFFFF as I saw it mentioned in the PDF.

http://www.element14.com/community/s...atasheet_6.pdf


Quick Reply
Message:

Thread Tools