3D Printing

Wow, it’s been almost a year since I’ve updated this. I really need to dedicate more time to documenting my various hacks. I have a few written up in drafts, but never published because I didn’t have the time to finish them. Well this is an attempt to start that. I will also be integrating Facebook comments, hopefully so as to curb the amount of spam comments that I have to weed out (100 or so a day) to get any real comments (3 a year? if that?).


So anyway, I’ve gotten to add a new tag, 3d printing!

I’ve been looking at 3d printers for a bit over a year now, kind of skirting the edge of the hobby. I’ve wanted to jump into it but never really had motivation to actually spend the money on it. My father, who is an engraver/cncer/metalworker, also happens to be into steampunk. He’s decided that he wants to build a paper towel holder, which would be an absolute nightmare to to machine… enter 3d printing!. His paper towel holder is modeled after two DC motor end-pieces on either side, with the paper towel holder in the middle. This is primarily because the end pieces look cool. You can purchase the motor ends rather than trying to machine them, but they cost several hundred dollars. Somehow I’ve managed to convince him to spend MORE than a couple hundred of dollars on a 3d printer which would be capable of printing the pieces he needs.


So a couple of months ago I purchased a half completed 3d printer along with my father. We spend a couple of weeks (well, a couple of sundays) fiddling with it and getting it assembled. Finally got it running, and was getting kind of crappy prints out of it.


I did some searching, and found out that the hotend that we were using was kind of a home-made deal, so I went and purchased a J-Head (hotends.com). The owner lives about an hour north of me, so I stopped by his shop and bought one. Got a chance to hang out with him for an hour or so, really cool guy, awesome little machine shop he has. Got the j-head installed on the machine and it was printing WAY better. Printed a PCB holder for the control board, added a couple fans to the machine to help cool the part, and it just kept getting better. I brought the printer to my house, got it all set up,and started printing more improvements. Printed a power supply mounting bracket, printed different Y axis rail holders, Y axis plate mounts, and installed the heated bed. Before the heated bed, I was using blue painters tape wiped down with acetone before every print, to make the part stick.


Below is a gallery with some pictures of my adventures. As I take more, I’ll continue to make updates. There are a couple test prints, some tool holders for my father (He’s doing the majority of the 3d work), and a Jaguar ECU enclosure that I designed myself (Woohoo! first real design!)

Jaguar A3 Part 2

Managed to scrounge up some solder, so I did some more :) . I got everything done that I had components for. I’m missing 3-4 components, so I’m going to have to make a mouser order for that stuff later anyway. Gallery attached of the rest of the build.

Jaguar A3

In my last post I commented about something I had recently discovered, FreeEMS as a potential solution to my Camaro problem. Today I received my copy of Jaguar A3, which is revision 3 (still alpha) of a FreeEMS compatible ECU.

Soldering it together wasn’t difficult at all especially since there is a really awesome how-to for Jaguar, put together by Preson, with help from DeuceEFI (mastermind behind Jaguar). These instructions cover from assembly, all the way through to testing. I’ve got it about halfway done, and I ran out of Solder, as well as discovered that I am missing one or two required components. In a month or so I’ll put in another mouser order and hopefully get it completed. Gallery attached for your viewing pleasure. I am well aware that I suck at soldering… I’m a code guy yanno :)


It has been a while since my last post, and I apologize for that. Between buying a house, and traveling for work, I’ve not had much time for silly things like updating my blog :) . As a few people are aware, I have a 1987 Camaro that has been nonfunctional for about 4 years now. It’s gotten to the point where I’m just sick and tired of looking at it, so I’ve lately embarked on a project to build my own ECU for it. Lucky for me, there is a FOSS Do-It-Yourself EFI as it were . In talking to the lead developer, it seems that they don’t really have any decent tuning client to assist with tuning the already very runnable codebase. This is where I saw a niche that I could fill. Enter: EMStudio. C++ Qt based tuner for the FreeEMS ecu. Thus far it has a fairly small feature list, it can open/edit ram data on the device, either via hex edit, or 2d table view , and display live data in a table or on gauges. All in all I’m very proud of how far it’s come and what it can do in such a short amount of time.

