A student team at Ohio State University has designed and built a custom Controller Area Network (CAN) data acquisition system complete with a sensor interface, rider display, and a Linux-based data logger for a RW-2x motorcyle.
They call their small, convenient micro-controller circuit board the Magic CAN Node, and it measures automotive sensors throughout the electric vehicle. This includes a variety of thermistor resistors to check changes in temperature. A few 0-5V and 0-12V sensors to monitor brake pressure transducers along with some differential air pressure sensors can be added too. Since the vehicle is basically a “rolling electromagnetic noise bomb”, they wanted to keep all of these analog sensors as close to the source as possible.
The Magic CAN Node is based on a Texas Instruments microcontroller called the TMS320F28035. This keeps the energy consumption at a low level.
For message handling, the team, led by [Aaron], tapped into the built-in CAN module within the F28035. All of the CAN plugs have two of the pins shorted to GND or +12V, so when there’s only one plug connected, the analog switch IC will connect a 120 ohm resistor across the CAN lines.
The rest of the board is laid out in SI units, but the expansion interface is 0.1” pin headers on 0.1” centers. Seven of the analog inputs are available on the expansion header, as well as PWM outputs and digital interfaces (serial, SPI, I2C). Plus, a backpack can be made out of some perfboard if needed.
Software features can be programmable over CAN as well making it able to receive and respond to commands over the network bus. The user interface is made up of bright, illuminated push buttons and has a unique feature in which the buttons light up, either red or green, depending on which way current flows. Lights in the buttons indicate which ones are active. Tri-colors indicate the status of the motor controller and GPS/datalogging unit.
Combine together the CAN bus and a datalogger and they created the CANCorder! This is a device on RW-2x that uses a Beaglebone Black, which not only records all the data on the CAN bus but also provides a quick and easy way to access the current data inside. It can even find past data recorded as well.
It was created by [Jenn] who was equipped with a custom built cape and a USB WiFi dongle to transform the Beaglebone into the CANCorder. This provided the them with the basic features to start off the project: which was a way to access CAN data easily.
Their early goal for data logging was achieved by using a database file to cross check the various CAN messages that the CANCorder intercepted. They did this by programming the software to parses a specially formatted file that holds all the CAN messages. The data parsed by the software then had to be stored in a way that allowed quick searching later on.
An AVL tree was chosen because it self balances itself as nodes are inserted; allowing for quick searching. Since adding nodes would occur only once during execution and nodes would never be removed, the inefficiency with these two operations was not a concern.
For more CAN hacking, check out this introduction to CAN and automotive hacking.
I didn’t see any of the code or board files. Closed source project?
*ahem THE Ohio State University
Problem is, most motorcycle guys HATE canbus bikes. you cant make any decent modifications unless you rip out the OEM ECM and install a $4500 aftermarket unit. Now some canbus systems have been completely hacked BMW’s canbus for example has been hacked so you can easily add a turbo to the motorcycle, nothing like having a older K100 1100cc with 30psi of boost that is drastically faster than a hayabusa.
If you hack enough you can reverse engineer most of the systems, but it takes time and high IQ hackers. And a lot of times you do not have overlap between smart hardware hackers and gearheads. and motorcycle gearheads have even less overlap.
Since this is a totally custom bike, and we designed the CAN system, hacking is not a problem :) It may not be obvious from the summary, but this is also an electric bike. There are a bunch more details on our websitse, linked above.
Why use CANbus?
it is an awful committee designed standard that no one ever implemented without proprietary hacks…
if you developed everything else… why stick CANbus in there to being with? i’m really curious…
Faster than a hayabusa with a turbo?
*cough* bullshit *cough*
I’ve got a lot of respect for German mechanical engineering, German electrical engineering – not so much.
The only thing better than Japanese engineering (mechanical or electrical) is more Japanese engineering,
You wouldn’t need anywhere near 30psi on the ‘busa to eat the BMW’s breakfast.
In my experience the boundary to knowledge is your willingness to learn NOT the complexity of whatever. I know many “crusty old farts” who can CAN/ECU with the best of them. How? Wanting to actually know about something rather than just insisting that they already know everything.
Okay you connected a microcontroller to sensors and a display. Wooot.
serious, what do you do with all that new knowledge? Any serious application which is worth ??
Is there any useful application? or is it just weight without a proper use?
I really do not see any application. Why. bc bikes were build for ages without that stoof and second even electrobikes do not had this.
more stuff leads to more problems, leads to more time wasted solving it when it does not works.
e.g. my ford focus 1 vs my ford focus MKII (too much shit in it which failed already over the time) do i need it, serious nope. Do i wanted it, nope, but it comes all in one package. When you look at the older cars your realize they did ti right. not too much electrical shit.
sorry to bash your work, but i do not see a benefit in it as of now. or the author did not made it clear where it is. if it is just a can implementation, oh nice but on the other hand, do we need it? does it solve any problem, … hmm i doubt…
“my _ford_….” there’s you problem – right there!
Sounds like someone needs a tissue
My BMW S1000RR has an ODBII connector and passes sensor information out. A simple converted added an normal ODBII connector. Add Torque and I am all set for a fair amount of data logging…