an exact clock for a vintage car

Since I drive my vintage XJS not too often, I disconnect the battery. This is to prevent if from going flat before I want to use it the next time. Of course it would be better to install a special charger for classic cars. But there is no outlet in the underground car park. The car starts when I want to use it, so one could say: mission accomplished. If only there was no clock in the dashboard.  It doesn’t run when the battery is disconnected. Having to adjust the clock every time is not the solution I was looking for.

My first idea was to get a DFC77 radio clock with hands, and put it inside the case of the original dash clock. All the clocks that had hands were too big to fit into the case. So I ordered a small module with an LCD. The problem was that it had good reception at home, but not inside the car. The long waves seem to have a hard time penetrating the Faraday cage of the car body.

The next option that delivers exact time over the air is GPS. So I ordered a cheap GPS receiver from China, and built a prototype with an AtMega microcontroller and a small OLED. The prototype kind of worked, but after the first drive, the GPS module failed completely. So I ordered a better one from an AdaFruit reseller in Switzerland. This module still works very well, but I found out the hard way that it needs a very clean power source. The next problem were random failures and reboots of the micro controller. This turned out to be caused by memory overruns. They are harder to detect on a micro controller  than on a regular computer. The display needs a framebuffer in RAM, and for the GPS I need enough space to store and parse the full NMEA sentences. I tried to reuse and re-initialize the same memory for every reading, but that didn’t work out. Neither didn’t I find a similar controller with more RAM. If I was going to produce a number of devices I would for sure use a better controller, but as it is a one off prototype, I just used two AtMegas. One for the display, and one for the GPS.

GPS has no reception in tunnels and underground parking garages. So I planned to implement a simple counter that just increases the time when GPS reception was lost. But then I decided it was not important enough. Instead I wanted to proceed, and have the device ready in the car. But I couldn’t resist to display a leaper for when there is not reception.

In a classic car, everything should be in original condition, so I didn’t want to destroy the original clock. Instead I was looking to buy a used clock that didn’t have to be in working condition. The ones I found in Switzerland were too pricey for only the case. So I found one on ebay for £22 that was shipped from the UK.

The problem that remains is that the OLED sometimes initializes with a random dot pattern and stays that way until the next power cycle. It happened more when I had it connected directly to the main battery. But since I connected it the the dash back light, it never happened again. So maybe it is important how fast the voltage increases when power is switched on.

As usual, the code is on github.

image20150625_202655132 image20150625_201613328 IMG_2636 IMG_2638

sniffing i2c with the BusPirate

I received my BusPirate v4 a while ago, but didn’t really use it so far. That’s a cool analysis/debug tool for serial buses such as uart, spi, i2c and the like. For me i2c is the most interesting. From time to time, the communication doesn’t work as it should, and so far, I worked it out with trial and error. I hope the BusPirate can be of help in such situations in the future. So, here is my first test run.

The BusPirate is controlled through an uart textual interface:

minicom -D /dev/ttyACM1 -b 115200

When you connect to it, it performs a self test, and then you can choose the mode by entering m. In my case, that’s 4 for i2c. Next I get to choose between hardware and software. I don’t know the implications yet, but what I see is that hardware offers higher speeds, and locks up more often. Then I get to choose the bus speed. 100KHz is the standard. With ? you can always get a list of possible commands. (0) shows a list of available macros. (1) scans all possible addresses for connected devices, just like i2cdetect would do it on the computer. (2) finally is what I was after, that’s the i2c sniffer.

I was actually hoping it could find out why I’m having problems reading back a simple value from an AtMega8 to a RaspberyPi. The AtMega8 is at address 0x11 and the command to read the value is 0xA1. I verified with a serial connection to the AtMega8 that it has a proper value, but on the RaspberryPi I always get a 0. At least the command was received on the AVR as I could verify with the UART, but writing the value back is the problem. So here is what the sniffer outputs for the attempted read:

