-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jan 24, 2008 at 05:15:10PM -0800, James Newton wrote:
> That is a REALLY interesting idea... 
> 
> Bob has talked in the past about having an "unused" pin that sends out
> status info all the time in some special format...
> 
> If you send out status data in a serial stream fast enough and continuously,
> it should look more or less consistent when used to light the power on LED
> on the widget you are making. 
> 
> For no extra cost, you get a visible status data stream. 
> 
> Of course, you can't read it with the naked eye... Other than to note that
> the light goes out or comes on brighter when the uC stops running.
> 
> Then the question is what can you use to read it? What if the light pattern
> was the same as what a barcode reader would see if it was scanned over an
> area? So assuming your customer has a barcode reader connected to his or her
> keyboard (as is the case at a lot of POS terminals) then you just tell them
> to go to a web page that you have set up, and then point the barcode wand
> right over the power LED on your widget. Some JavaScript on the page parses
> the data stream, breaks it off in chunks and sends them to you via AJAX. 
> 
> Or perhaps IRdA is the better protocol? 
> 
> What do PDA's talk in when you "beam" contacts between units? 
> 
> At worst, you send them a "visible light to RS232 adapter" which everyone
> has laying around right?

I think I've got it...

A typical scenario in my projects is to have a bunch of leds controlled
by a master OE pin of some sort. I always connect those OE pins to a PWM
pin on the PIC, although, they may or may not actually implement
dimming, but the connection is there.

Now most of you guys have been focusing on various modulation strategies
that average out to a given brightness level. Given that this is
debugging info, we probably don't really need to actually pass that much
data around however, which means are bit rates can be low. That said, an
led has a heck of a lot of bandwith...

So instead make your data transmission extremely *short*, so short that
the brightness decrease isn't noticable. The average bit-rate will be
still low, but we've already decided that's ok.

I built a simple 1-pin unidirectional data transfer concept awhile back
where single byte data packets were prefixed with a 32-bit random
number. The reciever would then sample bits at the correct clock rate
constantly, and whenever that magic number appeared, sample the next
8-bits and call it data. Worked really nicely, and could even be fairly
error free with some simple tactics like replicating each data bit three
times/checksums/something.

My initial test assumed fixed baud rates, although a more intelligent
decoder could do stuff like determine the timing between the first bit,
(low->high->low) and sample based on that.

In all the whole device could be implemented in a little dongle with a
high speed visible wavelength photo-diode sensor, a pic to decode, and a
rs232 output at the other end.

- -- 
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHm1VC3bMhDbI9xWQRAiMIAKCsIdajea5Y4u7nwhSP0aV3LLTtUgCePobt
1O7DK6YDI6fgJiNIg9/IMeM=
=jNS8
-----END PGP SIGNATURE-----
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist