___   
(  _`\ 
| |_) )
| ,__/'
| |    
(_)    
       
       

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

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

_________
\__   __/
   ) (   
   | |   
   | |   
   | |   
___) (___
\_______/
         

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

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 specifies what needs to be done for the next firmware release. Next release is named: '''STABLE_1_1''' Tasks left before release: * New Timing Scheme (Dave & Marcell) ** complete the JAVA prototype ** implement the OnlineCourse/Modeling/Scheduler . This makes it possible to guarantee worstcase 300..400 usec turnaround for the highest priority trigger-process code ** Port model to firmware ** the interrupt becomes rediculously simple. This helps porting to ARM ** the clever stuff moves to userspace. If the next output event is due in less than 400usec (or there is no trigger expected before the output event), we schedule the eventqueue event right away (not wait for next trigger) ** Make it work * Scheduler (Fredrik) ** Framework needs review ''Semi-Done'' ** Port tasks to use it ''Done'' ** Move code from interrupt context to prio0 * Move towards 16x16 maps with configurable bins per table ** Implement in firmware ** Adapt megatune / mtx profiles to suit firmware changes * Remove config.warmup_rpm[] and add back a single rpm multiplier for decreasing warmup enrichment at increasing rpms * Fix broken configs when updating Tasks suggested: * Make seperate v2 release and only support it for bugfixes * '''Displaying and logging all inputs''' ** Second WBO2 Channel * '''Compensations''' ** EGT based fuel enrichment (High power engines need a enrichment for cooling when the engine has been under load for a while) * '''Alarms/Status lights''' ** Alarms when lost or broken sensor signals detected ** Alarm when TPS is outside the configured range (with some mariginal), maybe add a 47k or so pullup so a lost signal can be identified (Currently floating) ** if possible, detect a broken MAP signal: the same method that we use for WBO2 nernst would work everywhere. It involves pulsing the signal through a big (10..100k) resistor from a 5V square pulsing and measuring the divided AC component. At high impedance (no signal connected) the AC component will be high. **Bits in realtimevars, presenting status for digital inputs and enabled WBO2 Tasks that have to wait until another release (Only put suggested tasks here): * MAT based ignition retard, 10 temp bins (the same bins we use for CLT) so ignition retard can be specified,that will offset the whole ignition-advance n[] map. The CLT bins temperature values can move from config (EEPROM) to flash, since they are never changed anyway. The MAT-retard can go to the same config positions. - I write here, how professional systems does it. They uses INJ and IGN correction(both advance and retard available!!) tables too. There are tables according to CLT, and MAT. Booth CLT and MAT bins shold be wider ranged, because theese functions often used to protect the engine. For example retard the advance 2 deg and add 10 percent more fuel at 110 celcius CLT(or at 70 celsius MAT). Serious engines could work up to 115 celsius or more CLT(coolant system under heavy pressure there). So we should increase the highest CLT temp that the genboard can realize at least about 125celsius, i think. And at the cooler CLT and MAT bins we could make to work the engine more good(for example -10 celsius MAT, it could have more advance, and more fuel too).I know this could be a very serious software project for us, but it could be great if the genboard could handle theese functions.- by FERO * a VERY simple deceleration fuel cutoff, a single MAP value.below that, no fuel is injected. Actually, the injpw calculation should be changed the j[]==0 means no fuel injected (currently the injopen is still applied in this case !!!). With this change there is no need for a MAP threshold in config to implement this cutoff.
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.