I just wanted to give a small update as to what I’m working on. I’m not dead or gone, I’m just busy.

Visit to Scantool.net

So for the past month I’ve been on travel for work in Arizona. Yesterday I was on my way home, and happened to be in Phoenix. As it turns out, scantool.net’s HQ is located in Phoenix so I dropped by for a visit. I had not initially realized how large of a staff they have on site, but a good number of them took time out of their day to talk to me and I really appreciate that. I actually wound up being there for several hours. Between discussions over CAN network and sitting in the Chevy Sonic I had rented to decode a variety of CAN messages using their can sniffer, it was a very eventful and interesting day.

Initially we got into discussions about CAN based OBD2 messaging, specifically the meanings of the different identifiers in 11bit vs 29bit. It seems that there were a few different modes of CAN That I was confused about the OBDLink MX’s return values for. There are a few different CAN modes that the OBDLink MX supports, the main differencing factors are 11vs29bit, and 15765 vs 11898 protocols. 15765 has an extra byte in the return for PCI, or Protocol Control Information field, defined here. This was of course, throwing my software through a loop since I wasn’t handling this, and this made for an extra byte on top of everything else. 11898 CAN does not have this identifier, since it is just RAW can values. The OBDLink does not actually return what is listed in the wikipedia article on CAN_Bus, adding even more confusion. The underlying CAN hardware internal to the OBDLink MX strips out start-of-frame, the RTR/IDE bits, and the DLC (unless otherwise requested to show it via ATD1 if I remember correctly).

Armed with this new information, we moved into a conference room, set up one of their wonderful OBD2 simulators, a Y cable, and a second laptop/tool to attempt to try out my new CAN Parser software to sniff what a CAN datatool is doing. Of course, as with anything technology we ran into a few issues. The first of which was the fact that I was running linux. When connecting over rfcomm using a bluetooth adapter on linux, you have to manually bind the rfcomm channel on your device to access /dev/rfcomm0. This is a bit of a hassle, since upon power cycling the device, or disconnecting screen from that particular pty, it breaks the connection and you have to unbind and rebind, which doesn’t seem to work 100% of the time. This is not an issue with the Obdlink MX, this is a linux issue since windows has no issues keeping the com port connected and active even under device powercycles. I will have to investigate more thoroughly if there is a method for easy connecting under linux.

The few times we actually got it to work, I realized that there were a lot of contingencies I did not actually plan for in the writing of my CanParse application. So after some mad random coding, and a bit of pizza and soda (thanks guys!), we moved out into the car. Jason, from what I can tell (forgive me if I get this wrong), one of the hardware guys hooked up his can sniffer to the Chevy Sonic, while I hooked up the OBDLink MX via Y-cable. Couple of weird things happened, including the rpm dial flickering up and down and random dingings of the door alarm, even when the door was closed. We figured this was just his can sniffer doing something weird, and moved on. Unfortunately I did learn that my CanParse application is missing a few key usefulness features that will be required before it is used in such a fashion to actually decode what is happening on the CAN bus. I will be detailing these in a later post as I write them into the code. Using Jason’s scan sniffer application, we were able to decode several things over the course of about two hours, including how to control the radio from the steering wheel controls, and how to identify when the lock/unlock and blinkers went on and off. We were unable to control the blinkers or locks, possibly due to a gateway node on the CAN network blocking our traffic, or us just not seeing the proper commands and only viewing notifications. Not entirely sure, but it was still very cool information to have. Just an example, but one could write a piece of hardware that monitors the CAN network, and logs lock-unlock events, turn signals, speed, rpm, a whole bunch of values to identify if someone is driving the car appropriately, or dangerously. I can think of a couple companies which could benefit from this, a couple who would want this, and a couple who NEED this :) .

