Project Logs

Collapse

• Crunchtrack’s hacks

  Mastro Gippo • 09/19/2015 at 15:13 • 0 comments

  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. I pretty soon found three other members to form a team and we started working on an idea I had for a while: an anti-theft device for your notebook that could locate it anywhere and disable it.

  Basics

  Almost every modern (cheap) notebook has some spare space to install the Crunchtrack; even if you have the latest ultracompact, as long as there’s an optical unit you can swap it for a caddy with a second hard drive, freeing up some precious space.

  The Crunchtrack can then be connected straight to the battery connector on the mainboard, to ensure that it will be always online, independently from the OS or any other variable.

  Now you can find your PC anywhere in the world, and issue commands remotely.

  Disabling the computer

  So, they stole your notebook and when you tracked it you found it so far away that’s not worth the trip to recover it anymore. You will want to wipe and disable it. There are a few options for that, depending on your goals. If you want to destroy the data, there are a few ways to accomplish it, as you can see here:

  …but that’s messy. A better way would be to have the [always encrypted!] data on an SSD drive and short the notebook battery to the flash chips in a way that would destroy them beyond recovery. That’s a very nice way to wipe data, as it only requires a mosfet and can be used to burn the motherboard too, flipping the finger to the thief that will not be able to resell your notebook anymore.

  Building a detonator (don’t try this at home)

  For our presentation, we went for a good show for our audience, and decided to use explosives.

  Everyone who played with model rocketry will know this basic detonator design: we basically heat up a diode enough to light up a match taped to it, which in turn ignites something else (in our case a strip of firecrackers). I had to put a resistor in series to slow down the diode burning rate, as the LiPo battery I used in the demo was providing too much current and destroyed the diode immediately.

  And here’s the final result during our demo at 3:30:

  
  

  and we f***ing won!!!

• First tests

  Mastro Gippo • 09/19/2015 at 12:05 • 0 comments

  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.

  What bugs me, is that I can design a complex board like Crunchtrack’s without a single error, and then make stupid mistakes on an extremely dumb board like that adapter. In this case, I made the most classic of mistakes: I swapped TX and RX.
  As an afterthought, I also added a Reset button.
  Boards are available in the GIT!

  The basic test code is very simple, and I published an example on the mbed’s repository here: https://developer.mbed.org/users/gipmad/code/Crunchtrack_GPS_GSM/

  With this code it’s easy to test the GPS and the GSM functionality of the board, as it just forwards the serial port of either the GPS or the GSM to the PC’s serial port. There’s also a basic implementation of the GPS parser library that handles the raw GPS data and prints out coordinates and other data.

  I was pleasantly surprised when, without ever studying antennas and radio stuff but with just common sense and datasheet reading, I managed to get a very good signal from the GPS and the GSM radios:

  5 satellites locked, and in a very sub-optimal place too! The antenna was just outside my window, on the ground floor, surrounded by houses:

  Debugging

  I tried hard to get the GNU toolchain working, but had no success yet. As a backup plan, I’m now working with IAR EWARM tool suite that “just works” and allows me to debug code with no extra configuration at all; I just have to press “run”. Moving back to the GNU toolchain is going to take no effort, as the code is the same. it takes just too much effort to set it up and right now I want to focus just on coding. The IAR suite is also available in two free versions, a code size limited one and a time limited one, so it should be good to get started.

• Wiki online!

  Mastro Gippo • 09/16/2015 at 18:52 • 0 comments

  From the start, I wanted the Crunchtrack to be a very wide project where my own hardware plays only a relatively small part. True to my intentions, I finally put the first prototype of the wiki online! It's a basic Mediawiki installation, there's not much yet; I decided to inaugurate it with the first page about the first tutorial on how to get basic informations about cars.

  I also recorded the first video; it took a lot of effort and tens of retakes, and I'm still light years away from what I'd like to see (my inspiration is EEVblog). I hope to improve my english loquacity in my next trips :)

• OBD adapter board

  Mastro Gippo • 09/15/2015 at 11:49 • 0 comments

  
  

  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.

  The goal of this board was to provide some supply filter and the CAN transceiver; I also included 6 jumpers to allow the user to choose one of the three standard CAN pin sets. Well, I got them all wrong. I even swapped CAN H and CAN L in two places! So that's the two red bodge wires. The other ugly thing is the TO92 78L05 soldered on a SOT23 space: I designed the board to accommodate a smaller regulator, but when I assembled it it blew up when I applied the 12V power. Turns out that you can't find wide input linear regulators in that size, and the one I was using had a max input of 6V.
  

  Last mistake is the big electrolytic cap on the upper left; of course metal can electrolytics are too tall to be squeezed between the two boards and I've replaced it with a tantalum one.
  

  So I just redesigned the board, available in the Git, but beware: it's not tested yet!

