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:
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.
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.