Project goals

endre has bought a LED display made by Mediotext a while ago from Vatera, with dried out capacitors. The project aims to replace the original microcontroller with Arduino and to develop an Arduino library so that one can make use of the display for various projects.

The display

The display itself is built up with 96x7 5mm red LED pixels made by german firm Mediotext, and has had a 6502 microcontroller that has been replaced with Arduino lately. Award goes to MrT for his excellent reverse engineering work.

Interface Image

The display is equipped with a DB-9 connector on the top, having the folling pinout:
  1. SHR_CLK
  2. SHR_DAT
  4. +5v
  5. GND
  6. ROW_ID_0
  7. ROW_ID_1
  8. ROW_ID_2
The BUZZER and RESERVED lines are not connected as of now. Line +5v provides enough power to run an Arduino on it, eliminating the need for an external power supply.


The X and Y axis "addressing" are completely independent and driving them has completely different approach.
  • X axis: a LED is "addressable" by filling the shift registers with loading all of the 96 LEDs levels (Arduino shiftOut() function) corresponding to a specific row.
  • Y axis: a row can be selected by pulling the ROW_ID_x levels down. Obviously only one row can be selected at a time.
  • Blanking: The display can be blanked (for example during the shiftOut update period) with all the lines pulled down.

Arduino code

Arduino source code is available in the https://github.com/hsbp/arduino2mediotext repository. The master branch has code that scrolls a hardcoded text.

Remote control branch

The remote-control branch makes the Arduino a dumb framebuffer that can be controlled over a serial connection. Currently, the protocol offers only one command, block update and a speed of 19.200 bps.

Block update command

The block update command deals with 8-pixel horizontal blocks, resulting in 12 × 7 such blocks. The header bits look like the following:


  • AAA is the first row to be updated (0-6)
  • BBB is the first row not to be updated (1-7)
  • CCCC is the first 8-pixel horizontal block to be updated (0-11)
  • DDDD is the first 8-pixel horizontal block not to be updated (1-12)
So the first two bytes define the command (11 = block update) and the four boundaries of the rectangle shaped block to be updated. After this header, there should be w × h bytes, where w = BBB - AAA (width) and h = DDDD - CCCC (height). Each of these represent a 8-pixel horizontal block, and the order should be left to right then top to bottom.

Arduino accelerated graphics commands (beta)

The virtual width of the display should be increased to 256 pixels, with two offsets representing the 96-pixel wide window used for the block update command above (ops offset) and the one used for driving the display (display offset). By default, both are zero, resulting in backwards compatibility.

These offsets can be set with the following commands. Since the ops offset is kept at 8-pixel (block) boundaries, 5 bits are enough, these are marked with X below.


For smooth scrolling, the display offset can take any value between 0-255, thus it's sent on its own after the following bits.


To get Arduino accelerated smooth scrolling, automated incrementing of the display offset can be enabled and its speed can be set using the following command. XXXXXX denotes a 6-bit value of the speed, all zeroes mean no scrolling, which is the default.


For dynamic scrollers, querying the display offset can be necessary, this can be done using the following command.


This will result in the Arduino sending back the current value of the display offset in a single byte.

Last but not least, commands could be saved in the EEPROM for autonomous (PC-less) operations. The header consists of the command (100000) and 10 bytes of length.


This is followed by the number of bytes denoted by the length field, so the length field doesn't take the header into account, only the payload. These are then written into the EEPROM with the header included, so that the Arduino will know how many bytes in the EEPROM are valid. Because EEPROM writes are slow and the Arduino serial receive buffer is limited, the second header byte (the low 8 bits of the payload length) and all the payload bytes are echoed back, and the client should wait for this acknowledgment before sending the next byte.

After reset, the Arduino waits for 5 seconds for serial commands, and if none arrive, it performs PC-less operation in which it reads the commands from the EEPROM and execute them just as if they would've been sent over the serial port. This will probably consist of one or more block update commands separated by set ops offset commands, with a set scroll speed command at the end.

This still leaves space for future commands:



Python API

To make things easier, a simple Python API is implemented by the Remote class, having the following methods. Pixels are expressed with tuples having two members, X and Y.
  • __init__(serial_class=Serial) the only optional parameter can be used for testing, otherwise the /dev/ttyUSB0 (first USB-Serial converter on Linux) will be used using pySerial
  • set_pixel(pixel, value) sets the pixel specified by the first parameter to value (True means lit, False means dark)
  • get_pixel(pixel) returns the current state of the pixel specified by the only parameter
  • flush_pixels() if any pixels has changed since the last flush, it updates the affected region
Note: for performance reason, set_pixel calls doesn't take effect until the next call to flush_pixels, but get_pixel already returns the new value

If you need low-level access, the framebuf attribute stores the framebuffer as a flat list of boolean values, from left to right then top to bottom. Reading it should not cause any problems, but writing it is discouraged as the next call to flush_pixels will not know which pixels you changed.


The last two can be seen in action on YouTube: https://www.youtube.com/watch?v=OaNeMzZPdtQ

Font ideas

As seen on..

#hspbp LED display at Hacktivity

Contributors to this page: dnet , eapo and endre .
Page last modified on Sunday 20 of May, 2018 21:47:32 CEST by dnet.

Upcoming Events

No records to display