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 <[email protected]>
Datum: 19. 10. 2012
Předmět: Re: [BRLTTY] Getting my braille driver for the FCHAD working.
"[quoted lines by [email protected] 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: [email protected] | 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: [email protected]
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
(http://mielke.cc/mailman/listinfo/brltty)"
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: [email protected]
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
