Repository: nvaccess/nvda

Issue:
support for Optelec convertcard 
Hi. I have an braille wouager and a Optelec convertecard wich makes it possible to use braille voyager for newer computers. I am not expert, but as i understand it, the card convert  braille voyager and even other older braildisplays from Tieman to a newer protocols like alva.
However this card is working on jaws, Windows eyes, and other screenreaders. However nvda does not work with this card. I believe it is more then me who have this issue, a new brailledisplay is not the cheepest eithem you can buy. so support for this would be an good idea. I am not a programer, but i'm not believe this is an bigger task to fix. That could be integrated in that allready alva drivers wich is allready included in NVDA.   


Discussion:
Interesting, I do not know this device. CC @dkager
What display do you have to select in other screen readers in order to 
get the voyager working with this convert device?

Hi. In jaws i select something call Optelec Alva BC6. I dont know, but 
there is even drivers for this card in order to use with jawsand other 
screanrederscan  of curse sen it to some one if it's helpful.

Alexander
Den 2017-01-14 kl. 09:36, skrev Leonard de Ruijter:
> Interesting, I do not know this device. CC @dkager
> What display do you have to select in other screen readers in order to
> get the voyager working with this convert device?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> <https://github.com/nvaccess/nvda/issues/6731#issuecomment-272610642>, 
> or mute the thread 
> <https://github.com/notifications/unsubscribe-auth/AX86WeSt5ML8ayb9SiVmBLqk7-fsr7qMks5rSIkGgaJpZM4LjjHb>.
>


I have heard of this card and even seem to recall there being a reason why it it not in NVDA. But I don't know what device ID it uses. We could ping Optelec, unless @jcsteh can shed some light.
Hi, at this time, besides Jamie, you should contact VFO to see what’s up. Thanks.

 

