I picked up an Open Workbench Logic Sniffer from SeeedStudio. This is a pretty useful tool for the price.  I had only seen someone work with a logic analyzer before so I had to do some learning before I could start to use it. If you end up getting one, I found this page to be a pretty good documentation hub. I also watched some youtube videos about how to use it which were only somewhat helpful.

After acquiring a passing knowledge of how to use the logic analyzer, I needed a way to get to the logic signals from the tiny connector. So… this happened:

This wasn’t as hard as it could have been, but was still pretty hard especially since some of the wires fell off several times and I had to re-solder them in between the other wires without accidentally desoldering the other wires. And then, I attached some wire clippies to the wires above and to a breadboard where my logic analyzer was plugged in:

Great, so everything was plugged in and ready to figure out. But what exactly was I trying to figure out:

In case you can’t read upside down and backwards, it says “Please Wait”. I needed to figure out how it was sending those words over the 6 wires that the LCD was connected with. So then I connected my logic analyzer to my computer and started capturing data. The logic analyzer only captures logic for a short window of time, and the message seen above only appears on the screen for about 2 seconds so I had to be quick and precise. I would plug the printer in, then wait a second or so, and then hit capture on the logic analyzer software. This was not easy. After struggling for about an hour I finally got something that looked like the data I was looking for, but I wasn’t sure.

The logic analyzer software has options to analyze I2C, SPI, and a bunch of other types of logic. I was pretty sure that it was either I2C or SPI, but I didn’t know which one, and I didn’t know enough about either one to figure it out. I was finally to the point in my electronics hobbiest career where I had to learn I2C and SPI. I had a feeling that it was using I2C so I started with that.

A quick Google search of “I2C” lead me to this tutorial, and after a bit of reading I felt I had a pretty good understanding of the bus. Since I felt like the data was I2C, I decided to wait on learning the SPI bus. However looking back at and analyzing the logic capture file that I had saved, I realized that the software wasn’t analyzing the data as anything readable and there was a mysterious line that would go logic low when the data was sent. It was time to stop being lazy and learn SPI (which, in the end, wasn’t really that difficult).

Another quick Google search of “spi tutorial” lead me to a couple of tutorials (first one, second one). Turns out that mysterious line that would go logic low when data was sent was the slave select line. Plugging what I learned into the logic analyzer software and tweaking the settings a bit led me to a really geeky point in my life. I saw the following on the screen and was more excited than I’d like to admit:

“Please Wait” it said. I had learned the language of the LCD. It was using SPI! Now it was time to rig up my arduino to talk to the LCD. So then I did this:

Don’t worry, this isn’t the same connector from before that I soldered wires to for use with the logic analyzer (you were worried weren’t you). Luckily I had a similar Brother printer that used the same LCD and connector. I desoldered the connector from that printer very carefully since it’s mostly made of plastic and plastic tends to melt when you poke it with a soldering iron. Then I soldered on some wires and plugged it in to a breadboard with a 16MHz/5v Arduino pro mini on it. And then, I wrote some code using the SPI library to recreate what I was seeing on the logic lines. And then, I wired everything up and uploaded the code… And then it didn’t work.

My best guess was that, even though I was dividing the clock frequency by 128, 125kHz (16MHz / 128) was just too fast for the little LCD. hrm. Measuring the wavelength of the clock signal in the logic analyzer software showed me that the printer was sending data at 33kHz-ish. I had a 4.096MHz crystal lying around which, with the same setup, would get me to 32kHz. Close enough. I busted out my DIP Atmega328P, wired it up with the crystal, wired it to my Pocket Programmer, plugged it in, tried to program it, remembered that for some reason the pocket programmer only works with the old version of the arduino software, opened arduino version 22, sucessfully programmed the Atmega, and… no luck. Now I was really confused.

My best guess now was that I missed something when looking at the logic. Maybe there was something required at start up for the LCD to work. But I wasn’t about to try and get the timing perfect by plugging in the printer manually and manually clicking capture. That was ridiculous last time, and it took way too long to find the window of logic where the communication was happening. If I tried that method again, frustration and anger would happen, and something might be destroyed. I previously had an idea that I could use my controllable power outlet and some Java code to automate the process of plugging the printer in and pressing the capture button on the logic analyzer software.

I figured I could use some keyboard simulation to press the enter key with focus on the capture button, and that didn’t turn out to be very hard at all. I found that Java’s Robot class made it really easy to simulate the enter key being pressed. Now I needed to figure out how to connect to a device on a COM port, and read from it. This device would be an arduino connected to my controllable power outlet. However, doing this in Java turned out to be not so easy. In fact, apparently this is no longer supported in Java. That sucks. Now what to do.

