Saturday, July 13, 2013

The kit is on sale

A small batch of these kits are now for sale, complete with a special cable harness for nice plug-and-play installation. The installation itself takes about 10 minutes. Link to installation guide.

The complete plug-and-play interface kit can be purchased for €65 (includes shipping).
Contact for more details and current availability status.

Update: the kits are out of stock at the moment. When they become available again, this page will be updated, but if you're interested in the kit, send an e-mail to the above address anyway, then there's a fair chance you get notified when they are back in stock.

Friday, July 5, 2013

SID display working nicely

Been playing with the SID communication protocol a little and now the Aux-In adapter properly displays it's own text on the SID, when the aux input is selected. No blinking text when buttons are pressed on the head unit and it politely goes quiet when other devices (Park Assist, ACC, TWICE) need to display their messages.

Also implemented a customization mode, so now I can change the text to whatever I want without removing the box from the car, using radio buttons 1 & 3 to navigate and 2 & 5 to pick characters to display. The text is automatically stored in EEPROM and reloaded next time.

Update: I've had some reports, that the SID text display is not reliable on (some?) 9-3's (flickering). So for now, the SID text is considered experimental on 9-3's.

Thursday, March 14, 2013

Building a CD-changer Aux-In for Saab Radio

( Click here if you want one :)

The beginning
As probably quite a few owners of older Saab cars, I have been less than satisfied with the entertainment  options available in my Saab 9-5 factory head-unit. What comes over the air is usually not to my taste and messing with CD-s gets annoying fast. Replacing the HU didn't appeal either.
Existing options to add some sort of input to Saab radios were either bad quality or too hackish. The cleanest way in my opinion is to re-purpose the unused cd-changer inputs for best possible quality. At least that's what I told to myself, the real reason probably was that I wanted a new project to play with :)
There were a few other similar projects on the net, but none were quite what I had in mind. Besides, the fun is in the making, the result is just a bonus. Like solving crosswords.

That was about half a year ago. So, here I'm going to document, what I ended up doing and how it all turned out. Been happy with the result for almost 2 months now...

Not a new idea
The idea of using a microcontroller or computer to fake a cd-changer  is not new. There was the Audiotroll several years back, there is a similar interface available at, but also several open-source projects can be found on the Internet. One quite interesting is at, another one was beginning to take shape at

When researching the Saab I-Bus communication on the internet, Tomi Liljemark's site was extremely helpful and also quite a bit of useful information can be found at the forums. As I don't have a real CD-changer myself, I learned a lot about HU-CDC communication from analyzing other people's I-Bus logs on the forums, so kudos to Tomi and thank you all who have shared!

Faking a cd-changer:
To convince the HU (head unit) to enable CDC (cd changer) inputs, the CDC needs to respond to the HU requests in a particular way. There are 4 CAN messages involved with HU <-> CDC communication:

- 3C0h - CD Changer control (next, previous track, change disc, etc)
- 3C8h - CD Changer information (what discs are loaded, which one currently plays, etc).
These 2 are well documented  on Tomi's site. Message 3C0h can be ignored, since the virtual CDC is not going to change disks or tracks anyway. All it needs to do, is periodically send 3C8h messages and let HU know that it has discs loaded and is playing one of them.

- 6A1h - Audio head unit
- 6A2h - CD Changer status
HU uses messages 6A1h to command the CDC to wake up, go to sleep, etc. CDC responds with message 6A2h about it's current state. Not much more information was available about these and it was actually a little tricky, as it seems the HU gets upset when it receives 6A2h messages from CDC when it does not expect them. At least sending them by 1 sek interval, similar to the 3C8h message, did not work. What does seem to work, is to transmit 6A2h only as a response to 6A1h from HU. How the whole conversation is supposed to play out and what the message bits and bytes all mean, is still unclear, though.

1) Send 3C8h periodically, to let HU know about the status of CDC
2) Respond with 6A2h, when 6A1h request from HU is received

The Hardware
The emulator is built around a tinyAVR microcontroller and MCP2515 CAN controller. The CAN controller is clocked from it's own 16MHz crystal for accurate CAN frame timing, the AVR is running on it's internal RC oscillator.

The CDC inputs are balanced line inputs, so the single-ended signal from an audio source (phone, mp3 player, etc) must be converted to balanced signal. This is achieved with the following circuit:

The balanced line driver is operating on single +5V supply and is based on inverting level shifter (U4A, U4B) with second inverting stages (U4C, U4D) to create the complementary output signals. The outputs have 2,5V DC bias, but this is fine, because the CDC inputs at the HU side have decoupling capacitors.
The single 5V supply voltage is rather low and OPA4134 op-amps used here are not even rail-to-rail output, but real life testing has shown that this circuit works very well.
An alternative would have been dedicated line drivers, e.g. DRV135, but they need dual supply voltages, are considerably more expensive (although TI's free samples program helps) and don't really provide any benefits other than saving a few resistors.

The PC board
Both the CDC emulator and line driver fit on a single 50mm x 42mm double side PCB, using SMD components. The audio jack, ISP header and the two IDC connectors on the right are the only through-hole components. Size of the components (0805 passives and 1.27mm pitch IC's) still allow hand soldering with fine tip iron, but solder paste and any reflow technique is way better, once the learning curve is over :)

The layout (a bit modified):

and the real thing:

The board was made to fit a specific enclosure, but the sharp corners at the top right and bottom left were getting in the way of actually fitting the board in the enclosure with the audio jack mounted, so a little milling was needed. Not really a problem, though.

In the box:

The Firmware
The emulator firmware compiles with avr-gcc / Atmel Studio 6. With -o1 optimization level it comes out 640 bytes total, so it can easily fit even in ATtiny13, though the code can be compiled also for ATtiny25/45/85.
The various definitions are in the include file TinyEmu.h and the C source code (just the emulator, without SID text) in TinyEmu.c
All fuse bits are left to factory defaults.

The Cable
I will probably draw a proper diagram of the connections at some point, when I get the mood for it. For now, some pictures.
The cable harness is plug-and-play into existing Saab harness, between the Saab plug and the radio cage.
One end goes to the radio cage, where the factory plug was. The other end plugs into that factory plug.

The brown connector plugs into the adapter, so the adapter is easily removable after installation, if necessary. This came handy when trying out various versions of the firmware.

The 26-pin plug is the same as used in Saab's, so the cable properly fits in the back of the cage and holds in place just like the original:

Another one, with the adapter connected:

And this is what the Head Unit thinks when CDC is activated :)