Re: Bidirectional communications with (RGB) LEDs

On 5/1/2024 9:04 PM, Don Y wrote:

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