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

 _    _ 
( )  ( )
`\`\/'/'
  >  <  
 /'/\`\ 
(_)  (_)
        
        

 _       _ 
( )  _  ( )
| | ( ) | |
| | | | | |
| (_/ \_) |
`\___x___/'
           
           

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

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

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:
A high performance, flexible (but simple) CRC protected communication protocol for serial lines (like FBUS, RS232, RS485, etc...). Can also be stored in files or SDcard blocks '''For the curious (developer of dataloggers, university projects, etc...)''' '''Advantages over megatune protocol''' * CRC protection * while allowing flexible response length (amount of bytes not restricted to a certain number) ** this does not result in decoding uncertainties ** nor does it require to send silence between packets ** therefore also suitable for over-internet communication where the serial line is proxied (with ser2net program for example) over TCP possibly to another continent '''Advantage over the AIM protocol''' * The framing byte is in the proper position (between frames, not inside the packet !) * "type" allows different type of packets (not just the 5 byte channel=>value packet) '''Advantage over SerialComm/SIPR''' (SIPR is a nice design, SIPR also bears the same advantages listed above) * it allows sending the high eventrate primary trigger triggerlog with low 10% overhead, compared to 200+% overhead with packing 2 byte into SIPR packets. ** this is because the number of future primary trigger events is uncertain at the start of the packet (and reserving a large buffer is highly undesirable in the microcontroller, avoided with this smart protocol, also saves CPU and complexity) ---- '''More information is helpful especially during first startup''' For example: * 12 tooth coiltype primary trigger with camsync ** the camsync position is very sensitive: must be around the middle between primtrig (ideally 12..18 crankdeg) otherwise if too close, the cambelt sloppiness could result in bad camsync position * 60-2 triggerlog with or without camsync Now other events like commanded spark can be sent (and is actually sent since 1.1.90) in the triggerlog. Optionally ECU runtime data also. More and more information helps the installer when struggling through the first startup and verification of the setup => can save days (or weeks). ---- '''Overview''' The generic format is: '''HDLCbytestuffed( N*primtrig, datablock, type, CRC), 7e''' 0x7e is the frame marker. Anything in between the 7e markers is the HDLC bytestuffed packet. HDLC bytestuffing is the industry standard: * replaces 7e with 7d,5e * replaces 7d with 7d,5d Decoding is trivial (the inverse operation). * type determines the length of the datablock (and interpretation) * any preceding bytes (if exists) are primtrig timestamps ** so the N*primtrig part is optional (usually N=0). ** Actually, currently we only allow N>0 with secondary trigger and wheelspeed and similar events (the firmware closes the packet before some other type, like engine runtime datablock sent). ---- '''Example''' The realtime data is requested by READ_REALTIME_STUFFED_TYPE_COMMAND (32+128=160) that is a0, and modbus CRC is 38bf (but in little endian): a0 bf 38 * And of course, because of HDLC framing, HDLC_END 0x7E before and after ** from brayterm you send $7e$a0$bf$38$7e to get the long response (>60 bytes). v3 response is sent by the MTsendRTvar_triggerlog() function (see comm.c in the firmware zip). So payload comes from MTsendRTvar() function: HDLC_bytestuffed_escaped_and_framed( <payload, 32>, 2byteLittleEndianModbusCRC( <payload, 32> ) ) where 32 is the RT_STUFFED_TYPE (yes, the type is always at the end of the packet, right before the CRC: there is very good reason for this, notably when the primary, secondary and other trigger events are logged and type is NOT known in advance). ---- '''See also''' * see frame FORMAT in /svn/firmware/utilities/v3GUI-CommModel/triggerlog/TriggerFrame.cpp * if you want to decode with uc, see /svn/firmware/firmware/branches/stable1_1/triggerframe.c (it's not final, especially the "type" codes) ---- '''Compatibility''' * the "A" command did not change. Kept compatible with old. ** The "A" command has been there for 8+ years * New commands like binary READ_REALTIME_STUFFED_TYPE_COMMAND = 160 assigned for the engine runtime data when requested in the proper "triggerframe" format So for now one can use the old crappy megatune command ("A" => 56 bytes unframed, or "D" that is more than 56 bytes now) or one can use the new more robust commands. We usually try to keep old compatibility commands until the new is reasonable, stable and works. Roadmap: * old megatune commands and unframed replies * new commands reply using triggerframe format in VEMS ECU => PC direction * triggerframe format also used in the PC => VEMS ECU direction Note that (since 1.1.89) the triggerframe format can also be chosen for the SD-card inodes ("files"). This allows logging very special and rare events on the SD-card (like more details about occasional intermittent trigger-problem that happens 1-2 times a day) - very useful when analyzing engine operation (without this, the installer is almost completely in the dark, the traditional error code flags provide too little info).
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.