Grumpy crem... Shouldn't have sent this, perhaps, but there are times when the unspeakable incompetence of programmers drives me into incoherent rage... Sorry, incoherent fucking rage...
It might help to explain the annoyance that this isn't their first attempt, and I've given them perfectly good source code that would do the job, so they're playing the "not invented here" game by refusing to use it. And so wasting my time... Tossers...
> Attached is a dump of the RS232 data.
> Please check that it conforms to your specification.
No, it certainly doesn't conform to our specification. Tell the stupid bastards to try reading the fucking documentation, I've made it perfectly clear (in several places) that all the data is encoded as pairs of hex characters.
[sigh] Let's look at the bytes.
The first four bytes are OK, I suppose, though not what I asked for.
> 0D 43 41 4E
[CR] CAN - I'd rather they used KAN, it seems (slightly) cleaner to avoid using hex chars in the header, but that doesn't particularly matter.
> 47 00 00 01 02 03 04 05 06 [etc]
But after the first four bytes they go into a bit of a decline. All the rest are garbage - they've completely failed to grasp the idea (god knows how) that ALL the raw bytes are encoded as pairs of hex characters... They're not allowed to send any bytes other than the ASCII characters for "0" to "9" and "A" to "F"
Let me quote from the fucking documentation: "Data bytes are encoded using pairs of hexadecimal characters."
Is there anything even vaguely unclear about that? It's the second fucking sentence... Can't they read? Did they get bored after reading the first sentence and give up? If that isn't clear then what about this?
"After a valid marker field ALL machine-readable data will be represented as octal bytes encoded as pairs of hexadecimal ASCII characters (0123456789ABCDEF or 0123456789abcdef)."
What sort of moron do you have to be read that and not grasp the idea we encode data as "pairs of hexadecimal ASCII characters"?
I don't need or intend to waste my time on drivelling fucking morons like this... The documentation is perfectly clear, tell them to get someone in off the fucking street to read it to them if they can't understand simple bloody english. Pillocks...
[polite but irrelevent bit removed]
I've given them source code that does the encoding, why can't they just use it? If they don't want to use it then what sort of pillock doesn't at least look at it to see what it's doing? Christ, where do you dig these people up?
Here is the relevant bit of the protocol document, in case they haven't even bothered to look at the fucking thing.
I've made bold (assuming your email client understands this) the places where I made it absolutely fucking clear how the data are encoded... Perhaps you can see why I'm pissed off at having to deal with some jerk who can't read?
Haven't they even got the fucking common sense to look at the examples I've included and see that they're nothing at all like the drivel they're sending? There are times when I despair at the sheer unbelievable moronic stupidity of programmers.
[first line of documentation]
Messages use standard ASCII encoding. Data bytes are encoded using pairs of hexadecimal characters.
After a valid marker field ALL machine-readable data will be represented as octal bytes encoded as pairs of hexadecimal ASCII characters (0123456789ABCDEF or 0123456789abcdef). These pairs may optionally be separated by SPACE characters to increase human readability. Any character aside from (0123456789ABCDEF or 0123456789abcdef) and SPACE will be treated as a terminator. Normally upper case should be used for hexadecimal numbers, but lower case may be used.
Following the marker field there may be an arbitrary number of space characters, then there must be two hexadecimal characters representing a single byte of "message length" information.
[section and some examples (FFS!) deleted]
Following the length field there may be an arbitrary number of space characters, then there must be two hexadecimal characters representing a single byte of "message type" information. This contains a single byte representing the type of the message. This field must be present in a valid message.
[section including another example deleted]
Following the "message-type" field there may, or may not, be message data. If there is it must be an even number of hexadecimal characters representing a number of bytes. These may be separated by any combination of space characters but ONLY between pairs of hexadecimal digits.
Following the message data, or the message-type field if there is no data, there may be an arbitrary number of space characters, then there would normally be two hexadecimal characters representing a single byte of "checksum" information.