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

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

 __      __
 \ \    / /
  \ \  / / 
   \ \/ /  
    \  /   
     \/    
           
           

         
|\     /|
| )   ( |
| |   | |
| |   | |
| |   | |
| (___) |
(_______)
         

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

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 integrity (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 (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 ---- '''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) TODO: complete instructions * newest 1.2.35 fw * 1-wire disabled (and 08,01 configured for 2nd Ibutton) * GPS disabled * AIM: sent via 2nd channel, or with old VT ** 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) * ...
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.