I want to build portable device with arduino board to communicate with cash register. For servicing cash register, usual we using notebook with some java app from cash register manufacturer.
And now the problem. I capture serial data from app to serial port, and i cannot decode data intended to represent data and time. Few examples of captured data:
Date and time from app and type of service:
01.08.2016 12:00 and type:T
06 02 0a 62 00 96 f9 45 56 01 00 00 02 02 99
31.07.2014 22:00 type: B
06 02 0a 62 00 d3 5c a2 4a 01 00 00 03 02 8b
I get it first part: 06 02 0a 62, it is ascii code, and zero bytes in middle (probably space between data). But the rest i dont get it :). Maybe it some bcd data with crc encoding?
Manufacturer did not give any information about communication protocol.
I did not ask manufacturer, can try. Yes it is whole output (input data to cash register). I captured that data with "Free serial analyzer" and when i copy that data to Serial console and send it to cash register, i get same results as from cash register windows application.
at the first stage, you can try to decode the messages (CRC is only used to verify they were received correctly) - you can do that later once you get the feel for the messages you are seeing...
(But you will need to create valid CRC before you SEND commands -to- the register, as it will verify /ignore messages with incorrect CRC values.)
Receive CRC is a good idea once you know what you're looking at.
The length in your second example also does not make sense; either 0x0209 (or bytes swapped) or 0x0901 (or bytes swapped). The length of the message is (far) shorter.
This is (with 99.99% certainty) a short message; 0x06 is an ACK coming from somewhere (reply from register on previous message) and should not be counted. So the start is 0x02 followed by a length indication of one byte (0x09) followed by 9 data bytes followed by 2 crc bytes.
sterretje:
THE CRC is not a CRC, you can simple add all the values of the bytes (except for the first one and the CRC itself) and you will get the correct result
Short message
[s]02[/s] 01 65 [s]00 66[/s]
0x01 + 0x65 = 0x0066;
Long message
You will have to review the second example; SOH is not 0x03 nor is it 0x06 (and you mix them up in your explanation).
The length in your second example also does not make sense; either 0x0209 (or bytes swapped) or 0x0901 (or bytes swapped). The length of the message is (far) shorter.
This is (with 99.99% certainty) a short message; 0x06 is an ACK coming from somewhere (reply from register on previous message) and should not be counted. So the start is 0x02 followed by a length indication of one byte (0x09) followed by 9 data bytes followed by 2 crc bytes.
Yes, you are write. Thanks. But this is there example, that make me think wrong:
adi__:
So, crc bytes are just sum from? I only need to sum this bytes and add two in the end of array?
Yes, just sum them; it's actually called checksum
adi__:
What i am doing wrong?
Unix timestamps run from 1970/01/01; according to your (or the manufacturers) description, the timestamp is since 2000/01/01. Try to subtract 946684800 (0x386D43800) before converting. I did try it but did not manage to get the correct result (either so not sure what's up.).
sterretje:
Yes, just sum them; it's actually called checksum
Unix timestamps run from 1970/01/01; according to your (or the manufacturers) description, the timestamp is since 2000/01/01. Try to subtract 946684800 (0x386D43800) before converting. I did try it but did not manage to get the correct result (either so not sure what's up.).
Mr. Sterretje,
many thanks for your help. Yes, manufacturer using timestamp 2000/01/01. I try everything, but, i cant get correct results.
/dev:
Maybe milliseconds since 1-1-200**0** 00:00:00 GMT, with a 2-hour offset for local time?
0x79FF6DEC53 = 523976436819ms
= 523976436s
Using [this date/time calculator](http://www.timeanddate.com/date/dateadded.html?m1=1&d1=1&y1=2000&type=add&ay=&am=&aw=&ad=&h1=0&i1=0&s1=0&ah=&ai=&as=523976436&rec=), it produces
August 8, 2016 at 1:00:36 PM
...within one second of 15:00:07 minus 2 hours of the example. Other examples are spot on or off by one second.
Fun!
/dev
Thanks man. I am f* blind. Is date in big endian format?
If you don't have a Time library yet, there's a Time class in my NeoGPS library that might be handy. It defaults to the Y2K epoch and is optimized for Arduinos. You could easily delete the includes, the NeoGPS namespace and the NEOGPS_PACKED at the end... just use Time.h and Time.cpp.