The problem is rather technical and to be honest I think there is no solution, but going to ask nevertheless. I am talking to my ECU (ME7.9.10 / Fiat) over CAN with a CAN-bus shield + Arduino. The CAN parameters for this are 500kbps and 29bit ids. It does work and I can read the Fiat specific PIDs, but I have problem with speed. A complete single CAN interaction (frame send + wait for return frame + read of receive frame) takes variable time from 4ms to 13ms (measured internally on Arduino). 4 is perfectly fine for my purposes, 13 is not. The CAN-bus shield library has the particular MCP CFG1/2/3 parameter settings for 500kbps, and I wonder if there is a way to set them up such that it average response time would be quicker. I found a website with a calculator for these parameters (https://www.kvaser.com/support/calculators/bit-timing-calculator/), but to be honest I cannot be bothered (yet) to try all the options I get there. Any ideas? Is there something else I should be looking into?

I wouldn't be asking at all, if I hadn't seen that ELM327 manages to keep a somewhat faster and more consistent speed when talking to the same ECU. I did not measure it, but I could visually see it when watching traced traffic on my Raspberry based CAN sniffer.

It could of course be that the one interrupt handler that I have in the sketch causes delays, but I really optimised this one, and I cannot see how it cause 10ms lags.

Using a different controller is not yet an option, if I can kick it down to consistent 4ms with MCP by finding the issue then I'd be set.

Looks can be deceiving, I actually externally logged the times of my Arduino CAN runs and ELM327 runs for continuous traffic. ELM traffic is very consistent each pair of SEND/RECV messages is spaced from each other by 4ms (I talk to ELM at 115200 baud, the spacing time is probably dependant on the baud rate), and the CAN reply after send takes ~15ms. In my implementation the replies arrive (from the log) between 4 to 10ms after send. So it is faster anyway you look at it. But, the culprit, my implementation, for whatever reason, requests communication from the ECU only every 80ms to 100ms, and this is where my bottle neck is, not the CAN response time. I need to redo this contraption communication stack of mine.

If you are interested why this is done in the first place: Arduino collects both the CAN traffic from the ECU and serial traffic from Zeitronix and sends it collectively through bluetooth to an Android based dashboard.

I always strive to make my programs interrupt driven (unless the complexity overgrows me, but that's not the case here).

Further experimentation shows that the complete turn around time (spacing + communication) cannot be brought below ~20ms on this ECU, so I had to work with this base line. The complete batch reading of the parameters that I want to transport to Android now takes ~115ms and is very consistent. Then I took the Zetronix approach of sending the complete frame with all the data in one go (rather than requesting parameters one by one and having back and forth serial communication, this is what I (stupidly) did so far) and that resulted in an end refresh rate of about 8fps, which is now acceptable (more importantly, it is consistent).

Further ideas for improvement: CLT and IAT do not have to be read with every frame, every 1s is defo sufficient, and then I can offset them at .5s to maintain consistent rate. Then I can still save a couple of ms on every frame by increasing the Bluetooth baud rate (currently at 38400, do not yet know if it maintains stability at 115200). If all that can bring me to 11-12 fps then I am all set.

With the improvements I mentioned (make IAT & CLT less frequent plus 115200 baud for Bluetooth, yes, it is Serial-to-Bluetooth setup) things got decent, it seems I have a stable 12 fps, looks pleasing to the eye. Looks stable too, I walked about 6 meters away with my phone before it lost connection.

Not sure what you mean by segment synchronous (I am behind with some things while being quite far with some other), but I guess you mean the factory "dash" messages that the ECU throws at the bus unasked? First, I do not have any docs for it, and I have done so much tracking / sniffing / reverse engineering for this ECU I am sick of it. Second, I am certain it would not provide me with some info I need (like boost target, lambda target, or things that are simply not there at all (yet), but I will program them in, like ethanol content). Hence I need to rely on request / reply diagnostics. Still have to find out though if there is a way to put the ECU in a faster mode (I do "start diagnostic session", but a default one, for this I have some docs, need to check them for possible parameters / options).

There is one other unchecked thing, speed considerations wise, I am working with a bench ECU, it has only power and single CAN line connected. It might be, just might, that because of probing the bus for the missing ECUs / signals, the regular diagnostics speed is crippled. This I will find out only when I finally connect this contraption of mine to the car.

As you say, for the dash it is OK, my other dream was to have a one button press, high resolution logger (could go to Android, or an SD card on Arduino, does not matter). But with this speed there is no advantage of just logging stuff through ELM327 from PC. But, if I insist on having better speed, I will simply create a new CAN diagnostic message in the ECU program to dump all data I need in one message (possibly multi-frame, but these frames are much faster). Then I have all data in a single 20ms slot, that gives me a theoretical 50 fps of display / logging.

Not to be totally ungrateful for the support, here is a practically finalised version of the app, particular selection of gauges to be made and still untested with real car ECU data, only on the bench. The moving gauge is boost signal from Zeitronix, the rest is practically still, because so is the ECU, but the data is real. The crate button, if you wonder, is for future map switching (there will be a hardware version of the button too):

https://www.youtube.com/watch?v=UJV2sLSf55s

I made an experiment with packaging all the display / logging data into one multi-frame CAN message already in the ECU. This improves things a lot, I can pass 30+ bytes of data, that is more vars than before, and have better refresh rate at the same time. I still have to measure the actual rate (pure curiosity) and make a clip of this.

EDIT: measured the rate, each complete data frame takes ~37ms which gives a very healthy 25 fps

Hi
Nice jobe mate


Envoyé de mon iPhone en utilisant Tapatalk