Rapid Prototyping with MacroFab, Part 2

As I described in Part 1, I am using MacroFab for rapid prototyping of my jeepbot concept project. In this post, I’ll describe the next phase of my project and how MacroFab has made it easy to get there.

As I thought about what jeepbot should be, the concept evolved into several different ideas. What I wanted to build first was a control board that directly controlled a simple relay box, like the one described by Hooz’s DIY project post. The idea was to focus on the control circuitry first, rather than the relay circuitry. The control board would replace a bank of switches, so easily plug-and-play. This would allow me to fine-tune the design over time, while retaining a good, simple relay box in the vehicle. I also renamed the project concept switchbot to go with the idea of being vehicle independent.

For my first board, I designed a circuit that contained a Atmel ATmega328P micro-controller, a MCP2515 CAN controller, a MCP2551 CAN transceiver, and a 74HC595D 8-bit shift register. I only designed in 4 switch circuits for this initial board. Each switch circuit is protected by a LTV816 optocoupler, to isolate the micro-controller’s digital logic from the actual switches. These output lines can in turn be used to drive other circuits, such as a relay board.

To round out the board, I added a two-port terminal connector for +12v power and ground, a two-port terminal connector for CAN high and low connections, and a DB9 connector for easily interfacing into automobile OBD-II connectors. I used a 6-port Molex connector for output for power, ground, and the 4 switch channels. A reset button and a 2×3 header for in-system chip programming (ICSP) interface to program the ATmega micro-controller was important to make sure I could download firmware later.

The board also has a simple +12v to +5v power supply regulation circuit and protection diode, but not with significant automotive transient protection. That circuitry will likely be needed in future versions.

You can find the Eagle files for this version of the board on github at https://github.com/dcgibbons/switchbot/releases/tag/v1.0_alpha

Like with my previous board, I used the MacroFab web interface to upload my Eagle design files. This board had a lot more parts than my previous one, and my experience with the previous board taught me I needed to be more careful in double-checking my part selection. Even with my caution, the engineers at MacroFab found several discrepancies for me to clarify, mostly with resistor values.

While the board was being produced, I discovered the diode value mistake I made with my previous board. I found the same mistake in this board, so I asked MacroFab if it could be replaced – yep! And they did so easily, since this was before assembly of the board had actually begun.


During the final assembly of the board, MacroFab found the two-port connector parts I selected for my CAN and power interfaces were wrong for my board design. I asked them not to populate those connectors as I had many of the correct ones in my workshop.

MacroFab also found during assembly that the crystal oscillator part I had selected would not  match the pins exactly on my board. The size was correct, but the orientation was wrong. I recall that selecting the oscillator part was difficult, so I was not too surprised. A little bit more research from the parts houses and I found what I thought would be a better part. MacroFab agreed and ordered it for me. This extra order only added a couple of days to the overall board assembly time.

IMG_2448A couple of weeks after ordering, my boards arrived. I ordered two of the boards this time, as I wanted to be able to leave one in my Jeep and use another for bench testing. As soon as they arrived, I hand soldered in the two-port connectors I had (I have a nice supply of them from SparkFun as they are so commonly used on Arduino-based boards).

The next step was to power up the board and see what happens. No smoke; it lives! Without a program downloaded to the micro-controller nothing much happened, but the solid power-on LED and the all 4 switch LEDs being on indicated to me that the core of the system was alive.


Next I used an AVR ICSP programmer to download software using the Arduino IDE, which front-ends the avrdude tool. I picked the Arduino blink sketch to see if it would download… success! I do not have an LED on pin 13 of the ATmega so I couldn’t see the sketch actually running, so next I dowloadeded my shiftreg test sketch. This sketch will cycle through all 4 switches and leave each one active for a few milliseconds. It will also display anything it receives over the CAN bus to its own serial output, although I did not make it easy to show serial output on this board.


Surprisingly to me, not only did the sketch download, it actually worked. The switch indicator LEDs lit up in turn, and with a meter I could measure the signal voltage on each output line on the Molex connector. Success!

