Reading Serial Data

[RavensFan]

I would say yes.  The 64 bits means 8 bytes.

This really is a bastardized communication protocol.  It looks like a combination of real byte values, and encoded hexadecimal characters.  I was recently looking at a thread where someone was asking about binary coded decimal.  This looks like the data bytes of the message are some sort of "Binary/ASCII Coded Hexadecimal".  Nibbles are the ASCII representation of Hexacdecimal characters.

[mnanda98]

What about term character?

[ben64]

---

@mnanda98 wrote:
Also on page 5, 2.2.2 the manual says the generator yasss packets of 64 bits of data... Does this mean 8bytes? I am becoming p confused...

---

My guess is that when there is data included in the message, which is not the case for initialisation and probably also for commands. It would probably be a good idea to request support from the manufacturer.

Ben64

[RavensFan]

I think you can safely make the termination character the byte value 03.

It looks like the data will never be that value because they are sending the ASCII byte values for hex characters.

And the two checksum bytes are the ASCII byte value for the hexadecimal characters.

The more I see this manual, the worse I realize the whole communication scheme is.

For a checksum of 17 hex,  they send it out as the byte for "1" and the byte for "7".

But for the data section, they are packing those characters tighter into nibbles, so for A1C1 hex,  they are converting those to the ASCII equivalents of "A" "1" "C" and "1".  But packing the "A" and "1" together into a single byte and the "C" and the "1" together into a single byte.

What a mess.  Whoever created this should be shot.

[JÞB]

---

@mnanda98 wrote:
What about term character?

---

Yes, set your Term Char ot ETX 0x03.  Pull the last two Characters off (the CSum) convert the ASCII to 2 Hex digits and Subtract the result from FF.  Take the rest of the string, Convert to array of U8 and add them all together MOD 256.  Compare the two results and only if they are equal fire back the ACK ETX to shut up the retransmissions.

You will want one of these handy.

Lord only knows why Start of Text and End of Text were selected over SOH / EOT.  Perhaps the engineer got confuesed between the mnemonics for "Text" And "Transmission"

<Sea Story> its not the only butchered protocol out there. I once delt with a device that expected "SOH Data !Data CSum EOT" where !Data was the complement of Data.  The CSUM was always FF!</Sea Story>

[RavensFan]

---

@JÞB wrote:

Lord only knows why Start of Text and End of Text were selected over SOH / EOT.  Perhaps the engineer got confuesed between the mnemonics for "Text" And "Transmission"

---

That doesn't seem unusual to me.  I've communicated with numerous models of a brand of motor controllers where its binary, but non-modbus, transmission protocol used STX and ETX.  I have yet to see the SOH adn EOT characters used in the realm of devices I've worked.  It also used ACK and NAK as one byte messages to acknowledge or negative acknowledge messages.  I think it also used a few other characters to tell it to backup or move forward through a series of parameters.  (I stayed away from those messages.  I figured if I wanted the next parameter in line, I would send an explicit message to tell it what parameter I wanted next.)

[ben64]

One of these might also be very handy

Spoiler