The author put a Raspberry Pi Zero, a Bluetooth "whistle" and a cable inside his new Handy Tech Active Star 40 braille display. A built-in USB port provides power. The result is a self-sufficient monitorless ARM computer with the Linux operating system, equipped with a keyboard and a Braille display. It can be charged/powered via USB, including from a power bank or solar charger. So it can go without mains power for days, not hours.
Dimensional differentiation of Braille displays
First of all, they differ in line length. Devices with 60 or more characters are good when working with a desktop computer, 40 – are convenient for carrying along with a laptop. There are now also braille displays that connect to smartphones and tablets, with a line length of 14 or 18 characters.
In the past, braille displays were quite massive. The 40-character one, for example, was the size and weight of a 13-inch laptop. Now, with the same number of characters, they are small enough that you can put the display in front of the laptop, not the laptop on top of the display.
It’s certainly better, but it’s still not very comfortable to keep two separate devices on your lap. When you work at a desk, there are no complaints, but it is worth remembering that the laptop is called a laptop in another way, and try to justify this name, as it turns out that the miniature 40-character display is even less convenient.
So the author waited for the release of the long-promised new model in the Handy Tech Star series. Back in 2002 the previous Handy Tech Braille Star 40 was released, with enough cabinet space to put a laptop on top. And if it doesn’t fit, a sliding stand is provided. This model has now been replaced by the Active Star 40, which is pretty much the same but with upgraded electronics.
And the retractable stand remains :
But the most convenient thing about the novelty is a recess about the size of a smartphone (see KDPV).It opens by sliding the pad backwards. It was not convenient to hold a smartphone there, but it is necessary to use the empty compartment, inside of which there is even a power output.
The first thing the author came up with was to put a Raspberry Pi in there, but when the display was purchased, it turned out that the stand covering the compartment would not slide in with the "Raspberry". If only the board had been 3mm thinner…
But a colleague told me about the Raspberry Pi Zero, which turned out to be so tiny that it could fit two… or perhaps even three. It was immediately ordered, along with a 64GB memory card, Bluetooth, a "whistle" and a Micro USB cable. A few days later it all arrived, and some sighted friends helped the author prepare the card. Everything worked right away.
What has been done for this
There are two USB ports on the back of the Handy Tech Active Star 40 for devices such as keyboards. A small keyboard with a magnetic attachment is included. When the keyboard is connected and the display itself works via Bluetooth, the computer additionally identifies it as a Bluetooth keyboard as well.
So if a Bluetooth "whistle" is connected to the Raspberry Pi Zero, placed in the smartphone compartment, it can communicate with the Braille display via Bluetooth by BRLTTY and if you also connect a keyboard to the display, the "malinka" will work with it as well.
But that’s not all. The "Malinka" itself, in turn, can access the Internet via Bluetooth PAN from any device that supports it. The author configured his smartphone and computers at home and at work in this way, but in the future he plans to adapt another "malinka" for this – a classic, not Zero, connected to Ethernet and another Bluetooth-"whistle".
BlueZ5 and PAN
The way to configure PAN with BlueZ turned out to be non-obvious. The author found a Pyhton script, bt-pan (see below), which allows to configure a PAN without a GUI.
It can be used to configure both the server and the client. By receiving the appropriate D-Bus command when operating in client mode, it creates a new network device bnep0 immediately after establishing a connection to the server. Normally DHCP is used to assign an IP address to this interface. In server mode, BlueZ requires the name of a bridge device to which it can add a slave device for each client to connect. Configuring an address for the bridge device and running a DHCP server plus IP masking on the bridge is usually all that is required.
Bluetooth PAN access point with Systemd
The author used systemd-networkd to configure the bridge:
Now, we have to make BlueZ configure the NAP profile. It turns out that you can’t do this with the BlueZ 5.36 utilities. If the author is wrong, correct him: mlang (knows how to move his ears) guru
But he found blog post and Python script to make the necessary calls on the D-Bus.
For convenience, the author has used the Systemd service to run the script and check the dependency permissions.
[Unit]Description=Bluetooth Personal Area NetworkAfter=bluetooth.service systemd-networkd.serviceRequires=systemd-networkd.servicePartOf=bluetooth.service[Service]Type=notifyExecStart=/usr/local/sbin/pan[Install]WantedBy=bluetooth.target
#!/bin/sh# Ugly hack to work around #787480iptables -Fiptables -t nat -Fiptables -t mangle -Fiptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEexec /usr/local/sbin/bt-pan --systemd --debug server pan
The second file would not be needed if Debian had support for IPMasquerade= (cf. #787480 ).
After executing the commands systemctl daemon-reload and systemctl restart systemd-networkd you can start Bluetooth PAN with the command systemctl start pan
Bluetooth PAN client using Systemd
The client part is also easy to configure with Systemd.
[Unit]Description=Bluetooth Personal Area Network client[Service]Type=notifyExecStart=/usr/local/sbin/bt-pan --debug --systemd client %I --wait
Now, after restarting the configuration, you can connect to a given Bluetooth access point like this :
systemctl start pan@00:11:22:33:44:55
Pairing using the command line
Of course, the server and clients must be configured after pairing them via Bluetooth. On the server, you have to run bluetoothctl and give it commands :
power onagent ondefault-agentscan onscan offpair XX:XX:XX:XX:XX:XXtrust XX:XX:XX:XX:XX:XX
After starting the scan, wait a few seconds until the device you want is listed. Make a note of its address and use it by giving the pair command and, if necessary, the trust command.
On the client side, you do the same thing, but you don’t need the trust command. The server needs it to accept the connection to the NAP profile without manual confirmation by the user.
The author is not sure if this is the optimal command sequence. Maybe all that’s needed is to pair the client with the server and execute the trust command on the server, but he hasn’t tried that yet.
Permission to use the HID Bluetooth profile
Requires the "malinka" to recognize the keyboard connected to the Braille display by wire, and wired by the display itself via Bluetooth. This is done in the same way, only instead of agent on it is necessary to give the command agent KeyboardOnly and bluetoothctl will find a device with HID profile.
But setting up Bluetooth from the command line is a bit tricky
Although the author managed to configure everything, he realizes that setting up BlueZ through the command line is awkward. At first he thought that agents were only needed to enter PINs, but it turns out, for example, that you have to type "agent KeyboardOnly" to enable the HID profile. Surprisingly, to run Bluetooth PAN you have to scour the repositories for the right script. He remembers that the previous version of BlueZ had a ready-made tool for this pand – So where does he go with BlueZ 5? Suddenly there is a new solution, unknown to the author, but lying on the surface?
The data transfer rate was about 120 kbit/s, which is quite enough. The 1-gigahertz ARM processor is very fast for a command line interface. The author plans to use mostly ssh and emacs on the device anyway.
Console fonts and screen resolution
The default screen resolution used by the framebuffer on the Raspberry Pi Zero is quite strange: fbset reports that it is 656×416 pixels (no monitor connected of course). With the 8×16 console font, it is 82 characters per line and 26 lines.
It is inconvenient to work with a 40-character Braille display in this mode. The author would also like to have Unicode characters displayed in Braille. Luckily Linux supports 512 characters and most console fonts have 256 characters. You can use two 256-character fonts together with console-setup. The author has added the following lines to the /etc/default/console-setup file :
Note : the font brl-16×8.psf needs console-braille to be installed.
The braille display has a 3.5mm "jack", but the author is unaware of adapters to take the audio signal from the Mini-HDMI. The author was not able to use the sound card built into the "Malinka" (strange, the translator was sure that Zero does not have it, but there are ways to output sound by PWM to the GPIO). He plans to use a USB-OTG hub and connect an external card and output sound to the built-in braille speaker. The two external cards didn’t work for some reason, he is now looking for a similar device on a different chipset.
It’s also inconvenient to manually disconnect the "malinka", wait a few seconds and disconnect the braille display. And all because it removes power from the connector in the compartment when you turn it off. The author is planning to put a small buffer battery in the slot and inform the "malinka" about turning off the display via GPIO so that it can start to finish its work. Such a UPS in miniature.
If you have the same Braille display and would like to do the same with it, the author is willing to provide a ready-made system image (based on Raspbian Stretch). Write to him at the address above. If enough people want to, kits with everything you need to do this can even be produced.
Thanks to Dave Mielke for proofreading the text.
Thanks to Simon Kainz for the photo illustrations.
Thanks to colleagues at Grazka Technical University for quickly introducing the author to the world of Raspberry Pi.
P.S. First tweet the author’s first tweet on the subject (not opening – translator) was made just five days before the original publication of this article, and we can consider that except for sound problems, the task was practically solved. By the way, the author edited the final text from a "self-sufficient Braille display" which he made by connecting it via SSH to his home computer.