The second print (blue) is finally usable, but I refined it to make it fit more neatly. The third print (orange) is the last one I did today and the components of my previous prototype fit perfectly.
The print may not look perfect, but hey, is quite a step above the “duck tape version”, isn’t it?
The first case doesn’t fit 100% – as usual – so I’ve made some improvements before launching the next print. 😉
As the original case doesn’t fit the needs and can’t be easily modified to do so, I just decided to create a new one. 3h of printing to go … let’s wait and see 😉
Today I’ve been building two more CanSee dongles. As the case is slightly different than the one of my development build, the screws don’t fit, so I needed to tape the cases, but the dongles do work, despite of the tape 😉
These two babies are definitely test builds, meaning that I experimented a lot on how to put the different elements together, putting them in the wrong order, placed them upside-down and all that kind of stuff that occurs while experimenting.
But they are operational 😉
Anyone interested in getting one?
Just be warned: I’m not a professional and doing this just for fun, so the risk is fully yours! Although I’ve tested them in my car (which did not blew up … uff) I give no warranty and will not be responsible of whatever you do with the dongle.
Micro introduction: A CANbus, which is used to connect all computers in the car, can only carry chunks of 8 bytes plus an ID, called frames. All data used to actually operate the car, such as switch positions, speed, and hundreds of other parameters are stuffed into unique frames and send out freely, almost always at fixed timed intervals. This is why we call them free frames. There is zero standardization among car makers on the meaning of the ID and the bits inside. Commercial dongles are not really designed to pick these up and have a lot of trouble doing so reliably or at all. (hint: “Timeout on ATMA” anyone?)
To actually diagnose the car, far larger “messages” are required. Even a VIN doesn’t fit in one frame, let alone i.e. the data for the voltage heatmap. For this purpose there is a protocol called ISO-TP which allows you to send longer messages. A software layer chops it up in frames, adds some synchronization data and sends it on. Exactly the same happens for long answers. ISO-TP formatted messages are almost exclusively of the query-response type. One participant (say the dongle or the dealers diagnostics tool) requests something, a computer on the bus answers. Even entire firmware up- and downloads are performed this way.
Why is this relevant? The ELM327 based dongles have basic support for ISO-TP. It’s a pain to set up, but it works and it’s actually what they are designed to do. The caveat being it only works for receiving long messages. We never gave this a lot of thought as the queries we put to the car always fit one single frame. Until the TPMS requirement came up. Writing the valve ID’s requires sending a long message. We implemented “long message ISO-TP” from the get go in the CanSee DIY dongle, so after tedious debugging, we knew setting TPMS worked, but now we had to tweak the driver for the ELM327 dongles to support long messages.
Luckily we were not the first. This nut was already cracked by Cedric Paille, the hero who made DDT4All. By carefully going through the logs of DDT4All, we could modify our ELM327 driver to now also send long messages.Thank you Cedric! The crazy thing is that if you use a commercial dongle, it does quite a bit of the ISO-TP hard work for receiving frames, but for sending quite a bit more is done CanZE and suddenly it is timing-relevant. This is what actually held up a new CanZE release.
Teaser: we have more things up our sleeves regarding not just the CanSee DIY dongle but also for the good old ELM’s. But first: a few final test and then release. As always, stay tuned.
Too impatient to wait for the ODB2 cases to arrive, I reused my ELM732 WiFi dongle I didn’t use anyway, to build a second CanSee dongle.
LED’s have been put into a new order and the interior is somewhat cleaner. There is no second transceiver in yet, but a placeholder is present.
So stay tuned 😉
New material arrived …
So let’s wait for the ODB2 cases to arrive before the fun can start 😉
While heavily a Work in Progress, Bob has started to put together some decent documentation on the dongle. It’s in the Wiki section of the firmware on gitlab. Have a peek and maybe you want to go on an order spree.
On the hardware side, as you probably have noticed we’ve progressed from the breadboard to veroboard-and-hot-glued in an OBD2 dongle enclosure. At least our builds are now a bit wife-friendly 😉
On the software side we’re working on a few features such as direct access to the Multimedia CANbus that Bob mentioned in the previous post, It will open up a few possibilities you will really like (more on that later). Also, we’re working on making the thing a bit more secure, but also more friendly for the non-technical user.
And then there is the ton of other things small and large. To name just a few:
– some things need to be slightly changed in CanZE now that is fed with data so much faster
– a setting screen in CanZE for this device
– low level technical stuff to make more things possible
For the techies: implementing sending multi-frame ISO-TP messages is needed. It required a lot of testing and coding and what not. This is how my desk looks around midnight. CANbus sniffer (Arduino DUE with GVRET) under USB control, T-cable with custom RJ-45 pinout, RJ45 splitter, RJ45 coupler with a CAN termination resistor tucked inside, RJ45 power insert contraption with lots of hot glue, the DIY Dongle being monitored over USB ……..
Is anyone experienced in moving this sort of home grown garage build stuff to the level of a decent and efficient PCB design without using a development board, a production run and maybe even fulfillment?
My current development dongle already looks somewhat clearer, now that it got it’s case, but under the hood, there is still room for improvement.
The second transceiver has recently be added, still it is not being used right now. So the hardware is present and software development is “under construction”.