From: Davy Kager [mailto:notifications@github.com] 
Sent: Saturday, January 14, 2017 3:29 AM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: Re: [nvaccess/nvda] support for Optelec convertcard (#6731)

 

I have heard of this card and even seem to recall there being a reason why it it not in NVDA. But I don't know what device ID it uses. We could ping Optelec, unless @jcsteh <https://github.com/jcsteh>  can shed some light.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <https://github.com/nvaccess/nvda/issues/6731#issuecomment-272618358> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkNZiacr1wba8WYc2ai19Sa2jhcEhks5rSLFzgaJpZM4LjjHb> .


As I understand it, this should work with our ALVA driver. What happens if
you select "ALVA BC640/680 series" from the braille displaylist?

It say something like can not initiate the brailledisplay. And om my 
voyager i can read the velcome tex "braille voyager conected".




Den 2017-01-14 kl. 22:28, skrev James Teh:
> As I understand it, this should work with our ALVA driver. What happens if
> you select "ALVA BC640/680 series" from the braille displaylist?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> <https://github.com/nvaccess/nvda/issues/6731#issuecomment-272654470>, 
> or mute the thread 
> <https://github.com/notifications/unsubscribe-auth/AX86WU76u3bRGxEhxut1mpmPX7K586Tuks5rST4KgaJpZM4LjjHb>.
>


Could you share the log file:
- NVDA menu
- Tools
- View log
- Copy the bottom lines, which should say something about an error.

I wonder if our alvaw32.dll is too old. Upgrading this library would add a lot of dependencies if I remember correctly.
Is this ok?

ERROR - braille.BrailleHandler.setDisplayByName (12:04:39):
Error initializing display driver
Traceback (most recent call last):
   File "braille.pyc", line 1502, in setDisplayByName
   File "brailleDisplayDrivers\alvaBC6.pyc", line 58, in __init__
RuntimeError: No ALVA display found
INFO - braille.BrailleHandler.setDisplayByName (12:04:39):
Loaded braille display driver noBraille, current display has 0 cells.




Den 2017-01-15 kl. 11:57, skrev Davy Kager:
>
> Could you share the log file:
>
>   * NVDA menu
>   * Tools
>   * View log
>   * Copy the bottom lines, which should say something about an error.
>
> I wonder if our alvaw32.dll is too old. Upgrading this library would 
> add a lot of dependencies if I remember correctly.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> <https://github.com/nvaccess/nvda/issues/6731#issuecomment-272687773>, 
> or mute the thread 
> <https://github.com/notifications/unsubscribe-auth/AX86WVLvNgl0_rgHOXUM4061UXgLTCpzks5rSfuMgaJpZM4LjjHb>.
>


Yeah, it looks to me like the library from Optelec doesn't find the display.
Yes, it's so i understand it also. An no profecional gues, could it have 
something to do that i run 64 bit pc? But on other hand, the 
brailldisplay is not dead, it wake up when i turn on the computer so my 
unprofecional gues that it must have something to do with drivers for 
nvda. There is maybe some one who from optelec or have conection with 
them and can find out how this card works?????




Den 2017-01-15 kl. 12:13, skrev Davy Kager:
>
> Yeah, it looks to me like the library from Optelec doesn't find the 
> display.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> <https://github.com/nvaccess/nvda/issues/6731#issuecomment-272688493>, 
> or mute the thread 
> <https://github.com/notifications/unsubscribe-auth/AX86WWYKiX1_Ee353jjbs3yiIWxG8Zy1ks5rSf9wgaJpZM4LjjHb>.
>


Was the converter connected to the computer via USB, serial or Bluetooth?

It's possible that the older version of the ALVA dll we use doesn't support
this, but that surprises me because I thought this converter was released
long before the new dll was released. We definitely can't update to the
newer dll; it introduces a lot of large dependencies. We'd either need to
write a new driver using the raw protocol or drop the ALVA driver from NVDA
itself and distribute it as an add-on with the new dll. We don't have
access to one of these converters, though, so there's no guarantee we'd get
it right if we wrote a new driver.

Hi,

discussion about problems with protocol converter can be found at issue #5493, where has been already told, that a newest library is too big to be included in NVDA core... Whatever I still have a problem but as work around I have begun using a BRLTTY also on 64-bit systems when I wanted to use an ALVA Satellite. When I use other screen readers, I use Satellite with protocol converter.
I'm refferencing this to #5493, because the protocol converter supports both Braille Voyager braille displays and Satellite braille displays.
Fair enough, but is the old (current) library supposed to support the converter?
Is the raw protocol documented anywhere? This might be tricky to get right on Bluetooth.
This old displays does not support bluetooth. And personaly i think an 
solotion would be better to find without BRLTTY, it's for an mayority of 
users very tricky and only for tech-.persons. As i understand Linux is 
prio 1 for them. I hope you people who has an knowlegde about this, will 
find and solotion without brltty.  to



Den 2017-01-16 kl. 15:48, skrev Davy Kager:
>
> Fair enough, but is the old (current) library supposed to support the 
> converter?
> Is the raw protocol documented anywhere? This might be tricky to get 
> right on Bluetooth.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> <https://github.com/nvaccess/nvda/issues/6731#issuecomment-272881470>, 
> or mute the thread 
> <https://github.com/notifications/unsubscribe-auth/AX86WUyUUcbhivybq-BdsteIW4qbH98Gks5rS4MhgaJpZM4LjjHb>.
>


Hi,

here we talk about usb connection. the usb protocol converter presents
Satellite and Voyager displays as BC6 displays. unfortunately, when a
display is connected to a computer via this hardware interface, NVDA
says "could not load BC6 display" even a device is plugged in and
display is ready.

oh, how protocol converter connects? a device has to connectors:
- mini usb "female" connector, where a usb cable from computer is connected.
- clasical usb "b" "male" connector which is connected to a display.

regards, Jožef

2017-01-16 16:07 GMT+01.00, Bamze66 <notifications@github.com>:
> This old displays does not support bluetooth. And personaly i think an
> solotion would be better to find without BRLTTY, it's for an mayority of
> users very tricky and only for tech-.persons. As i understand Linux is
> prio 1 for them. I hope you people who has an knowlegde about this, will
> find and solotion without brltty.  to
>
>
>
> Den 2017-01-16 kl. 15:48, skrev Davy Kager:
>>
>> Fair enough, but is the old (current) library supposed to support the
>> converter?
>> Is the raw protocol documented anywhere? This might be tricky to get
>> right on Bluetooth.
>>
>> —
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/nvaccess/nvda/issues/6731#issuecomment-272881470>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AX86WUyUUcbhivybq-BdsteIW4qbH98Gks5rS4MhgaJpZM4LjjHb>.
>>
>
>
>
> --
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub:
> https://github.com/nvaccess/nvda/issues/6731#issuecomment-272886399

[**@dkager**](https://github.com/dkager) commented on [17 Jan. 2017, 12:48 am AEST](https://github.com/nvaccess/nvda/issues/6731#issuecomment-272881470 "2017-01-16T14:48:00Z - Replied by Github Reply Comments"):
> Fair enough, but is the old (current) library supposed to support the converter?

I don't know. I assumed so, but that seems not to be the case.

I do know that the converter has a different USB product id. That is, it doesn't show up as a 640 or a 680; it has its own id. I guess the older dll mustn't know about this id.

> Is the raw protocol documented anywhere?

I do have the documentation from Optelec, yes. It's not publicly available, though. (Don't get me started on how ridiculous that is.) If someone wants to work on this, I can probably provide it.

> This might be tricky to get right on Bluetooth.

I don't think the converter supports Bluetooth? As for the BC640/680, I also have the Bluetooth protocol documentation. Unfortunately, it's a completely different protocol to the one they use for USB.
Yes, protocol converter supports only USB, cause this works with displays (Voyager and Satellite), which do not have a BT interface.
I have a BC6, so I could give this a shot. But a few remarks first:
- It is not completely certain that the DLL is the culprit. I could ask Optelec about it, we also had contact last year when I extended the BC6 keymap.
- I am not experienced enough in this to do it without looking at an existing driver. Maybe the one for the Brailliant BI?
- Or is the user base small enough to justify an addon with latest DLL? In The Netherlands there are still quite a few users of this display, so that would increase the threshold a bit for them.
An add-on with dll doesn't have to mean that we have to throw away the 
driver in core. The add-on can just replace the driver in core IMO.

[**@dkager**](https://github.com/dkager) commented on [17 Jan. 2017, 5:32 pm AEST](https://github.com/nvaccess/nvda/issues/6731#issuecomment-273041639 "2017-01-17T07:32:09Z - Replied by Github Reply Comments"):
> - It is not completely certain that the DLL is the culprit. I could ask Optelec about it, we also had contact last year when I extended the BC6 keymap.

I do have contacts at Optelec, but we haven't had any contact since the merge with VFO. I can try poking them if need be.

> - I am not experienced enough in this to do it without looking at an existing driver. Maybe the one for the Brailliant BI?

brailliantB is probably the best driver to start with. It has to support both HID and Bluetooth serial and uses the new hwIo stuff for both.

> - Or is the user base small enough to justify an addon with latest DLL? In The Netherlands there are still quite a few users of this display, so that would increase the threshold a bit for them.

It isn't an ideal solution, but nor is the current situation. I'll discuss with others here. We do have a BC640, though it's not currently with me at the moment.

[**@leonardder**](https://github.com/leonardder) commented on [17 Jan. 2017, 5:34 pm AEST](https://github.com/nvaccess/nvda/issues/6731#issuecomment-273041953 "2017-01-17T07:34:12Z - Replied by Github Reply Comments"):
> An add-on with dll doesn't have to mean that we have to throw away the 
> driver in core. The add-on can just replace the driver in core IMO.

I disagree. It is difficult to explain, will confuse users and will thereby create additional support load.
I wonder if there would be any other benefits to a Python-based driver. For me as BC640 user support for the converter card isn't very interesting. But maybe something like automatic reconnect or thread safety.
If nothing else I'll gladly test the new driver if it is realized. Maybe poking VFO is a good idea. Your contacts are probably better than mine. :)
Hi,

for existing BC6 users, there is no benefit, but benefit is for users,
who use Satellite series displays (544 Pro, 570, 584 Pro and 544
Traveller) and Voyager series. In South slavic countries there are
many users who use these display especially Satellite series.

Regards, Jožef

2017-01-18 10:39 GMT+01.00, Davy Kager <notifications@github.com>:
> I wonder if there would be any other benefits to a Python-based driver. For
> me as BC640 user support for the converter card isn't very interesting. But
> maybe something like automatic reconnect or thread safety.
> If nothing else I'll gladly test the new driver if it is realized. Maybe
> poking VFO is a good idea. Your contacts are probably better than mine. :)
>
> --
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub:
> https://github.com/nvaccess/nvda/issues/6731#issuecomment-273428273

Auto reconnect is not something that should be done in individual drivers.
It will happen as part of braille display detection (#1271).

The other thing moving to a Python based driver gives us is direct access
to the braille keys so NVDA can use its own braille input code, rather than
the ALVA's own braille translator. Right now, that's probably not a massive
win, but it will be once we have uncontracted and contracted input.

I may get a chance to look at this some time in the next few months, but
I'm not certain.

Related issue: #7733.
This will be covered by #7733. I'm not treating this issue as duplicate though, since it covers a specific case which is currently not available in NVDA, whereas other Alva users can already use most if not all functions of their displays.
@Adriani90 reported in #1586 that the Converter Card isn't working as expected.

It would be really helpful if we could have a log file of what's going wrong when trying to connect to the particular Voyager display you mentioned. Would you or the user your mentioned be able to retrieve a log with debug logging enabled? To have as much debug information as possible, please also do the following

1. Open a python console (nvda+control+z)
2. Paste the following in the console, and press enter: 
    `import config; config.conf['debugLog']['hwIo']=True`

3. Try to connect to the Voyager using the new Optelec driver.
@gregjozk: Do you still have no possibilities to test this device?
@michaeldcurran: I labeled this p2, since the converter card is promised to work in 2018.1, and it looks like it doesn't, though we followed the protocol and there aren't issues with native BC devices. I think it should at least be a show stopper for a release of 2018.1 until we've found out what's causing the problem reported by @Adriani90 
[Here](https://ci.appveyor.com/api/buildjobs/y0stnqb2jjwlaacc/artifacts/output%2Fnvda_snapshot_try-protocolConverterPID-14888%2Cf73ef85b.exe) is a try build that is likely to fix this issue.
Dear all,

first of all sorry for the delay. We had to conduct more testings. I am unfotunately not allowed to upload things at this time, so I will paste the Content of the log files in here. But this should not be a Problem because searching for the "alva" or "enter" will bring you to the relevant results.



Resolving patch:
diff --git a/source/braille.py b/source/braille.py
--- a/source/braille.py
+++ b/source/braille.py
@@ -1937,7 +1937,7 @@ def func(cls):
 #: Maps old braille display driver names to new drivers that supersede old drivers.
 RENAMED_DRIVERS = {
 	"syncBraille":"hims",
-	"alvaBc6":"alva"
+	"alvaBC6":"alva"
 }
 
 def initialize():
diff --git a/source/brailleDisplayDrivers/alva.py b/source/brailleDisplayDrivers/alva.py
--- a/source/brailleDisplayDrivers/alva.py
+++ b/source/brailleDisplayDrivers/alva.py
@@ -34,6 +34,8 @@
 ALVA_RTC_REPORT = b"\x0a"
 ALVA_RTC_STR_LENGTH = 7
 ALVA_RTC_MAX_DRIFT = 5
+ALVA_RTC_MIN_YEAR = 1900
+ALVA_RTC_MAX_YEAR = 3000
 
 ALVA_MODEL_IDS = {
 	0x40: "BC640",
@@ -142,7 +144,10 @@ def _updateSettings(self):
 			displaySettings = self._dev.getFeature(ALVA_DISPLAY_SETTINGS_REPORT)
 			self.numCells = ord(displaySettings[ALVA_DISPLAY_SETTINGS_CELL_COUNT_POS])
 			timeStr = self._dev.getFeature(ALVA_RTC_REPORT)[1:ALVA_RTC_STR_LENGTH+1]
-			self._handleTime(timeStr)
+			try:
+				self._handleTime(timeStr)
+			except:
+				log.debugWarning("Getting time from ALVA display failed", exc_info=True)
 			keySettings = self._dev.getFeature(ALVA_KEY_SETTINGS_REPORT)[ALVA_KEY_SETTINGS_POS]
 			self._rawKeyboardInput = bool(ord(keySettings) & ALVA_KEY_RAW_INPUT_MASK)
 		else:
@@ -235,6 +240,7 @@ def _ser6OnReceive(self, data):
 		elif cmd == b"r": # Raw keyboard messages enable/disable
 			self._rawKeyboardInput = bool(ord(value))
 		elif cmd == b"H": # Time
+			# Handling time for serial displays does not block initialization if it fails.
 			self._handleTime(value)
 
 	def _hidOnReceive(self, data):
@@ -293,14 +299,22 @@ def display(self, cells):
 
 	def _handleTime(self, timeStr):
 		ords = map(ord, timeStr)
-		displayDateTime = datetime.datetime(
-			year=ords[0] | ords[1] << 8,
-			month=ords[2],
-			day=ords[3],
-			hour=ords[4],
-			minute=ords[5],
-			second=ords[6]
-		)
+		year=ords[0] | ords[1] << 8
+		if not ALVA_RTC_MIN_YEAR <= year <= ALVA_RTC_MAX_YEAR:
+			log.debug("This ALVA display doesn't reveal clock information")
+			return
+		try:
+			displayDateTime = datetime.datetime(
+				year=year,
+				month=ords[2],
+				day=ords[3],
+				hour=ords[4],
+				minute=ords[5],
+				second=ords[6]
+			)
+		except ValueError:
+			log.debugWarning("Invalid time/date of ALVA display: %r"%timeStr)
+			return
 		localDateTime = datetime.datetime.today()
 		if abs((displayDateTime - localDateTime).total_seconds()) >= ALVA_RTC_MAX_DRIFT:
 			log.debugWarning("Display time out of sync: %s"%displayDateTime.isoformat())


Test patch: