Problem with COM port device

[burche]

Hi

I know this is not OS development question, but I hope you can help me. I have a customer that both a device that uses serial com to talk with the PC, but the small program that he got with it is written for DOS, and my program (POS system) uses at least Win2000. On Win98 this small program accepts command line parameters and sends them to the device. I installed a monitor on the COM1 and catch what they talk. I issued the same commands and it worked from my program. But the catch is, in one command there are two bytes encoded (crc or what else I don know) and I can't figure out what it is. I hope someone of you is used to this kind of problems and can easily see the solution. Here is a sample that the program sends:


02 33 2F 53 2F 61 2F 2F 31 2F 33 2F 31 2F 30 2F .3/S/a//1/3/1/0/36.
33 36 03

02 33 2F 53 2F 61 2F 2F 31 2F 35 2F 31 2F 30 2F .3/S/a//1/5/1/0/38.
33 38 03

02 33 2F 53 2F 62 2F 2F 31 2F 34 2F 31 2F 30 2F .3/S/b//1/4/1/0/38.
33 38 03

02 33 2F 53 2F 62 2F 2F 31 2F 35 2F 31 2F 30 2F .3/S/b//1/5/1/0/39.
33 39 03

02 33 2F 53 2F 63 2F 2F 31 2F 35 2F 31 2F 30 2F .3/S/c//1/5/1/0/40.
34 30 03

02 33 2F 53 2F 63 2F 2F 31 2F 35 2F 31 2F 30 2F .3/S/c//1/5/1/0/40.
34 30 03


The last two bytes before 03 (bold) are changing depending on the content.

Can you see something, maybe your eyes are better then mine? How are the 2 bytes calculated?

If you need I can send you the whole comunication in txt file

Thanks,
Goran

[Brendan]

Hi,

It looks like a 4 bit sum of all preceding characters, where:

0 = 0x33, 0x30
1 = 0x33, 0x31
2 = 0x33, 0x32
3 = 0x33, 0x33
4 = 0x33, 0x34
5 = 0x33, 0x35
6 = 0x33, 0x36
7 = 0x33, 0x37
8 = 0x33, 0x38
9 = 0x33, 0x39
10 = 0x34, 0x30
11 = 0x34, 0x31
12 = 0x34, 0x32
13 = 0x34, 0x33
14 = 0x34, 0x34
15 = 0x34, 0x35

I'm only guessing though - I didn't work out the sum of all bytes before the unknown bytes, and there isn't enough variation in the data to know for sure.


Cheers,

Brendan

[burche]

Hi Brendan

Thank you very much for the fast answer. I'll attach some log files (it is not long, it is simple protocol), so maybe you can see for sure what it is.

Goran

[Brendan]

Hi,

Thank you very much for the fast answer. I'll attach some log files (it is not long, it is simple protocol), so maybe you can see for sure what it is.

Doh - I'm wrong - I checked a few more and it only worked for some of them.

Probably the best way would be to enter the data from the logs into a spreadsheet, and then try to guess the formula from that. That way you can put in a new formula and quickly figure out if it's the right formula or not.

Of course there's another possibility - those unknown numbers might not be a CRC or checksum at all. In this case the only way to figure out what they are might be to get documentation for the hardware itself (e.g. from the manufacturer).

Some of the entries in the logs don't contain any checksum, which makes me wonder why they'd use checksums some of the time but not all of the time (especially when it's probably easier to rely on the parity built into the serial port instead).

Any clues as to what this device is? For "point of sale" systems I can only think of cash registers, bar-code scanners, credit card readers and electronic scales, but the style of communications doesn't seem right for any of these devices.


Cheers,

Brendan

[burche]

Hi

It is a cash register ARCADIA 6010, but it is from a Greek manufacturer I think, I can't find any useful info on the net. The reseller here has just this program for DOS and can't give me more info.

I noticed that in the message passed if a is changed to b or 1 to 2 these two numbers are changed respectively. So, if there is a and 2 OR b and 1, at the end you get the same numbers..

Any other hints would be great. I look now for all kind checksums on the net, maybe I get something, but I am running out of time..

Thanks again

[Dex]

Have tryed disassembling the Dos program ?.

[burche]

No, I am afraid I am not that good

Here is a sample command line:

a "3/S/COCA COLA//1/5/1/0"

And in the attachment is the file, if there is a hero to disassemble it

[Brendan]

Hi,

It is a cash register ARCADIA 6010, but it is from a Greek manufacturer I think, I can't find any useful info on the net. The reseller here has just this program for DOS and can't give me more info.

I noticed that in the message passed if a is changed to b or 1 to 2 these two numbers are changed respectively. So, if there is a and 2 OR b and 1, at the end you get the same numbers..

I noticed that too, and AFAIK the 4 bit checksum theory is correct for the entries you originally posted.

Any other hints would be great. I look now for all kind checksums on the net, maybe I get something, but I am running out of time..

We have a saying here - there's more than one way to skin a cat.

Can you disassemble the DOS program (both in practice and legally) and get the information that way?

Alternatively, can you search for cash registers that have useful documentation and/or suitable software and then tell the customer you only support "brand XYZ" cash registers?

Another idea would be to find a Greek translator and try to get information from the manufacturer.

The last way would be to tell your customer you charge by the hour, and because you didn't provide the keyboard they still have to pay for your time...


Cheers,

Brendan

[burche]

Just for a reference, I found it, it was 2 last dec digits of a one byte checksum, starting after the 2F

Code: Select all

02 33 2F 53 2F
;/code]
and excluding all 2F-s in the row, and minus 2 at the end.

I don't know is this something standard, but it works now.  8) 

Goran