View source for LED Panel 30x7

{{Project
 |name=LED Panel 30x7
 |image=LED_panel_30x7.jpg
 |founder=Buger
 |status=active
 |tags=hw
 |shortdesc=LED Panels 30x7 - make them working
 |created=2026-28-10
}}
= What is this about =
This project is about to make these LED panels working. We got them for free including power supplies and some cables, however the communication protocol is unknown. 

To be able to use them we need to find out the protocol, or make our own firmware.

= Hack the protocol! =
The device is equipped with pair of XLR connectors connected in parallel suggesting use of DMX or RS485 protocol with daisy-chaining in mind, also the vendor (https://www.srs-group.com) is making a lot of DMX stuff, however I tried to send it DMX data on all 512 channels but no luck. I also tried to send it RS485 data in various formats, baudrates, etc - nothing worked.

I also tried to read the firmware of the main controller (atmega16) but its locked (as usual).

So I deciced to go "my firmware" way...

= Make our own firmware =
To be able to make our own firmware we need to know how this works - so I spent couple of hours reverse engineering the control board so we have the schematic 

[[File:LED_panel_30x7_schematic.jpg|center|frameless|600x600px|LED & driver layout]]

Then I used money of the US tax payers (free chatgpt AI) to make the firmware for atmega16 in arduino with the MightyCore atmega16 support. I told him where and how are the shift registers and row decoders connected, his first task was just to display "base48" text... He did it... Then I asked him to add very simple serial protocol that whill wait for device address and then starts to receive graphics data column by column... And that worked too. 

After some polishing here is the firmware that:
- on powerup shows the device address for 3 seconds
- then screen is cleared and it waits for serial data (115200, 8N1)
- it ignores all data until device address is received
- after it receives its address, it starts to receive graphics data
- because each colum of display consists of 7 LEDs, I decided that all bytes with 0 in the most significant bit (0x0-0x7F) will represent graphics data (simply each bit corresponds to LED in the column) and all with 1 in this bit (0x80-0xFF) will represent device address
- therefore the device address needs to be in 0x80-0xFF range, this way we can handle up to 128 devices on the same bus
- after each received graphics byte column counter is incremented
- therefore if the device address its for example 0x80, you need to send 0x80, 0x7F, 0x7F, ... and 28 more 0x7Fs to make all LEDs on the panel lid up