FioranoCars wrote:Yes, sadly due to "gaps" between buffers, this is not suitable to listen and follow a "conversation", any data missed would be a failure, and render the analysis void. As a quick and dirty, is my CAN signal valid, it's great.
I don't think that is such a big limitation.
The "initialization" between computer modules in a car (if exists) shouldn't take more that a second or two, and should only happen right after you turn the ignition switch on or you open the car.
Any modern Pico Oscilloscope can record much more than that, with detail, in a single buffer.
The only limitation I see is when you want to capture a communication event, that it will happen only once, and that you don't know when it will happen or if it will happen.
I don't believe that you could have some type of communication protocol in cars, under CAN, K-line, ..., that you couldn't understand anything if you miss just one frame.
In a vehicle environment I don't believe that this makes sense.
FioranoCars wrote:The ELM327 is according to "superior" sources too slow for this sort of task and other has limitations, not sure what, but that's the word, and I'll not double check others work, as hardware is relatively cheap anyway.
The Arduino (faster than most Pi's especially in terms of I/O operations) is also thought to be a bit slow if you get into complex stuff, and the recommendation for serious playing is the Intel® Galileo Gen 2 board, which is sort of compatible with the Arduino sketches, but has access to Visual Studio as well, so no doubt much more powerful, though still single core, single thread architecture. I'll probably hold off the Intel board as it's about 10x the cost, and I have a few spare Arduino floating.
That may be true, I don't know for sure, never got my hands on that to prove otherwise, but I can't understand why they are slow for this.
Some car computer modules have a very low processing power, maybe lower than an Arduino board, and they do get the job done. They process network data, send network data and do there stuff in the middle.
You are talking about single core limitation and processing K-line data. K-line has a theoretical max speed of 10.4 kbps.
This is just a very stupid low speed value.
Even CAN networks at the most common 500 kbit/second, are a slow communication method, in modern computer power standards.
I will be very surprised if you find any limitation in recording all CAN data at 500 kbps with a regular Arduino board and a CAN shield.
FioranoCars wrote:Also the Application Layer stuff (message structures, contents) and initialisation, although right now I'm planning on listening only, sooner or later it'll crop up as to why the initialistions failed, so understanding the wake up stuff is pretty important too.
I can only say good luck with that.
I have before successfully decoded some non "scan tool data" in a car network, like the rpm value that goes to the instrument cluster, radio station name, button pressed, ...
All of this was possibility because I knew what I was looking for.
For instance, capturing the data and increasing the rpm at the same time, changing the radio station, or pressing a button multiple times...
What I have seen so far, regarding "Application Layer", is that there isn't (almost) any.
For instance, the ID that you have in the CAN message, represents the data "source" or content type. The meaning of the data in that frame is a very static thing.
As an example of something that I have "decoded" in CAN, in a Opel/Vauxhall Astra H, the RPM value is broadcasted in a CAN frame with ID 0110 (hex) or 272 decimal value.
The bits from 9 to 24 represent a 16 bit binary integer number of the RPM value.
In here you can see the decoded frames (just bits filtering), and a chart with the RPM that is "encoded" in the data.
I think it makes total sense for the manufactures to do things like this. If you add a more complex application layer, then you will need more computer power, for no practical reason.
More than that, you will increase the network overhead, in a "slow" type network.
FioranoCars wrote:Also anything (docs or sites) dealing with Arduino and OBD, there are quite a few, many with little recent activity, so if you stuble over something, please pop it my way! Ideally not projects to make a dashboard or fuel economy meter, as they are not really too relevant, but heck, I'm happy to filter!
Projects using something other than data that you can't get with the standard OBDII protocol I believe are really rare, and very limited in function.
Other than getting OBDII data, I have only seen little stuff, like using the steering wheel buttons as an input to an android tablet, and stuff like that.
I believe the reason is that OBDII is the only documented and standard communication protocol in cars.
More, I had read sometime ago, something about reverse engineering the data in car network to be illegal.
Don't really know for sure, but makes some sense to me, since because of this we could be producing documentation for an immobilizer bypass, odometer value change, MIF light always off, ...
FioranoCars wrote:Finally, any links to software for analysis of CAN/Data packets. I use Wireshark for TCPIP stuff, and could just write the data into a format that program can read, which I might do anyway to give the output an opensource universal viewer, but if there is anything (commercial or Free/Opensource) that is dedicated to OBD/CAN packets, then please let me know, this is probably the critical part of the jigsaw ... raw data is one thing, the analysis of THOUSANDS of message per minute is the value! Bear in mind some captures could be 10-60minutes long (LandRover vehicle shutdown is 45mins), road tests for intermittent faults ...
I believe Wireshark type software only makes sense if we are talking of a higher level protocol like TCP/IP, and you could get "metadata" from the overhead of the protocol.
In here, at least as far as I have seen, the only stuff that you have is the network related data (ID, Checksum, CRC, ...) and the raw data bytes.
FioranoCars wrote:Will try and prototype something in next 4-5 weeks, let you know how it goes, but I want to let the theory soak in before I go blowing up any ECU's !
Please keep us informed with your progress, and I'm very curious to see your approach to this.