LichtKrant - Revision history

Bertrik Sikken: /* UDP RGB565 interface */

2025-11-12T14:46:33Z

UDP RGB565 interface

← Older revision		Revision as of 14:46, 12 November 2025
Line 234:		Line 234:
	convert metaballs.gif rgb:- \|./ledbanner2udp		convert metaballs.gif rgb:- \|./ledbanner2udp
	(metaballs.gif was generated using https://github.com/bertrik/nyancat )		(metaballs.gif was generated using https://github.com/bertrik/nyancat )

			The software attempts to join multicast group 239.0.0.1 at port 1565 to receive UDP frames.
			If that fails, it opens a regular UDP unicast receive socket on port 1565 to receive UDP frames.

	The software contains an mDNS responder that allows the network interface to be addressed as esp-ledsign.local (instead of using the ipv4 address).		The software contains an mDNS responder that allows the network interface to be addressed as esp-ledsign.local (instead of using the ipv4 address).

Bertrik Sikken: /* Frame forwarder */

2025-11-09T15:20:30Z

Frame forwarder

← Older revision		Revision as of 15:20, 9 November 2025
Line 248:		Line 248:
	A C program (https://github.com/bertrik/lichtkrant/blob/master/ledbanner2udp.c ledbanner2udp]) accepts frames in the ledbanner internal frame format, converts the pixels to rgb565 (to make one frame fit in exactly one UDP packet) and forwards the frame to a configurable UDP host/port (ip address of the lichtkrant).		A C program (https://github.com/bertrik/lichtkrant/blob/master/ledbanner2udp.c ledbanner2udp]) accepts frames in the ledbanner internal frame format, converts the pixels to rgb565 (to make one frame fit in exactly one UDP packet) and forwards the frame to a configurable UDP host/port (ip address of the lichtkrant).

	The UDP destination port also supports a multicast address. ~~For~~ sending to a multicast address, the TTL is configured to 1 (local network).		The UDP destination port also supports a multicast address. When sending to a multicast address, the TTL is configured to 1 (local network).
			For multicast, the ledbanner script is configured for 239.0.0.1, port 1565.

	This program runs on the ledbanner pi, chained at the end of the 'pipeline' of image processes.		This program runs on the ledbanner pi, chained at the end of the 'pipeline' of image processes.

Bertrik Sikken: /* Frame forwarder */

2025-11-09T14:50:46Z

Frame forwarder

← Older revision		Revision as of 14:50, 9 November 2025
Line 247:		Line 247:
	=== Frame forwarder ===		=== Frame forwarder ===
	A C program (https://github.com/bertrik/lichtkrant/blob/master/ledbanner2udp.c ledbanner2udp]) accepts frames in the ledbanner internal frame format, converts the pixels to rgb565 (to make one frame fit in exactly one UDP packet) and forwards the frame to a configurable UDP host/port (ip address of the lichtkrant).		A C program (https://github.com/bertrik/lichtkrant/blob/master/ledbanner2udp.c ledbanner2udp]) accepts frames in the ledbanner internal frame format, converts the pixels to rgb565 (to make one frame fit in exactly one UDP packet) and forwards the frame to a configurable UDP host/port (ip address of the lichtkrant).

			The UDP destination port also supports a multicast address. For sending to a multicast address, the TTL is configured to 1 (local network).

	This program runs on the ledbanner pi, chained at the end of the 'pipeline' of image processes.		This program runs on the ledbanner pi, chained at the end of the 'pipeline' of image processes.

			An UDP frame is organised in 8 rows (top to bottom) of 80 pixels each (left to right) of 16-bit words.
			Each 16-bit word is constructed like this (big endian):
			* bits 15-11: red
			* bits 10-5: green
			* bits 4-0: blue
			This results in one UDP packet of 1280 bytes per image frame, which fits within the typical UDP frame size (max 1500 bytes).

	== Links ==		== Links ==

Bertrik Sikken: /* UDP RGB565 interface */

2020-08-17T14:05:01Z

UDP RGB565 interface

← Older revision		Revision as of 14:05, 17 August 2020
Line 236:		Line 236:

	The software contains an mDNS responder that allows the network interface to be addressed as esp-ledsign.local (instead of using the ipv4 address).		The software contains an mDNS responder that allows the network interface to be addressed as esp-ledsign.local (instead of using the ipv4 address).
			At startup, when no UDP frames have received yet, the display shows its IP address.

	=== Command interpreter ===		=== Command interpreter ===

Bertrik Sikken: /* Status */

2020-08-17T10:00:59Z

Status

← Older revision		Revision as of 10:00, 17 August 2020
Line 7:		Line 7:
	}}		}}

	== ~~Status~~ ==		== Features ==
	~~Status as of 2020/2/26:~~		* Reverse engineered it, I know how it works and documented it, the original controller board has been removed and replaced by an ESP8266.
	* Reverse engineered it, I know how it works and documented it, the original controller board has been removed and replaced by an ESP8266		* The sign can show 4-bit gradients in both red and green, blue is ignored.
	* ~~Software works, allowing arbitrary bitmap graphics to be sent over WiFi.~~ The sign can show 4-bit gradients in both red and green, ~~essentially it now has 8-bit colors instead of 2-bit~~.		* Arbitrary bitmap graphics can be sent to the display over WiFi, using an UDP protocol encoding one frame in one packet as 80x8 pixels in rgb565 format.
	* UDP ~~support has been added, allowing for sending a full 80x8~~ frame ~~as rgb565 data~~ in one ~~UDP~~ packet
	* Revspace now has a LED sign in ~~the kitchen~~

	Movie: https://www.youtube.com/watch?v=P8D3vtvg2U4		Movie: https://www.youtube.com/watch?v=P8D3vtvg2U4

