Thursday, December 4, 2014

Braillenote and Bluetooth

I bought a BrailleNote recently.
It's a little broken and that's the condition it was advertised in. Turns out it's not too bad.

  • The battery is shot (easy enough to build a new battery pack though).
  • There's no charger (guess who has an adapter which matches perfectly*)
  • Some keys are missing (not rocket science to fix if I cared to)
  • And it's running KeySoft 7.2
Turning it on the first time was a little stressful. I could not find the voltage the AC charger is supposed to put out but I kind of felt like it used 12 volts dc and I hoped 1.5 amps was good enough and that it was center positive... because that's what I used. The smart thing to do would have been to ask someone but it was midnight, it was broken anyways as far as I knew and I didn't care about salvaging anything but the Braille display which I doubted would be damaged even if I fried the mainboard. So I just plugged it in and turned it on.

Darn it worked. What to do with it? I wanted to take it apart, stick a BeagleBone in it as a new brain and make it a Linux system.

It runs this now ancient version of Windows CE 4.2 and there was never an SDK for it. In theory it supports being a Braille display via bluetooth but I can't find a reference to getting that working with brltty or any other open source program. Therefore my current plan is to attempt to reverse engineer the bluetooth connection and hook it up to brltty (mostly because I don't have a null modem serial cable).

I'm convinced this thing talks rfcomm and that's mostly because Wireshark was decoding the bluetooth traffic for me and identified it as such. Also, the cursor keys were easy to decode as the BrailleNote sends it when in Braille Terminal mode even without a properly configured program on the computer. My main problem is I don't really know anything about writing a program to connect via bluetooth. I've used rfcomm on the command line to hook up bluetooth modules as serial ports but none of the channels and combinations worked for me. I was under the impression there were only 30 channels when I tried this last but now it's looking to me like I need to use a particular UUID which I hope is in the Wireshark or hcidump output. 

Todo List:

  • Get brltty talking to this over bluetooth.
  • Build new battery pack
  • Replace the Interactive Fiction program with something I write (I've previously determined it is it's own .exe which talks over some named pipes for I/O.)
  • Find my VM for Windows 2000 that had all the Windows CE development tools for 4.2. That really ought to be before writing a new program since that's what I'll need to do it.

Other Fun

  • A process segfaults when I plug in the USB cable after installing SynCE. Actually it segfaults when I unplug it again too.
  • I can't read the display. Probably should learn at some point but fortunately it has voice output enabled by default.
  • I should screenshots and bluetooth data for the next post.

*No idea what the proper amperage is.

Thursday, March 27, 2014

Mumble 1.2.5 on Fedora 20

 UPDATE:
A update has been pushed to the official updates-testing.
You should probably use that one and uninstall mine beforehand.
https://bugzilla.redhat.com/show_bug.cgi?id=1062209
https://admin.fedoraproject.org/updates/mumble-1.2.5-1.fc20
Test it and leave karma.


Old Post Follows:
Mumble 1.2.5 came out a few weeks ago but the version in Fedora is still stuck on 1.2.4. Since I don't know what the protocol is for prodding package maintainers to push updates and I recently stumbled across COPR I decided to try making an update myself.

What's COPR? Read yourself. https://fedorahosted.org/copr/wiki/UserDocs#FAQ

Short version is someone loads some source code into it and it compiles, packages and hosts a repository to install it from.

Here's my attempt.
http://copr.fedoraproject.org/coprs/chder/mumble/

The existing RPM SPEC file from 1.2.4 worked with only trivial changes for 1.2.5. Some day I should try packaging my own code and writing a SPEC from scratch.