This is a series of wiki pages for The Free Braille Display Project.


Braille Cells

Typically 20 or 40 of them. Each costs typically $50. Yes, each. HackableDevices people have confirmed that the mechanical part is probably difficult to produce in a cheaper way in small quantities.

A description of the Optelec Braille Cells, which Samuel has a few units

A few manufacturers:


At least a couple on the sides, for navigation.

Also note that the braille modules usually have one or two buttons each (called cursor routing, to request for bringing the software cursor to that position), whose state should to be shifted out, compared to the old value, and submitted separately.


Could be a mere microcontroller with a free firmware: a PIC16, a 68, an arduino,...

firmware should be easy to upgrade, and simple to add features.

Run Linux on the device? (i.e. notetaker)


At least Serial and USB, USB could merely be a serial-to-USB FTDI converter.

Bluetooth as an option (via a converter, probably).


Latency should be as low as possible.

text to be displayed can be shifted in, i.e. 20Hz. For a 40 cell display, that means at least 40bytes*8bits*20Hz = 6400bps communication bandwidth (excluding protocol overhead). The braille buttons state also need to be read and sent back over the wire.

Power supply

Typically 5V for the electronic.

Like 100, 200, or 250 V, DC, depending on the precise braille module. The metec ones seem to need 200V DC +/- 10%. Current usually just a few mA on dot change, typically 10µA when not changing.

Some braille devices actually just draw all the current from the USB plug, converting it to 200V as needed.


Depending on the protocol, the capacity of a micro-controler will vary. Of course, several of them can be implemented and the user could choose which one(s) it prefers.

The universal open braille protocol(UOBP)

A proposed open and generalized protocol is being outlined here. This protocol should provide the extensibility required to support any kind of present and future Braille display.

All values are little endian.

=====Level 2 frames===== are proposed to look like:

[START_FLAG(1 octet)|LEN(2 octets)|TYPE(1 octet)|SUBTYPE(1 octet)|INFORMATION|XOR(1 octet)|END_FLAG(1 octet)]

A firmware implementation of this level 2 can be found here as defined by the functions "sendFrame" and "checkForFrameAndReact."

=====Level 3 frame type codes(incomplete):=====

======Type 0: Initialization frames======

* Type 0, subType 0:

Request for initialization from host to Braille device.





First two octets=type of host driver(brltty=0)

Second two octets=version of host driver.

* Type 0, subType 1:

Initialization frame from braille device. Response to a frame type[0:0]. LEN=Depends on length of device capability specification. TYPE=0 SUBTYPE=1 INFORMATION: The information of this frame is broken into 3 parts: [Device UUID|List of standard capabilities|list of extended capabilities]

First 16 octets = device UUID.

Next 2 octets = Number of standard capabilities.

Standard capabilities are described with [CAPABILITY ID(2 octets)|INFO(length is capability specific)]

0 = Device has a buffer of multiple simultaneous display braille cells. INFO = DISPLAY ROWS(2 octets) + DISPLAY COLUMNS(2 octets)

1 = Device has routing keys. INFO = ROUTING KEYS ROWS(2 octets) + ROUTING KEY COLUMNS(2 octets)

2 = Device has a Fast Character cell. INFO = NO INFO

3 = Device has Fast Character touch sensors. INFO = SENSOR ROWS(2 octets) + SENSOR COLUMNS(2 octets)

4 = Device sends standard keyboard keycodes. INFO = Keyboard type(1 octet). 0 = 110 keys

5 = Device has a 8/10 key braille keyboard and sends braille keyboard codes. INFO = Keyboard type (1 octet). 0 = 10 keys.

6 = Device can be mounted and has file transfer capabilities. INFO = ???

Following the standard capabilities list is a list of the extended capabilities(capabilities not described in this standard).

First 2 octets = number of extended capabilities.

The extended capabilities list is in the format: [UUID of extended capability|Length of INFO|INFO] The length of the INFO is declared here, so that drivers not supporting a given extended capability can ignore the section.

* Type 0 subType 2 Non persistent(session length) settings sent from the driver to the device. LEN=depends on the number of capabilities who's settings must be set. TYPE=0 SUBTYPE=2

* Type 1 Driver sending the device information to be displayed immediately.

* Type 1 subtype 0 Buffer to be displayed by a multi cell braille device. This buffer is left to right top to bottom and must have a length equal to the number of columns specified by the device x the number of rows specified by the device.

* Type 1 subtype 1 Character to be displayed by an FCHAD device. LEN = 1 TYPE = 1 SUBTYPE = 1 INFORMATION = The character to be displayed(1 octet) with bit to dot mapping as follows:

14 25 36 78

* Type 2 frames Key presses and other events sent from braille device.

* Type 2 subType 0 110 key keyboard key-press. LEN=1 TYPE=2 SUBTYPE=0 INFO=keycode(1 octet)

* Type 2 subType 1 Braille key chord(chording is done within the device!). LEN=1 TYPE=2 SUBTYPE=1 INFO=key. Bits represent braille dots in standard braille dot form

14 25 36 78

* Type 2 subType 2 Braille routing key key-press.

LEN=4 TYPE=2 SUBTYPE=2 INFO=First two octets = routing key row. Second two = routing key column.

* FCHAD touch sensors. depending on whether response time or detail are more important to the driver, we can specify in the settings whether we want to receive raw events or condesed events. With condensed events, only the extreme(far right and left in a multi touch context)completed touches(both down and up) will be sent. Otherwise, every touch and release is sent. * Type 2 subType 3 FCHAD touch sensor down. LEN=4 TYPE=2 subType=3 INFO=First tow octets

* Type 2 subType 4 FCHAD touch sensor up.

* Type 2 subType 5 FCHAD touch sensor press.


None: FreeBrailleDisplay (last edited 2019-11-11 00:44:36 by SamuelThibault)