MembersPage/GunnarReynisson/AdvancedVEMS (2019-04-21 20:06:24)

Eventually VEMS will release new and more advanced hardware, hardware I think the current VEMSTune implementation wouldn´t be able to handle properly.

See linked PDF for my notes on organizing complex ECUs into more easily manageable user experience and user interface.

http://www.vems.hu/files/VemsTune/VEMS%20Advanced.pdf

I don´t think everything in that document needs to be exactly as it is there, but by following similar construct a more advanced VEMS can make itself more user friendly and more easily supported.

If you want any information on anything in Pectel ECUs let me know. I can provide screenshots of anything requested.


Consideratiosn about input and outputs for future VEMS

I think for maximum versatility and future proofing the base of the VEMS ECU should be so that each input or output selectable should be detached from a physical input pin, this allows for instance CAN channels(or other protocols) to act as analog/digital inputs, as would outputs be (apart from ignition/injection outputs unless the receiver has live crank angle measurements at its disposal).

This could be described as base software and application software layers in where the application software layer only deals in the mathematics and logics while the base software only deals in converting physical pin values and stream protocol values into engineering values to be put into the two layers interface.

Example Fuel injection pulswewidth direct to pin

Application software sends the value to the base software as Cyl1_Pw

additionally the injection angle is also sent seperately as Cyl1_Angle

  • Inputs are Cyl1_Pw = 6.3ms
  • Cyl_Angle = 360°

Other inputs are

  • Cyl 1 Injector = Pin 8 - In Base Software side

BaseSw takes care of WHEN to start pulling the injector circuit down and when to stop given that it knows the crank angle etc.

Boost control 2 methods

Method 1 & 2

Method 1

Base Sw :

Boost output is set as a physical pin, BaseSw calculates timing and actions the pin accordingly

Method 2

Base Sw :

Boost output is set as CAN out -

CAN Id = 0x45, 16Bit size, Byte 0-1, gain 0.01%/bit , offset = 0

Can message byte 0-1 is sent as 4000 >> 0000 1111 1010 0000

Whoever is the receiver will handle the rest from there.

Inputs

In the App Sw the values are just a engineering value and so the software is written entirely on engineering values and boolean logic

The App Sw wouldn´t need to care where the value comes from.

Base software acts as the source of all the analog channels to the app software.

I believe this methododoloy also allows faster updates to control strategies in the App Sw as the interface between the AppSw and BaseSw is already in place and might not need updating everytime there is an App Sw update. This also allows a big interface to be constructed between the two before some channels are even being used like, i.e. fuel injector gauge pressure doesn´t need to be used, but the "fuel injector gauge SENSOR" is constructed from the start and will therefor always be available.