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

_________
\__    _/
   )  (  
   |  |  
   |  |  
   |  |  
|\_)  )  
(____/   
         

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

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

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

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:
'''This page lists some applications that could be implemented with''' using large part of '''GenBoard HW''' (or as is) and considerable part of the firmware (but extension is needed): * http://www.popsci.com/popsci/auto/article/0,12543,611352,00.html * chicken incubation system * industrial control * help GenBoard/VerThree/Testing * GoBox * AutoTrans (automatic gearbox) * OvenControl * get lotsof ideas from here: http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/ ---- '''Piggyback''' - this should definitely have it's own page '''terminology''' * '''plug-and-play''' (eg. PlugAndPlayJetronic): an ECM applied to a specific connector and set of sensors to provide plug-and-play install (or rather plug-and-tune, since tuning still often needed unless someone has done it already and published results) * '''runtime piggyback''': cooperating with an alien ECU (design compromise to ''try'' to save on some hassle) to provide engine control. There are several ways to achieve this: ** intercepting ignition and injection signals: this is very problematic and complex ** MAP or MAF substitute (fooling) * '''tunetime piggyback''': watching inputs and intercepting or just watching outputs of an alien ECU for diagnostics (detect faults) and logging the control tables (maps). This makes a lot of sense, when used as a tuning aid (vs. runtime piggyback). The tuned maps are executed with a normal ECM ( native or plug-and-play style install) during production-runtime. I want to develop an open source engine piggy-back controller. The idea is very similar to your project here, except I want to minimize initial tuning by taking inputs from the stock ECU. Many hours went into their testing and I want to preserve much of that. However, I want flexibility to tune my engine based on my modifications. People try this from time to time and almost always come to the conclusion that runtime piggyback with intercepting injection signals is nothing but a pain: More wires, more connectors, more things to fail and even when nothing fails, control is just worse (unless you have a tuningprogram that can cope with both ECMs at the same time: which you don't). With a friendly ECM, no tuning is lost, you have all the config and tables that you tuned. With a foo-ECM (that is tuned without knowing what is tuned (?!); or rather tuned by others with no direct access to maps) ignition and injection can be logged (even on the table, without driving), see OnlineCourse/AlienIgnitionLogging. My target application is the Dodge SRT-4. We already have 4 different very well tuned ECUs. ''The engine is tuned, not the ECU''. The ECU is just a way to execute the tables tuned for the engine. The same tables can be imported to any ECU, so the installed ECU can execute them. '''Runtime piggyback is not needed to save tuning work'''. In fact, to carry existing tuned maps is a software issueto help users converting tables from different formats to the format required by the installed ECM (this is often done manually). On the other hand, piggyback - if done right - is useful to reduce install-wiring work (plug-and-play is another way to reduce install-wiring work). So, the plan is to have inputs for the fuel injector and ignition drives from the stock ECU and modify them slightly as needed. '''Runtime Piggyback only makes sense to make an install possible with reduced wiring (5..6 wires)'''. This is possible and feasible, but it does not involve taking the fuel injectors from the stock ECU. It involves MAP/MAF substitute (fooling) instead. For example, adjusting fuel injector pulse widths to trim out excess fuel at WOT when using W/I (W/I ?). I don't know if maybe I'm re-inventing the wheel and there already is such a project underway, or what... Perhaps a modified GenBoard could perform this task? Anyway, if you really interested in details, check out my long-winded thread at srtforums. http://www.srtforums.com/forums/showthread.php?p=2033955 The first page summarizes most of the project. ---- Doing that as a piggy pack controller seems both very cool and overly complex. I wonder if you'd be better off * making a plug'n'play loom set to run a native VEMS ECU * or using a simple input (eg, MAP/MAF) interceptor to adjust fueling. Eg, [http://autospeed.drive.com.au/cms/A_2418/article.html here] and [http://autospeed.drive.com.au/cms/A_2420/article.html here]. Richard just hit the nail on the head with this. ---- Thanks for the info! Good ideas. A. I could run VEMS full stand-alone, but I don't really feel like going through all the re-tuning. I have a good tune as it is, I just want minor changes. Plus, I'd need to wire up a lot more sensors. Perhaps someday I will. B. We don't have a MAF sensor. The ECU determines MAF from MAP, temp and RPM. so MAP substitute makes sense (not MAF, naturally). Perhaps what I might like to do is re-layout the GenBoard to change some of the extra injector drivers to be inputs instead of outputs. We only have 4 cylinders and it will stay that way. Also, change half the ignition drivers to be inputs. I'd also need to add some DACs. I'm not sure if I saw any on your design. Is it possible to get copies of the schematics and PCB layouts in their native format? I'm not sure what capture program you are using, but I can probably get it or use it at work. I'm an embedded software developer and I've done PCB layouts before. It shouldn't be hard for me to tweak your design to my purpose. If you're interested in this (either the technology or the business side), you can join development (either at VemsExecutives/Firmware or VemsExecutives/HardwareDesign or VemsExecutives/TuningSoftware). You will be surprised that this takes appr. 50% tuningsoftware, 30% firmware and just about 20% hardware. However, it only makes sense if project goals are established. Development makes no sense unless >200 (rather 500) units can be sold: design is "general" enough (without arbitrary restrictions) and it is . It GenBoard/VerThree has 16 analog inputs, that can be used to measure the injection/ignition signal of alien ECM with just firmware changes (no hardware changes). ---- See GenBoard/UnderDevelopment/StagedInjectors Why not add control for 2 or more fuel injectors per cylinder. This would allow for the accurate dosing at idle, but also give the capacity for a large enough dose to be administered while the inlet valve is open during the induction phase, thus enabling sequential injection right up to maximum rpm. Combine this with an O2 sensor for each cylinder in the exhaust manifold, and we can potentially obtain close to perfect stiochemetric combustion on a cylinder by cylinder basis (and could also allow for better detection of misfires/burning oil etc). This combination could also be able to detect and cope with injector failure and fouling problems, providing fault tolerance in the fuel injection system. This is nice, but only feasible with a set of networked ECM (instead of adding 8 WBO2 sensors and 8 more injector drivers to GenBoard/VerThree). It is under development, see VemsFrontier/ArmEfi
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.