• Schematics...

  Mastro Gippo • 08/17/2015 at 18:14 • 0 comments

  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

  Mastro Gippo • 08/16/2015 at 14:38 • 0 comments

  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.
  

  For the first prototype I went for a SIM800L as the GSM module.

  This incredibly small module provides a basic GPRS connection; while the 2G network is getting discontinued in the AT&T nefwork in 2017, there are plenty of other countries where the device will still keep working and hopefully I'll be able to find 3G/4G devices of a similar size on the market. Another problem of this modem is that it has pins on the bottom like a BGA, and soldering will be harder than a normal BGA chip because there are actually components inside that module that may move around during soldering. Because of that, an important restriction is that this module can't be oven reflowed while being mounted on the bottom side of the PCB as the components inside may just fall off. And since I'm using two modules here, I need to place them on the same side of the PCB. While I was aware of that problem, I decided not to care as I was going to manually solder them and I knew I was going to redesign the PCB sooner or later anyway.

  Unfortunately this came back to bite me: while being extra delicate soldering the GSM module, a SIM card pin didn't reflow properly so everything worked perfectly but the internet connection. As the Rad1o badge developers, since the missing connection was on a pin on the edge of the board, I tried to fix this by drilling a hole through the PCB and soldering a thin wire to the missing connections

  That didn't work of course, and I messed it up beyond repair, a very nice excuse to start working on the second prototype.

  Looking for horror pictures? There you go, here I didn't have a 1uH inductor to couple the GPS antenna supply and I fixed it with a wiggly wire:

  And here I didn't have the right resistor for the switching regulator, so I used a potentiometer to experiment with different voltages too:

• The Website

  Mastro Gippo • 08/10/2015 at 11:57 • 0 comments

  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:

  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

  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/

• Intro

  Mastro Gippo • 08/08/2015 at 16:29 • 0 comments

  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:the Open Vehicle Monitoring System, an IoT device to control every aspect of your car from a smartphone app, and the GEVCU, an universal ECU especially designed to handle the common problems faced when converting an ICE car to electric.

  Inspired by these two devices, I want to build something that could take the best of the two approaches to very similar problems.

  The Crunchtrack

  I have a few goals in mind.

  – I want my device to be small. That is both tho satisfy my efficiency fetish, and to have it fit inside the shell of a standard ELM327 bluetooth adapter:

  (This is the original bluetooth board)

  – I want it to be connected to the internet. I will use a GSM GPRS module and a GPS module to provide location

  – It will have an USB connector, so the user will be able to easily update firmware and, most important, load a custom firmware to temporary use it as a Reverse Engineering tool. This way, the user will not need to buy other tools and will be encouraged to develop new functionality.

  – It will be cheap. I’m aiming at a price a bit higher than the OVMS.

  – It will be easy to develop custom software, thanks to the mbed platform

  But wait, there’s more!

  I just described the hardware, but my vision is bigger than that.

  The community website

  Right now, if someone wants to find infos on a car’s CAN bus, he/she has to sort through a lot of noise. A lot of reverse engineered messages can usually be found on the documentation of the various projects like the OVMS, but other times they’re buried under thousands of messages on forum threads – and you may find later that they’re wrong, as it was documented a few posts later, so you have to read the entire thread to get useful info. Been there, done that. More importantly, there’s no standard way to present this kind of information.

  I think that we need to create a common repository/wiki database where we can share this kind of information with a common standard, aiming at being able to automatically download a “descriptor” file that can run on an universal software. More on that later.

  Instructional videos

  I want to make instructional videos on the lines of the EEVblog. I’m a very practical person, and I learn stuff only by doing it; my videos will be targeted to people like me, focusing on a defined task and explaining every step taken to get there.

  For example, to teach the basics I want to make a series of videos on how I built an ECU to open the top of my car from the remote; this may be the lineup:

  • Basic automotive electronics
  • where to find information and schematics
  • OEM diagnostic equipment
  • Reverse engineering the CAN bus
  • Transferring the studies into code for the ECU

  And that’s about it for the general idea. Stay tuned for more info!

View all 8 project logs