Path: ...!news-out.netnews.com!postmaster.netnews.com!us14.netnews.com!not-for-mail
X-Trace: DXC=mViP_Z4naic[BhXBdRB`OfU5[F2hIijDo7J470dMQQ7kbnl:Bh6K7Qbdae@QSNdb=dbGkWcfGLXEnJ4o68AXA]=d63^FDd_VWmgR<@>HgL4:V`_[?n`d5S`@e
X-Complaints-To: support@frugalusenet.com
Date: Fri, 3 May 2024 00:44:59 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Bidirectional communications with (RGB) LEDs
Newsgroups: sci.electronics.design
References: <v0uorl$3fc1e$1@dont-email.me>
Content-Language: en-US
From: bitrex <user@example.net>
In-Reply-To: <v0uorl$3fc1e$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 39
Message-ID: <66346bcb$0$3711205$882e4bbb@reader.netnews.com>
NNTP-Posting-Host: 127.0.0.1
X-Trace: 1714711499 reader.netnews.com 3711205 127.0.0.1:51381
Bytes: 2627

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