1.0.79

[mattias]

The pressure compensation with Alpha-N is only in 1.1.x firmware, and only above atmospheric.

Hope to stabilise that with 1.1.54 or is it 1.1.56 soon to be released. VemsTune even seems more solid now, Emil has been visiting the developers and made some progress.

[Sprocket]

The pressure compensation with Alpha-N is only in 1.1.x firmware, and only above atmospheric.

Hope to stabilise that with 1.1.54 or is it 1.1.56 soon to be released. VemsTune even seems more solid now, Emil has been visiting the developers and made some progress.

Changelog and 'FirmwareChanges' on the wiki state Baro correction since 1.0.19???? :-\

I am very surprised that there is no propper barometric compensation with Alpha N. Simple MAP sensor in free air measuring the barometric pressure air temp and air pressure gives density and therefore a correction can be worked out. The world is not flat and it rains a lot. :-\

Speed desnity it doesnt matter anyway as the map sensor is being used and compensates for barometric changes.

since 1.0.19:

   * added full power shift cut, with configurable spark and/or fuel cut
   * baro correction updated to work in the new non-lookup scheme; baro value to megatune is in real kpa now
   * baro/kpafactor table lookup is no longer supported
   * if MAP multiplying is configured, only used for RPM >= config.hybrid_rpm_m
   * added tach output supporting funcionality
   * new per page read and write serial commands were added to fix the megatune trashing config bug
   * old non-compat megatune commands were removed

[[email protected]]

As far as I knew the Baro correction works fine on AlphaN ???  I've been told that Air temp is factored in to the fuel calcs on AlphaN too.

[Sprocket]

Covered over 1200 miles this last week and only a few niggles. Well only one actualy.

Dual switching tables seems to be a problem. I canged the VE table to correct a spurious value right in the middle of cruse. It was a blatently obvious error in the table. Table was burned to ECU and MSQ saved. car was left over night, started in the morning and this spurious value was back!!. This was again corrected, and everything was fine. The following morning this spurious value was back !!!

It was at this point I configured the conf switch to 00 to dissable it and the problem dissapeared and I have had no trouble since.

Now then. I have a good idea why this happened. Prior to this last week, I changed the ignition coils to the ones I originaly was having problems with, but dramaticaly reduced the dwell times. This worked at first but then the ignition fuse blew again,after a good few hours driving. With a dwell of 0.5ms and crank added of 0.25ms, it still blew the fuse, eventualy. I wont be going back to those coils! anyway, during all this, I loaded a previous MSQ to switch back to the reliable coils, but I think I may have loaded the wrong one whith the wrong conf switch setting, which matched the other config on the opposing conf switch setting. This I think confused Vems, not knowing where to put any new changes, so it does not actualy burn them to memory, they are however in volatile memory.

I had it working, and now it doesnt, and the point at which I can trace back to was when the fuse blew on the coils and the MSQ was loaded.

Some research time in the next few days to prove that theory ;D