I’m actually seeing some results from my Light Programmer. I’m reading a photoresistor using the analog comparator on an ATmega168. Check out my previous post about the hardware, then join me after the break to see what I changed to get things working, and to see the demo video.
The good news is that it works. In the video I successfully decode a message twice in a row. The bad news is that this is rare. I figure the sync between the JavaScript app and the microcontroller is lost during transmission about 60% of the time.
Input Capture
The last time I posted about this I was using the analog comparator edge interrupt to monitor the photoresistor. This worked but I was detecting multiple edges for each transition. I’ve moved to using the Input Capture circuit which is part of TIMER1.
The input capture can be triggered by the analog comparator. The only real difference with input monitoring is that there is no toggle mode. Because you need to detect both rising and falling edges to use Manchester Encoding, the edge detect will need to be toggled during every interrupt in order to capture both rising and falling edges.
Decoding the Message
Describing how Manchester encoding is a full post in itself. I followed Atmel’s application note (PDF) on the top and you should give it a good read.
Basically, the clock and data signal are rolled into one. Each ‘bit frame’ has two equal parts (called T). The transition that happens between those two parts IS the bit itself. Transitions that happen between these frames are not data, but just used to maintain the timing.
The trick here is to get the sender and receiver to be synced up. The sender starts by sending a bunch of ones, the receiver watches those until 2T has passed between edges, which indicates the receiver has synced with the sender.
I’m also using a preamble of 0x0F to make sure I’m not syncing in the middle of a message.
What’s Not Working
This is a good question. I’m often loosing sync, as indicated by the “LOST” message on the image above. In that case, I lost sync because the sender stopped ending data.
I suspect that the sloppy timing of the in-browser sending program is the culprit. I’d love to keep this a browser-based solution, but I don’t know a way to get lower-level access needed for timing. In the interim, I will probably take another small microcontroller and write code that makes it a programmer by flashing an LED. If that setup is reliable, then it’s a problem with the JavaScript for sure.
The Code
I’ve posted code for the microcontroller, as well as the JavaScript/HTML sending package over at Github.