MEVD17.2 emulation in development
- Thread starter LamboLover
- Start date
Deliberate glitching by playing with the connection detected by quality < 100%. Ethanol reading stays steady.
I am using a simple filter that removes records with implausible changes and reports the percentage that are plausible. It seems to work well on the bench for deliberately poor connections that get moved.
Also depending on how the often the processing task is called it averages all the valid readings that have been buffered since it was last called.
I am having trouble with the 64 sample hardware buffer if it is allowed to fill up to the end it cannot be reset, and it is not documented how to do it and various guesses have not worked. However, something would be very wrong if there were more than 64 samples in say 10ms.
Also depending on how the often the processing task is called it averages all the valid readings that have been buffered since it was last called.
I am having trouble with the 64 sample hardware buffer if it is allowed to fill up to the end it cannot be reset, and it is not documented how to do it and various guesses have not worked. However, something would be very wrong if there were more than 64 samples in say 10ms.
Worked out the reset, pushed it to 83KHz to make sure it is happy. I have another application for the timer module that runs at 8KHz - anyone guess?
Do you make some timing guesses to prevent the buffer from filling up? I assume when you reset, the whole buffer is lost?
Hopefully some sort of sequential supplemental injector control as you hinted before, but I have no idea how much bandwidth that would require. How big are each of your packets?
For up to 200 Hz signal the task is at 200Hz to aim to process a buffer with only 1 sample. If there are 64 samples that fill the buffer in that time, it is detected and I have it attempting to reset the timer up to 10 times before giving up and showing an error that advises frequency input to be removed. If resetting I could use the buffer contents, but safer to discard here as ECU can use last good sample. There is a hardware filter that rejects small pulses but it has a maximum of 255 ticks at 80MHz so just over 3us or over 300KHz.
If this was a crank tooth feed, which is the other application for combustion analysis (from crank acceleration), PI etc it would need different handling.
Last edited:
This is exciting for me. 7BC is the CAN ID of the microcontroller sending flex fuel packets to the DME. 7BD is the DME replying with the same info (just for testing).
It is little endian, so 0x00B1 is 177 which means 17.7C fuel temp. 0x014D is 333 which means 33.3% ethanol content. 01 means 1% buffer use. 0x64 is 100% which is the quality of the pulse input.
I have considered virtual flex fuel but am concerned that it is mainly applied to engines with relatively low specific output.
Playing with web sockets over WiFi. Getting 700 packets per second with 120 byte payload each. Working on implementing larger payloads as want to find the limits before scaling back to something super stable, but this will be good for high speed datalogging - the present state of the art is every time a spark plug fires you log a row of data (350Hz at 7000 RPM on a six).
Edit - increased to 4096 byte payload per packet and 300 packets per second
It does not get more throughput if I go to larger payloads. 4095 bytes is the largest UDS packet anyway. Way faster than needed anyway.
Edit - increased to 4096 byte payload per packet and 300 packets per second
It does not get more throughput if I go to larger payloads. 4095 bytes is the largest UDS packet anyway. Way faster than needed anyway.
Last edited:
Bytes 6 and 7 are unused here. DLC gives the length of 8 bytes, you can do 0 to 8 with CAN.
ISO 15765 is used to form payloads of up to 4095 bytes by using multiple CAN packets, but it is not used in this example.
I have also been working with the microcontroller to handle TCP/IP frames that are fragmented into frames larger than 1500 byte MTU.
ISO 15765 is used to form payloads of up to 4095 bytes by using multiple CAN packets, but it is not used in this example.
I have also been working with the microcontroller to handle TCP/IP frames that are fragmented into frames larger than 1500 byte MTU.
Lots of issues fixed with TCP segments, queues, memory allocation, interrupts blah blah blah.
Result is what seems to be a robust WiFi to CAN that can fill the CAN bus without any dropped frames. Sounds like a minor point until I realised that most CAN interfaces, wired never mind wireless, seem unable to do this and rely on going slower or heavily filtering out stuff they don't want. It is transferring data 2000 times faster than a typical ELM327 clone, and 160 times faster than the best ones based on the STN chips.
Result is what seems to be a robust WiFi to CAN that can fill the CAN bus without any dropped frames. Sounds like a minor point until I realised that most CAN interfaces, wired never mind wireless, seem unable to do this and rely on going slower or heavily filtering out stuff they don't want. It is transferring data 2000 times faster than a typical ELM327 clone, and 160 times faster than the best ones based on the STN chips.
So, are you saying this external controller will be hooked up to the OBD port? Or that you want to communicate with something on the OBD port at this speed?
Yes, it goes into the OBD port - it has power, ground, comms, spare pins, and very low installation/testing hassle. The OBD port can be unclipped and pushed in, or a slim Y connector can be used if the device is to be hidden, or it could be wired in anywhere that you could wire in an OBD socket. I've wanted to do a wireless OBD interface for a while since few of the available options are good enough for realtime tuning, but needing the ethanol content sensor on CAN resulted in a combined design. Another plus for using the OBD port is that I noted that BMS said there was more data available there from other modules (through the gateway) rather than on the powertrain CAN side of the gateway, so it seemed a good plan.
It doesn't mean that other devices on the CAN bus could not go under the hood and have more I/O in future.
Today I took my D4 S8 to the dealer to get a recall done on the leaking turbo coolant lines, but it included an ECU reflash. They wouldn't do any of it because it had been tuned, but I don't have tuning gear for it as I had someone else do it a few years back. So ordered something for doing that through the OBD port, but in the meantime, pulled the ECU to get a backup and restore original (nightmare windshield cowl and bracing to get to it, similar overall hassle to a BMW N55/S55 DME except you can plug in the ECU and test it much easier) and flashed it on the bench once I could work out the VAG files to obtain an original.
Yesterday did some testing with late model BMW and Audi gateways to see what CAN messages I can get through - basically flood it with packets from either side and see what goes each way. Some nice options on both models to get realtime through the OBD port on the Audi, and ethanol content sensor in through the OBD port on the BMW.
It doesn't mean that other devices on the CAN bus could not go under the hood and have more I/O in future.
Today I took my D4 S8 to the dealer to get a recall done on the leaking turbo coolant lines, but it included an ECU reflash. They wouldn't do any of it because it had been tuned, but I don't have tuning gear for it as I had someone else do it a few years back. So ordered something for doing that through the OBD port, but in the meantime, pulled the ECU to get a backup and restore original (nightmare windshield cowl and bracing to get to it, similar overall hassle to a BMW N55/S55 DME except you can plug in the ECU and test it much easier) and flashed it on the bench once I could work out the VAG files to obtain an original.
Yesterday did some testing with late model BMW and Audi gateways to see what CAN messages I can get through - basically flood it with packets from either side and see what goes each way. Some nice options on both models to get realtime through the OBD port on the Audi, and ethanol content sensor in through the OBD port on the BMW.
Last edited:
Realtime tuning/emulation and custom CAN frames (ethanol content) are passing through the BMW F series gateway on the bench
