Aspects that brought this up
Philosophic:
Is there only one way to think about the future? The one with more technology, more devices connected together generating huge amounts of data? Or could we think is the other way round: which is the minimal amount of technology and information that helps me to solve the problem I think about?
I tend to think in the later way quite often.
So the main idea is: What is the bare minimum I want from a smart wrist watch? To me it's -besides the obvious time/date- to remind me of appointments/things not to forget. Most of the time the reminder itself is enough, say if the watch vibrates/beebs, I instantly know what it was about without looking what the subject actually is.
Retro:
I can still remember the fascination I experienced as a boy when I first looked on the LED display of the first pocket calculators (hp and alike). So I wanted to biuld a wrist watch with that display for quite a while.
So as style will be one of those "driver watches", where you can see the Display without take the hand from the steering wheel or in my case from handlebar of my recumbent.
But not only the hardware design should be retro, by using a LED bubble Display, but also by using a data transmission, which allready exists for decades, the DCF77 signal.
And remember this is the technology which was used, when mankind started space travelling!
Hacking/Connecting:
The DCF77 signal is ment to submit the actual -atomic correct- time once every minute, by sending 0 ans 1 bits, which are represented by manupulating the waveform with Amplitude-shift_keying (for details see DCF77 link above)
But it does it with a)some redundancy, b)some unused bits and c) some bits that never change. By using these unused information, it should be possible to send information, which could be decoded by the watch as other/additional information, e.g. an appointment with a alarm. By generating "wrong" parity bits on purpose no normal radio clocks would be harmed, even in the most unlikly case one of those will be within range of the sender.
(perhaps it could be also possible to transmit this information at higher speed)
As the sending device two ways are to be proved:
1) a monitor! Allmost any monitor is able to send the DCF77 signal by generating b/w images n the "right speed".
Monitor as sender
2) building a sender from scratch (e.g.: DCF77-send-atiny85
(sorry for the german links, found no others)
Option 1) is to be prefered, since ylmost any device with a display could be used as a "sender"
My "non studio-quality" concept video:
System Design Diagramm
The design is really simple:
Just an arduino connected to: a DCF77 receiver, the bubble Display, a lipoly Battery, some buttons (for triggering the display, init receiving etc.), virbra motor and/or piezo speaker for feetback.
The official DCF signal triggers the correc time (perhaps a RTC is needed as backup) and a modified signal is used to put extra information into the watch, like alarms appointments or whatever is transmitted.
The modified signal can be send from a Monitor, by genarating b/w images in the rigt "speed" to make it send a 77,5kHz em-wave, like mentioned above in the Hacking section.
Or if that won't work a own short range sender is to be build.
This is, of cozrse the test setup. The goal is a custom arduino board with most of the components "on board"
The monitor transmitter is a nice idea, but I wonder if the sync pulses would interrupt the signal enough to throw it off, and make it useless. Are you using a CRT monitor? An LCD wouldn't give off nearly enough noise, I'd think.
Still, 77.5KHz, they make sound cards that can output up to 192KHz. Including USB ones, for convenience. Or maybe your motherboard's sound chip supports it. That might be a better alternate route. Just send square waves at approximately the right signal.
I dunno how well you can squeeze 77.5 into 192, wouldn't give an exactly even ratio for the pulses... Perhaps use a lower frequency and rely on harmonics? Or possibly, perhaps the sound card has a programmable rate for it's DAC? Since they can do 44.1KHz and others, maybe it's clock can be programmed to 75.5?
I'm just throwing ideas from the top of my head, but it's something to consider I think.
Other options... Maybe just an Arduino or the like? Should be possible to toggle a pin at that speed, then just use a wire for antenna. Somebody on a forum mentioned a 2.6MHz toggle rate, by bypassing Arduino's pin functions and using something a little lower level. Not as far as raw machine code, but just a bit lower than the convenient top-level library stuff.