Couple of other key things to note that came out of this meeting. There is an asynchronous communications mode that is eventually planned (ATMA mode with bidirectional communication), however logistically it’s not simple, so it may not happen very soon. It is definitely on their minds though, which is a huge bonus to the CAN crowd. I know that pretty much anyone with a MX and a CAN car would benefit from this, so I can only hope that they implement it soon.

The other thing had to do with CAN masks, I’ll go over that in my next post along with ATMA/STMA/STM differences.

Couple of pictures.


Their offices, they have cubicles

This is the back side of the cubicles. They’re not too large. There is a little white fan looking thing to the left of the paper cutter. It is a Wimshurst Electrostatic Generator. And let me tell you, even through 4-5 people, it still hurts.

This is the lab, they have cool workbenches for assembling stuff ESD safe-like.

And last but not least, me standing with the guys who took so much time out of their days to talk to me and deal with all my questions. From left to right, Joe, Jason, Me, Vitaliy, Vitaliy. That’s right, there are two of them. And I thought it was a unique name :) . Thanks again guys!

OBD2 CAN Parsing

So I’ve been on travel for a few weeks, and the rental vehicle I got is a Chevy Sonic. Ignoring the fact that it’s a brand new shitbox, I noticed that it has GMLan. I fortunately brought my OBDLink MX along with me so I can plug in and play with the car. Upon playing around a little with a terminal I found that messages go by so fast, that it’s really not practical to use a terminal at all for monitoring CAN messages. I put together a little CanParser application to assist in the process, and this lead me to try and figure out exactly how to parse CAN messages.

For all intents and purposes in the automotive world you can break down CAN messages into 11bit, and 29bit. This is how many bits are in the header of each message. The Sonic uses both, however predominantly 29bit so that is where I focused my efforts. Let’s take a long at some messages.

10 30 40 58 C0 9A 01
10 22 00 40 00 00 00 00 0F FD 00 00
10 30 80 60 C0 9A 01
10 22 E0 40 00 1B EC C3 C0 49 0A C6

10 30 40 is the header for the first message, and the rest is the actual message. The header can be broken apart into priority, param, and source IDs. The priority is bits 4,5, and 6 of the first byte, so that would be a priority of 4. Param is split between the first three bytes. Two bits of the first, the entire second, and third. Source is then the 4th byte This may seem a bit confusing, so I’ll break it down bit by bit. Say we have the message:

10 0A C0 97 82 08 01 FF D4
The header is 10 0A C0 97
  1  |   0  |   0  |   A  |   C  |   0  |   9  |   7
0001 | 0000 | 0000 | 1010 | 1100 | 0000 | 1001 | 0111
Written another way:
000 | 100 | 00000010100110 | 0000010010111
0     4         56               97

Skip 3 bytes in the front, then the next 3 is the priority, b100, or 0×04.
The next 14 are the paramID, 0×56, and the last 13 are the source ID, 0×97. then the rest of the message, 82 08 01 FF D4 is the packet that we want to play with. Unfortunately this is as far as I have gotten. I’ve not been able to figure out what any of the messages on the vehicle mean yet, but I’m slowly working on it.

I also have not yet been able to figure out how to parse 11bit CAN headers, with any luck that will be next.


I’ve recently taken libobd, and ported it to c#! It actually wasn’t all that difficult to do either. A long time ago when I first started writing libobd, I made the decision to keep the core communications library, the one that handes the actual serial communication, parsing out messages, but not handling them, as a seperate library. It’s compiled into libobd, but it’s written in pure c++ so it can be compiled on any platform without library dependancies. This allows my to export functions and hook into them from any language, for instance, from c# using pinvoke.

pinvoke is a very powerful tool that allows you to load a library at runtime, and call functions within that library. The main limiting factor, is that the functions must not be name-mangled, as a c++ compiler often does. Compiling functions defined as extern “C” causes the compiler to not mangle the names, and thus allows me to call the functions from c#. Below are a few of the functions I put into libobd to allow me to use it:

