Notes on the 5 byte "de-facto standard" AIM serial protocol.
Every 5th byte is A3 in the serial stream (see MembersPage/HankMoody/AIM for more examples and pdf)
Example:
- (03EB=) 1003RPM - 01 A3 03 EB 92
- (07D6=) 2006RPM - 01 A3 07 D6 81
The AIM serial protocol was originally implemented to send data to some (AIM and other) dashes.
The protocol has some nice properties:
- 2 byte CRC for data integriry (similar to VEMS triggerframe format and modbus RTU)
- can be broadcasted to an arbitrary number of receivers (via passive amplifiers if necessary)
- relatively simple
- the bytesequence can be decoded easily (without any timing restriction)
- many standard channel id-s (RPM, TPS, MAP, ...)
- with some scaler mismatch between AIM protocol doc and AIM implementation (like wheelspeed multiplier)
- can be extended with vendor-specific channels (eg. sending PWM duty to VEMS round => actuators)
- physical layer can be RS232 for simplicity with a few meter cablelength (or perhaps TTL-RS232 inside one box)
- or RS485 (differential twisted pair with push-pull transmitter) for awesome transmission (upto 1200m). In practice, installers with some sloppyness (and usually without advanced equipment and knowledge) are more likely to successfully install RS485 than CAN bus.
The protocol has 2 notable stupidity:
- the constant A3 is the 2nd byte in the frame.
- normally the constant "marker" (or FRAME_END) is between frames (eg. 0x7e in the extremely widely used HDLC/PPP and VEMS triggerframe format).
- the byte order is (must be) kept so receivers can decode
- The protocol defines some wasted bandwidth with the "10msec" slots (referred to as "teletype restriction", from 1980 when some mechanical printers were in sync with 300 baud serial stream)
- This does not makes sense, because it's unnecessary constraint for the transmitter, while it does not make the receiver simpler
- actually, easier to implement the receiver state-machine so it only depends on byte-values, and not sensitive to timing (and therefore that is the correct way to decode received data)
- 2 bytes (sometimes 16 bits, often 8..10 bits) of valuable data in 5 byte packets already somewhat prohibitive; becomes really poor with the added overhead of wasted bw (gap between slots)
- "teletype restriction" is especially inconvenient if transceiver and receiver would both handle and prefer higher baudrate (which makes sense); or if transmitted via TCP/IP (ser2net or similar) which is becoming very common
VEMS, when sending via 1st serial (RS232 by default) port, respects both stupidity (and all tested AIM receivers were reported cooperating).
When sending via 2nd serial port (RS232 by default),
- respects the "misplaced A3"
- but to be able to send more data (more channels will be added in future) timing might not be respected. Any sane receiver should easily decode the bytestream. We retest that round firmware can receive perfectly (it was implemented in a sane way from the start).
- any suspicious receiver device should be tested on first serial
- any report about AIM and 2nd serial is neglected, if the report lacks notes about how the same device behaved when connected to first serial (and VEMS configured to send via 1st serial).
- if some receiver cannot decode the correct bytesequence