I am trying to write some code to communicate with an old device over serial that uses the Siemens 3964r protocol. This includes a checksum, or more accurately a BCC (block check character) at the end of the transmission. A single char after the ETX. The docs define the BCC as this:
With the 3964R transfer protocol, data security is enhanced by sending an additional block
check character (BCC = Block Check Character).
The block check character is the even longitudinal parity (EXOR logic operation of all data
bytes) of a sent or received block. Its calculation begins with the first byte of user data (first
byte of the frame) after the connection establishment, and ends after the DLE ETX character
at connection termination.
Here is some sample data in hex.
53 54 41 54 55 53 10 03 07
07 is the BCC in this one.
4d 45 41 53 4d 50 54 45 53 54 41 4e 41 50 52 47 30 30 30 55 78 30 31 31 2e 30 30 5a 30 31 31 31 30 10 03 61
61 is the BCC in this one.
I know in general how to do XOR operations, but I haven't been able to figure out any combination of things that gives me a proper BCC. I think I am interpreting the definition wrong.
My preferred language for this is javascript as it's for a node.js electron app. I can read the buffer and get the hex values. And I can construct propoer messages back. But it won't work correctly until I can include a proper BCC. So just looking for someone smarter than me that knows exactly how to produce a valid BCC.
thanks!
The document that was posted as the first comment had the right structure to calculate the 3964r BCC. That document is here:
https://support.industry.siemens.com/cs/attachments/1117397/s7300_cp341_manual_en_en-US.pdf?download=true
Here is a simple javascript function. The hexarray would be passed in, not hardcoded like here, but this accurately calculates the BCC for this particular protocol. If anyone cares or needs it. I just wrote out the bcc as a hex string to the console in this, but you can make it a function and actually return something useable.
var hexarr = ['4d', 45, 41, 53, '4d', 50, 30, 30, 10, 03];
var bcc = 0;
var xor = 0;
for(var i= 0; i< hexarr.length; i++){
var hexint = parseInt(hexarr[i],16);
if(i==0){ xor = hexint; }
else {
bcc = xor ^ hexint;
xor = bcc;
}
}
console.log(bcc.toString(16));
Related
I have to import a list of badge codes for a customer from an old software to the new one. Codes refer to 125Khz readonly rfid badges (most likely, not 100% shure about that).
If I read a given badge, the resulting hex string in the new software is "27000052B4", but in the old it is stored as "30 30 30 30 30 32 31 31 37 32 0D 0A".
I can't understand the transformation applied, and how to obtain "my" code from the stored one.
It's possible that some kind of "encryption" has been applied to the code, or that the stored code it's not the actual mifare tag uid but some other kind of value stored in memory, but I would like to ask if anyone can guess how to, if possibile at all, get the "normal" hex codes from the old values.
As a reference, I paste here a couple of old/new pairs:
badge n. 27000052B4, stored as: 30 30 30 30 30 32 31 31 37 32 0D 0A
badge n. 5B006E82AA, stored as: 30 30 30 37 32 34 32 34 31 30 0D 0A
To recap, I need to obtain the badge number in hex string starting from the stored value, in order to be able to recognize the badge/customer when i read it with the new software.
As an additional note, the trailing part "0D 0A" seems to be just a CRLF and it's the same for all the stored badges.
I'm not sure about the first 2 digits of the badge number, but the stored value is a US-ASCII encoded string that contains the decimal representation of the trailing 4(?) bytes of the badge number (and a carriage return + line feed):
30 30 30 30 30 32 31 31 37 32 0D 0A
is the string
"0000021172\r\n"
21172 in decimal is 0x52B4 in hexadecimal (i.e. the last part of 27000052B4). Similarly, 7242410 in decimal is 0x6E82AA in hexadecimal (i.e. the last part of 5B006E82AA).
Today i got this reader from local shop. Earlier i worked with Wiegand type readers with no problem. So anyway, when i try to read EM type card with 0009177233 ID (written on card) i should get at least 9177233 with start and stop chars expected. But instead i get 50008C0891
ASCII 50008C0891
HEX 02 35 30 30 30 38 43 30 38 39 31 0D 0A 03
BIN 00000010 00110101 00110000 00110000 00110000 00111000 01000011 00110000
00111000 00111001 00110001 00001101 00001010 00000011
I use USB-RS232 converter and RealTerm software.
Does anyone has any ideas why?
Are there 2 ID's?
The decimal 9177233 equals HEX 8C0891, so the software gives you the serialnumber in hexadecimal notation. I think, the full number 50008C0891 is the 5 Bytes (40bit) from the UID of the EM-type chip.
Regards
I'm trying to interpret the communication between an ISO 7816 type card and the card reader. I've connected inline between the card and the reader when i dump the ouput to console i'm getting data that that im not expecting, see below:
Action: Card inserted to reader, expect an ATR only
Expected output:
3B 65 00 00 B0 40 40 22 00
Actual Output:
E0 3B 65 00 B0 40 40 22 00 90 00 80 9B 80 E0 E2
The 90 00 is the standard for OK that it reset, but why i am still logging additional data both before the ATR (E0) as well as data after
The communication line is documented in ISO 7816-3 (electrical interface and transmission protocols), look for the respective chapters of T=0 or T=1 protocol. T=1 is a block oriented protocol involving a prolog containing node addresses and an epilog containing a CRC/LRC.
For the ATR however, no protocol is running yet, since here the information is contained, which protocols the card supports, for the terminal to choose. Surely so early 90 00 is no SW1/SW2.
I had a long time decoding IR codes with optimum's Ken Shirriff Arduino Library. I modified the code a bit so that I was able to dump a Samsung air conditioner (MH026FB) 56-bit signals.
The results of my work is located in Google Docs document Samsung MH026FB AirCon IR Codes Dump.
It is a spreasheet with all dumped values and the interpretation of results. AFAIK, air conditioner unit sends out two or three "bursts" of 56 bit data, depending on command. I was able to decode bits properly, figuring out where air conditioner temperature, fan, function and other options are located.
The problem I have is related to the checksum. In all those 7-byte codes, the second one is computed somehow from the latter 5 bytes, for example:
BF B2 0F FF FF FF F0 (lead-in code)
7F B8 8A 71 F6 4F F0 (auto mode - 25 degrees)
7F B2 80 71 7A 4F F0 (auto mode - 26 degrees)
7F B4 80 71 FA 7D F0 (heat mode - 26 degrees - fan auto)
Since I re-create the IR codes at runtime, I need to be able to compute checksum for these codes.
I tried with many standard checksum algorithms, none of them gave meaningful results. The checksum seems to be related to number of zeroes in the rest of code (bytes from 3 to 7), but I really can't figure it how.
Is there a solution to this problem?
Ken Shirriff sorted this out. Algorithm is as follow:
Count the number of 1 bits in all the bytes except #2 (checksum)
Compute count mod 15. If the value is 0, use 15 instead.
Take the value from 2, flip the 4 bits, and reverse the 4 bits.
The checksum is Bn where n is the value from the previous step.
Congraturations to him for his smartness and sharpness.
When bit order in bytes/packets and 0/1 are interpreted properly (from the algorithm it appears that both are reversed), the algorithm would be just sum of 0 bits modulo 15.
It is nearly correct.
Count the 0's / 1's (You can call them what you like, but it is the short signals).
Do not count 2. byte and first/last bit of 3.byte (depending if you are seeing it as big or little indian).
Take the result and -30 (29-30 = 15, only looking af 4 bits!)
Reverse result
Checksum = 0x4 "reverse resultesult", if short signals = 0, and 0xB "reverse resultesult" if long signal = 0.
i used Ken's method but mod 15 didnt work for me.
Count the number of 1 bits in all the bytes except #2 (checksum)
Compute count mod 17. if value is 16, use first byte of mode result(0).
Take the value , flip the 4 bits.
The checksum is 0xn9 where n is the value from the previous step.
I have the following frame:
7e 01 00 00 01 00 18 ef 00 00 00 b5 20 c1 05 10 02 71 2e 1a c2 05 10 01 71 00 6e 87 02 00 01 42 71 2e 1a 01 96 27 be 27 54 17 3d b9 93 ac 7e
If I understand correctly, then it is this portion of the frame on which the FCS is calculated:
010000010018ef000000b520c1051002712e1ac205100171006e8702000142712e1a019627be2754173db9
I've tried entering this into a number of online calculators but I cant produce 0x93ac from the above data.
http://www.lammertbies.nl/comm/info/crc-calculation.html with input type hex.
How is 0x93ac arrived at?
Thanks,
Barry
Answering rather for others who got here while searching for advice.
The key is what several points in the closely related ITU-T recommendations (e.g. Q.921, available online for quite some time already) say:
1. the lowest order bit is transmitted (and thus received) first
This legacy behaviour is in contrary to the daily life conventions where highest order digits are written first in the order of reading, and all the generic online calculators and libraries perform the calculation using the conventional order and provide optional settings to facilitate the reversed one.
Therefore, you must ask the online calculator
to reverse the order of bits in the message you've input in the "conventional" format before performing the calculation,
to reverse the order of bits of the result so that you get them in
the same order like in the message itself
Quite reasonably, some calculators offer just a single common setting for both.
This reasons the settings "reverse data bytes" and "reverse CRC result before Final XOR" recommended in the previous answer;
2. the result of the CRC calculation must be bit-inverted before sending
Bit inversion is another name of "xor by 0xffff...". There is a purpose in bit-inverting the CRC calculation result before sending it as the message FCS (the last two bytes of the message, the '93 ac' in your example).
See point 4 for details.
This reasons the setting "Final value ffff", whose name is quite misleading as it actually defines the pattern to be for xor'ed with the result of the calculation. As such operation is required by several CRC types, only the xor patterns vary from 0 (no op) through 0xfff... (complete inversion), generic calculators/libraries offer it for simplicity of use.
3. the calculation must include processing of a leading sequence of 0xffff
This reasons the point "initial value ffff".
4. on the receiving (checking) side, it is recommended to push the complete message, i.e. including the FCS, through the CRC calculation, and expect the result to be 0x1d0f
There is some clever thinking behind this:
the intrinsic property of the CRC algorithm is that
CRC( x.CRC(x) )
is always 0 (x represents the original message and "." represents concatenation).
running the complete message through the calculation rather than
calculating only the message itself and comparing with the FCS
received separately means much simpler algorithm (or even circuitry)
at the receiving side.
however, it is too easy to make a coding mistake causing a result to become 0. Luckily, thanks to the CRC algorithm intrinsic properties again,
CRC( x.(CRC(x))' )
yields a constant value independent of x and different from 0 (at least for CRC-CCITT, which we talk about here). The "'" sign represents the bit inversion as required in point 2.
First of all, CRC value is 0xac93
Use this calculator: http://www.zorc.breitbandkatze.de/crc.html
Set CRC order 16
Polynomial 1021
Initial value ffff
Final value ffff
"reverse data bytes"
"reverse CRC result before Final XOR"
Enter your sequence as:
%01%00%00%01%00%18%ef%00%00%00%b5%20%c1%05%10%02%71%2e%1a%c2%05%10%01%71%00%6e%87%02%00%01%42%71%2e%1a%01%96%27%be%27%54%17%3d%b9
Press "calculate" and you get 0xAC93
This is simple Python script for HDLC CRC calculation. You can use it for DLMS
def byte_mirror(c):
c = (c & 0xF0) >> 4 | (c & 0x0F) << 4
c = (c & 0xCC) >> 2 | (c & 0x33) << 2
c = (c & 0xAA) >> 1 | (c & 0x55) << 1
return c
CRC_INIT=0xffff
POLYNOMIAL=0x1021
DATA_VALUE=0xA0
SNRM_request=[ 0x7E, 0xA0, 0x08, 0x03, 0x02, 0xFF, 0x93, 0xCA, 0xE4, 0x7E]
print("sent>>", end=" ")
for x in SNRM_request:
if x>15:
print(hex(x), end=" ")
else:
a=str(hex(x))
a = a[:2] + "0" + a[2:]
print(a, end=" ")
lenn=len(SNRM_request)
print(" ")
crc = CRC_INIT
for i in range(lenn):
if( (i!=0) and (i!=(lenn-1)) and (i!=(lenn-2)) and (i!=(lenn-3)) ):
print("i>>",i)
c=SNRM_request[i]
c=byte_mirror(c)
c = c << 8
print(hex(c))
for j in range(8):
print(hex(c))
print("CRC",hex(crc))
if (crc ^ c) & 0x8000:
crc = (crc << 1) ^ POLYNOMIAL
else:
crc = crc << 1
c = c << 1
crc=crc%65536
c =c%65536
print("CRC-CALC",hex(crc))
crc=0xFFFF-crc
print("CRC- NOT",hex(crc))
crc_HI=crc//256
crc_LO=crc%256
print("CRC-HI",hex(crc_HI))
print("CRC-LO",hex(crc_LO))
crc_HI=byte_mirror(crc_HI)
crc_LO=byte_mirror(crc_LO)
print("CRC-HI-zrc",hex(crc_HI))
print("CRC-LO-zrc",hex(crc_LO))
crc=256*crc_HI+crc_LO
print("CRC-END",hex(crc))
For future readers, there's code in appendix C of RFC1662 to calculate FCS for HDLC.