MEVD17.2 emulation in development

LamboLover

Corporal
Apr 6, 2017
238
242
0
Ride
Everything

Video for Dave, you do not have to be Dave to watch it.

It just shows a 10 second counter that waits for missing ethanol content from CAN and the fairly noticeable alert to the driver.

If CAN is resumed, I extinguish the CEL, but if fuel pressure drops or the engine runs lean, I leave the CEL on and a programmable limp until it is manually cleared or the DME is power cycled. Will test the limps a bit more tomorrow but they work at idle.
 

doublespaces

Administrator
Oct 18, 2016
9,303
4,331
0
AZ
Ride
2009 E93 335i
Fantastic! This information really only applies to tuners though, where as burble is an end user type of thing so it is expected for this to have less visibility. Nonetheless, the tuners will absolutely know how awesome this is.
 
  • Like
Reactions: LamboLover

bradsm87

Corporal
Dec 15, 2016
162
53
0
Fantastic! This information really only applies to tuners though, where as burble is an end user type of thing so it is expected for this to have less visibility. Nonetheless, the tuners will absolutely know how awesome this is.

Not exactly. These safety features will likely be something that end users purchase. All end users should be very excited for AFR and fuel pressure safeties. It's pretty dodgy that the DME without this mod just keeps going despite variances and/or issues.
 
  • Like
Reactions: 9krpmrx8

LamboLover

Corporal
Apr 6, 2017
238
242
0
Ride
Everything
Vacation done:
34119122_10156378065669337_3948075620864360448_n.jpg


Board prototyping:
upload_2018-6-13_16-30-39.png


Comms firmware:
upload_2018-6-13_16-31-0.png


DME:
1000 mile test on production intent firmware passed.
 

LamboLover

Corporal
Apr 6, 2017
238
242
0
Ride
Everything
35289476_10156399980209337_7823074847088443392_o.jpg

Latency matters, this is 15 times better than the usual CAN drivers on the ESP32. Don't want any slow ass interfaces, N55 is slow enough already ;) Y axis in seconds, x axis is showing almost 1000 CAN frames sent in a second and the time to get a reply.
 

LamboLover

Corporal
Apr 6, 2017
238
242
0
Ride
Everything
Small update: still awaiting hardware prototype, there was a change on the physical soldered link between the header and main boards and the EE has been busy.

Device firmware coming on very well. Writing ISO15765 controls that are robust and fast requires a lot of attention to detail to get the timing and multiple conversations that some flashing needs over multiple CAN IDs just right. Testing with two BMW and one VAG ECU on the bench as these cover KWP on CAN, UDS on CAN with extended addressing, UDS on CAN with normal addressing. Still to do the sleep/wake, over the air update, prototype hardware testing and work out how to get it to present itself over wireless (I prefer WiFi for robustness and performance over bluetooth, but station or access point on different types of devices, whether in range of home/work/garage/dyno/workship WiFi or out with just cellular access and tethering).
 

LamboLover

Corporal
Apr 6, 2017
238
242
0
Ride
Everything
image.png
Periodic timing command setup over WiFi to CAN.

This sort of thing can send "tester present" type messages autonomously, saving the flashing or logging app having to do it.

Some control units need this sort of thing to stop the session being dropped, and it may as well go on the hardware rather than travel regularly between the controlling device and the interface.

Watching the heap as the firmware grows, I have 200KB free heap with all tasks running. I detest memory leaks.
 

Attachments

  • image.png
    image.png
    52.4 KB · Views: 150
Last edited:
  • Like
Reactions: Jake@MHD

LamboLover

Corporal
Apr 6, 2017
238
242
0
Ride
Everything
upload_2018-7-10_15-48-51.png

Go on then, we'll have a variety of simultaneous periodic timed CAN events at different rates. 6000 of them a second.
 

Sbrach

Corporal
Oct 2, 2017
224
175
0
Ride
N55 DCT E82
PI has been proving to be a headache on S55 and N55. The scalar table is utilized by most tuners to remove fuel to compensate for the fuel injected via PI. Of course it is also used for ethanol compensation so it gets a bit convoluted especially since the PI is usually triggered by boost pressure rather than by load or target fuel mass. On top of that there seems to be limits to the allowable deviation from 1.0 before you get "misfires" and limp mode.

I speculated that the best approach would be a DI pulse width signal (preferably by cylinder) along with a percentage increase to the flow table for injectors. Then the math is simple to multiply the DI pulse width by a factor to get a PI pulse width that adds enough fuel to equal the flow we added to the DI flow table. Fuel mass would then be accurate in the DME even though PI is providing part of that fuel and scalar could be utilized strictly for ethanol content. The added benefit is that when the DME shuts off a DI injector the calculated PI pulse width would then be zero.

I don't know if there is an OTS PI controller that can do this but assuming there is would your hardware be able to output the injector PW values?
 
  • Like
Reactions: LamboLover

LamboLover

Corporal
Apr 6, 2017
238
242
0
Ride
Everything
Present OBD design has three pins left after CAN, K line, ethanol content, ethernet, tachometer/crank trigger. Two are outputs, one from 3.3V DAC, other through 9A low side drive. In the present form factor, there is not the space or thermal capacity for further high current outputs even if an extra connector were added.

External ignition/injector amplifier boxes are available reasonably or one can be built. 6 outputs in a different form factor.

You could output fuel mass or duration, DI/PI fraction on CAN and get three or six cylinders into one CAN packet.

Thought needed for when you would output new data and whether that one cycle delay between PI and DI is acceptable, because the PI fuel for a combustion event is mostly delivered before the DI waveform which is susceptible to change. Also multiple injections in DI complicate it.

It needs more thought. I certainly like many elements of it.
 

LamboLover

Corporal
Apr 6, 2017
238
242
0
Ride
Everything
Delving into memory and CPU usage on the ESP32. I was having a problem where if I had the ESP32 sending out regular frames on timers, but also dumping the entire CAN bus to websockets over WiFi, and accepting special commands from websockets that do things like dump memory and CPU usage to serial I was getting CAN Tx error frames from the ESP32. This was very disappointing because of all the work I've put into it to avoid race conditions and get strong performance. It turned out to be the mundane reason that I was powering the ESP32 from a laptop USB port. Schoolboy error that had hours of fiddling around thinking I had a heap problem, multicore problem, race problem or just a general John brain problem. Now all is sweet again with good juice to the ESP32. It is interesting to study the CPU usage - here the ESP timers are 3% CPU usage sending 3000 frames a second (but they cannot quite get that here because the bus is deliberately full). CANRx is receiving and processing another few thousand CAN frames a second (about 600 from a Bosch MED17 and the rest from Kvaser loading the bus), but also sending them all to websocket queues. I just cannot push it any harder.

upload_2018-7-17_11-44-5.png
 

LamboLover

Corporal
Apr 6, 2017
238
242
0
Ride
Everything
I'm deep in lwip networking with TCP/IP. Some latency issues to sort, but with large packets it is getting some impressive throughput for a microcontroller - nearly all of that is payload, so about 100 times faster than USB to serial link.

upload_2018-7-24_18-4-45.png