I try to find how calculate checksum form hdlc frame. I try with example:
7E A0 0A 00 02 00 23 21 93 [18 71] - checksum 7E
I tried this calculator: https://www.scadacore.com/tools/programming-calculators/online-checksum-calculator/
I put there this part of frame: A0 0A 00 02 00 23 21 93
but result didn't match...
I need your advice, guys...
Without hitting the books, I recall that 7E is not the checksum, just the Tag - first byte in an hdlc message. Do you have the whole message you can share?
Implement on python:
After calculating crc,
write higher bit first and then your lower bits, for eg
crc= "3a3b"
crc_used in packet=3b3a
you can try this:
import crcmod #pip3 install crcmod
import sys
def calculate_crc(packet):
packet=''.join(packet.split(' '))
crc16 = crcmod.mkCrcFun(0x11021, rev=True, initCrc=0x0000, xorOut=0xFFFF)
fcs=str(hex(crc16(bytes.fromhex(packet))))
crc_f=str(fcs[4:6])+str(fcs[2:4])
if len(crc_f)<4:
diff=4-len(crc_f)
crc_f= "0"*diff + crc_f
return str(crc_f).upper()
print(calculate_crc("A0 0A 00 02 00 23 21 93"))
output: 1871
Related
I'm struggling with an old radiation sensor and his communication protocol.
The sensor is event driven, the master starts the communication with a data transmission or a data request.
Each data telegram uses a CRC16 to check only the variable data block and a CRC8 to check all the telegram.
My main problem is the crc16, According to the datasheet the poly used to check the data block is: CRC16 = X^14 + X^12 + X^5 + 1 --> 0x5021 ??
I captured some data with a valid CRC16 and tried to replicate the expected value in order to send my own data transmission, but I can't get the same value.
I'm using the sunshine CRC calculator trying any possible combination with that poly.
I also try CRC Reveng but no results.
Here are a few data with the correct CRC16:.
Data | CRC16 (MSB LSB)
14 00 00 0A | 1B 84
15 00 00 0C | 15 88
16 00 00 18 | 08 1D
00 00 00 00 | 00 00
00 00 00 01 | 19 D8
00 00 00 02 | 33 B0
01 00 00 00 | 5A DC
08 00 00 00 | c6 c2
10 00 00 00 | 85 95
80 00 00 00 | 0C EC
ff ff ff ff | f3 99
If I send an invalid CRC16 in the telegram, the sensor send a negative acknowledge with the expected value, so I can try any data in order to test or get more examples if needed.
if useful, the sensor uses a 8bit 8051 microprocessor, and this is an example of a valid CRC8 checked with sunshine CRC:
CRC8 = X^8 + X^6 + X^3 + 1 --> 0x49
Input reflected Result reflected
control byte | Data |CRC16 | CRC8
01 0E 01 00 24 2A 06 ff ff ff ff f3 99 |-> 0F
Any help is appreciated !
Looks like a typo on the polynomial. An n-bit CRC polynomial always starts with xn. Like your correct 8-bit polynomial. The 16-bit polynomial should read X16 + X12 + X5 + 1, which in fact is a very common 16-bit CRC polynomial.
To preserve the note in the comment, the four data bytes in the examples are swapped in each pair of bytes, which needs to be undone to get the correct CRC. (The control bytes in the CRC8 example are not swapped.)
So 14 00 00 0a becomes 00 14 0a 00, for which the above-described CRC gives the expected 0x1b84.
I would guess that the CRC is stored in the stream also swapped, so the message as bytes would be 00 14 0a 00 84 1b. That results in a sequence whose total CRC is 0.
I want to generate random bytes in Ruby, but I also want to insert some constant values into specific positions of the random bytes.
random_hex_string = SecureRandom.hex (length)
random_hex_string.insert(0,"0102")
random_hex_string.insert(30*1,"36")
So I generate random hex bytes and insert my hex values there. The problem is that I have now a string not a byte array. So when I print it:
File.open("file.txt", 'w+b') do |f|
f.write(random_hex_string)
It - not surprisingly - converts the hex string into binary then writes it. So my hex values are not kept. To be more clear, when I write my hex string to the file, and then I want to see the same hex values when I hex dump the file. How can I do this?
You can turn it into a single element array and pack it as hex. For instance, when I run your code:
require 'securerandom'
length = 2 ** 6
random_hex_string = SecureRandom.hex (length)
random_hex_string.insert(0,"0102")
random_hex_string.insert(30*1,"36")
puts random_hex_string
File.open("file.txt", 'w+b') do |file|
file.write([random_hex_string].pack('H*')) # see also 'h'
end
I get the output
010299e84e9e4541d08cb800462b6f36a87ff118d6291368e96e8907598a2dfd4090658fea1dab6ed460ab512ddc54522329f6b4ddd287e4302ef603ce60e85e631591
and then running
$ hexdump file.txt
0000000 01 02 99 e8 4e 9e 45 41 d0 8c b8 00 46 2b 6f 36
0000010 a8 7f f1 18 d6 29 13 68 e9 6e 89 07 59 8a 2d fd
0000020 40 90 65 8f ea 1d ab 6e d4 60 ab 51 2d dc 54 52
0000030 23 29 f6 b4 dd d2 87 e4 30 2e f6 03 ce 60 e8 5e
0000040 63 15 91
0000043
Unless, I'm mistaken, it matches up perfectly with the output from the script.
I've never messed with Array#pack before, and haven't done much with hex, but this seems to be giving the results you require, so should be a step in the right direction at least.
Why ask for hex when you don't actually want hex? Just do this:
random_bytes = SecureRandom.random_bytes(length)
random_bytes.insert(0, "\x01\x02")
random_bytes.insert(15, "\x36")
I'm programming a low level communication with an Epson tm-t88iv thermal printer on a Linux device, which receives only hexadecimal packages. I have read the manual trying to understand how the checksum is built but i can't manage to recreate it.
the manual says that the checksum are 4 bytes representing the 2 bytes sum of all the data in the package sent.
I have currently four working examples I found by listening to a port on a windows computer with a different program. the last 4 hexadecimals are the checksum (03 marks the end of the data and is included in the checksum calculation, according to the manual).
02 AC 00 01 1C 00 00 03 30 30 43 45
02 AC 00 00 1C 80 80 1C 00 00 1C 00 00 1C 03 30 32 32 31
02 AD 07 01 1C 00 00 1C 31 30 03 30 31 35 33
02 AD 00 00 1C 80 80 1C 00 00 1C 00 00 1C 03 30 32 32 32
I have read somewhere that there is a sum32 algorithm but i can't find any example of it or how to program it.
Wow, this is a bad algorithm! If someone else finds himself trying to understand Epson's terrible low-level communication manual, this is how the check-sum is done:
The checksum base is 30 30 30 30
Sum in hexadecimals all of the data package (for example, 02+89+00+00+1C+80+80+1C+00+01+1C+09+0C+1C+03 = 214)
Then separate the result digit by digit, if its a letter add 1 to the value (for example B2 would be 2|1|4).
sum it to the checksum base number by number starting from right to left (this would be a checksum of 30 32 31 34).
Note: It works perfectly, but for some reason the examples I posted above don't seem to match so much. They are all the printers response, but slightly after it got a hardware problem and had to be reformatted by technical support, so maybe it got fixed.
I hope it helps somebody somewhere.
I have to integrate Passbook with a website that provides PDF417 barcodes with data encoded in binary (as opposed to text), such as this:
Is there any way I can encode this binary chunk in pass.json so that Passbook displays it on the iPhone identically to the original picture?
Again, I cannot switch to text-based barcodes because I do not own the data. Just for clarification, the attached picture contains a PDF417 barcode that, when decoded, contains non-printable characters, such as the NULL character, which is why I refer to it as binary.
UPDATE
This is how the image decodes into a byte array:
01 00 01 00 02 00 E7 C4 B5 96 B8 42 94 B3 B4 75
1A D1 F2 38 92 EA B5 0E 17 5D 0B 2A AA 64 18 CC
28 62 86 E5 74 5D A3 89 09 12 6E D5 7A 1A C9 EE
BF 23 9C E1 60 AD 9E DE 92 6D E5 79 99 C7 91 F1
6A D5 82 2E B6 E3 81 24 F8 0A F8 E6 44 5D 56 D2
00 00 00 00 00 00 40 0D 00 09 20 23 00 96 13 5C
10 EC 0C EA A3 E8 A3 20 30 4B 2A 20 7D 0F BB DF
F7 5E FA 1E 76 F7 40 20 10 08 04 02 81 40 20 30
A3 D5 6C 1A 04 76 14 10
This is how I try to transform it into a utf-8 string:
{"message": "\u0001\u0000\u0001\u0000\u0002\u0000\u00E7\u00C4\u00B5\u0096\u00B8\u0042\u0094\u00B3\u00B4\u0075\u001A\u00D1\u00F2\u0038\u0092\u00EA\u00B5\u000E\u0017\u005D\u000B\u002A\u00AA\u0064\u0018\u00CC\u0028\u0062\u0086\u00E5\u0074\u005D\u00A3\u0089\u0009\u0012\u006E\u00D5\u007A\u001A\u00C9\u00EE\u00BF\u0023\u009C\u00E1\u0060\u00AD\u009E\u00DE\u0092\u006D\u00E5\u0079\u0099\u00C7\u0091\u00F1\u006A\u00D5\u0082\u002E\u00B6\u00E3\u0081\u0024\u00F8\u000A\u00F8\u00E6\u0044\u005D\u0056\u00D2\u0000\u0000\u0000\u0000\u0000\u0000\u0040\u000D\u0000\u0009\u0020\u0023\u0000\u0096\u0013\u005C\u0010\u00EC\u000C\u00EA\u00A3\u00E8\u00A3\u0020\u0030\u004B\u002A\u0020\u007D\u000F\u00BB\u00DF\u00F7\u005E\u00FA\u001E\u0076\u00F7\u0040\u0020\u0010\u0008\u0004\u0002\u0081\u0040\u0020\u0030\u00A3\u00D5\u006C\u001A\u0004\u0076\u0014\u0010";}
However, Passbook does not display an equivalent barcode. In fact, it displays just a few first bytes.
I don't think you want to decode the binary data of the image, but instead want to read the data from the barcode as if it were scanned.
You could use a service like http://zxing.org/w/decode.jspx which gives you the value of the barcode as if it were being scanned.
Send the 'Raw Text' value to pass.json.
I haven't used this service, but after a quick read I'm assuming it goes in 'message' below:
"barcode" : {
"message" : "ABCD 123 EFGH 456 IJKL 789 MNOP",
"format" : "PKBarcodeFormatPDF417",
"messageEncoding" : "iso-8859-1"
}
ref: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/PassKit_PG/Chapters/Creating.html#//apple_ref/doc/uid/TP40012195-CH4-SW1
How do you turn off the feature or stop the creation of all the .ddp files for your Delphi 7 forms? I read something about removing the designdgm60.bpl, but is that the only way? It seems that there was another way I can't remember any longer.
Update: I tried renaming the designdgm70.bpl and that just creates a ton of program errors.
Also, I'm using Delphi 7.2 on one computer and there is no design tab I can see unless its covered by something in CnWizards. 7.2 definitely creates the ddp files though.
DDP files are for Delphi diagrams (DDP stands for Delphi Diagram Portfolio) in Delphi 6-7. Delphi 5 used the DTI extension for this.
DDP files can have meaningful information. They don't get compiled into .DCU/.EXE./... as they are for documentation purposes only.
Did you create diagrams of components on your form/datamodule? I used to do that (to explain structure to co-workers) so I was actually really happy with the DDP files.
Before deleting them, inspect them to see if they contain documentation you want to keep.
You can safely delete them if they are 51 bytes long and the TDUMP of it looks like this:
000000: 07 18 44 45 4C 50 48 49 2E 44 49 41 47 52 41 4D ..DELPHI.DIAGRAM
000010: 2E 50 4F 52 54 46 4F 4C 49 4F 0F 00 00 E0 40 02 .PORTFOLIO....#.
000020: 01 09 06 09 55 6E 74 69 74 6C 65 64 31 06 00 02 ....Untitled1...
000030: 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
I suppose that it's impossible to turn off .ddp creation in IDE by built-in methods, but DDevExtensions tool includes this option (File Cleaner)
You can install DDevExtensions which is free.
There is an option which you can check that automatically deletes .ddp files.