## ## ##### ## ## ## ## ## ##
_ _ | \ | | | \| | | . ` | | |\ | |_| \_|
_ _ ( ) _ ( ) | | ( ) | | | | | | | | | (_/ \_) | `\___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: '''This page lists some items for developers they can pick from''' * GenBoard/UnderDevelopment/FirmwareChanges is updated when some feature makes it into a release ** normally added to VemsTune Help also ** sometimes (eg. for serious features ~more than 2 lines) good to split to separate page, like GenBoard/VerThree/FlexFuel and only link from here. ---- * ''' Multiple sparks during cranking and idle ''' given that 1000rpm takes 120ms, its easy to allow multiple sparks during idle and cranking for fuels like E85 and as well as improving combustion. 1000rpm = 120ms , each ms is only 6 degrees. So a 2.5ms charge is only 15degrees, so 2ms wait time and then re-fire will allow 15deg at idle to re fire at just -12 deg ATDC which can help with idle combustion. ---- * '''Electronic Wastegate control via H-bridge output''' I believe this is needed as '''electric''' wastegates are common place and use H bridges to operate. Currently I can see that the one I have worked with (1000Hz found in many BMWs, Hondas, Mercs etc... more exact model, actuator partnr, Ohm or current measurement ?) operates like '''dual solenoid Vanos essentially''', tight deadband straight into full force opening and closing, very accurate and has a '''feedback sensor'''. * Base duty = '''target wastegate position''' * Final duty = Base '''+ PID''' ** Very easy to tune. ** the VEMS v3 fw PID boostcontrol works like this (Base + PID). The resulting PWM signal can contol an H-bridge, similarly as in [http://vems.hu/vt/help/v3/v3_electronic_throttle_control.html ETC]. ** However, the back-n-forth signal of dual solenoid BMW Vanos is different (number of outputs, and semantics: they are "direction output", so PWM is not applicable). Naturally, H-bridge (if 2 inputs are exposed) can be controlled from 2 outputs of course. * Important: the PID can be calculated from MAP, or from the wastegate position feedback (which most wastegates lack, but these provide). ** So "PID with MAP target" or "PID with wastegate position target" would be more descriptive. ** they are not "isomorph" (not just small config or signal choice selection): The latter has +1 PID controller involved (and to be tuned). ** however, both PID seem incompatible with the 2 direction signals similar to the "BMW dual solanoid Vanos" ---- * '''Misc Output Hysteresis: Implemented (fw 1.2.38)''' Lack of a hysteresis on Misc 1 and Misc 2 outputs => was not very suitable for some apps * eg. Activating Water/ Methanol injection above X MAP, Misc 1 output causes flutter of the solenoid at the activation point. ** We are using this on a 1100CC 'suck through' supercharged engine without an intercooler and boost set to peak at 12psi. Charge temps would rocket into the 80's but the addition of water/ meth injection keeps it well below 50c. with Primary activation point above 80% TPS, We tried secondary activation point on temperature on the dyno but the solenoid was on and off as the MAT changed. On the dyno steady state, MAP activation causes the solenoid to flutter at the activation point since boost is directly linked to the RPM. On an acceleration ramp the solenoid flutters only as MAP passes the activation point. Introduced settings to configure a hysteresis in Misc 1 and Misc 2 on '''MAT, MAP or RPM'''. * or time based ? (time based hyst currently not configurable) ** minimal time for ON, OFF states ? Any idea what would be suitable for the solenoid ? 200..400 msec ? * RPM-only hyst would NOT help IMHO, because small MAT or MAP fluctuations would still cause output ripple. Hyst would be needed on ALL of them. Appr 200 RPM, 4 Celsius, 4kPa between upper and lower points sound suitable though. **In our application''' we only need hysteresis on MAP''' but the more the merrier. ** note: (next time) provide both vemslog+annotation for any such request (so new implementation can be tested against very similar conditions) ---- * '''Limp mode''' (fphil - Mostly to open the subject) - When to go to limp mode? - Which limp modes ? Per ex. one case to jump to limp mode could be when primary trigger and secondary rigger events go out of sync. The following limp mode could consists of: engine stop, engine resync ignition advance set>0, boost=0 etc ..; this in order to protect the engine and not to be stuck in the traffic. One may think to some other cases ... ---- * '''Turbo Speed Sensor - and protection''' Jason has had requests to implement a turbo speed sensor strategy ** It's acceptable to convert the frequency based TSS to a 0-5v input. Jason is working on a circuit for that. Three things needed: ** A way to set Analog Input X being a TSS ** A way to calibrate the TSS analog input to turbo rpm ** An adjustment strategy so if the turbo RPM hits a specific value, take action, such as decrease WGDC a certain amount to slow down the turbo. ** Background: Large Borg Warner EFR turbos have exploding turbine wheels at their advertised speed limit. This has been proven in dyno tests at Iroz Motorsports. Implementing a protection strategy will save thousands of dollars. ---- * '''A / B map switching alteration from VEMS forum''' I would like to share my thoughts with how VEMS does its A / B map switching, as I understand it every calibrate-able value is in both configs. I think we should re-consider how VEMS does this as the current setup wastes precious map space with values that never change between configs, things like injection and ignition setups, crank, cam setups, wideband settings, ecu calibrations, sensor calibrations, idle control settings, outputs etc. Things that should change with map switching are : fuel tables, ignition tables, lambda tables, boost control tables, variable cam targets etc. I don´t know how much space there is to work with in total, but I feel we are wasting alot of if, I´d personally rather skip all map switching and put in more anytrim functions or incorporate them as standard functions. Thoughts? ---- From VEMS support forum. Currently VEMS allows a few analog inputs to be setup for logging purposes, none of those are usable for control , however the trouble is that they can all have the same name, like oil pressure, however oil pressure is not selectable as an input into log viewer, you will have to select the calibrated analog channel you are using, however it still only refers to the analog channel (ADC cal. CH0), the channel name should be Oil Pressure 1 or Oil Pressure 2 and so on. When a channel has been selected for one analog it cannot be selected for another. I feel this needs proper setting up. Also I think Vemstune should show you the curve you have created to the right on the analog calibration channel window so you can visually see the results There is also a fuel pressure channel that is not possible to set to as an input. So why is it even there? ---- * '''IAC Alpha-N Load Compensation''' This would be more ideal if the % value started at the IAC highest temp value, i.e that value can be considered "closed" Most IAC setups operate around the 30-60% mark, many IAC valves also dont have a linear flow to opening duty cycle correlation, thus having anything in there even at min settings will make the lowest TPS value be higher then 1%. So maybe this can more like % increase in TPS based % increase of duty cycle from baseline at highest coolant temp? Has this been picked up or disregarded?? ---- * '''Fuel Pressure feedback & failsafe''' MembersPage/Sascha ** Using fuel pressure sensor to actively monitor and compensate for primary fueling (inj pw). Using this we can compensate for failing FPR (lost boost reference/clogged lines/etc) or weak/failing fuel pump(s) (especially on multi-pump scenario). **Also fault monitoring/threshold for boost reduction/check engine light/full ign/fuel cut if set threshold is passed (optional). **Similar to this implementation from Pro-EFI > http://www.spracingforum.com/forums/showthread.php?28-ProEFI-Fuel-Pressure-Compensation-Review-Video ---- Actual '''1.1.8x''' feature brainstorming (features that are not sufficiently clarified yet, or not decided if/when they can go in) * Boost Control "Speed input selector" ** to choose between "WSpeed 1" and "WSpeed 2" in config (like in the Launch Control dialog) ** driven wheel wired to "Wheelspeed 1" (done this way on MANY installs), and now that we have a "Wheelspeed 2" input, I wired a car using "Wheelspeed 2" as the non-driven speed. The boost control is working from the Driven wheel, and I want it to use the non-driven wheel - without having to re-wire the cars. We are using the Rear Wheel Speed (non-driven) to control the launch RPM and the Boost (Using simple refDC per Wheelsopeed), and we are using the Front Transmission (Speedometer Sensor) to log the Front Wheel Speed and wheel spin (FWD Drag car) * FW Issue - it seems that with 1.1.88 fw, the '''WheelSpeed 1 input is now "spiky"'''. I will email a data log to show this. ** If you have SD-card, and '''enable "triggerlog format" in SD-card logging menu''' (available since 1.1.89 when "GPS data to SDcard" was implemented, please use 1.1.94 to capture), than publish the saved SDcard... .vemslog and .triggerlog files (zip them, don't forget to send both). This is invaluable help to diagnose/reproduce your wheelspeed pattern (is it possible that it might be uneven pattern ?) * another 8x1 table enrichment(analog_input*configurable_const - MAP) or enrichment (analog_input). The absolute_ ** the MAT/TPS could also be more generic if some other input could be used instead of MAT (than the in-flash MAT enrichment could be applied, or configurably none) * Add settings per gear for 'boost valve off until X pressure' ** How would it be configured? Why isn't 116 kPa good in all gears ? * Gear indicator flickers to next gear when crossing 5000 RPM effects boost DC settings. Can more filtering be applied? ** likely misconfigured gear-refspeed table. As usual, vemslog makes it possible to help (without vemslog chances to help are significantly reduced) ** Check your refspeed versus the speed sensor gear settings. The gear indicator for me has been rock solid. KevinBlack ** Something was noted around 1.1.84 about filter changes on speed input, my sensor used to work much better than it does now. Seems as though other people have the same problem? *** What Fw version do you use? Can you send .Vemslog (possibly via VemsTune / Help / Vems Sharing Center)? **** Here you go, thanks! http://vems.hu/vemstune/sharingcenter/reports.php?cmd=view&key=wWgosL * For speed 1 & 2, and there also be a selection for input? Such as clk & data from ps2 for those using the ps2 cable for inputs. ** Wheelspeed 1 is on ps2 clock, but wheelspeed2 is on processor SCL pin, check InputTrigger/WheelSpeed *** I see this, but was wondering if there could be an option to select other pins. *100% scaleble analog input curve **For example, instead of fixed voltage scales against configurable temperature scales as in Analog Input Calibration 'Custom Temperature Curve', what about configurable voltage scales also? 'Custom Sensor Curve' is not very versatile, as it only seems to be dedicated to temperature. ***Reason. I propose to use a freely available Bosch MAF sensor on the tubocharger compressor inlet. Adding MAF sensor on inlet tract of compressor is simple. MAF against MAP will then give compressor speed and efficiency when plotted on the compressor map. Some Bosch MAF sensors have good documentation giving good scaling data that will allow for a fairly acurate measurement. with this I would determine compressor efficiencies without the need to use expensive turbine tachometers or calculating BSFC then working back from dyno hp readings, which we all know can be optimistic. Sprocket ***I have just bought some extra large graph paper to plot out the MAF curve at 0.01v and kg/hr per milimeter graph. The MAF I have chosen is a 640kg/h unit so that'll be 0.5 x 0.64meter graph! I can then extrapolate the air flow values accurately against the fixed VEMS sensor curve volts, job done. Just seems a bit archaic. *'''Limp Home Mode''' A value substitution for CLT and MAT sensors when either is open circuit or dead short: It was exactly like that originally (many years ago) but in Russia when it was extremely cold, it happened to trigger the "open circuit" (5V) value ... bad ! ........Does anyone start or run an engine below -30c CLT? Does anyone run a warm engine with less than -30c MAT without pre heat? If so, must be a small minority in relation to the majority who could benifit from this feature. It could be disabled in a similar way as Baro correction? ** You can already fill this in the sensor calibration dialog, just fill min and max values with what you like //Emil ** CE light is now an integral part of all late firmware but lacks this worth while feature. Activating CE light at 0V or 5V would not hurt.............but does nothing to help get you home on its own. **A simple fixed value in firmware should sufice, activating the warning light. OR, Suggested warning light configuration points for both CLT and MAT are Min/ Max values outside of which a configurable 'limp home' value will be substituted. Suggested substitution values as taken from Rover MEMS documentation (Rover LOS, Limited Operating strategy) http://www.gomog.com/allmorgan/RoverPlus4MEMS.pdf are 60c for CLT and 35c for MAT. Obviously this is never a perfect solution, never will be, but then neither is a dead sensor. It might be the difference between a ride home on the back of a recovery truck though (or if someone sees CLT value on LCD, android or VemsTune, than from VT with the 17 point curve a default value can be applied or a resistor inserted in the sensor connector)....... So i have to carry either a laptop around with the car or have a special plug or resistor that will get lost, just on the off chance i'll need it if a sensor just so happens to fail? **How do OEM's fulfill this requirement? **I'd expect some sort of simple proving logic. If CLT is similar to MAT, CLT and MAT are valid, even if CLT and MAT are similar at 'fault' value > use sensor values, if CLT is greater than MAT and neither are at fault value > use sensor value. If MAT is greteater than CLT and CLT is at 'fault' value > use substitute value. If CLT is greater than MAT and MAT is at 'fault' value > use substitute value. Obviously there needs to be some sort of hysteresis applied. **MAP needs to be included, but with no substitute value, rather 'cut' engine since no substitute value will alow engine to run to any drivable degree. Dangerous for engine. How do we determine if MAP has failed? '''Traction Control''' * Traction control to reduce transitional loading of transmission on high powered cars, particularly with turbocharged engines. ** real life case scenario. Wide sticky slick tyres on a car with a high power to weight ratio. Stress on drivetrain components as traction is suddenly lost then regained. Traction control is significant enough to completely eliminate driveshaft and CV joint failures that were otherwise common place meaning finishing a set of racing laps nearly impossible. *** Competing product Emerald M3DK6 successfully implemented a Beta version of traction control on a friends car in the case scenario above with outstanding results. A video of this car in action for those who appreciate pushing the boundaries. http://www.youtube.com/watch?v=SyFlhYnS4G4&feature=c4-overview&list=UUvulpGCeHRDdmBr_w3ZvXZA You can hear the traction control in action as power is applied out of the corners. This car is a Miglia spec classic Mini with the original design A Series 1.3 engine and transmission, 16v cylinder head and turbocharger. At 20psi boost this engine produces a modest 260hp and 240lbft, car weights 600kg and runs on 8" wide super sticky slick tyres. No surprise then why it breaks CV joints. '''Idle deadband''' (fphil) We have got already an iac_integral_deadband (1 RPM resolution) which is configurable. I believe there is a need for a deadband about the target on the total PID command as a last block before the command is sent to the actuator. The integral would be kept summing up in the deadband window. (comment) winding up integral inside while not sending to actuator ? In our experience that is asking for trouble, mostly fluctuations). (fphil) - added - you are right about the windup. In the case I thought we had got a very steady noise of known amplitude plus other tricks. Besides the ignition control by itself in the deadband could not be enough to zeroed the steady error. (-wrong-This is unarmful in the neighborhood of the target added and advisable to get the mean value at the target-wrong)-added-, (in my experience,but I do not know in our case what other component is in th PID control loop: filters, delay ...). Indeed for a noisy rpm and high P or D, the command is unnecessary noisy about the target and could even lead to instability due to phase lag. (comment) Do you have an example (vemslog) when iac_integral_deadband is set properly, but behavior would be ... instead. We don't understand how it differs from the existing iac_integral_deadband. It would be easy to freeze output (not even apply P and D in the deadband) but P doesn't really matter (the deadband window is small) anyway. Maybe you need a D deadband for the differential term ? (fphil) - For an example of an undershoot due to a non summing integral while in dead band see http://www.vemssupport.com/forum/index.php/topic,2231.0.html. - Why the deadband window should be small? There is the ignition control which works there in any case. - The deadband I told is the last block/function before the PID command is sent to the actuator. So it applies on the P, D and I action together - added - when I had stopped summing up, or on the P and D action if I is still summing up -added-. Of course when there is no rpm noise or if P and D is low, any deadband for PID control is useless. In the case of time lag or delay in the control loop, deadband on I can be useful. However it should be better to reduce delay and time - phase lag. ** To be specific. At time n, - modified -let PD(n) the total PD action, let D be the rpm deadband, my proposal is to set as last statement: *** if -D<E(n)<D and then PD(n)=PD(n-1) -modified- ---- '''Links - subpages''' * GenBoard/UnderDevelopment/FirmwareChanges/TestingAndReleases ** In the future we want first 2 number (of the revision: 1.1 1.2 .. 1.9 1.10 1.11 ... ) to be the "config" revision. The 3d number is for intermediate changes (MegaTune or firmware) that don't effect config. So anyone can easily know that 1.1.8 MegaTune should be compatible with 1.1.3 firmware. * GenBoard/UnderDevelopment/FirmWare/NextRelease specifies what tasks has to be done before we can create a new stable release * GenBoard/UnderDevelopment/FirmWare/LcdRelated '''LCD Related''' * GenBoard/UnderDevelopment/FirmWare/PowerRelated '''idle, ALS, launch and friends''' * GenBoard/UnderDevelopment/StagedInjectors '''INJECTOR_STAGING''' * GenBoard/UnderDevelopment/OverrunAndTipIn '''Advanced overrun and tip in handling.''' * GenBoard/UnderDevelopment/AccelerationEnrichment '''Advanced transient fueling method''' * GenBoard/UnderDevelopment/AlphaNIAC '''Coping with IAC position changes with AlphaN''' * GenBoard/UnderDevelopment/TemperatureCompensation '''Limiting the Knock Window based on IAT&CLT scaling''' * GenBoard/UnderDevelopment/FirmWare/MiscOutputs * GenBoard/UnderDevelopment/DigitalInputs * GenBoard/UnderDevelopment/FirmWare/MenuRelated * GenBoard/UnderDevelopment/FirmWare/SyntaxRelated * GenBoard/UnderDevelopment/FirmWare/ConfigRelated ** GenBoard/UnderDevelopment/FirmWare/DynamicConfigRelated * GenBoard/UnderDevelopment/FirmWare/AirConditioner * GenBoard/UnderDevelopment/FirmWare/CoolantTemperatureRange * GenBoard/UnderDevelopment/FirmWare/GPSrelated * GenBoard/UnderDevelopment/FirmWare/TriggerRelated * GenBoard/UnderDevelopment/FirmWare/KnockDetection * OnlineCourse/Modeling/Scheduler * GenBoard/LoggerIntegration * GenBoard/UnderDevelopment/CommToRound * GenBoard/UnderDevelopment/FirmWare/Settings discussion on how settings are retrieved and stored ---- '''Below is mostly implemented (OBSOLETE)'''. Feel free to delete any item that is implemented and reasonably mentioned in VemsTune help. ---- ''' 'features'' could be mapped to ''product'' in ofbiz ''' using product associations. * feature name * short description * long description * priority * state (wishlist, designed, implemented, tested, well-tested) * test documents * responsible person(s) * implementation file(s) * other data ---- '''Priorities:''' 0: unknown (may be urgent too) 1. light-wish 2. wish 3. strong wish 4. planned far future 5. planned near future 6. planned very soon 7. urgent 8. urgent bugfix 9. critical bugfix ---- '''Strategical list''' List of tasks that you can choose from if you want to join: Feel free to add new items, add your name if you feel like doing it (that '''does not mean others cannot participate'''), or start a discussion about them. * IssueReports * p=4 Add a time delay before engaging idle PID. Right now naturally falling RPMs will cause integral loading. Instead it should get time to land at the configured DC PWM and then use PID from there to adapt to changes in load. This is how other engine management does it and would work well. For bonus points we could remember the last PID value from when TPS changed (ie from when we left idle) and start there as a configurable option. It would be a very simple 'adaptive' idle, fooled only by things such as load change when not in idle. At least a good option for engines without A/C. * pri=4 Anytrim for idle target so that A/C compressor switch or fan switch can bump idle without needing an entire second config. * pri=5 independent tach output is done, but the divider will be changed to allow precise tuning and tricks like 6cyl tacho gauge on 4..5 cyl engines '''DONE''' * any mcp3208 input configurable for ALS / Launch input ** addition that inputs using the mcp3208 channels need a digital filter, low voltage = signal, high voltage = no signal, with shiftcut switch pressed, the function keeps reenabling all the time, even though the noise isnt visible on a gauge in megatune. My proposition is that high voltage(5V) for 100mS duration will be needed before reenabling, start with testing on shift-cut, where the problem is. I suspect the current implementation reenables shiftcut with one mcp3208 sample indicating high. //Emil * 2nd WBO2 channel * DONE: (since 1.0.45 firmware) for idle solenoid, if PWM period=0 configured, than we should revert to original extremely-fast softpwm behavior (instead of the nicely controlled period as now) * camsync and missing tooth-style multitooth (like 60-2) crankwheel for 4 cyl (working on 5 cyl, but not on 4 ;-) * pri=5 LoggerIntegration (MembersPage/RichardBarrington) * pri=6 overlapping dwell for direct ign (MembersPage/MarcellGal). * pri=7 ArmEfi (HW) * DROPPED: pri=7 ArmUfo (HW) used as lambda meter * pri=7 Lambda vout on OC3C, 10:1AFR=0% 30:1=100% (For Autronic Autotune) * pri=7 Input from professional lambda meters (1v per lambda) or Autronic format (AFR10:1=0v AFR30:1=1v) (For verifying our WBo2 application.) LSM11 curve is needed in table format (not unprecise drawing) * pri=5 DizzyBoard IonSense (MembersPage/KeithHargrove MembersPage/JörgenKarlsson) * pri=4 StreetDyno (using RPM, VSS, GPS), ChassisDyno (MembersPage/RedMist) * pri=5 MegaTunix handling the MSAVR variables (mcd) (MembersPage/RichardBarrington) * pri=6 OtherTuningsoftware (or compiling MegaTunix on win32) * pri=3 histogram of tooth-times to catch bad (inverted) install of VR sensor (33+1.5+1.5 instead of 34+2) and possibly other problems * pri=1 currently it's not supported to build a firmware with -D NOIGN. It doesn't make much sense, since ignition can be disabled in configuration. Only makes sense for special apps, that are short of flash. The pri=8 was a joke, I guess. * pri=2 WBO2 only builds with -D BENCHMARK set. This is known. * pri=6 Support for even tooth wheels (cam sync with multiple tooth wheels even) This will be needed for any Rotary with stock triggers and Hondas with stock triggers, probably more than that too. * pri=1 CEL Reserve and define an ouput for driving a check engine light. But what conditions should activate it (besides the 2 seconds or "until RPM found" powerup light-up)? ** Eg. if WBO2 Ri target cannot be reached (or Ri confidence low) for a significant time, we know that WBO2 is not functional. ** if WBO2 is working, and it shows lambda target cannot be reached. ** serious knock detected ** For dual-trigger applications the loss of one trigger can activate it ** I suggest using the ODBII fault codes: http://www.nology.com/OBD2FaultCodes.htm And why not override whatever is in the LCD display. Often the "end user" does not know how to "ask VEMS" using the standard tools. * pri=0 If using WBO2, NB02 output to fool vehicles own ecu. Maybe useful if original ecu still controls engine check lights, fuel consumption meter and so on? * pri=3 '''Cool Down Enrichment''' MembersPage/GoranJurkovic/DaewooLaNOS/GoingVEMS/CoolDownEnrichment Thing that every stock ECU has and it's needed for turbo engines! ---- Misc. '''smaller TODO items''' * generic logging functionality * we might want to apply ign_balance + advance in the mda.. command, so mda28 really means 10 deg BTDC (even with non-0 ign_balance). Now the user must consider ign_balance (most often 0 anyway when checking the base timing) * svn revision stored in flash. We update firmware_revision.h like "1.0.18" (without reusing numbers for release candidates) so this should not be badly needed. We have the compile date anyway. * a small branch in bin/make-...pl for canonizing config.txt and tables.txt: this will allow us diffing the result read back via ''mcd'' and whatever is in the config.txt and tables.txt files: see what changed, and catch config.mtt made with bad global.h revisions. * baro/dbaro should be done after table lookup * make the battery voltage measurement configurable (compensate for wrong voltage divider) * search_table(n) "on demand", no need to run it if say engine.coolant hasn't changed since last time. I say make it binary-search (log(n) steps) instead. (well, in case of coolant I guess a slow linterp without rx21 is still there...) * cranking pw decrease with time to avoid flooding * Injector flow bench: mxo (too fast?), mdp, duration * airden = airden_table[MATFACTOR] instead of seperate table? (We already have the MATFACTOR) * flash checksum * "lock" eeprom after flash update (don't do anything before special command is executed that unlocks the eeprom). Some suggest to park the eeprom pointer to a dummy unused location, so it's not pointed to the last used active data - an overcautios step to prevent corruption. I'm still uncertain about RC-type or the MCP809-type reset circuit options, either is possible. * lightweight sheduler so RS232 what_to_send() and rpmcalc,fuelcalc get higher priority than LCD and other inferior tasks * runtime configurable iac (enabling of stepper / pwm) * comm.c: VE_TABLE_FIX doesn't work as expected (?) ----- Some User request for the GenBoard 2.2-3.0 * '''N2O activate output''' DONE * '''Shift Light''' - Indicates the engine runs over a configured RPM, and driver needs to shift (1 bit output channel). Look similar to N2O output (which also consider TPS, and is DONE). * '''Spray intercooler''' - Power on/off the WaterInjection pump or the InterCoolers cooling fan, controlled by MAT signal (1 or 2 bit output) Needs a configurable output pin, like the WOT. See GenBoard/UnderDevelopment/ConfigurableMiscOutputs. * '''Two channels of working WBO2'''. For logging and LCD. ** it's not hard, just make sure the nernst samples are not repeated in SRAM. Now every WBO2_SAMPLING 's handler2k run, a nernst sampling is started. Every 10th msec. We want one every 5th msec, for the A and than for the B channel. The output variables need new SRAM space, but that's not much space. wbo2_sampling.nernst_sample_cnt MSB can show the actually used WBO2 channel. Basically jump from sampling one channel to the other very rapidly - from a resource standpoint of view * '''Use of both knock channels simultaneously''' * '''Use of BMW-type IAC valve''' as it's experimental at MembersPage/GergelyLezsak/IdleControl/Firmware ---- '''Michael's browsing through the firmware''' '''TODO'S''' ---- '''Ignition channel configuration''' How does '''bootloader''' handle inverted/noninverted igndriver? The trick is in ioinit.c: the initialization block is inside ''#if (defined __MEGASQUIRT_C__) || (! defined HARDWARE_PULLUP_OR_DOWN)'' So in the bootloader, the pins are left as input if HARDWARE_PULLUP_OR_DOWN is defined (so the PWM-ing SIL5 10k does it's pullup job). This has somewhat changed, since we always use the FETDRIVER_INVERTING. BootLoader pulls outputs high so real outputs are inactivated. For the ignition, we leave as the hardware reset leaves the ignition (off). Inverted ignition configured in software (ign_out=0x71) is not supported. Inverted ignition must be configured in HW. The '''h[2] configuration could be made more general''', there are 2 options: * like the h[0], allow more than one ignition channel to be fired simultaneously (without IGN_DUALOUT) * configure like other output channels in GenBoard/Manual/DigitalOut/Table (02 instead of 00, 32 instead of 03, 72 instead of 07, etc...) Both has some overhead, the second has marginal. As an extreme case, it could be configurable, which approach is used :-) ---- '''verify calculated edgetime_corr coefficient''' The visual gnuplot-linreg is OK, you can log WideBandO2 data to RS232 and verify with ''linreg.pl'' ---- pri=6 MUST-do sg. like this for GenBoard v3.0: '''configurable with tables''' (vs. compiletime). * injector: DONE (see h-table: 8 bit mask limits to max 8 independent injector banks) * ignition: simple for direct ign for non overlapping dwell Each sequential output (like inj and ign) should be driven this way: * engine cycle (normally 720 crankdegree) is splitted to N (N=7..0) channels. It is possible that primary injection has 8 channels, while ign has some other number (eg. 4 with wasted spark) and secondary injection (eg. water) has 2 channels. * the channels (at least the 1st) are synchronized to InputTrigger * the channel number points to the h[2] table, so the firmware knows where to look up the channels * I checked the i259 initialization code when ign_out=71 (for the common ign_out=70 it's tested thoroughly). It looks good. It seems to me that the hardware RC reset on the i259 is applied for too long: the processor reset comes too early, so for inverted semantics the hardware reset takes precedence. ---- '''This stuff is DROPPED for now in favor of an even simpler, still powerful scheme''' old port_act stuff for the curious: that particular channel to * switchoff/gopwm/switchon (for inj) or * init/charge_coil/release_spark (for ign) * alltogether 8 port_acts in a table for every channel: 2/3/3 for the above portactsets (this makes it possible to use very primitive atomic portacts) * the looked-up 8-bit portacts can be executed simply. Eg. 00 and FF are nop. These should ideally be referred from configuration with symbolic names translated by perl - otherwise we'll run out of space in the future. ignconf.c and injconf.c should be dropped (even more complex :-) : * only port_act part remains (simple, as outlined above) * ''following-action'' functionality will go to the tables (next channel -> next line) * condition will go to the IC3 handler (simply step the channelnumber and reset after the number of configured channels is reached.) * dispatcher only gets a 1 byte val_t, in which the action is coded: bits 6:7 selects type of action: ign/injprimary/injsecondary/ ... /special, bits 4:5 the off/gopwm/on (inj) or init/on/off (for ign) bits 0:2 selects the channel 0..7 (bit 3 is future) We can first write a generic handler that will use the lower 3 bits to determine the channel (tableline), later it can be unrolled for faster execution. Packing the bits in a better way could help gcc optimize well after unrolling. In each dispatcher() call up to 3 port_acts can be executed depending on the relevant port_acts read out from the table (00 bails out earlier, FF not!) as the 3 consequtive values in the relevant port-act config table. ---- '''(EEPROM) Storage related''' As you know (storage.c) we have all tables and config (that live in EEPROM) mirrored in SRAM. Config and h-table must stay in sram (or flash), so it is always available, even during EEPROM writing! (since it is used all over the place, including interrupts). However, we'll have about 9 (!) 16*8 byte tables (it only took to change 2 constants - one VE_SIZE_RPM in firmware and $elements in make_tables.pl - to get 16 RPM bins, but it requires some more testing), which is not marginal. * it would be nice to read from EEPROM * only have dirty lines in SRAM * the fuelcalc can wait max a few msec if the EEPROM is being written (for some ECM saving configuration data requires engine off). EEPROM write should only be allowed to start (it takes 8.5 msec) if the fuelcalc is not needed within 9 msec. Doing it right after fuelcalc is perfect at high RPM; simplest algorithm is to do a storage, than a fuelcalc and so on (needlessly too many fuelcalc at low RPM). Later we will need sg. like a debug flag, that enables writing these tables. So in mtt mode they will not be accidentally overwritten (misconfiguration of ''h'' table would change the behaviour fundamentally, but why is that a problem? ). '''Suggested names tables:''' * h for hardware, currently 3*8 bytes GenBoard/Manual/Config/HwMap large 16x8 tables (16 in the RPM, 8 in the kPa direction): * l lambdacorr target (already there) for WideBandO2 closedloop and learning (8x8 should be enough) * j VE (reference) table (formerly dummy fake-VE of traditional megasquirt) * v VE (reference) table for secondary table * p precision learnt VE (should there be 2 tables, one for each banks?) this is currently 16 bit (but only 8*8) * n ignition max ignadv map * w ignition knock adjust window (8x8 should be enough) * i ignition knock learned adjust * g lo(g) of knock history (knockcounts per loadsite): 16 bits would be better ---- '''TPS auto-calibration''' Allow engine.tps pull the (tps_low, tps_high) lower/higher. Trigger condition for reset (reset means let (tps_low, tps_high)=sensors[TPS],sensors[TPS]+1) could be: * dedicated menucomman * or special occasion (ignition on for 20 sec without starting?) * special values: tps_low=FF and tps_high=00 or tps_low=00 and tps_high=FF * '''my favorite:''' abs(tps_high-tps_low)==1 * Remember during implementation that tps_low >= tps_high is legal now, so direction must be preserved ---- '''ADC related''' * we have 10, or 12 (MCP3208) or more (using filtering) bits available * for most ADC channels the upper 8 bits are enough * WBO2 Ri calculations use 10 bits samples of the nernst input. * MAP calc uses 11 bits: in speed-density setup the VE value is multiplied with MAP. For a 2.5bar MAP sensor the readings (using only 8 bits) for 30 and 31 kpa would be appr. 30 and 31 (difference is 1 LSB) which is significant. With using 10 bits it becomes 120, 124 (4 LSBs), much nicer. I'm thinking of killing the ifndef WBO2 ADC setup, and tweaking the WBO2 ADC to work with non-WBO2. The sensor values must be accessed with getter functions get_sensor(x) (that can be inlined or macro-d), not like sensor[x]. (This will come very handy when the digital signal can come from other controllers later). Do we need the prev_sensor_reading[] array ? We can just do <code> // exponential decay: uint16_t t = get_sensor(x) + new_reading) >> 1; cli(); // needed on AVR because 16 bits set_sensor_value(x, t); sei(); </code> Note that the ''' ''getter'' should work the same way no matter the signal comes from a local internal ADC, MCP3208 or a combination of 2 signals (like cold-junction compensation signal of a K-Thermo comes from a different channel), or from network'''. We might want different getter-wrappers for different bitwidths (an 8 and a 16 bit getter, the 8 is needed so the upgrade is simpler, and 8 bit is actually enough at most places). '''Sampling freq''': We currently have 2 classes: * low priority (sampling every 8 .. 9 msec is perfect) * sampling a burst of one channel (for WBO2) once in a while (the other channels are not selected during this burst) We should finally have: * low priority (sampling every 10 .. 15 msec is perfect) * medium-priority (sampling every 5 .. 8 msec is perfect). This can be achieved with a sequence (maybe flash-defined) that has these medium-priority events multiple times. * sampling a burst of one (but it should be selectable!) channel (for WBO2) once in a while. Generic notify mechanism for observers (eg. the WBO2 calculations). Note that almost same would be used for uC-controlled hot-air-wire air-flow measurement. ---- '''can we kill the handler2k?''' * benefits: the number of read ADC samples (the main job of handler2k currently ifdef WBO2) cannot be decreased, but it can be done at a time when it is cheaper: when there is no conflict with scheduled events. * disadvantages * work amount any low priority maintenance task * that we can do from userspace, should go to userspace * that we cannot do from userspace (needs interrupt) should first check if there is an upcoming event scheduled. It would postpone its action for some time if there is, so not to delay the event execution at all. ---- '''do the timing from last possible tooth''' - AdvancedIgnition * trig2spark needs to be updated to give back the proposed engine.trigger_tooth and the (time or rpm_period) multiplier that need to be scheduled after it. * use engine.trigger_tooth that is coming from userspace instead of config.trigger_tooth * note: engine.trigger_tooth needs to be updated in a syncronized way (from dispatcher igndeact), such as the igncount that we got wrong last time :-) * possible to still schedule ignact (dwellstart) the very same way as now (from previous deact or some predetermined trigger). Optionally calculate another trigger tooth and delay from userspace (as trig2spark). ---- pri=2 * check if MegaTune can cause config corruption in the AVR * review comm.c compatibility layer I think megatunix is safe, anyone confirm this? yes. We couldn't reproduce the problem with the same genboard with another computer (and megatune). It seems the USB-RS232 converter caused the problem by making rare errors in the AVR => PC direction (bootloader was fine, although the bootloader moves very little info from AVR => PC : checksum only) ---- '''Trigger scaledown''' trigger should consist of only the following actions: * capture time * store time in buffer for userspace (=> flag userspace) * update phase * check a simple condition if it needs to schedule an action * if needed, calculate when to schedule with a simple multiplication and addition * schedule the required action This depends on userspace preparing an execution plan, sg. like: ignition should be fired n degrees after p-th tooth: in interrupt this means very simple condition (maybe it could also check if trigger frequency did not change drastically, or something...) and very simple calculation. ---- '''Flexible analog output''' ( OC3C ) An analog output (maybe external GND referenced) should be easy to configure. Could be configured as MAP,'''WBO2''', NBO2, ignadv, injpw, RPM etc... This would allow * relatively fast, hackless diagnostics without LCD and notebook (only DVM and PS2 is needed). * more importantly it would allow proper logging with inferior (read: most) dyno-s. With many dyno-s the only way to identify log-sections is via logging external analog signal (besides hard paperwork of course). Eg. if one is tuning ignadv (setting fueling is fast with GenBoard/VerThree lambdatarget feature) he wants to know which power-log belongs to which ignadv setting. '''The WBO2 output is high priority at least''' Someone please make sure the most used curves are linked near from GenBoard/Manual/WBSensor''' ---- '''See also''' * A good collection of subroutines, eg. I2C: http://hubbard.engr.scu.edu/embedded/avr/avrlib/ We should probably contribute at least pid, softpwm and eventqueue. ---- User Suggestion Firmware version 1.1.58 onwards suports Fuel trim in N2O settings. Perhaps this could be further enhanced by introducing scaled fuel trim. Monitoring the cylinder pressure with a transducer or just a manual potentiometer mounted on the dash. Simple linear scaling of fuel against analogue input voltage. This would be a far more useful function as Nitrous Oxide systems calibrate the Nitrous to fuel ratio by fixed oriface jets. Cylinder pressures change with temperature resulting in a change of the N2O/fuel ratio. While it is favourable to run Nitrous systems in the very rich areas of engine operation, any change that results in a richer still condition can introduce rich missfire, and like wise, any change that results in a leaner condition could end up potentialy damaging to the engine. Suggested pressure transducer http://www.noswizard.com/product_desc.php?id=154 Suggested config settings Input channel No Fuel trim volts Full Fuel trim volts No fuel trim enrichment (biased at 100% for zero fuel trim) Full fuel trim enrichment (biased at 100% for zero fuel trim) This should be restricted to trim only. Base Nitrous tuning should be done with the Nitrous system Jets I run a small 1275cc engine with 100bhp normaly aspirated. I now have a 50hp hit of nitrous ontop and suffer with rich missfire when the ambient temperatures are low. There is no suitable jet to remove only the required fuel to move out of rich missfire and I have to trim the fuel with Vems. This means connecting a PC. * Instead of correcting fuel to changing environment, nitrous supply could be corrected to temp/press changes for a constant and predictable power (and mixture). If you are playing with a WON system PWM-ing it is a good alternative of stages and jetting. I'll do a review on such experiments soon (GergelyLezsak) ** Yes I use a WON system with no heater. Kits are sold as such and its not the end of the world. I am currently looking into the PWM'ing of the solenoids as I had previously suggested in NitrousController near the bottom. I am aiming to ramp up to 100hp over rpm, making life easier on the gearbox which is already stressed as it is. However, after asking on the WON forum about the flyback voltage, I have decided to use a SSR between Genboard and the Pulsoids. WON reckon the flyback voltage to be 1kv at last testing. I have IGTBs fitted instead of FETs, but even those only have a transient voltage clamp of 420v. The SSR would isolate the transient voltages and also is more suited to the high current of the pulsoids. ---- '''ADC linear Scaling, and ADC=>nonlinear curve for logging''' This can be done in VemsTune or MegaTune since ages (traditionally with 256 point curve stored on the PC). Now there is a small '''permanent storage area inside the ECU''' that vemstune can use for whatever it wants (does not effect control in any way). This makes it possible that any config (or runtimelog saved with VemsTune, since that includes config and tables ) "remembers" these analog calibrations so they need not be stored separately (on web, or on PC, eg in. dedicated vemstune directory). * ADC linear scaling ** VemsTune: add gauge, see ADC raw and ADC calibrated channels (8 extra ADC) ** values can be calibrated in dialog (one-by-one, or all at a time with "import" or '''drag config file to dialog also imports relevant settings''') *** new (2010 Jan) VemsTune freezes these values when changed, so they do not get overwritten from the config found in the log during log playback. This is helpful when log was captured with uncalibrated or badly calibrated values (which happens in practice, eg. sensors calibrated or recalibrated later) Similarly, * the same storage area can be used for 1 or 2 channels, but nonlinear curve ( simple 8 or 10 point curve scaling table for one or two analogue input chanels, like extra temperature, position or pressure sensors). ** If it's not enough for a special fully instrumented engine, you can just store these curves on the PC (and patch any new vemstune). * recommended dialog: ** ADC Channel Select ** X axis: ADC Volts ** Y axis: sensor Value ( temperature, pressure, position, whatever) ---- I can source '''linear pressure transducers''' with low enough scale for fuel pressure, and high enough for oil pressure. http://195.159.109.134/vemsuk/forum/index.php/topic,358.0.html ---- '''LCD Page/layout change request''' - MembersPage/Sascha I am proposing a more "efficient" use of LCD pages while at the same time offering the ability for the end user to configure the LCD output without the need of a FW/code rewrite. I've noticed in the recent FW's that a few pages have a clean layout of approx 8 unit outputs w/ decent room for pretty much any variable. But users are still restricted to the variables that the FW creators think the page should display @ the time of compile. I suggest the reduction of the number of pages, maybe only having 2-3 pages but with user configurable variable slots very much like afreshtiny. That way the user can select the variables to be shown in the 8 slots of his liking via VEMStune, either predefined or from raw values or even values with applicable multipliers (ie. AFR instead of Lambda for example). Icing on the cake would be the ability to use an analog input to connect a button to have the LCD switch between the 2-3 pages in a loop just like afreshtiny as well. Not sure if this is possible though as I know a power cycle is needed when changing pages currently. ---- '''PWM Cooling fan output feature''' - MembersPage/Sascha Would like to suggest that there be a PWM option under the cooling fan output. '''Coolant-fan output driver''' * directly PWMing an INJ output ? directly driving from injector or ignition output would fry the output (and traces, and connector-receptacles) for almost all fans (except maybe a small 5-10A coolant fan, perhaps on gokarts ?). * Relay is not suitable either. * 60-100A (< 6 mOhm ) TO220 PFET or NFET with cooling fins and a giant flyback-diode ? ** IRF1405PBF (IR) N-POWERFET 55V 169A 150W Rds<0.0053R (TO-220) AUTOMOTIVE ** IRF3205ZPBF (IR) N-POWERFET 55V 75A 170W Rds<0.0049R TO-220AB (TO-220) ** IRFP064NPBF (IR) N-POWERFET 55V 98A 150W Rds<0.008R TO-247AC ('''TO-247''') ** IRL7833PBF (IR) N-POWERFET-LOGIC 30V 150A 140W '''0.0038R''' (TO-220) ** IRL2203NPBF (IR) N-POWERFET-LOGIC 30V 100A 130W 0,007R TO-220AB (TO-220) ** IRL3803PBF (IR) N-POWERFET-LOGIC 30V 140A 200W 0.006R TO-220AB (TO-220) ** P-FETs are rare with Rds<0.02 ... IRF4905PBF (IR) P-POWERFET 55V 74A 200W 0.02R TO-220AB (TO-220) * or a low power output when controlling a fan controller like a Temic unit or similar, eg the "600W Temic unit2 as mentioned below Simple 0-100% base DC table similar to IAC should do the trick. * 0-20% is likely just calling for trouble * maybe min 30% (possibly 100% kickstart for 0.26-0.5 second than back to 30%), than up to 100% as temp increases by about 8C ** what would be a reasonable frequency ? *** 100-250Hz seems fine on the ~600W Temic unit usually mounted on new BMW and Mercedes cars - In my experiments ~10% duty is the slowest when the fan starts, and 75% is the maximum. The response is not linear in-between. These have computerized control; below 10 and over 75 the controller simply stops the fan. Doesn't respond to soft start/stop or "kick in" signals. Test video here: http://www.youtube.com/watch?v=BHmlr1JMqt0 ---- '''Feature Request - ON/OFF VVT mapping under camshaft control''' - MembersPage/Sascha I'm thinking it would be nice to be able to more accurately map even on/off style VVT by using the actual Camshaft Control tables under Motorsports group... but with a simple option of 0 and 1 (off and on) in the MAP/RPM table, and a non PWM option in the setup page. Right now using Misc 1 to control VANOS is just ok, but being able to map VANOS more like a stock ECU would be much, much better obviously. Is this not already possible by selecting extreme ends of the angle range? I.e the cam is idle at 200° and advanced at 212° , so in the map you put in 190 for idle and 220° for advanced, the ecu will then simply switch on the single wire output in an attempt to achieve those targets? Of course that requires camsync, so I do agree with Sacsha that 0/1 should be implemented, and the switch point is the perimiter value. i.e if 1 is at 3000rpm and 50% throttle, and next axis value is 3000rpm and 60% throttle and that value has a zero the switch point should be 50.1% and not 55% or 59.9% - GunnarReynisson ---- 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.