RoadTest: Microchip CAN Bus Analyser Tool
Author: mcb1
Creation date:
Evaluation Type: Test Equipment
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: null
What were the biggest problems encountered?: Some of the advertised features were not implemented in the software.
Detailed Review:
Firstly I wish to thank element14 and Microchip for the opportunity to test the Can Bus Analyser Tool.
My application was based on :-
I have been involved with the Automotive world and more specifically modification of them via Hot Rodding for about 40 years.
The recent trend to electronic control means that the days of physical adjustment are gone, and you need to delve into the vehicle brains.
Diagnostic testers and reset devices are available for a few dollars, but these don't provide all the information.
They are simply a subset of the data that flows between the various modules fitted to modern cars.
My latest car has a few areas that need tweaking and while you can purchase an rather expensive box that connects and tweaks a couple of parameters, the software is limited, and not cheap.
In my case there are a few other signals that need to be extracted and either displayed or captured for display.
One of these is the APM where it shuts down to 4 cylinders. Some other makes have an indication, but sadly Chevrolet didn't provide this on a Camaro.
There are a few other pieces of data that are best not mentioned here, but affect the performance, that I would like to tweak, but I'm not sure which module controls it.
For this test review I'd like to talk about what is CAN bus.
Where it is used and demonstrate what it looks like.
I'd like to show how you can identify the data, and therefore be able to identify where it originates.
In my car there is interaction between the MyLink audio system and the vehicle, so again being able to identify data is the aim.
We've also talked about data logging and more specifically Geotracking.
As I understand most modern vehicles have GPS data running around, so the ability to identify this data with a view to logging it is another feature to demonstrate.
At the very least being able to log and pass on vehicle speed means that alarms systems can be designed to report to an owner when their vehicle is being moved without them on board.
I'm impressed by the packaging.
Microchip have certainly gone out of their way to ensure the product arrives safely, despite the abuse many postal services, customs agencies or couriers try inflict on it.
The supplied USB cable looks like it is good quality and is a decent length, so well done.
It was smaller than I imagined, and I would have preferred to see the labelling of the connector on the device, rather than referring to the manual.
However it looks robust enough.
A quick check of Wikipedia had this information.
Development of the CAN bus started in 1983 at Robert Bosch GmbH.[1] The protocol was officially released in 1986 at the Society of Automotive Engineers (SAE) conference in Detroit, Michigan. The first CAN controller chips, produced by Intel and Philips, came on the market in 1987. Released in 1991 the Mercedes-Benz W140 was the first production vehicle to feature a CAN-based multiplex wiring system.[2][3]
The pair of wires are driven differentially, or more simply one line goes positive while the other goes negative from the resting level.
source https://en.wikipedia.org/wiki/CAN_bus
This gives the effect of twice the modulation, but more importantly, any interference or induced noise simply shifts both lines the same direction, and therefore does not add any noise to the signal.
Contrary to many other bus protocols, there is no master/slave arrangement, and both lines carry the signal, unlike many others where one is the clock and the other the data.
If you've ever been in a room where multiple people are trying to contribute to a discussion, eventually some drop out until there is only one left carrying the conversation (often not the most interesting or important )
For the CAN protocol to work, each node has a priority, with zero being the highest priority.
Again from Wikipedia ...
For example, consider an 11-bit ID CAN network, with two nodes with IDs of 15 (binary representation, 00000001111) and 16 (binary representation, 00000010000). If these two nodes transmit at the same time, each will first transmit the start bit then transmit the first six zeros of their ID with no arbitration decision being made.
When the 7th bit is transmitted, the node with the ID of 16 transmits a 1 (recessive) for its ID, and the node with the ID of 15 transmits a 0 (dominant) for its ID. When this happens, the node with the ID of 16 knows it transmitted a 1, but sees a 0 and realizes that there is a collision and it lost arbitration. Node 16 stops transmitting which allows the node with ID of 15 to continue its transmission without any loss of data. The node with the lowest ID will always win the arbitration, and therefore has the highest priority.
So unlike our room conversation, we have nodes that have a higher priority than others, and can therefore pass on their information, without having to wait for the other less important nodes to stop talking.
The last thing you want in a car is the ABS trying to tell the engine to reduce power, while the stereo is trying to tell the HUD what song is playing.
In theory it could be used anywhere, however like any serial system there are limitations.
Vehicles appear to be the primary design catalyst and ISO finally got on board in 1993.
With the mandanted OBD-II in the USA in 1996 and in Europe in 2001, it was fitting that it got used as one of five protocols
(see attached spreadsheet of various vehicles and the protocol they use)
The protocol is licenced by Bosch, and the link below outlines the costs.
Obviously if you buy a CAN chip, then the royalties have been included, but anyone making their own hardware should be aware of the licencing.
There are many reasons why people want to modify the manufacturers default settings.
While the EPA might wish to limit the abilty to modify the engine parameters, in some states and countries it may be perfectly legal.
I can recall carburettors with sealed adjusters, or limiting caps fitted in order to restrict the home mechanic, and the software is no different.
Engine management is only one aspect and indeed just one of the multitude of controllers fitted in modern vehicles.
I can recall that if you wanted to do engine transplants, you simply needed the Engine ECU and Transmission controller, but now it seems there are various other modules that need to communicate.
To solve any issues with transplants, these guys have solved that by packaging everything (inc fuel tank). https://www.clevelandpap.com/specialties/worlds-first-hellcat-turnkey-pallet/
The first part of hacking is to understand what each message relates to, and while there seems to be 4 different groups, it's far more complex than that.
As I started looking to see if someone had endured the pain before, I came across this article about one person deciphering a MINI.
http://bobodyne.com/web-docs/robots/MINI/CAN/Presentation/
I like how he approached the deciphering, and in particular deciding which message related to which wheel sensor.
http://bobodyne.com/web-docs/robots/MINI/CAN/Presentation/Slide43.html
You may recall a news story about some guys hacking a vehicle and comprimising it.
As I understand they got into the braking system and prevented it from stopping while under controlled conditions.
As usual the news agencies sensationalised it, but in reasearching this I came across the full story.
http://illmatics.com/Remote%20Car%20Hacking.pdf
From the news story, you got the impression that someone simply fired up a laptop and connected into the car and executed a few commands.
The reality is far from that, and involved buying a target vehicle and some VERY expensive diagnostic tool, along with a few years research.
I suspect that this research will lead to legislation for manufacturers to follow in order to ensure safety is not comprimised.
Chrysler has already recalled 1.4 million vehicles and Sprint Cellular blocked port 6667 traffic, and other manufacturers will not want to do recalls.
Security for IoT devices would seem to fall into the same realm as CAN BUS, so the more connected we allow our vehicles, the more we could be comprimising the security.
For my application I wanted to see how easy it is to identify the APM control signal. This tells the vehicle to shut down to 4 cylinders to save fuel.
Unfortunately Chevrolet didn't provide any indication, and unless you are on a smooth road as it shuts cylinders down, it's hard to know if you're in that mode.
I have no problems with it in 4 cylinder mode, right up to when you plant the right foot to overtake and it chops down two gears, then brings the other 4 cylinders online.
As it does this it creates a stumble while it sorts itself out and the GForces kick in. Having the indication means you can manipulate it right before the overtake.
I've seen it on the later Dodge, and now I'm keen to have it as well.
The OBD-II Pinout
source The Car Hacker’s Handbook
Tests
I've had a lot of other things on my plate, but today I was able to do some real world testing on an actual vehicle.
The software was transfered to my Laptop, and the device plugged in and detected.
When I plugged it into the vehicle (you need to purchase a OBD-II to DB9 cable) the canbus Rx came up but there was no data.
I checked with the ELM device I have and it was happily producing data, so back to the Microchip device, and nothing.
After a bit of head scratching and some more checking it appears there are two standards for OBD to DB9.
source The Car Hacker’s Handbook
So after some checking, it seems that my cable was US version but the Microchip CAN Bus Analyser is using the UK standard.
Luckily for me there are only 4 wires to worry about, so a not so elegant but perfectly serviceable adaptor was made.
I elected to start recording a few different scenarios so I could try to decipher the results.
I chose to use the Rolling Trace, as I wanted to see the data change, and the Fixed Trace simply counted the instances and gave the latest result.
The attached spreadsheet shows the data collected, but the next issue was how is it arranged.
I was expecting to see a better breakdown of the ID, and instead it was simply a number.
Some online information didn't match the numbers, and I struggled for some time to find something to align the ID's to what information I had.
The GMLAN Bible should have given me everything I needed, but alas I struggled to match the data I had with their numbers.
https://docs.google.com/spreadsheets/d/1qEwOXSr3bWoc2VUhpuIam236OOZxPc2hxpLUsV0xkn0/edit#gid=1
I found some other numbers here www.carmodder.com • View topic - GMLan Bible updates
I wasn't sure if Data0 is the MSB or LSB bit, and even checked the source files to see if there was some clue.
It sort of made sense when the DLC said 2 and only Data0 and Data1 were populated, so it is simply the stream of data with no manipulation.
I finally made solid progress with this link
Time | ID | DLC | Data0 | Data1 | Data2 | Data3 | Data4 | Data5 | Data6 | Data7 | |
164.7232 | RX | 0x514 | 8 | 0x47 | 0x31 | 0x46 | 0x4B | 0x31 | 0x45 | 0x4A | 0x35 |
164.7082 | RX | 0x4E1 | 8 | 0x46 | 0x39 | 0x33 | 0x30 | 0x30 | 0x30 | 0x33 | 0x37 |
According to the above link this represents the Ascii VIN number in Hex ( http://www.asciitable.com/ )
Another figure that seems correct is the Outside Temperature.
610.6123 | RX | 0x4C1 | 8 | 0x00 | 0xCB | 0x49 | 0x41 | 0x7E | 0x00 | 0x00 | 0x00 |
0x7E = 126 126 / 2 = 63 63 - 40 = 23 which was the Temperature when I did these checks (and that was inside the garage).
So finally I have some valid data that I can use to continue.
It is a reasonable piece of hardware, that would allow modification (the source files download in the Application directory).
It is fighting against some other shields, kits and commercial products, and if the intended target is vehicles, then it is missing the cable.
The software requires Admin privildge to install on a Windows7 machine, which happens after you start the process.
What concerns me is the lack of software to match the advertised hardware, despite many years passing.
Mr Microchip, if you want to make this stand out against your competitors, then you need to implement all the promised items.
Hence I marked it down based on what I term "Vapourware".
The other problem I have is that Microchip suggest you can download and use https://www.k2l.de/products/38/OptoLyzer%C3%82%C2%AEStudio/
After downloading this, it refuses to load if the Microchip Driver is installed (which you installed with the Microchip CAN Bus software).
I'm not sure how you feel, but I don't like software that won't play nicely with legitimately installed software, especially since it's just a USB driver!.
Now that I've proven the CAN Bus Analyser works, I might install the software to see if it has any advantages.
Looking at the links above and the time taken to decipher the codes, it might be some time before I get the one I want.
Interestingly these guys seem to have sorted it out.
Many of the items are already available in the Driver Information Display, but it does mention APM
DASHCONTROL OBDII DISPLAY CONTROLLER, CHEVROLET CAMARO, 2010-2015
My only concern is that it sticks down a bit far, and many of the items are already available, so the cost/benefit ratio is low.
My thanks for the opportunity to review this, and hopefully I've provided some useful links.
I know I've expanded the ones I had, and the next few nights I'll be exploring some others I collected.
Cheers
Mark
Top Comments
Nice review Mark,
DAB
Thanks DAB
I'm now found yet another distraction to stop me getting all those other projects done