• Bidirectional communications with (RGB) LEDs

    From Don Y@21:1/5 to All on Wed May 1 18:04:47 2024
    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!)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to Don Y on Fri May 3 00:44:59 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to bitrex on Thu May 2 22:55:52 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)