__declspec(dllexport) void *obdLibNew()
return new obdLib();
__declspec(dllexport) int obdLibOpenPort(void *ptr,const char *portname,int baudrate)
obdLib *lib = ((obdLib*)ptr);
return lib->openPort(portname,baudrate);

The declspec(dllexport) means that the function will be exported with cdecl calling convention. This is important, as here are the counterpart function prototypes in c#:

[DllImport(obdlibloc, EntryPoint = "obdLibNew")]
public static extern IntPtr obdLibNew();
[DllImport(obdlibloc, CallingConvention = CallingConvention.Cdecl)]
public static extern int obdLibOpenPort(IntPtr ptr, String portname, Int32 baudrate);

The way this works, is I can call obdLibNew() from c#, and it returns an IntPtr. this IntPtr is a pointer to the actual instance of the c++ library. While technically this is having unmanaged code inside c#, and therefore very dangerous, if done correctly is is a perfectly fine and valid way to interop between C++ and c#. One issue that I ran into, was how to pass a string from a c# application into the C dll file. This was easily solved by using byte[].

__declspec(dllexport) bool obdLibSendObdRequest(void *ptr,const char *req,int length, char *reply,int replylength,int sleeptime, int timeout)
obdLib *lib = ((obdLib*)ptr);
std::vector<byte> replyvect;
if (!lib->sendObdRequest(req,length,&replyvect,sleeptime,timeout))
return false;
if (replyvect.size() > replylength)
//Not enough room in the buffer
return false;
for (int i=0;i<replyvect.size();i++)
reply[i] = replyvect.at(i);
return true;

[DllImport(obdlibloc, EntryPoint = "obdLibSendObdRequestString", CallingConvention = CallingConvention.Cdecl)]
public static extern bool obdLibSendObdRequestStringTwo(IntPtr ptr, String req, Int32 length, byte[] reply, Int32 replylength, out Int32 returnlength, Int32 sleeptime, Int32 timeout);

What this does, is it allows me to say in c#:

byte[] mybyte = new byte[1024];
int retlength = 0;
obdLibSendObdRequestString(ptr,”010C\r”,5,mybyte,1024,out retlength,10,1000);

This passes mybyte into the function, so mybyte is automatically filled with the reply, and retlength tells us how much of mybyte was used. It may seem hokey, but it works really well and reliably every time. This has allowed me to create a c# wrapper for the underlying obdlib class: http://www.mp3car.com/showthread.php?t=150896

So if you’ve ever wanted to integrate obd2 into a .net application but didn’t know where to start, there you go!

This is also available on libobd’s git at https://gitorious.org/libobd





A project I’ve been working on, and testing in conjunction with tripzero, is something I call CuteIPC. Play on words for an Inter-Process Communication framework based off Nokia’s Qt (pronounced cute). The entire concept for this came from one of many arguments I have with tripzero, in which I proclaim that my monolithic style carpc frontend for the Windows Operating System is more beneficial from both a development and user standpoint than his multi-process Linux based concept. I’ll spout about exactly what that means in a later post.

As I often do, I gave trip the benefit of the doubt. We started discussing the limiting factors of a multi-process approach to a piece of software, and what hurdles would have to be overcome to make multi-process programming efficient. The big one was a lack of a decent cross-platform IPC framework. Qt has internally several IPC classes, however they all had limiting factors that guided us to the decision that we would have to write our own. The idea was to emulate the server-client architecture of dbus, where clients could offer services for any other client to take advantage of.

The implementation details involved the server running a TCP daemon on a offbeat port of localhost, so any client could connect, register its presents on the “bus”, and communicate with other clients connected to the bus. This is about how the typical IPC that I came across had worked. So why write our own? In three words: QObject JSON Proxies. What this does, is it allows me to procedurally generate class definitions of any client on the bus in JSON. Basically defining the interface that is exposed on the bus. Function calls, Signals and Slots, Properties, etc. Once these are defined in JSON, they are transmitted across the bus to any client who requests it. The client can then generate a header in ANY language, using this JSON as a definition file for how to generate the interface header.