I now have the basis for real hardware testing in my vehicle. I’ll post a follow-up on further progress with this project.

The most amazing thing about this experience so far has been the ease of use of the MacroFab interface, their quick turn-around time, and the pricing. For these two boards, the price was approximately $76 each. For a hobbyist, this pricing puts real low-volume projects in easy each. At higher quantities, the price drops dramatically. For 1,000 units, for example, pricing approaches $15 a board for this design.

Stay tuned…


Published by


Chad is a software developer from Colorado, USA. He's been working in the software industry since the 1980s and presently works for Alert Logic, a provider of managed security-as-a-service solutions for the Cloud. He spends way too much time bicycling or playing with cars.

7 thoughts on “Rapid Prototyping with MacroFab, Part 2”

  1. I’m curious how your project is going. (I picked up a rubicon unlimited) and wouldn’t mind talking to you a bit sometime.

    I’m wondering if I met you at the Boulder hackerspace a while back – I haven’t been there since I got all my tools moved to CO. Give me a yell maybe we can meetup for coffee in Ned or something.

  2. I just started following your work on the Jeep interfacing. Nice work. I’m thinking about trying something similar on my ’16 JK. I’d like to incorporate the GPIO pins on the Pi, or perhaps even on an Arduino to send commands on the CANBUS.

    I do security work on the side, and would love to be able to flip a hard switch, and “blackout” my brake and reverse lights, instrument lights, etc. this should certainly be in the realm of what’s possible here, yes? It sort of defeats the purpose of hiding up on a hill, and giving away my position whenever I move!

  3. All things are possible! Unfortunately what you want to do might actually be better off by using physical switches on each light circuit, unless we can find some hidden messages that the bus could listen to.

    Here’s the general problem: the system works by the CCN broadcasting light settings from the switches over to the TIPM and other devices. It’s a constant stream of messages every 100ms or so. If you want to override that and tell the lights to go off, you’re fighting with what the CCN wants to send.

    You can work around that by building a proxy device in front of the TIPM or CCN, and only passing messages you want it to pass. This concept works OK; I haven’t personally done it given the challenges of the different terminals and connectors involved (especially with the TIPM).

    Another option might be to hack the software in the TIPM or CCN; again a higher level of difficulty but possible.

    And I’m not sure the CCN (dash) has a mode where all the lights are completely off, if it has any power at all.

    So lots of questions, but it’s one of those that is tricker than you’d likely think.

  4. Hello Chad,

    I was wondering how you were getting on?

    I’m about to start on the whole process with my new Jeep Patriot, mostly for fun but also to see how much information is being sent over CAN and whether I can decrypt it or not. It’s been a long time since I played with reverse engineering so it’ll take me a whole to get back up to speed!

    I was wondering if you compiled a list of codes already discovered as I don’t want to repeat your already sterling work.

  5. The Patriot has a completely different set of messages so you’ll need to analyze the get the full set there, anyway.

    Generally, that will vary between vehicle architectures. The JK itself was an oddball compared so some of the other FCA vehicles.

  6. Hi Chad,

    I wonder if You could help me in my… let’s name it “project”.
    Since a while, I have Jeep WJ 2.7 CRD with Mercedes gearbox 722.6 (or NAG1, as Jeepers call it). From the moment I bought this car, there’s question in my mind, if I can get information about current gear and lock-up status from CAN bus, then send it to led segment display. The point is, I have to know messages that contain such information, so the best would be to sniff CAN communication and analyze it. I’ve gone through plenty of resources returned by Google, but the way You suggest it – to use Linux based sniffer – seems to be most acurately fit my needs. The point is, that my knowledge of Linux seems to be not enough to understand how to connect with Linux to my Bluetooth OBD2 interface. Here comes question to You, if You could describe, how to pair Linux with Bluetooth interface, then sniff communication on this device? I’d really appreciate such help, as after nine months of “creeping” around this subject, I feel that I am still virtually at the starting point.

Leave a Reply

Your email address will not be published. Required fields are marked *