VEMS Home Products Documentation Wiki Webstore
WikiHome ProjectPage DocsPage UnderDevelopment MembersPage SiteIndex RecentChanges Preferences
GenBoard/UnderDevelopment/FirmWare (2011-04-06 19:37:56)

This page lists some items for developers they can pick from

GenBoard/UnderDevelopment/FirmwareChanges is updated when some feature makes it into a release

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

(to choose between "WSpeed 1" and "WSpeed 2")
  • are you suggesting a configuration item ("static" setting) ?
  • or an mcp3208 analog channel based input switch that changes to other wheelspeed channel when activated ?
  • what is the usecase ? What is the other wheelspeed input used for ? Different wheelspeed signal for launch and boostcontrol ?

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