Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Bidirectional communications with (RGB) LEDs
Date: Thu, 2 May 2024 22:55:52 -0700
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <v11u9g$cj91$2@dont-email.me>
References: <v0uorl$3fc1e$1@dont-email.me>
 <66346bcb$0$3711205$882e4bbb@reader.netnews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 03 May 2024 07:56:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7ff8d649110e8370d6cf8434bf1d67f6";
	logging-data="412961"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19XEzfCG+TjuxroYtpzxCTq"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:cqeB/OX5WA24TrHhFmGOn6lz6rM=
Content-Language: en-US
In-Reply-To: <66346bcb$0$3711205$882e4bbb@reader.netnews.com>
Bytes: 4726

On 5/2/2024 9:44 PM, bitrex wrote:
> 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?

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.