This is a series of wiki pages for The Free Braille Display Project.
Links
slides from Mario from his LSM 2010 talk
Requirements
- Durable (10 years of daily use)
- Several refreshes per second
- Low latency
- 20 or 40 cells
- A couple of navigations buttons (too cumbersome to use the PC keyboard for this)
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:
Metec, e.g. a single module example, an integrated group of 20 modules
KGS, apparently 404 :/
Buttons
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.
Controller
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)
Communication
At least Serial and USB, USB could merely be a serial-to-USB FTDI converter.
Bluetooth as an option (via a converter, probably).
Timing
Latency should be as low as possible.
- The metec cells need 50ms to rise a dot, during which the next
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.
- The metec cells clock is 500KHz max.
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.
Protocol
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.
- Samuel believes a simple protocol to announce the number of cells, display dots, and return keypresses should be feasible in 512 bytes PROM and a few SRAM variables.
- Thomas also suggested that the protocol could just be opcodes that directly manipulate the hardware itself (i.e. something like microcode permanently provided to the chip). This however probably needs much more communication bandwidth.
- Mario suggested that VT100 could be implemented. That'd mean recording the 80x25 text (2000 SRAM bytes) and implementing a screen reader within the device itself. Can make all kinds of Operating systems accessible: those which support serial console (often a requirement for server-oriented systems).
- A few well-known proprietary protocols should probably be implemented, for compatibility with proprietary screen readers and thus wider adoption. Samuel has already implemented a simulation of the Baum protocol, for instance.
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."
https://raw.github.com/timthelion/FCHAD_firmware_arduino/master/FCHAD_firmware.ino
=====Level 3 frame type codes(incomplete):=====
======Type 0: Initialization frames======
* Type 0, subType 0:
Request for initialization from host to Braille device.
LEN=4
TYPE=0
SUBTYPE=0
INFORMATION:
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.
Who?
- Hackers with no project ideas
- Electronic student project
- Mathieu Destrian, a french entrepreneur I met in Nice and who came to Bordeaux was interested.