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

NVSExplorer - The ESP32 flash provisioning toolkit

This part of SiliconTorch has its own documentation

SiliconHeater - The config REPL using NVSExplorer's API

Ignites the SiliconTorches by remote-configuring them through MQTT.

This part of SiliconTorch has its own documentation

FxCyanF aka CyanLights 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!