While I developed the Crunchtrack with the automotive field in mind, it became clear pretty soon that the board had a lot of potential in a lot of other applications. The very small board with a powerful MCU, a wide supply range, GSM, GPS and SD card is very flexible, so I bought it to the BattleHack Hackathon to see how far it could go. Continue reading Crunchtrack’s hacks
Category Archives: Crunchtrack
First tests
So how do you debug/develop for the Crunchtrack? Hardware-wise, the setup is very simple: I designed 2 boards, one is a breadboard adapter that breaks out all the pins from the expansion connector, and the other is the debug adapter that connects the debug connector to ST’s STlink debugger, sawed off from a Nucleo board. Continue reading First tests
OBD adapter board
The first prototype of this board was a disaster. I whipped it up in a rush just to fill some spare space before sending the main board to print, and while the Crunchtrack prototype came out nearly perfect, I messed up almost everything in this very simple board. Continue reading OBD adapter board
Crunchtrack:Schematics…
Schematics are online! As a bonus, I designed 2 verisons of the packages for the SIM800 modules, one with all the pins and one with only the mandatory pins to get the module up and running. I had to resort to this trick to save space for the tightly packed tracks, that on the PCB are spaced at 6/6 mil. A better board manufacturer would allow me to decrease the size of the tracks, but that’s for a future prototype. I don’t like having the modules “flapping around” in the breeze with most of their pins unsoldered, especially in the mechanical stressful environment that is a vehicle.
Design considerations and first prototype
An important goal that I set for this project is that it must be easily replicated and modified by everyone; that’s why I went for a 2 layer board and and a microcontroller in a LQFP package. To meet regulations I will probably have to switch to a 4 layer board in the production version.
Continue reading Design considerations and first prototype
Crunchtrack: web site
I think that we need to create a common repository/wiki database where we can share reverse engineered car information with a common standard, aiming at being able to automatically download a “descriptor” file that can run on an universal software.
This is not as hard as it seems; most of the data is usually extracted as the raw number, multiplied by a number, plus an offset. More complex formulas are not very common but exist and will be handled accordingly.
So, for every car, we have a page that states pinouts, bus speed, misc notes, and all the found messages. Log files can be shared and will be available for anyone to study.
Example page:
Car: Renault Twizy
Bus speed: 500Kbps
Pinouts:
– OBD connector
— Pin 6: CAN H
— Pin 14: CAN L
Messages:
[table]
Name,Address,Lenght,Repetition rate
BMS status,0x155,8,10ms
Battery pack temperature,0x55, 8,1000ms
Single cell voltage 1-5,0×556,8,100ms
…,,,
[/table]
Message specifics:
0x155 BMS status (10ms)
| Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 | |
| Name | – | PWRH | PWRL | CSTAT | SOCH | SOCL | – | – |
| Example | 0x07 | 0x97 | 0xFF | 0x54 | 0x6B | 0xF0 | 0x00 | 0x6F |
| Name | Parameter name | Min | Max | Formula | UM |
| PWRH PWRL | Battery power | – | 0x0F00 | (0x7D0-(n&0x0FFF))*16 | kW |
| Instantaneous battery power measured from the BMS. A negative value indicates charging, either due to regenerative braking or AC charging connection. This value can be used in conjunction with BV (0x55F) to calculate current flow. The indicated power is the total coming from the battery, power consumed by auxiliary devices is not separated from the traction power. Example: (0x7D0-(0x97FF&0x0FFF))*16 = -752W (charging) |
|||||
| CSTAT | BMS status | – | – | n | – |
| BMS unit status. · 0x94 = Initialization in progress; data acquired may not be valid · 0x54 = BMS ready |
|||||
| SOCH SOCL | SOC | 0 | 0x9C40 | n/400 | % |
| Battery state of charge. Example: 0x6BF0/400 = 69.06% |
|||||
This is just a brief example; the table may need more columns (to define if the message is read only or if we can send it to activate stuff, a method to handle bitmapped statuses, etc.) but it’s just to explain the idea. There will be a standard way to describe requests and responses, and how to handle data spanning multiple messages.
The community will help to converge to a standard way to save log files, develop tools to convert them, study their content and publish results. I have a small collection of softwares I’ve written in these years that I will make available with an open source license. Other options are:
Kayak http://kayak.2codeornot2code.org/index.html
OVMS CAN-RE-tool https://github.com/openvehicles/CAN-RE-Tool
BusMaster http://rbei-etas.github.io/busmaster/
Project Crunchtrack: Intro
I’ve always loved complex machines that can handle and transform huge amounts of energy to make very useful work. Among these machines, my life choices got me into the automotive field, where I’ve been working for the past 10 years. Just after school I found a job at Texa, an automotive diagnostic company, where I was writing software and reverse engineering communication protocols. My passion for efficiency and electronics made me leave that job after 5 years to pursue a career more focused on pure electric vehicles, so I joined another company where I developed power trains for EV conversions, and I even worked on a DeLorean conversion.
While working with electric cars, I stumbled upon two very interesting open source projects: Continue reading Project Crunchtrack: Intro