[BRLTTY] My experience with Humanware Monarch

Sat May 31 13:42:34 UTC 2025

It is important to point out it has a unique silicone cell system which is why I didn't go into it.  I have yet to see one where a pin has not failed.

-----Original Message-----
From: BRLTTY <brltty-bounces at brltty.app> On Behalf Of Devin Prater
Sent: Saturday, May 31, 2025 3:09 AM
To: Informal discussion between users and developers of BRLTTY. <brltty at brltty.app>
Subject: Re: [BRLTTY] My experience with Humanware Monarch

I have seen the Cadence Braille display. This one has a much, much faster refresh rate, about as fast as regular displays. I think it still has the issue of you can't touch the area of the display while it refreshes, but it handles it much better. When you move your finger from that exact cell, it refreshes. Now, it has four units that can be conjoined into a larger display. You can even connect just two together, in landscape or portrait configurations. The singleton is about 40 cells, about ten cells across four lines.

On 5/30/2025 4:06 PM, Aura Kelloniemi wrote:
> Hello list,
>
> Humanware/APH Monarch braille display has been mentioned a few times 
> on this list lately. I had a chance to try it out just a few days ago 
> and I think it would be worthwhile to report my experiences here.
>
> So the device is intended to display both text and graphics using 
> braille dots. It is not separated to distinct lines. Its resolution is 
> 96x40 braille dots. In computer braille mode it can show 8 lines and 
> 32 columns of text (assuming empty dot between character cells—both vertically and horizontally).
>
> There are two very important downsides in this device if one plans to 
> use it as a braille display for accessing text terminals. First of 
> all, the display renders itself very slowly. Every refresh takes about two seconds (or more).
> This includes adding or removing single characters. I did not try it 
> in a terminal (of course, because there is no driver available), but I 
> suspect that a two seconds delay is a major issue when trying to 
> navigate a terminal screen.
>
> The second problem is that the dots that are being rendered must not 
> be touched during refresh, or the rendering process will be just 
> partial. If the display is being touched during rendering, the dots 
> being touched may not be raised/lowered and the user needs to trigger 
> a refresh (there is a button for that in the display).
>
> Rendering the dots makes considerably more noise than what is usual to 
> braille displays. Also the dot panel is under a plastic membrane which 
> feels a bit sticky, especially if one's hands are not very dry. The 
> touch recognition feature in Monarch works very differently from how 
> it is implemented in some HandyTech displays. I was told there are 
> some light sensors which detect the position of the user's finger on 
> the display, and routing/button activation needs to be triggered b 
> pressing a button with the other hand. Lighting conditions can affect 
> how touch recognition works. For me it worked about 90% of cases.
>
> I suppose all the "defects" related to display refreshing are due to 
> the technology used in the display. I don't know how the display works 
> internally, but certainly the braille dots are controlled in a 
> different way compared to traditional displays.
>
> What is good in this display? First of all, it is big. Reading long 
> passages of text with a multi-line display is (for me at least) much 
> faster than with a single-line display. Also the graphics feature is 
> very nice, although the resolution is low—but hey, now blind people have access to pixel art.
>
> Considerations for BRLTTY: there are a few things that could be 
> implemented in BRLTTY to help utilize multi-line displays in 
> terminals. The most important of these is to split long terminal lines 
> on multiple braille lines. For example, if the terminal width is 80 
> characters, BRLTTY could use three lines on Monarch braille display to 
> display one terminal line. Of course BRLTTY could dynamically choose 
> how many braille lines to use for representing one terminal line (trimming trailing whitespace).
>
> Sometimes (when reading a table, or playing a grid-based game) it is 
> useful to move the whole multi-line braille window horizontally. But 
> when reading linear text (like in text editor, web browser, or output 
> of `ls -l`) the user probably would like to avoid the horizontal 
> shifts and instead read terminal contents linearly (even though line 
> breaks in the visual terminal will be in different points than on the braille display).
>
> This functionality of splitting screen lines on multiple braille lines 
> would be especially useful for Monarch display, because of its long 
> refresh time, but I guess it would be very helpful for anyone using a multi-line display.
>
> Another thing that would help Monarch users would be audible 
> notification before the display is redrawn. Because the display 
> contents will get garbled if the user touches the display while it is 
> refreshed, it would be nice to have BRLTTY beep before it refreshes 
> the display so that the user has time to remove their fingers from the display.
>
> Blinking: due to the long rendering time, all features that utilize 
> blinking (like blinking cursor, blinking attributes, etc.) must be 
> disabled when using Monarch.
>
> Line height control: BRLTTY should be able to scale the line height 
> and line spacing. The user should be able to control how many blank 
> dot rows are left between lines of text.
>
> One great feature that Monarch (and other similar displays) would 
> allow us to implement is 10-dot braille. I at least have pushed 
> computer braille to its limits long time ago and would love to have 
> more dots in my braille cells. The extra dots could be used for 
> representing terminal attributes or just to be able to differentiate 
> more characters from each other. Actually, because there is always an 
> empty vertical column of dots between each character cell, these dots could also be utilized, resulting in 15-dot braille (3x5 dot cells).
> These could be useful in representing line graphics (for example).
>
> Images support: many modern terminals can display images. BRLTTY could 
> add support for these terminals and display the images on suitable 
> braille displays.
>
> Finally, I would have two questions for those who have used the other 
> multi-line displays currently available (Canute 360 and Dotpad): do 
> these displays have the same issues with refreshing that Monarch has 
> (long refresh times, garbling of the display if touched during a 
> redraw)? Do these displays have any way to point to a specific dot 
> (e.g. to route cursor to a particular position)?
>
> If you have questions regarding Monarch, I can try to answer them.
>
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY at brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty