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: http://www.technobotsonline.com/switches-and-relays/tactile-pcb- switches/tactile-switches-button-caps.html 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: http://en.qi-hardware.com/wiki/File:Positioning_the_Keyboard_Layer.jpg http://en.qi-hardware.com/wiki/File:Disassemble_nanonote.JPG 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. [*] http://en.qi-hardware.com/wiki/USB_BOOT_mode 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: http://www.interface-controls.com/ Meanwhile, here's what the OpenPandora device uses: http://pandorawiki.org/File:Final_Keymat.jpg 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 http://www.ampire.com.tw 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. http://en.qi-hardware.com/wiki/LCD 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: https://www.elfaelektronikk.no/elfa3~no_en/elfa/init.do?item=75-503-56&toc=20375 https://www.elfaelektronikk.no/elfa3~no_en/elfa/init.do?item=75-503-58&toc=20375 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: > http://gamma.spb.ru/download/AM-320480ATMQW-B0H.PDF > http://www.ampdisplay.com/documents/pdf/AM-320480A1TZQW-TB0H.pdf > > The controller (RM68040) appears to be the same as the Ilitek > ILI9481, with this data sheet: > http://www.allshore.com/pdf/ILITEKILI9481.pdf > > > 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: > > http://projects.qi-hardware.com/index.php/p/ben-scans/source/tree/master/da > 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. Paul _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
