@XLTechie You indicate that there is a "HumanWare" version, does this mean that your Zoomax is not made by HumanWare? Do you know if it is a USB serial or HID based device? If it is a device with a USB serial interface, you could select the COM port manually and try a few drivers that might work based on the manufacturer.

@XLTechie Based on BRLTTY sourcecode, this display seems to use the Baum protocol. However, the vendor and product IDs that I see in BRLTTY are not listed in NVDA's Baum driver and therefore will not be autodetected.

Based on the vendor and product IDs, this seems to be a device with built-in USB serial converter based on the very common CH-340 chip. So, if you choose the Baum driver and manually select the right serial port, this may work.

To get this autodetected, add it's vendor and product ID to the registerAutomaticDetection method under the KEY_SERIAL key like "VID_1A86&PID_7523",.

Please let me know if this works.

@bramd many thanks for this research! Will do some tests and report back.

@bramd Unfortunately, it does not. I can select the Baum driver when the display is connected (but not when it isn't). I can choose a comm port--I tried it both in a USB hub and direct, in which case the only port available changed from COM8 to COM7. However both times, I get the no display detected error

Tried in Alpha and 2023.3.

I didn't try making a compile with the IDs in auto detection--I figured if it doesn't work manually, it won't work automatically. If I am wrong there, I can try that next.

I have the same display running version 2.0, firmware 29. I (1) changed the logging level to debug, (2) enabled the hwIo debugging category, (3) restarted NVDA with add-ons disabled, and (4) pressed control+shift+NVDA+f1 to start the log fragment. I then plugged the display into my USB port, pressed ctrl+NVDA+a to choose a braille display, pressed B to choose Baum/HumanWare/APH/Orbit braille displays, tabbed over and chose USB-SERIAL CH340, and pressed Enter. That log fragment is attached (see Zoomax NLS eReader .txt).

@tmthywynn8 Thanks for the input. From your log it seems the display doesn't respond at all to the request from the driver. I'm not familiar at all with this hardware, but please ensure it is turned on and set to a braille display mode if it has internal menus or options to do so. Some displays still show up as a serial port, even if the hardware is turned off or otherwise unavailable. A logical next step would be to get this running with BRLTTY to check if that code is working and check the differences between BRLTTY and the NVDA driver.

I do not recall if I put the display into USB mode or not, but I did the same steps as earlier, except after plugging it in to the USB port, I made sure to put into USB mode (the display says USB in braille; see ZoomaxNVDA.txt). I will try to use BRLTTY after work.

So I couldn't get the stand-alone version of BRLTTY to work, however Narrator's interface for it worked like a charm. I couldn't choose USB but had to explicitly choose the serial port (in my case COM5. Once that was done, I started narrator, force-quitted the screen reader, loaded NVDA, and chose BRLTTY as the display. I couldn't type any braille, but panning and other D-keys worked as expected.

When using BRLTTY with Narrator though, input keys worked as expected, however the space key did not do anything—had to use BL and BR. When I first started Narrator, the display said BRLTTY 5.6 in computer braille (⡃⡗⡇⡞⡞⡿⠀⠢⠨⠖), and when exiting BRLTTY stopped (⡃⡗⡇⡞⡞⠽⠀⠎⠞⠕⠏⠏⠑⠙). If I force-quit Narrator, disconnect and reconnect the uSB cable, the display says BRLTTY 5.6 followed by no screen (⣝⠕⠀⠎⠉⠗⠑⠑⠝). Note that JAWS works without explicitly choosing anything but the display and its connection type, USB.

@tmthywynn8 As far as I know, Narrator does not ship with BRLTTY 6.6 and always as an "M" suffix after the version, such as "6.4M". So I think you somehow ran the standalone 6.6 version. By default the standalone version si configured to sleep if the braille API is not used, so that it is just starting when NVDA/Narator accesses it is normal. It would be really helpful if you could give a brltty log with input and output packets logged. You can do this by running debug-brltty.bat from the standalone version. You may need to add the correct parameters for your display such as "-dserial:COM5" to set the port if you don't have that already in brltty.conf. The debug-brltty.bat should log to your terminal and also to a log file if I remember correctly. I hope we ca nsee how BRLTTY initializes the display based on the raw packets and compare this with NVDA.

I definitely saw it say "BRLTTY 5.6" and not "6.6M", and yes, the version shipped with Narrator in Windows 10 is 5.6 not 6.6.

As suggested, I did install the older release instead of the 6.x series, which seemed to work, though input still isn't working with NVDA (I'm probably not doing it correctly). I'm not sure if this is the log you wanted, but I was able to run it with the debug batch file as recommended, though did run it as admin since I saw that the log was going to be written in the program directory. The only change I did was remove the time stamps because it was quite verbose:
debug.log

I received the NLS eReader Zoomax braille display driver from the National Library Service today (see this zip archive), and the display does work with NVDA with both USB and Bluetooth connections. The only problem is that b11 (the spacebar) isn't registered as such in the mapping, though the Bluetooth mode gets around that by mapping it to b10 (identical to BR). Not sure how this is to integrate into the Baum driver, but one of the comments did say it was based on said driver.

As a priority we should update our documentation to clearly state that this specific device does not work with NVDA.

Creating support in NVDA for this device will be challenging without spec information from the manufacturer.

@tmthywynn8 Based on that driver the changes seem very minimal. It seems this device does not respond to a cell count request and therefore the Baum driver will not recognize it. In this driver the cell count is hardcoded to 20 cells.

I think the best solution here would be to find a way to identify this device in the Baum driver and set the cell count to 20 instead of relying on the display reporting it's cell count. Since I don't own this device, I have no easy way to find a good way to identify it and have no motivation to work on this. Besides, I think manufacturers should just extend the driver that is already there and submit their changes to NVDA core to give their users a good user experience. They took the effort to clone the Baum driver and made the minimal changes they need, so doing this properly and submitting a PR to NVDA is not that much of a stretch.

Are you sure? It does look like from the BRLTTY log that the cell count is returned, i.e.:

serial: input: 1B 01 14
input packet: 01 14
Cell Count: 20 (20 text, 0 status)

I will, of course, write to the folks at NLS to see if the author of this driver would be willing to push their code upstream and incorporate into NVDA itself.

@tmthywynn8 Good catch. I was just looking at their driver, which hardcodes the cell count and didn't compare it to the BRLTTY log this time. So I don't know why they do this.