CyanLight
=========

Evolved from a "Simple `PT4115`-BreakoutBoard" we now have a full blown electronics and software project!

`CyanLight` now stands for the complete light and animation system which I'm developing for my appartement.

It consists of multiple hardware and software layers with a possible full stack-up looking like this from the bottom upwards:

- `CyanLight v[10W].1` - `PT4115` board (LED current control)  
- `CyanLightControl` - `ESP32` board outputting some `PWM` signals  
- `SiliconTorch[C++]` - `ESP32` firmware implementing protocols like `CyanBus` and `FxCyanF`  
- `CyanBus` - `RS485` serial protocol for packetized data streaming  
- `FxCyanF` - `LED` animation protocol  
- `CyanBusInjector` - `Ethernet` to `CyanBus` bridging board  
- `SiliconTorch[PY]` - High-Level device control via `Python`  

The last mentioned layer would then run on some SBC in a drawer and do the animation rendering. But what if this is not the end?  

Big things are on the way! Source-less animation building coming soon™!


`CyanLight` PCBs
----------------

Section moved to the [PCB README file](/pcb/README.md)


`FxCyanF` aka `CyanLight`s network protocol
--------------------------------------------

### Introduction

`CyanLight` makes use of a next generation network protocol featuring a higher hardware abstraction and up to `32 bit` color depth compared to the rigid `8 bit` definition of `FxBuffer`. 
Both protocols share the same basic concept: Time critical animation data is sent via fire-and-forget channels like `UDP` or `IrDA` while for device information and configuration a slow but stable channel is used.


### General Architecture

`FxCyanF` constists of the following protocols:

- `MQTT` for configuration als device status
  - animation data *may* be sent over `MQTT` too, but this is only recommended for very slow animations or setting of a constant mood in your living room
- `UDP` for animation data
- `CyanBus` (`RS485`) for animation data
- ~~`IrDA` for animation data~~


### The `MQTT` protocol

**[TODO!]**


### The `UDP` protocol

**[TODO!]**


### The `CyanBus` protocol stack

**[TODO!]**


### ~~The `IrDA` protocol~~

There won't be any `IrDA` as R&D discovered the following problems:

- The "classical" low-bandwidth chips for e.g. TV remotes aren't usable for UART communication. At `9600 Baud` there is half text half garbage, at `4800 Baud` we got 2-3 wrong chars per line (~40 chars).
- **ANY** higher-bandwidth `IrDA` chips are either very expensive (8$ for `LT1328` IF you even get one) and the `16 MBaud` ones are completely ungettable and 2-3x more expensive!

**⇨ `IrDA` is unfeasible!**