2nd RS232 serial is also very practical, see BroadcastDatastreamAimSecondSerial to configure v3 sending => 2nd RS232
If using 1st serial, and AIM stream is enabled:
- AIM stream is started on powerup, but ECU STOPS sending AIM data when it receives CRC protected command
- eg. from VemsTune or [android vemsdisplay "triggerframe" mode]
- The AIM stream is started again on powerup/reboot
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)