Bidirectional communications with (RGB) LEDs

[Don Y]

I have an RGB LED on each device to convey status information
to the user (there are many "states" of interest). I also
use this to communicate with a bit of test/configuration/debug
equipment instead of exposing an "electrical" connection to
the user (it's easy to mate something physically when you just
need LIGHT to bridge the gap).

As I don't want this to COST anything (even a two-pin electrical
connector has cost), I've implemented a really crude protocol
that seems reasonably reliable (again, this is tightly coupled).

But, I only get a few hundred bits per second out of the interface.

For the configuration activities, this is sufficient as I can
take "many seconds" to install "secrets", etc. I don't really care
about incident ambient light triggering any unintentional
transactions, etc.

But, as a diagnostic/debug hook, it is sorely limited -- even if
I tokenize the interface.

Using more than one of the LEDs in the package would likely
make matters worse (as I don't see any easy way to create different
"channels" between emitters/detectors).

Currently, I use an extra pin to allow me to drive the LED or
reverse bias it to (indirectly) sense photocurrent. No other actives
involved and the software is pretty trivial.

Any other approaches I can explore to increase the thickness of the pipe
without adding to hardware costs? (even 9600 bps would be a big step up!)

[bitrex]

Post by Don Y
I have an RGB LED on each device to convey status information
to the user (there are many "states" of interest).  I also
use this to communicate with a bit of test/configuration/debug
equipment instead of exposing an "electrical" connection to
the user (it's easy to mate something physically when you just
need LIGHT to bridge the gap).
As I don't want this to COST anything (even a two-pin electrical
connector has cost), I've implemented a really crude protocol
that seems reasonably reliable (again, this is tightly coupled).
But, I only get a few hundred bits per second out of the interface.
For the configuration activities, this is sufficient as I can
take "many seconds" to install "secrets", etc.  I don't really care
about incident ambient light triggering any unintentional
transactions, etc.
But, as a diagnostic/debug hook, it is sorely limited -- even if
I tokenize the interface.
Using more than one of the LEDs in the package would likely
make matters worse (as I don't see any easy way to create different
"channels" between emitters/detectors).
Currently, I use an extra pin to allow me to drive the LED or
reverse bias it to (indirectly) sense photocurrent.  No other actives
involved and the software is pretty trivial.
Any other approaches I can explore to increase the thickness of the pipe
without adding to hardware costs?  (even 9600 bps would be a big step up!)

Is the LED configured as a receiver sensitive enough to do a
higher-order modulations like 4-ASK?

And if so maybe combine that with some kind of basic data compression
like Huffman coding

[Don Y]

Post by Don Y
I have an RGB LED on each device to convey status information
to the user (there are many "states" of interest).  I also
use this to communicate with a bit of test/configuration/debug
equipment instead of exposing an "electrical" connection to
the user (it's easy to mate something physically when you just
need LIGHT to bridge the gap).
As I don't want this to COST anything (even a two-pin electrical
connector has cost), I've implemented a really crude protocol
that seems reasonably reliable (again, this is tightly coupled).
But, I only get a few hundred bits per second out of the interface.
For the configuration activities, this is sufficient as I can
take "many seconds" to install "secrets", etc.  I don't really care
about incident ambient light triggering any unintentional
transactions, etc.
But, as a diagnostic/debug hook, it is sorely limited -- even if
I tokenize the interface.
Using more than one of the LEDs in the package would likely
make matters worse (as I don't see any easy way to create different
"channels" between emitters/detectors).
Currently, I use an extra pin to allow me to drive the LED or
reverse bias it to (indirectly) sense photocurrent.  No other actives
involved and the software is pretty trivial.
Any other approaches I can explore to increase the thickness of the pipe
without adding to hardware costs?  (even 9600 bps would be a big step up!)

Is the LED configured as a receiver sensitive enough to do a higher-order
modulations like 4-ASK?

No. I treat the LED as a capacitor, precharging it "while dark".
Then, let it discharge based on photocurrent from a "nearby" emitter.
I indirectly "measure" this current by noting the time it takes to
cross a particular threshold.

In the absence of a nearby ACTIVE emitter, this takes "a long time".
(ditto for ambient light levels)

I don't care what about the magnitude of the capacitance or the
photocurrent or the threshold. I just "notice" what things are
nominally like and how they change when stimulated.

Pick a threshold (time interval) between these two extremes
and use that to indicate whether the LED is being illuminated
(by an external emitter) or not.

Because I own/design both sides of the link, I can ensure the
external emitter goes dark for an interval to allow the (receiving)
LED to transfer data to *it* (using a similar scheme -- why not?)

And, there's no reason that any of this has to be "fixed" and
can't, instead, be "relearned" each time a transaction takes place!

And if so maybe combine that with some kind of basic data compression like
Huffman coding

I can do better than Huffman as I know the content of all transactions.
So, a dialog *could* be:
23
985
16
4
3003
888
But, that doesn't mean I don't want to maximize the bandwidth of that
channel to maximize the vocabulary that I support!

[There are other communication mechanisms that are fatter pipes
but don't make the same sorts of guarantees about proximity.
(granted, one could design an optical repeater that spans
miles but that's not really likely or practical)]

I though I might be able to use the different wavelengths of
an emitter matched to their respective "detectors" but that's
iffy as the response of a particular "color" to other wavelengths
may confuse my thresholding scheme.