I’d heard of people connecting to their arduinos using Python, but before I could try that I had to relearn Python. The version of Python for windows comes with a very in depth help tutorial, which I read for a couple of hours. Once I was familiar enough to do some basic tasks I started diving into python libraries. I quickly found PySerial (download) which would make it relatively easy to connect to a COM port and do read/write operations. Then after looking through a couple of other libraries I found one that would do keyboard simulation (tutorial).

I combined some proof of concept python scripts and created a script that would allow you to specify waiting times (in milliseconds) for the turning on of the power outlet and the pressing of the enter button. By changing these times (mostly just the power outlet time) I was able to capture data from right after the printer was turned on. There ended up being nothing really useful there, however I kept playing and found a set of wait times that would capture the beginning of the data transmission (which I had seen before when I found it manually). Looking more closely at this logic, I found a sequence of numbers (13, 72 ,9) being sent before each transmission. When I uploaded the program with this sequence of numbers at the beginning of the transmission and did some rewiring it said “Hi”.

the controllable power outlet setup

I had done it! I successfully reverse engineered the LCD. I turned it on and off a couple of times, dragged my wife over to show her my accomplishment, and then realized that there was something wrong. Occasionally when I turned it on, the letters would smear down so that there were ugly lines showing on the screen instead of the text that was supposed to be showing. It was great that I had figured out how to make something show on the screen, but I wasn’t finished. This project was not complete (are you tired of reading yet?).

"Hello World?" being smeared down the screen

My first guess this time was that there was noise in the lines and I needed some filtering caps. After looking at the PCB from the printer, I found that there were some capacitors on there that I had missed when recreating the circuit. So then, I measured the values with a multimeter and found some lying around that had the same value. But inserting these capacitors into my circuit did not fix the problem.

In my original measurements to figure out the ground and power lines of the LCD, I had found that there were 2 lines that read as 5v which were pin 1 and pin 3. I had previously noticed that with only pin 1 connected to 5v the LCD would not work at all, so I had connected pins 1 and 3 together so that they were both at 5v. This was my current setup. I tried the only other option of connecting only pin 3 to 5v, and voila!, the LCD was turning on and printing the text (now “Hello World?”) every time. However, the screen was much more dim than it was when it had occasionally worked with the previous setup.

I was starting to get the idea that pin 1 was the contrast pin, and, after testing my theory by plugging pin 1 into my 5v line on my breadboard after the text was already showing, I found that to the best of my knowledge that pin 1 was indeed a contrast pin. So now my idea was that I needed to pull pin 1 high after the text was already being displayed. I wired pin 1 to pin 12 on my ATMega chip (arduino pin 6) and rewrote my program to turn on  pin 6 after the text was being displayed. At this point I’m feeling like I should be really close to just stomping on the whole thing if it doesn’t work. It didn’t work (however it was surprisingly not that frustrating).

I had one last idea to try before I was ready to quit and write this project off as beyond my current knowledge. There were periods of hundreds of milliseconds that I had not seen in the logic. It was time to stop taking shortcuts and just figure the whole thing out, so I, once again, got out my controllable power outlet setup, and started precisely writing down everything that I saw in the logic. What I found (from my notes):

vcc goes high
<1ms passes
contrast goes high
133ms pass
ss, sck, and mosi go high
7ms pass

3 (decial) is sent (start of sequence 3, 40, 20)
7ms pass
40 (decimal) is sent
7ms pass
20 (decimal) is sent
40ms pass

10 (decimal) is sent
140ms pass

26 (decimal) is sent (before it was 13)
7ms pass
72 (decimal) is sent
7ms pass
9 (decimal) is sent
26ms pass

then the following in decimal all while ss is low:
192, 0, 255 (32x)
(ends about 1350ish)

about 1800ms pass

at 1000, 3232-ish (power wait, capture wait)
3 (decimal) is sent
1.2ms pass
40 (decimal) is sent
1.2ms pass
20 (decimal) is sent
48ms pass

10 (decimal) is sent
200ms pass

26 (decimal) is sent (before it was 13)
1ms pass
72 (decimal) is sent
1ms pass
9 (decimal) is sent
7ms pass

then the following in decimal all while ss is low:
192, 0, “Please Wait” converted to hex space filled (space is 32 decimal)

