NanoNotes and electronic dictionaries

Paul Boddie paul at
Sat Aug 24 15:39:40 EDT 2013

On Saturday 24. August 2013 00.41.13 Werner Almesberger wrote:
> Paul Boddie wrote:
> > I imagine that one significantly different thing is the keyboard.
> I'd consider the keyboard the most difficult component. My
> hardware difficulty ranking would be, from hardest to easiest:
> 1) keyboard
> 2) case
> 3) WLAN
> 4) LCD
> 5) battery
> 6) audio
> 7) CPU and all the rest

It's perhaps a wake-up call that a lot of open hardware sits at number 7 on 
that list, really.

> The ideal keyboard would not only work and "feel right" but it would
> also allow for relatively easy reconfiguration. E.g., by accepting
> keycaps or similar that can be manufactured or imprinted with a
> small-tech approach (CNC mill, 3D printer, laser cutter, etc.)
> suitable for low-volume customization.

When buying a nice little gadget that I will be interfacing to the Ben, I 
found some interesting parts intended for arcade cabinets that had 
interchangeable key or button caps:

None of the actual switches for which these things are suitable would be 
appropriate for a small device, but I thought it was interesting to see such 
things for sale. I had hoped that some of the smaller switches would also 
permit customisation in this way, but I imagine that this is where "bespoke 
solutions" companies make their money.

> Note that there are quite unusual approaches that work well. E.g.,
> the OQO 01/01+ had a keyboard with small round buttons under a
> plastic film. Unlike the Sinclair ZX80/81, which used a somewhat
> similar approach, with painful results, the OQO keys had very clear
> tactile feedback.

What surprised me when I started looking was how much membrane technologies 
are used and how they have developed.

I had another look at the construction of the Ben, without actually taking 
mine apart, and found the following images on the wiki:

Maybe you know more about this, but it seems that the first image shows the 
dome switches being placed over the appropriate places on the circuit board, 
with the second image showing the result and the actual keyboard assembly that 
positions the keycaps above the switches. I couldn't find very much 
information about the nature of the dome switches, but I imagine that they're 
somewhat like that "carbonized rubber button" mentioned on the "USB BOOT mode" 
page [*] but with a certain amount of tactile resistance to provide a "click" 
when a key is pressed.


Looking around on the Internet and also taking things to bits, it looks like a 
lot of devices settle for silicone rubber keypads/keymats with all the keys 
provided on the same silicone rubber moulding and with the domes being 
provided as part of the moulding. Remote controls for televisions and other 
consumer electronics devices as well as home telephones seem to use such 
solutions ubiquitously. An interesting site with some technical details is 
this one:

Meanwhile, here's what the OpenPandora device uses:

I get the feeling that for those who work with this stuff, "everybody" knows 
all of this, but it is impenetrable for the rest of us, especially without any 
knowledge of the terminology.

> > Looking at screens, it seems pretty difficult to get one the same size as
> > the Ben's.
> Maybe not: go to then click on "TFT" in the
> side bar. The AM320480B looks quite reasonable for the Ben form
> factor: module size 87 x 58 mm, 480 x 320 pixels, 3.5" diagonal, 164
> dpi, 3:2 aspect ratio. This seems to be very similar to the iPhone 1
> and 3 display, so there ought to be a gazillion more.
> For comparison, the Ben's display: 70 x 51 mm, 320 x 240 pixels,
> 3.0" diagonal, 133 dpi, 4:3 aspect ratio. says 3.0" (60mm x 45 mm), but I suppose it 
is closer to 3.1".

> They're probably not too hard to source in the Chinese market.
> There are also some EU distributors that list it. Fun feature: the
> controller has its own frame buffer, so the CPU could stop screen
> refreshes when there are no changes and thus have more memory
> bandwidth available for other things.

I will admit to being lazy again and confess that I just looked at a local 
distributor. I don't think it is too unusual for smaller displays to have 
their own framebuffer: I have one of those colour LCD Arduino shields whose 
display controller maintains its own framebuffer which is accessed by telling 
the controller over SPI to update a window on the display using data that is 
then sent as one long sequence of values by the Arduino.

Even the fairly low resolution involved when multiplied by the pixel depth 
would demand a larger framebuffer than the Arduino's microcontroller could 
provide, so we end up with the Arduino communicating with something that is 
probably more powerful (an ARM7-based controller, I think). Another 
interesting feature is support for vertical scrolling, suggesting that the 
controller really was developed for mobile phones of the time with limited CPU 
and RAM resources needing a colour display and smoothly scrolling menus.

Anyway, a quick search locally produces something like these:

For some odd reason, the "module dimensions" of these things seem to exceed 
100mm in width, even though the module doesn't look that much larger than the 
panel in the pictures or diagrams, but the interesting thing about the 
datasheets is the way they have a dump of code in the appendix for 
"initialization for reference".

> Data sheet of the "A" version of that display:
> The controller (RM68040) appears to be the same as the Ilitek
> ILI9481, with this data sheet:
> > What is interesting about the Ben is that the screen only takes up 75%
> > or so of the available space, which then makes one wonder whether the
> > case could accommodate a larger panel anyway.
> Yes, there's a lot of unused space there. Just about as much as the
> above larger display would fill. This is what a scan of the Ben's
> display frame looks like:
> ta/jpg/ben-lcdframe-front-500um.jpg
> This display is slightly asymmetric, so a symmetric placement would
> leave room for an RF cable on one side leading to an antenna in the
> top area of the display shell.

Has anyone done anything with CAD software for the Ben's case? I see that 
there are DXF files as well as others, but I have been intending to mess 
around with OpenSCAD, and it would be interesting to explore the matter of 
machining cases for various things. Although the trend is towards 3D printing 
for everything, practicality dictates the use of more established methods. In 
the holiday period I read some articles related to model boats and aircraft, 
and although people active in that field are enthusiastic to try everything 
out that might make their hobbies easier and their output better, it appeared 
that the more useful technology emerging in their scene was in fact computer-
controlled laser cutting.

Of course, casework for things like the Ben would probably demand something 
else again, but it was interesting to see people using Inkscape to get their 
aircraft parts into a laser-ready form as well as the availability of 
increasingly inexpensive machines to do the physical work.


More information about the discussion mailing list