+
So at first glance we were thinking there wasn’t much special about this clock. It’s based on an Arduino and displays the time using a character LCD screen. But then we realized that there’s no battery-backed RTC and no buttons. How the heck do you set the time on this thing? [Mossblaser] is using a light programmer to set the time using a computer screen.
We’ve tried nearly the same data transfer technique before, using a white and black flashing computer screen to push Manchester encoding to a light dependent resistor. We were met with limited success, but you can see that [Mossblaser’s] rig is much more reliable and we think there’s a few reasons behind this. First, he’s only sending five bits per seconds, a very slow speed when it comes to digital transmissions. This helps to make up for slow LCD screen refresh. Also, the LDR is surrounded by material on the back of the case that will help to block out ambient light. And finally, he’s using a smaller part of the screen instead of flashing the whole thing. This may result in more accurate timing. You’ve got to admit, this is pretty slick!
http://www.youtube.com/watch?v=T5hS6n_OzEQ
http://en.wikipedia.org/wiki/Timex_Datalink
I used to have a Timex Ironman Triathlon Datalink watch that did the same thing. You could download names and phone numbers to the phone for pseudo-PDA utility. You downloaded a program to your PC, entered the data, hit download, and it flashed your CRT monitor to send the data to the phone.
Hey I remember that watch 🙂 I think I still have mine, though likely the battery self-destructed years ago 🙁
Neat idea to use the screen to send data. Every computer has different I/O devices, that often require complex circuitry to interface to. But every computer has a screen!
But, it seems to me that all clocks depend on some external human reference to tell them what time it is… except a sundial. It directly uses the sun.
Could one build a clock that uses sunlight to detect and set itself to the correct time and date? It would need an offset, unless you happened to live right in the center of a time zone. But that’s just human meddling with nature. 🙂
Doh… LDRs are terrible for obtaining high speeds, some have a release time of seconds. They’re good for detecting sunlight or slow variations acting themselves as filters due to their ultra low bandwidth, but they’re absolutely the worst choice for anything involving data communication.
If he used a photodiode or phototransistor he would obtain much higher speeds.
In this case the limitation was definitely making the sender send data fast enough without using something running closer to the hardware rather than the LDR’s response (though as you say this is yet another upper-bound on this system’s performance).
Another thought… Given that you’re just blinking a box on the screen, could you also allow setting it with a flashlight, by blinking it on/off?
Morse code would be an obvious candidate. If you only need the numbers, they are very easy to remember. Or for folks that don’t want to learn even that, it could just be 1 blink for 1, 2 for 2 etc.
Funny you should say that, I actually tested the sync detection of this using a torch with a “blink” mode on it before actually writing a program to flash the screen. As for Morse code, yes though I’d probably still use binary and modulate the duration of the flashes (which would also allow the computerised version to transmit faster for a given screen performance). My choice of M’cr encoding is however was also due to sentimental reasons.
@leeahart
If one goes for “manual modulation”, and there is no need to do that from a distance of a few meters, a single button is still better. The display can then provide some dynamic hints to make it understandable by everyone.
I almost thought this was a clock that knew what time it was based on sunlight exposure.
You could actually build a clock that would keep time based on the sunrise and sunset times and you’d never have to set it, even initially. However, if you wanted to make it a clock that didn’t ever need setting, you’d need it to sit around in one spot for at least a year (well, maybe 6 months if you just detect an equinox).
I think that could be worked out without knowing your position, once you tracked light for a year. It would certainly be a neat clock. One that learns time. It could start out with estimates, and you could just watch over the course of a year as the clock “grew up” and became accurate. That would be kind of a neat project!
“Your clock is off by 15 minutes!” “Oh, it just hasn’t learned how to keep time yet.”
Wow did I talk about this yesterday or what??? Thanks HAD!!
LDRs aren’t a bad choice for this, qwerty. They naturally filter out the screen flicker rate, yet are fast enough for reasonable data rates.
LDRs are slow to become fully dark-adapted, but that’s not important here. They are plenty fast enough when going between two relatively bright levels (1-10 msec).
I wonder what kind of transfer rates can you get using a method like this. It’d be great to be able to clip something to the side of my LCD and transmit data like that. Not having to worry about specialized ICs or level converters just to send a few bits of data.
Using this exact method, it’s pretty slow. Video monitors are designed for the persistence of the human eye, where anything faster than about 30 frames/second blurs together. If every other frame were on or off, that’s a data rate of 15 bits/second.
But, think outside the box… WAY outside. The human eye is masterful at perceiving color, and position. Thus video monitors are capable of hundreds or even thousands of unique colors.
So the way to get a higher data rate is to change the color of the pixels (so 15 bits/sec becomes 15 colors/sec, and each color provides 8 or 16 or possibly even 24 bits of data.
Then, nothing says that you can’t have separate parallel data streams for each pixel. There could be perhaps a million pixels!
So, the ultimate extreme of this method is to have a color camera look at the screen, and interpret a “video” not as images, but as data! 🙂
I remember seeing some analog video recordings where a few top lines are obviously dedicated to a binary-encoded timestamp (one of those several-pixel squares is toggling each second, etc). Don’t know an official name of this method. Also the idea is to simply have more optic inputs. Crosstalk might pose some problems, though.
@saimhe – I believe you are talking about Vertical interval timecode ( VITC )
QR codes on the screen anyone?
How about a clock that learns the time and date by detecting its geographic location and using a database of sunrise and sunset times.
Deliciously inaccurate and complicated “light programming.”
Thats what I suggested. :-p
However, it can’t know what time sunrise is without already knowing what time it is. The only way to make it a clock you truly never have to set is to let it detect sunrise and sunset every day until it hits an equinox. Then it would know local time, which may still vary by actual time a bit unless you’re in the logical center of a time zone.
It would likely never be totally accurate but it would be a really cool art installation to build a clock that “learns” how to keep time over a long timespan.
I should read these things more thoroughly!
The GPS would allow it to cheat, which is amusing in its own right because GPS sends the time and date and it would be ignored. The clock would already have an averaged pattern of day lengths, and because it already knows where it is, it would sooner or later become accurate. Obviously it’d be solar powered and potted in something perfectly clear.
I like your idea of it not knowing its location, and yes it might become very accurate, but as you point out, it may always be an amount of time out relative to its position in a timezone.
It could become very accurate, but would still have an offset (from your position within the time zone).
I wonder if the offset could be dealt with by its physical position? Include a compass, so rotating it provides an offset? Or a tilt sensor to do it?
I used the same principal for similar application. I archived 18 bit/s (~80 % success for 36 bits): Description and Source
When testing this out on a decent computer I think I achieved something similar (certainly much faster than here). Unfortunately I was far too lazy to implement error correction and so for the sake of the project it seemed much simpler to just slow everything right down.
Very impressed by your project, really nice and professional looking case, how did you make it? Is it some standard extrusion/end-caps or something custom?
I obtained an RGB-Sensor (3 photo diodes with filters) for an improvement. That should eliminate one major issue for high speed: The significant jitter of the non-realtime transmitter-hardware by using one wavelength for clock signal. Furthermore the speed can be at minimum doubled because no Manchester encoding is required when using a clock signal.
The case is made from a middle tube (steal clothes rail) and two end caps with end plates. The end plates are made from 0,7 mm PMMA and hold by the end caps. The end caps are made from thin walled PVC tubing (cable conduit). The PVC tube segments are heated above there glass transition temperature with hot air and pushed then over the ends of the middle tube (thick leather gloves are needed). After that some sanding is required for a nice looking finish.
The whole process can be done really fast und very cheap. The result is a really rugged case that can be fitted to the length of the circuit board and battery.
Photo of an other device (usb-wlan card with SMA-connector) with the same case type: “Simple DIY case for small wares“