VEMS Home Products Documentation Wiki Webstore
WikiHome ProjectPage DocsPage UnderDevelopment MembersPage SiteIndex RecentChanges Preferences
GenBoard/UnderDevelopment/FirmWare (2017-09-02 10:39:00)

This page lists some items for developers they can pick from

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) 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.

Lack of a hysteresis on Misc 1 and Misc 2 outputs => was not very suitable for some apps

Introduced settings to configure a hysteresis in Misc 1 and Misc 2 on MAT, MAP or RPM.

(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 ...

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.

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?

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??

Actual 1.1.8x feature brainstorming (features that are not sufficiently clarified yet, or not decided if/when they can go in)

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)

Traction Control

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

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.

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.

Misc. smaller TODO items

Some User request for the GenBoard 2.2-3.0

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:

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).

Each sequential output (like inj and ign) should be driven this way:

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

ignconf.c and injconf.c should be dropped (even more complex :-) :

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.

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:

large 16x8 tables (16 in the RPM, 8 in the kPa direction):

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:

ADC related

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\n

// exponential decay:
uint16_t t = get_sensor(x) + new_reading) >> 1;
cli(); // needed on AVR because 16 bits
set_sensor_value(x, t);
sei();

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:

We should finally have:

can we kill the handler2k?

any low priority maintenance task

do the timing from last possible tooth - AdvancedIgnition

pri=2

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:

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

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

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).

Similarly,

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

Simple 0-100% base DC table similar to IAC should do the trick.

- 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