Through some fancy code-trickery, this allows an application developer who is writing a GUI application, to access and use say, OBD2 functionality as if it was built into their program, even though it is seamlessly being ported over the IPC. An example is in order I believe.

{ “busname”:”revfeobd”, “name”:”RevFEObd”, “signals”: [ { "name":"pidReply", "args": [  {"type":"QString","name":"mode"}, {"type":"QString","name":"pid"}, {"type":"int","name":"set"}, {"type":"double","name":"time"} ] }, { “name”:”protocolReply”,  “args”: [ {"type":"QString","name":"protocol"} ] }, { “name”:”mfgStringReply”, “args”: [ {"type":"QString","name":"mfg"} ] } ] , “slots”: [ { "name":"deleteLater", "args": [ ] }, {  “name”:”addPid”, “args”: [ {"type":"QString","name":"pid"} ] } ] }

Looks like a mess dosen’t it? What this actually does, is define an interface for the RevFEObd class on the bus under the name revfeobd. Using this JSON as a template, we can generate this header file:

#include <QObject>
#include <cuteipc.h>
class RevFEObd : public QObject
RevFEObd(CuteIpc *ipc) {
m_ipc = ipc;
CuteIpc *m_ipc;
void pidReply( QString mode,QString pid,int set,double time);
void protocolReply( QString protocol);
void mfgStringReply( QString mfg);

public slots:
void pidReplySlot(QString mode,QString pid,int set,double time) {
emit pidReply(mode,pid,set,time);
void protocolReplySlot(QString protocol) {
emit protocolReply(protocol);
void mfgStringReplySlot(QString mfg) {
emit mfgStringReply(mfg);
void deleteLater() {
void addPid(QString pid) {

Ignoring all the bad formatting, this is generated procedurally at runtime. You can then compile this header into your application, and you have direct access to OBD2 functionality. Of course this still leaves the option of directly accessing the IPC and sending JSON calls directly, but the header generation provides for a much easier interface for those unfamiliar with JSON. It also allows for generation in languages other than c++. I’ve already gotten mostly written a c# header generator, which will allow for .net applications to take full advantage of anything running on the IPC bus.

Gumstix enclosures, a total mistake

So just a few days ago I posted about some Gumstix boards I had purchased. Today I sat down and attempted to put together the other enclosure for the Palo43 board. I have to say, I am completely and totally disappointed. I retract my previous statement about them being “not so bad”, and replace it with “You’re better off with no case at all”.

So I took this case out of the box, and it came, like the other, pre-assembled

Alright, that’s fairly typical, the other case came the same way. I started unbolting it to take it apart and I immediatly ran into issues. I got the back plate off, that came off easy. The side plates however, were stuck in place. I pried at them, wiggled them, even heated them up to no avail. Two things happened as I was prying:

There is a crack in the corner, it broke REALLY easy. Some of you might look at that picture, and see what I initially did not see; the reason for all my issues. Continuing on, I broke another part:

After this one broke, I realized that I could not insert the board with both the side plates on. It’s just not possible, since the board has to slide in at an angle, and you can’t attach the screen ribbon cable if you want to slide it in sideways. I did a bit closer of an examination, and I discovered… the parts are GLUED. Unlike the first case, this one is held together by glue. So I can not get the sides apart, and I can not insert the board with them together. Great. Useless. No wonder he provides no support unless he assembles them with the board included. I definitely will NOT be purchasing anything else from specialcomp, and nor should you if you expect to get even half your money’s worth. I am going to be creating my own cases, and to be honest, I’ll bet I could duplicate these case designs fairly easily and sell them for even cheaper. I’m not even going to post any of the rest of the pictures of the build. I got the LCD screen in, and it’s held in haphazardly, so it’s really not worth even talking about.

So moral of this story: Sometimes… you don’t get what you pay for. Sometimes you just have to cut your losses and run. Today… I am running.