mirror of
https://github.com/hyperion-project/hyperion.ng.git
synced 2023-10-10 13:36:59 +02:00
cleanup
Former-commit-id: b2dbb71c420528b78fd374dbcdba36bf4139c1b4
This commit is contained in:
brindosch
parent
8310a6d9d0
commit
04414b11b9
@ -1,66 +0,0 @@
|
||||
BACKGROUND
|
||||
---------------------------------------------------------
|
||||
The UDP led device type can be used to send LED data over UDP packets.
|
||||
It was originally designed to support an ESP8266 Wifi module based WS2812
|
||||
LED strip controller.
|
||||
|
||||
I've used this to support :
|
||||
- A string of 600 LEDs as xmas decorations
|
||||
The effects development kit is great for these scenarios
|
||||
|
||||
- a 61 LED collection of concentric circles
|
||||
This has been used as a "night light" and a super lo-res
|
||||
TV
|
||||
|
||||
In each of these cases, the hyperion-remote iOS app is a great way to
|
||||
control the effects.
|
||||
|
||||
|
||||
CONFIG
|
||||
---------------------------------------------------------
|
||||
Simple example for devices that support a raw binary protocol.
|
||||
"device" :
|
||||
{
|
||||
"name" : "MyPi",
|
||||
"type" : "udp",
|
||||
"output" : "esp201-0.home:2391", "protocol" : 0,
|
||||
"rate" : 1000000,
|
||||
"colorOrder" : "grb"
|
||||
},
|
||||
|
||||
|
||||
|
||||
If you are using an ESP8266/Arduino device with a long LED strip, you chould use this alternate protocol.
|
||||
The ESP8266/Arduino doesnt support datagram re-assembly so will never see any udp packets greater than 1450.
|
||||
"device" :
|
||||
{
|
||||
"name" : "MyPi",
|
||||
"type" : "udp",
|
||||
// "output" : "esp201-0.home:2392", "protocol" : 2, "maxpacket" : 1450,
|
||||
"rate" : 1000000,
|
||||
"colorOrder" : "rgb"
|
||||
},
|
||||
|
||||
PROTOCOL
|
||||
---------------------------------------------------------
|
||||
Simple UDP packets are sent.
|
||||
|
||||
Packet Format protocol 0:
|
||||
3 bytes per LED as R, G, B
|
||||
|
||||
Packet Format protocol 2:
|
||||
0: update number & 0xf;
|
||||
1: fragment of this update
|
||||
2: 1st led# of this update - high byte
|
||||
3: 1st led# of this update - low byte
|
||||
4..n 3 bytes per LED as R, G, B
|
||||
|
||||
Packet Format protocol 3: (simple TPM2.net implementation)
|
||||
0: 0x9C
|
||||
1: 0xDA
|
||||
2: number of databytes (leds * 3) - high byte
|
||||
3: number of databytes (leds * 3) - low byte
|
||||
4: fragment number (1-255)
|
||||
5: number of fragments (1-255)
|
||||
6..n: 3 bytes per LED as R, G, B
|
||||
n+1: 0x36
|
||||
Binary file not shown.
@ -1,165 +0,0 @@
|
||||
// Automatically generated configuration file for 'Hyperion daemon'
|
||||
// Generated by: HyperCon (The Hyperion deamon configuration file builder)
|
||||
// Created with HyperCon V1.00.0 (11.03.2016)
|
||||
|
||||
{
|
||||
/// Device configuration contains the following fields:
|
||||
/// * 'name' : The user friendly name of the device (only used for display purposes)
|
||||
/// * 'type' : The type of the device or leds (known types for now are
|
||||
/// APA102, Adalight, AdalightAPA102, AmbiLed, Atmo, Hyperion-USBASP-WS2801, Hyperion-USBASP-WS2812, Lightberry, Lightpack, LPD6803, LPD8806, Multi-Lightpack, P9813, Paintpack, PhilipsHUE, PiBlaster, SEDU, Test, ThinkerForge, TPM2, WS2801, WS2812b, None)
|
||||
/// * [device type specific configuration]
|
||||
/// * 'colorOrder' : The order of the color bytes ('rgb', 'rbg', 'bgr', etc.).
|
||||
///
|
||||
/// * 'Specific for AtmoOrb:
|
||||
/// * 'transitiontime' : Set the time of transition between color of Orb (not implemented)
|
||||
/// * 'port' : Multicast UDP port
|
||||
/// * 'numLeds' : Number of leds in Orb
|
||||
/// * 'orbIds' : The Orb ids to use
|
||||
/// * 'switchOffOnBlack': Define if Orb is to switch off when black is detected
|
||||
"device" :
|
||||
{
|
||||
"name" : "MyPi",
|
||||
"type" : "atmoorb",
|
||||
"output" : "239.15.18.2",
|
||||
"transitiontime" : 0,
|
||||
"port" : 49692,
|
||||
"numLeds" : 24,
|
||||
"orbIds" : "1",
|
||||
"switchOffOnBlack" : true,
|
||||
"colorOrder" : "rgb"
|
||||
},
|
||||
|
||||
/// Color manipulation configuration used to tune the output colors to specific surroundings.
|
||||
/// The configuration contains a list of color-transforms. Each transform contains the
|
||||
/// following fields:
|
||||
/// * 'id' : The unique identifier of the color transformation (eg 'device_1') /// * 'leds' : The indices (or index ranges) of the leds to which this color transform applies
|
||||
/// (eg '0-5, 9, 11, 12-17'). The indices are zero based. /// * 'hsv' : The manipulation in the Hue-Saturation-Value color domain with the following
|
||||
/// tuning parameters:
|
||||
/// - 'saturationGain' The gain adjustement of the saturation
|
||||
/// - 'valueGain' The gain adjustement of the value
|
||||
/// * 'red'/'green'/'blue' : The manipulation in the Red-Green-Blue color domain with the
|
||||
/// following tuning parameters for each channel:
|
||||
/// - 'threshold' The minimum required input value for the channel to be on
|
||||
/// (else zero)
|
||||
/// - 'gamma' The gamma-curve correction factor
|
||||
/// - 'blacklevel' The lowest possible value (when the channel is black)
|
||||
/// - 'whitelevel' The highest possible value (when the channel is white)
|
||||
///
|
||||
/// Next to the list with color transforms there is also a smoothing option.
|
||||
/// * 'smoothing' : Smoothing of the colors in the time-domain with the following tuning
|
||||
/// parameters:
|
||||
/// - 'type' The type of smoothing algorithm ('linear' or 'none')
|
||||
/// - 'time_ms' The time constant for smoothing algorithm in milliseconds
|
||||
/// - 'updateFrequency' The update frequency of the leds in Hz
|
||||
/// - 'updateDelay' The delay of the output to leds (in periods of smoothing)
|
||||
"color" :
|
||||
{
|
||||
"transform" :
|
||||
[
|
||||
{
|
||||
"id" : "default",
|
||||
"leds" : "*",
|
||||
"hsv" :
|
||||
{
|
||||
"saturationGain" : 1.0000,
|
||||
"valueGain" : 1.0000
|
||||
},
|
||||
"red" :
|
||||
{
|
||||
"threshold" : 0.0000,
|
||||
"gamma" : 2.2000,
|
||||
"blacklevel" : 0.0000,
|
||||
"whitelevel" : 1.0000
|
||||
},
|
||||
"green" :
|
||||
{
|
||||
"threshold" : 0.0000,
|
||||
"gamma" : 2.2000,
|
||||
"blacklevel" : 0.0000,
|
||||
"whitelevel" : 1.0000
|
||||
},
|
||||
"blue" :
|
||||
{
|
||||
"threshold" : 0.0000,
|
||||
"gamma" : 2.2000,
|
||||
"blacklevel" : 0.0000,
|
||||
"whitelevel" : 1.0000
|
||||
}
|
||||
}
|
||||
],
|
||||
"smoothing" :
|
||||
{
|
||||
"type" : "linear",
|
||||
"time_ms" : 100,
|
||||
"updateFrequency" : 60.0000,
|
||||
"updateDelay" : 0
|
||||
}
|
||||
},
|
||||
|
||||
/// The black border configuration, contains the following items:
|
||||
/// * enable : true if the detector should be activated
|
||||
/// * threshold : Value below which a pixel is regarded as black (value between 0.0 and 1.0)
|
||||
/// * unknownFrameCnt : Number of frames without any detection before the border is set to 0 (default 600)
|
||||
/// * borderFrameCnt : Number of frames before a consistent detected border gets set (default 50)
|
||||
/// * maxInconsistentCnt : Number of inconsistent frames that are ignored before a new border gets a chance to proof consistency
|
||||
/// * blurRemoveCnt : Number of pixels that get removed from the detected border to cut away blur (default 1)
|
||||
/// * mode : Border detection mode (values=default,classic,osd)
|
||||
"blackborderdetector" :
|
||||
{
|
||||
"enable" : false,
|
||||
"threshold" : 0.01,
|
||||
"unknownFrameCnt" : 600,
|
||||
"borderFrameCnt" : 50,
|
||||
"maxInconsistentCnt" : 10,
|
||||
"blurRemoveCnt" : 1,
|
||||
"mode" : "default"
|
||||
},
|
||||
|
||||
/// The configuration of the effect engine, contains the following items:
|
||||
/// * paths : An array with absolute location(s) of directories with effects
|
||||
/// * color : Set static color after boot -> set effect to "" (empty) and input the values [R,G,B] and set duration_ms NOT to 0 (use 1) instead
|
||||
/// * effect : The effect selected as 'boot sequence'
|
||||
/// * duration_ms : The duration of the selected effect (0=endless)
|
||||
/// * priority : The priority of the selected effect/static color (default=990) HINT: lower value result in HIGHER priority!
|
||||
"effects" :
|
||||
{
|
||||
"paths" :
|
||||
[
|
||||
"/opt/hyperion/effects"
|
||||
]
|
||||
},
|
||||
|
||||
/// The configuration of the Json server which enables the json remote interface
|
||||
/// * port : Port at which the json server is started
|
||||
"jsonServer" :
|
||||
{
|
||||
"port" : 19446
|
||||
},
|
||||
|
||||
/// The configuration of the Proto server which enables the protobuffer remote interface
|
||||
/// * port : Port at which the protobuffer server is started
|
||||
"protoServer" :
|
||||
{
|
||||
"port" : 19447
|
||||
},
|
||||
|
||||
/// The configuration for each individual led. This contains the specification of the area
|
||||
/// averaged of an input image for each led to determine its color. Each item in the list
|
||||
/// contains the following fields:
|
||||
/// * index: The index of the led. This determines its location in the string of leds; zero
|
||||
/// being the first led.
|
||||
/// * hscan: The fractional part of the image along the horizontal used for the averaging
|
||||
/// (minimum and maximum inclusive)
|
||||
/// * vscan: The fractional part of the image along the vertical used for the averaging
|
||||
/// (minimum and maximum inclusive)
|
||||
"leds" :
|
||||
[
|
||||
{
|
||||
"index" : 0,
|
||||
"hscan" : { "minimum" : 0.0000, "maximum" : 1.0000 },
|
||||
"vscan" : { "minimum" : 0.0000, "maximum" : 1.0000 }
|
||||
}
|
||||
],
|
||||
|
||||
"endOfJson" : "endOfJson"
|
||||
}
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
@ -1,79 +0,0 @@
|
||||
Fadecandy: Open Pixel Control Protocol
|
||||
======================================
|
||||
|
||||
The Fadecandy Server (`fcserver`) operates as a bridge between LED controllers attached over USB, and visual effects that communicate via a TCP socket.
|
||||
|
||||
The primary protocol supported by `fcserver` is [Open Pixel Control](http://openpixelcontrol.org), a super simple way to send RGB values over a socket. We support the standard Open Pixel Control commands, as well as some Fadecandy extensions.
|
||||
|
||||
Socket
|
||||
------
|
||||
|
||||
Open Pixel Control uses a TCP socket, by default on port 7890. For the best performance, remember to set TCP_NODELAY socket option.
|
||||
|
||||
Command Format
|
||||
--------------
|
||||
|
||||
All OPC commands follow the same general format. All multi-byte values in Open Pixel Control are in network byte order, high byte followed by low byte.
|
||||
|
||||
Channel | Command | Length (N) | Data
|
||||
---------- | --------- | ---------- | --------------------------
|
||||
1 byte | 1 byte | 2 bytes | N bytes of message data
|
||||
|
||||
Set Pixel Colors
|
||||
----------------
|
||||
|
||||
Video data arrives in a **Set Pixel Colors** command:
|
||||
|
||||
Byte | **Set Pixel Colors** command
|
||||
------ | --------------------------------
|
||||
0 | Channel Number
|
||||
1 | Command (0x00)
|
||||
2 - 3 | Data length
|
||||
4 | Pixel #0, Red
|
||||
5 | Pixel #0, Green
|
||||
6 | Pixel #0, Blue
|
||||
7 | Pixel #1, Red
|
||||
8 | Pixel #1, Green
|
||||
9 | Pixel #1, Blue
|
||||
… | …
|
||||
|
||||
As soon as a complete Set Pixel Colors command is received, a new frame of video will be broadcast simultaneously to all attached Fadecandy devices.
|
||||
|
||||
Set Global Color Correction
|
||||
---------------------------
|
||||
|
||||
The color correction data (from the 'color' configuration key) can also be changed at runtime, by sending a new blob of JSON text in a Fadecandy-specific command. Fadecandy's 16-bit System ID for Open Pixel Control's System Exclusive (0xFF) command is **0x0001**.
|
||||
|
||||
Byte | **Set Global Color Correction** command
|
||||
------ | ------------------------------------------
|
||||
0 | Channel Number (0x00, reserved)
|
||||
1 | Command (0xFF, System Exclusive)
|
||||
2 - 3 | Data length (JSON Length + 4)
|
||||
4 - 5 | System ID (0x0001, Fadecandy)
|
||||
6 - 7 | SysEx ID (0x0001, Set Global Color Correction)
|
||||
8 - … | JSON Text
|
||||
|
||||
Set Firmware Configuration
|
||||
--------------------------
|
||||
|
||||
The firmware supports some runtime configuration options. Any OPC client can send a new firmware configuration packet using this command. If the supplied data is shorter than the firmware's configuration buffer, only the provided bytes will be changed.
|
||||
|
||||
Byte | **Set Firmware Configuration** command
|
||||
------ | ------------------------------------------
|
||||
0 | Channel Number (0x00, reserved)
|
||||
1 | Command (0xFF, System Exclusive)
|
||||
2 - 3 | Data length (Configuration Length + 4)
|
||||
4 - 5 | System ID (0x0001, Fadecandy)
|
||||
6 - 7 | SysEx ID (0x0002, Set Firmware Configuration)
|
||||
8 - … | Configuration Data
|
||||
|
||||
Current firmwares support the following configuration options:
|
||||
|
||||
Byte Offset | Bits | Description
|
||||
----------- | ------ | ------------
|
||||
0 | 7 … 4 | (reserved)
|
||||
0 | 3 | Manual LED control bit
|
||||
0 | 2 | 0 = LED shows USB activity, 1 = LED under manual control
|
||||
0 | 1 | Disable keyframe interpolation
|
||||
0 | 0 | Disable dithering
|
||||
1 … 62 | 7 … 0 | (reserved)
|
||||
@ -1 +0,0 @@
|
||||
23f1b917ec588d71521aa698edf446a2e8c0ea5d
|
||||
Loading…
Reference in New Issue
Block a user