Pages: [1] 2
Author Topic: CAN timing with MCP  (Read 19712 times)
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« on: October 19, 2017, 12:26:00 PM »

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.
Logged
jcsbanks
Full Member
***

Karma: +15/-3
Offline Offline

Posts: 125


« Reply #1 on: October 19, 2017, 12:39:32 PM »

ESP32 logged by Kvaser which has 10us time stamp resolution starts a reply within 10us of receiving a packet and costs $10. MED17 was the delay with a 2ms task
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #2 on: October 19, 2017, 12:54:02 PM »

ESP32 logged by Kvaser which has 10us time stamp resolution starts a reply within 10us of receiving a packet and costs $10. MED17 was the delay with a 2ms task

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.
Logged
jcsbanks
Full Member
***

Karma: +15/-3
Offline Offline

Posts: 125


« Reply #3 on: October 19, 2017, 03:10:23 PM »

Even on the far faster microcontroller I changed from a software queue to an interrupt to handle the frames to get the response I wanted, altering the library to do so. Kvaser timestamps helped to work out where the latency was on this and a PC application too. I don't think you can rely on the latent device to report delays. CAN bit timing is not going to give 10ms delays when a packet at 500kbps only takes 0.25ms.
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #4 on: October 21, 2017, 03:10:52 AM »

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.
Logged
jcsbanks
Full Member
***

Karma: +15/-3
Offline Offline

Posts: 125


« Reply #5 on: October 21, 2017, 04:33:08 AM »

I predict having experienced variations on this theme over the years with CAN and serial that you will not be happy until you can tweak the actual code for performance instead of through layers of abstraction that are clearly not written for performance. You want CAN and serial receive interrupts to grab and process the data as quickly as possible. How you package for Bluetooth I have no idea, until the latest spec it was too latent for my needs. Even Kvaser USB was on a 1ms clock whereas the ESP32 would get down to native 0.25ms
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #6 on: October 22, 2017, 02:07:48 AM »

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.

Logged
jcsbanks
Full Member
***

Karma: +15/-3
Offline Offline

Posts: 125


« Reply #7 on: October 22, 2017, 04:35:41 AM »

For a dash display it sounds like you are getting there with your update rate.

Does ME7 have any segment synchronous logging options if you need to go faster? I think I saw something about it in old A2L using KWP over CAN but it did not seem well documented like CCP 2.1 on MED9/17.

Sounds like your bottleneck if you got faster rates from your ECU could soon be the baud rate between your MCU and bluetooth presumably through a serial connection?  Maybe your performance issues are solved for your project and it is just for live display so you don't need or want to go faster?
« Last Edit: October 22, 2017, 04:46:27 AM by jcsbanks » Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #8 on: October 22, 2017, 10:13:31 AM »

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.
Logged
jcsbanks
Full Member
***

Karma: +15/-3
Offline Offline

Posts: 125


« Reply #9 on: October 22, 2017, 11:25:35 AM »

Segment synchronous logging is where the ECU transmits CAN packets each cylinder event (so 350Hz at 7000RPM with a six cylinder). These are custom RAM addresses. Not sure whether this is in ME7, but is in MED9-.
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #10 on: November 10, 2017, 02:05:32 PM »

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


Logged
jcsbanks
Full Member
***

Karma: +15/-3
Offline Offline

Posts: 125


« Reply #11 on: November 13, 2017, 02:21:07 AM »

Very well done. Nice smooth graphics and looks responsive.
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #12 on: November 19, 2017, 02:19:20 PM »

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 Smiley
« Last Edit: November 19, 2017, 02:56:33 PM by woj » Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #13 on: December 24, 2017, 02:24:56 PM »

Small cry for help, mostly because I am away from most of my tools, I even left the multi-meter during my holiday, and have limited possibilities to diagnose the problem (which I will eventually do). To the point - my Arduino / CAN-BUS shield contraption to talk to my dash app worked flawlessly on my bench setup, when I now connected it to the car I managed to get a working CAN bus connection only once (not the first attempt), otherwise CAN connection seems to be dead (it is not, ELM327 works perfect all the time). There are some obvious differences - different powering setup, more ECUs and CAN traffic, etc. I had problems with filtering messages before, but that I think I sorted out in the code. The CAN cables are twisted, but the connection is not resistor terminated (but I check this too by shorting the appropriate bridge on the chip with a screwdriver, moreover, on the Fiat installations it is often advised to remove the resistor on the ELM to remedy some connection issues).

So essentially some bug in the connection I have overseen, or some unwanted message interference to code out. If it helps, in the process of trying to make this work I got several messages on the dash stating inaccessible Airbag, power steering, or ESP system, depending on an attempt (some of them stayed for a couple of key-ons). Sounds a bit like a grounding problem now that I think of it, but any obvious hints to solve the problem are welcome.
Logged
omarino
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 4


« Reply #14 on: December 26, 2017, 02:50:56 AM »

Hi
Nice jobe mate


Envoyé de mon iPhone en utilisant Tapatalk
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.022 seconds with 17 queries. (Pretty URLs adds 0.001s, 0q)