[[[][]][[[0x01+][0x04-[][[0x20+][[[[[][0x20-[][0x4C+][0x04-[][0x24+][0x20-][]]]

Let’s decipher those numbers. Plus means ACK and minus means NACK. Opening square bracked means start bit, and closing square bracket means stop bit. The expected sequence would be 0x22 (the address for sending to the AVR) 0xA1 (send back which value) 0x23 (the address for receiving from the AVR) 0x08 (or whatever value was stored on the AVR). But the above output doesn’t look like this at all. So, lets try to communicate from the BusPirate to the AVR directly. Here we go: Continue reading “sniffing i2c with the BusPirate”

AtMega breadboard header

A while ago, I ordered some AtTiny breadboard headers from tinkerlog.com. Unfortunately, they didn’t have any boards for AtMega’s left. The ones for the AtTiny’s are very handy, and I used them whenever prototyping something with an AtTiny. In fact, I used it almost whenever flashing an AtTiny. Many times I wished I had one of these tiny boards for the AtMega’s and at some point I even forgot that they existed. Often times I just included in ICSP header on the stripboard.

Last week I thought I must have such a board for the AtMega’s as well, and created one with a bit of stripboard. The wiring is not pretty, but the device works well, and is a real help when prototyping.

Fritzing layout on github

Adding a display to rfid time tracking

More than a year ago, I blogged here about using RFID to track presence times in the BORM ERP system. I used the system a lot since then. But the BlinkM was really limited as the only immediate feedback channel. To use it with multiple users, a display was needed. The default Arduino compatible displays seemed a bit overpriced, and the Nokia phone that I disassembled didn’t have the same display as I used for the spectrum analyzer. But these displays are available for a bargain from china. The only problem was that the bifferboard didn’t have enough GPIO pins available to drive the “SPI plus extras” interface. But i2c was already configured for the BlinkM.

So, the most obvious solution was to use an AtMega8 as an intermediary. I defined a simple protocol and implemented it as i2c and uart on the AVR. I also wrote a small python class to interface it from the client side. As I buffer only one complete command, I had to add some delays in the python script to make sure the AVR can complete the command before the next one arrives. Apart from that, it all worked well when testing on an Alix or RaspberryPi. But i2c communication refused to work entirely when testing with the bifferboard. Not even i2cdetect could locate the device. That was bad, since I wanted to use it with the Bifferboard, and the other two were only for testing during the development. I checked with the oscilloscope, and found out that the i2c clock on the bifferboard runs with only 33kHz while the other two run at the standard 100kHz. So I tried to adjust the i2c clock settings on the AVR, as well as different options with the external oscillators and clock settings, but I was still still out of luck. Then I replaced the AtMega8 with an AtMega168 and it immediately worked. Next, I tried another AtMega8 and this one also worked with the Bifferboard. I switched back and forth and re-flashed them with the exact same settings. Still, one of them worked with all tested linux devices, while the other one still refused to work with the Bifferboard. So I concluded, one of these cheap AVR’s from china must be flaky, and I just used the other one. Seems like that’s what you get for one 6th of the price you pay for these chips in Switzerland.

Apart from the display, I also added an RGB LED that behaves like the BlinkM before. And on top of that a small piezo buzzer. But since I could hardly hear it’s sound when driven with 3.3V, I didn’t bother re-soldering it when it fell off.

Now, my co-workers also started logging their times with RFID.

The code is still on github.

minimalist lasershow

For a long time I marvelled at sites with self built laser shows. There is truly amazing stuff out there. But most of them look like really lots of work. And with simple commercial units getting cheaper, I don’t know if all that effort can be justified. So I had a look at the commercial ones, and found out that DMX units are not enough if you want real-time control. I would need an ILDA connection for that. These units start at about CHF300. I’m considering it, but I’m not quite ready for the investment. To get started I wanted to toy a bit really cheap. I saw the posts where they glue mirrors onto loudspeakers for a long time, but that didn’t convince me. Then I saw someone using the lens mechanism of a CD-ROM for both axis simultaneously. That looked more interesting. Too bad, I disposed a CD-Rom drive just a week before seeing this.

I wasnt keen enough to drive the coils directly from the micro controller as in the instructable. Coils, like motors and relays are inductive loads that can induce high voltages in the opposite direction, once stopped. As the mechanism goes both ways, a h-bridge seemed appropriate. I had some L293D here which fitted the bill perfectly. To draw simple patterns, an AtMega8 should be enough, I thought. Because I had no more fitting sockets, I soldered it directly onto the PCB, hoping I wouldn’t have to remove it.

As I had no suitable mirror around, I cut out a small piece of a CD. I hot-glued it to a part of a paper clip, which ran through a hole of another small PCB, and hot-glued the other end to the lens. Applying voltage to the coils moved the mirror.

I wanted to draw a circle, but what I saw at the wall didn’t resemble to a circle at all. Debugging the thing, I discovered, that one of the four PWM outputs of the micro controller didn’t work at all. I read in the Arduino docs, that some PWM pins could be slower, so I avoided these from the start, but one didn’t work at all. I tried a couple of alternatives, also the slower ones, but no. Then I found out that the AtMega8 has only three PWM channels, and I only looked at the Arduino docs for the AtMega168 with which I did the first tests.

I’m sure with an AVR that has 4 PWM’s and a bit of tweaking, I should get better patterns. But with this design I’ll never get real-time laser show control, and it’s not suitable for ILDA test patterns. But it was fun experimenting nonetheless.

As usual, the code is at GitHub.

LED debugging the stereowrap hardware

I found out earlier that 5V is not enough to drive the shutter glasses. With my breadboard setup for stereowrap, I fed 12V to the op amps from an external source. Now that I moved the thing to a strip board, I added a step up converter that generates 12V from the 5V available on the USB port. I used an LT1301 which comes with an application note for exactly my use case. It was easy to implement and worked from the first try.

Then I temporarily switched from an arduino duemillanove to a leo stick. Although it’s a tiny clone which plugs directly into an USB port, it still seemed like a bit of an overkill. I thought of using one of the AtTiny’s for that project. As I was not too familiar with these yet, I first did a hello world blinking LED’s. Soon after, I learned that neither the Attiny45 nor the AtTiny85 have a hardware UART. Well, I thought, there is an arduino software serial library. Arduino libraries are generally very easy to use in the IDE. But as I programmed the chip directly this time I wanted to stay within CodeBlocks/CMake and use the arduino library from here. Continue reading “LED debugging the stereowrap hardware”

Make an RFID tag with an AtTiny and a coil

When I stumbled across this blog post, I was sure I have to try this at home. I had some interest in RFID for a while, but the Proxmark was too pricy for me just to play with. So this experiment came just right.

The attiny85’s were difficult to get in Switzerland, so I ordered them from Germany along with an ISP programmer. I think it would also work with other AtTiny’s for example the 45 is available from Conrad. The hex file is just 1.7 kB, so the AtTiny45 should suffice.

Continue reading “Make an RFID tag with an AtTiny and a coil”