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

  _  __
 | |/ /
 | ' / 
 |  <  
 | . \ 
 |_|\_\
       
       

 _   _ 
| \ | |
|  \| |
| . ` |
| |\  |
\_| \_/
       
       

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

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

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:
1968 Dodge Dart GT. 383 BB Port injection, on modified Holley dominator intake. 8x about 500 cc injectors. One of the early 3.0 VEMS boards, self assembled.Only fuel injection in use. Ignition is still being handled by MSD 6al and distributor. Trigger signal is taken from MSD tech ouput port, seems to be very reliable. This setup has been running just OK for more than 8 years. Runs fine without any idle control just startup and afterstart enrichment. No winter driving for this car though. Plan for this winter is to to update ignition using either two 2x2 coil packs or "smart" coils from AEM or something similar Additional stuff: 2004 Mazda RX8 gauge cluster fitted to dash. I'm using arduino due board with two CAN ports. Arduino pulls data from VEMS rs232 and pushes values to CAN-BUS in Mazda specific format. Seems to work exceptionally well even though still using only 9600 bps serial and 'A' requesting VEMS. Note: "new" firmware uses SerialComm/TriggerFrameFormat * the old no-CRC Man commands, and outright dangerous 1-byte megatune-compatible commands are disabled by default, because noise on the serial line causing config change is never good * some "preamble" command B1 "leave TF mode " can instruct the VEMS v3.x ECU fw to go to compat communications mode, at your own risk ** (7E) B1 7F 34 (7E) since modbus CRC of B1 is [https://www.lammertbies.nl/comm/info/crc-calculation.html 347F] and CRC is sent little endian (even though modbus is bigendian, funny standards). But instead of "A" mode: it is '''rather easy to query and interpret TF response''', we can most certainly help (with code examples) if you have such will and project page dedicated * We usually recommend stm32f103 for such serial to CAN at bare minimum (actually we use stm32 for real time comm and control anyway) if temperature reliability is an issue ** orange pi PC is a full power ARM computer (computer means that it can build its own software, which a controller usually cannot do), with 512..1024 MByte RAM, running even Perl or Python (even open-GL games), easier to program, ** for logging to SD FAT filesystem with timestamps, we have code for both stm32 and orange-pi, but orange-pi wins when communicating over wifi, or WAN, or doing other (usually display, logging, video or audio, relay and comm) tasks; if cooling fins are installed, underclocked (to say 480 or 720 MHz), not installed in engine bay, given reasonable testing, and not mission critical.
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.