[BRLTTY] Getting my braille driver for the FCHAD working.

Tue Oct 23 19:30:15 EDT 2012

Good news. The driver is done(and by that I mean that I have a preliminarily
functioning driver and firmware, and not that it is perfect in ever aspect 
of design and need never be changed again).  It can be downloaded it with 
this command:

$git clone https://github.com/timthelion/UOBP.git
(https://github.com/timthelion/UOBP.git)

The license on all of my code is GPL with the same version as the rest of 
BRLTTY.  The licence on the .md files is public-domain or CC-0 if you are in
a country without public domain.  There are however two files "mpr121.cpp" 
and "mpr121.h" which have another licence which I hope is GPL compat: 

(https://raw.github.com/timthelion/UOBP/master/brltty-4.4/Drivers/Braille/UOBP/FCHAD_firmware_arduino/src/License.txt)

(https://raw.github.com/timthelion/UOBP/master/brltty-4.4/Drivers/Braille/UOBP/FCHAD_firmware_arduino/src/License.txt)

https://raw.github.com/timthelion/UOBP/master/brltty-4.4/Drivers/Braille/
UOBP/FCHAD_firmware_arduino/src/License.txt
(https://raw.github.com/timthelion/UOBP/master/brltty-4.4/Drivers/Braille/UOBP/FCHAD_firmware_arduino/src/License.txt)

If it is not GPL compat, this is not a problem for the BRLTTY driver.  These
files are only used in the firmware and not in the driver itself.

In production code, line 29 of uobp_general.h should be commented out.  That
is "#define LOG_EVERYTHING 1"

I should be having the chance to test prototype #2 in the coming weeks.  I'm
so excited!  I am confident I can beat the opticon in both price and 
durability :D !

Timothy

PS: there is still one known bug.  And that is with the MakeFile.in .  I 
have not set it up properly, and therefor if you change a .h file, you must 
touch each .c file that was affected by the change in order to get  make to 
recompile those affected files.

---------- Původní zpráva ----------
Od: Dave Mielke <dave at mielke.cc>
Datum: 19. 10. 2012
Předmět: Re: [BRLTTY] Getting my braille driver for the FCHAD working.
"[quoted lines by timothyhobbs at seznam.cz on 2012/10/19 at 00:09 +0200]

>Oh, I had never heard of the opticon.  But yes it is similar.  It's a pity,
>seems you can no longer buy those devices.  I wanted to get an idea of the
>price!  

They cost a few thousand dollars ech. Not veyr cheap.

The weakest part of an Optacon was the wire connecting the lens module to 
the 
base unit. It was thin and light weight, to mkae it relatively easy to put 
up 
with, but that thin cable contained 39 (I believe) wires. This meant that 
each 
of those 39 wires had to be very thin. My experience was that after about a 
year of constant use there'd be a breakage. In the end, it meant that I had 
to 
own two Optacons so that I'd have one to use while the other one was off 
having 
that connecting cable repaired.

Another problem with the Optacon was that it had a scan rate which didn't 
match 
the scan rate of a computer terminal or monitor, so, when used on one of 
those, 
the image on the pin array would flicker quite badly. Also, holding the 
camera 
up against a vertical screen would become rather tiring.

>When I was prototyping, I made my device work so that one used a
>stylus to select the character, rather than touching physical touch 
sensors.
>  This was not a good method.  I found when reading that the main trouble
>was in figuring out where the stylus was and not accidentally skipping
>letters.  

This is where a constantly moving image would've helped. When it jumps from 
character to character, I can well imagine how easy it'd be to lose track of

precise position, or even misguess exact direction of motion. When the image

slides right along with the sensor, however, the user always knows exactly 
what 
he's doing and doesn't tend to lose his place. With the Optacon, for 
example, 
if the image of the character started to slowly move up then I knew I was 
moving the camera at a slight downward angle and could immediately make the 
needed correction.

>Of course I can program the device to scan across similarly to
>the opticon.  Take our sensor row as an example: 1 2 3 4 5 if the reader
>were to place only their index finger on the device, I could display for a
>touch registering only sensor 1, the entirety of the first character, for a
>touch registering 1 and 2 however, I could display the second half of the 
>first character and the first half of the second.  I don't think this would
>be a very good system though.  

No, it wouldn't. Since a braille character has only two columns, displaying 
the 
right half of the previous character along with the left half of the next 
character would simply look like yet another, entirely unexpected and odd, 
braille character. :-) Since the Optacon presented six columns of pins, the 
motion of the image felt quite smooth.

-- 
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is the End of 
Salvation.
EMail: dave at mielke.cc | Canada K2A 1H7 | http://Mielke.cc/now.html
(http://Mielke.cc/now.html)
http://FamilyRadio.com/(http://FamilyRadio.com/) | http://Mielke.cc/bible/
(http://Mielke.cc/bible/)
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY at mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
(http://mielke.cc/mailman/listinfo/brltty)"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mielke.cc/pipermail/brltty/attachments/20121024/7b781c65/attachment.html>