_______ 
(  ____ )
| (    )|
| (____)|
|  _____)
| (      
| )      
|/       
         

  ____  
 |  _ \ 
 | |_) |
 |  _ < 
 | |_) |
 |____/ 
        
        

         
    ###  
   ##    
  #####  
   ##    
   ##    
   ##    
         

     ### 
  #####  
 ##  ##  
 ##  ##  
 ##  ##  
 ##  ##  
  ### ## 
         

  _____  
 |  __ \ 
 | |__) |
 |  ___/ 
 | |     
 |_|     
         
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
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
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.