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:
- data integrity checksum (1 byte only)
- which lets roughly 0.4% of bit-errors sneak through; professional designs use min 2 byte CRC similar to VEMS triggerframe format and modbus RTU : to allow max 0.0015% of biterrors sneak through; the formula is more complex because double-bit errors in certain patterns should be considered; but min 2 byte can be considered good for most non-radhard designs
- 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 defined (RPM, TPS, MAP, ...)
- with some scaler mismatch between AIM protocol doc and AIM dash implementations (like wheelspeed multiplier)
- can be extended with vendor-specific channels (eg. sending PWM duty to VEMS round => actuators)
- physical layer can be RS232 (cablelength: a few meters) for simplicity (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 (reliably) 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" later on, 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
- it is very common that users hook up adapters that appear to work, but after line-silence, SWALLOW first byte (some only at high baudrate, some even at low). In real life, most users will NOT be able to diagnose what is going on, just conclude that their adapter works (and it does, with sane protocol), and fails with any "in-medias-res" protocol (like modbus RTU, or AIM if the waste-gaps are inserted as in the specification) that does not allow "preamble" because of bad design.
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) "teletype restriction" (wasted bandwidth gaps) 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 behaves when connected to first serial (and [http://vems.hu/vt/help/main/aim.html VEMS configured to send via 1st serial)
- if experience shows that some receiver (eg some dash with updated firmware) cannot decode the correct bytesequence without the wasted gaps, it can be connected to first serial (and we will see if demand justifies some "respect both stupidity"/"send more data" configuration flag)
Configure 2nd UART to send "5 byte stream" with datacontent matching the AIM (but currently no wasted gaps)
Requirements
- Newest 1.2.35 firmware (compile time after 2016-07-14)
Configuration (VemsTune checklist)
- VT -> Ecu Calibration:
- iButton anti theft: disabled
- prohibit/iButton2 high byte: 8
- prohibit/iButton2 low byte: 1
- VT ->Ecu Logger -> Ecu Log Settings:
- GPS Log Baud rate: 19200 (actually 2nd serial port baudrate; in old VT if this entry is greyed out => temporarily enable bytestuffing)
- Ecu log use byte stuffed format: disabled
- Automatic GPS Log to SD card on main serial port : disabled
- SD Card Trigger Log: disabled
- VT->Outputs->Display Settings:
- AIM disable => send via 2nd serial if 2nd serial is free (renamed accordingly in VT 2016-07-..)
- AIM enabled => send via 1st serial (as traditionally), respecting the "teletype restriction" (even those receivers should pick it up that do not understand the bytesequence without the wasted gaps)
- but only when VT -> Ecu Calibration:
- prohibit/iButton2 high byte: NOT 8 ; make sure this value is NOT 8 (eg. 255 is fine) before enabling AIM
2nd COM wiring
2nd COM port for live data (FW 1.2.35 and newer), 2nd RS232 3 pin (unpopulated header) towards the main processor:
- GND (easy to locate)
- TX (measures appr -7V when idle)
- RX (input, as an experiment pull to +5V with 1k resistor and it will follow to 3..4V perhaps).
Located above the MAX232D (SOIC16) chip, different header, otherwise the same pinout as the 1st RS232 (which is towards the L293D stepper driver IC). See GenBoard/VerThree/Schematic