Turned out that I was still missing some things. The numbers 3, 40, 20, and 10 were being sent right after startup, and what I thought was a 13 before turned out to be 26 (a logic analyzer software fluke I’m guessing?). So I programmed my ATMega 328 to precisely reflect my findings and I held my breath… uh… It worked? It really worked! I turned it on and off a couple of times to test it, and I couldn’t seem to find anything wrong. Wow. That was a long process.

I began the process of cleaning up my code and found that most of the timing didn’t really matter. It didn’t even matter that I was using a slower crystal. Using a regular 16MHz arduino worked fine. It was the 3, 40, 20, 10 sequence that did the trick. If only I had looked at all of the logic first. Still the path I took made for a good learning experience.

I just finished writing up an arduino library to do some fancy stuff with it. Check out my video below. Thanks for reading, and I hope you got something out of it.

In short, the photoresistor keeps Q1 turned on until the oven light goes off. Once the light goes off, Q2 is switched on which turns on the buzzer. The potentiometer is the adjust for the circuit so that if you have some really odd circumstances then it’ll still work (although you could probably just use a plain ol’ resistor).

After some home style etching and a little bit of rigging, I got it soldered up and strapped to my oven. To use: turn on your oven, flip the switch on the sensor board, and wait till the thing buzzes. Your oven will be preheated and you will waste a lot less energy (real nice if you have a propane oven) than if you’re just manually walking over and looking to see if the preheat light has gone off.

some pictures:

Sorry for the lack of more pictures of the process. This is part way through the process of taking off the etch resist with acetone (see home style etching).

This is the front side of the completed board. I had to hack on a 9 volt plug which is actually the top of another disassembled 9 volt.

The back side of the sensor board. The photoresistor is inside of a rubber holder for a microphone. I’m not really sure what I got this out of, but it worked perfectly for isolating the sensor from outside sources of light.

And last but not least, this is the sensor in position on my oven. I used a couple of bent up large paper clips to hold the thing in place. The blue stuff is heat shrink tubing around the paper clips which insulates them where they could potentially cause a short.  There is a “Preheat” light under sensor board that is similar to the “Cleaning” light that you can see.

Turns out I waited a really long time to post about this project (wow! almost a year already). This thing has been incredibly helpful, especially if you’re super distractible like me.

16+ channels alone would do it for me, but this thing goes so much further than that by including the following and more: 2 way communication with the receiver, AMOLED Touch-Screen, Linux based UI, and the ability to add a Video receiver unit for real time preview and/or recording.

On top of all the Controller functions, the receiver unit will have internal accelerometers and a gyro as well as a modular design for easy modification.

Let’s just hope they get the funding they need to start making them.

Check out the project page for more information.

So we got tired of not being able to see what time it was when we were watching movies/shows on Netflix. We could have just bought a clock, but where’s the fun in that? I had an EM-406 GPS module and an ArduPilot lying around, and I heard about Sparkfun’s 12ft GPS Wall Clock so I figured I would give it a try.

Read more…

I’ve succeeded at making it autonomous… kind of… well it works most of the time. Before about a week ago it was a big mess of wires. Then I etched a circuit board so that it wouldn’t be a big mess of wires. Then i realized that I swapped the headers on the motor controller board… so again… it is a big mess of wires. To fix this I’m going to make a patch board that swaps the headers again…

Read more…

Supplies:

• A blank PCB (“copper clad”) to etch your circuit from (here’s what I got but any copper clad will work. Note: avoid the 0.127″, it’s too thick to put some leads all the way through)
• Sharpie (for etch resist)
• Muriatic acid – 20 Baume 31.45% (the 14.5% junk doesn’t work). Also take care not to murder yourself with this stuff.
• Hydrogen peroxide – 3%
• A glass container with a lid. Make sure that the lid is not airtight. If it is airtight, it can explode… acid everywhere… bad news.
• Nerd goggles (safety first)
• Particle respirator mask
• Automotive rubbing compound (from the auto parts store)

Read more…

I thought that I would have to learn AVR code in order to program my ATMega328P micro. Then I got to reading on the arduino.cc website and found out that by changing a setting in the arduino software’s preferences.txt file I could simply use the arduino software and arduino code for programming my chip.

Read more…

The number of gaps is a constant and so I will be able to count the number of revolutions of the track and measure the distance that the robot has traveled. Furthermore, by putting a gap counter (an emitter and a detector) on both the right and left tracks I will be able to calculate the angle that the robot has turned when it does so.

Read more…