Bertrik Sikken: /* Hardware modifications */

2020-08-17T09:58:19Z

Hardware modifications

← Older revision		Revision as of 09:58, 17 August 2020
Line 144:		Line 144:
	[[File:Lichtkrant_wemosd1.jpg\|right\|thumb\|Wemos D1 mini as sign controller]]		[[File:Lichtkrant_wemosd1.jpg\|right\|thumb\|Wemos D1 mini as sign controller]]

	~~So far I've made the following modifications~~:		Modifications:
	* ~~Removed~~ the controller board		* Remove the original controller board
	* ~~Soldered~~ a power connector on the center of the display PCB, on the footprint that was already present. This is now the main entrance for 5V power.		* Solder a power connector on the center of the display PCB, on the footprint that was already present. This is now the main entrance for 5V power.
	* ~~Added~~ a Wemos D1 mini board, it is powered with 5V from the J1 connector, pinout:		* Add a Wemos D1 mini board and connect it to the J1 connector of the display board, it is powered with 5V from the J1 connector, pinout:

	{\| class="wikitable"		{\| class="wikitable"

Bertrik Sikken: /* Frame forwarder */

2020-05-20T16:00:26Z

Frame forwarder

← Older revision		Revision as of 16:00, 20 May 2020
Line 248:		Line 248:
	=== Frame forwarder ===		=== Frame forwarder ===
	A C program (https://github.com/bertrik/lichtkrant/blob/master/ledbanner2udp.c ledbanner2udp]) accepts frames in the ledbanner internal frame format, converts the pixels to rgb565 (to make one frame fit in exactly one UDP packet) and forwards the frame to a configurable UDP host/port (ip address of the lichtkrant).		A C program (https://github.com/bertrik/lichtkrant/blob/master/ledbanner2udp.c ledbanner2udp]) accepts frames in the ledbanner internal frame format, converts the pixels to rgb565 (to make one frame fit in exactly one UDP packet) and forwards the frame to a configurable UDP host/port (ip address of the lichtkrant).

			This program runs on the ledbanner pi, chained at the end of the 'pipeline' of image processes.

	== Links ==		== Links ==

Bertrik Sikken: /* Hardware modifications */

2020-05-20T15:55:10Z

Hardware modifications

← Older revision		Revision as of 15:55, 20 May 2020
Line 145:		Line 145:

	So far I've made the following modifications:		So far I've made the following modifications:
			* Removed the controller board
	* Soldered a power connector on the center of the display PCB, on the footprint that was already present. This is now the main entrance for 5V power.		* Soldered a power connector on the center of the display PCB, on the footprint that was already present. This is now the main entrance for 5V power.
	* Removed the controller board
	* Added a Wemos D1 mini board, it is powered with 5V from the J1 connector, pinout:		* Added a Wemos D1 mini board, it is powered with 5V from the J1 connector, pinout:

Bertrik Sikken: /* UDP RGB565 interface */

2020-05-20T10:15:47Z

UDP RGB565 interface

← Older revision		Revision as of 10:15, 20 May 2020
Line 225:		Line 225:

	=== UDP RGB565 interface ===		=== UDP RGB565 interface ===
	~~RAW~~ RGB565 ~~frames~~ can be sent over UDP to port 1565. The blue (B) channel is ignored, as is the lowest line of the frame.		Frames of 80x8 pixels in RGB565 format (big endian) can be sent over UDP to port 1565. The blue (B) channel is ignored, as is the lowest line of the frame.

	The frames can be converted from raw RGB to the RGB565 format using the ledbanner2udp program.		The frames can be converted from raw RGB to the RGB565 format using the ledbanner2udp program.

Bertrik Sikken: /* Integration into revspace infrastructure */

2020-05-20T10:13:41Z

Integration into revspace infrastructure

← Older revision		Revision as of 10:13, 20 May 2020
Line 244:		Line 244:

	== Integration into revspace infrastructure ==		== Integration into revspace infrastructure ==
			[[File:lichtkrant_hangt.jpg\|right\|thumb\|Lichtkrant in the kitchen]]

	=== Frame forwarder ===		=== Frame forwarder ===