In 2007, everyone discovered you could blink an LED with an Arduino. A few years after that, someone discovered you could make a PID controller work with an Arduino, and a great number of sous vide cooker hacks showed up on the Internet. Trends in electronics projects come and go, and this year we have CANbus sniffers and development platforms. One of these CAN dev platforms, CANcrusher, is a semifinalist for the Hackaday Prize, and does a great job at poking and prodding a CANbus.
Like a lot of very excellent projects, the CANcrusher is based on a Teensy 3.1 microcontroller. This, along with the MCP2515 CAN controller gives the CANcrusher three independent CAN channels supporting DW-CAN, SW-CAN, and LSFT. The software for the device can stream data directly to a computer over USB.
Simply providing an interface for a CAN bus is something that has been done to death, and to improve upon the many CANbus projects out there, the CANcrusher is adding Bluetooth, a GSM radio, SD datalogging, and a real time clock. It’s a great project for the Hackaday Prize with multiple videos explaining how it works and what it can do. You can check out the entry video for the CANcrusher below.
Interesting project, but I would have so much preferred to see this as a BBB cape and SocketCAN, then focus on the analysis software. Having a whole separate ARM host with HID connection just complicates things unnecessarily IMHO. For a start, using a BBB or similar makes all the other craziness like GSM modems and SD cards redundant – you can uplink the ethernet port however you like and/or let linux deal with the data management, and you don’t need a separate PC to run the analysis Java on.
Good suggestion. That was actually my first concept of this 3 years ago. I was going to use a Raspberry Pi and a CAN board tied in with a hotspot for remote logging but the overall power consumption was too much for a “leave behind” data logger. That’s really the concept of the CANcrusher is a low power data logger that can be accessed remotely and can also be used for packet sniffing if so desired. If all this was going to be was a packet sniffer, i think you are 100% right on that SocketCAN and a cape with multiple CAN channels would be a great embodiment… Hmmm, future version? Thanks for the comment.
I made an attachment board for a BBB with two CAN channels, it works great with SocketCAN!
(though it is for a specific application so it has a ton of other stuff, and exceeds the size of the BBB). CAN on linux is pretty neat.
That sounds great. Did it connect directly to the SPI bus? MCP2515’s or some other solution?
Even simpler, all boards based on the Allwinner A20 SOC (e.g. Banana Pi) have a CAN interface on board, and it’s even supported by can4linux.
You’ll just have to add a CAN transceiver.
I believe his goal was to create an affordable tool with professional capabilities. Indeed, the Banana Pi does include a single CAN-bus channel but, as I understand it, his solution provides simultaneous interaction with three separate ones. This can be useful in many circumstances, since modern cars usually have at least two CAN-bus channels – my Opel Insignia (Buick Regal in the US) has four! It also includes a LIN-bus channel interface which can be very useful for messing around directly with less important car systems like switch panels, window motor drivers etc.
What’s the differnce to use a ELM237 or STN1110?
Those seem to be specific to OBD vehicle interfaces. While CAN is one of the supported and common physical protocols, those accept other protocols as well.
ELM329 is for CAN, but they’re not just for OBD
Neat project, but when I think can crusher I think big capacitors: http://www.powerlabs.org/pssecc.htm
Exactly what I had in mind.