anelok: first light
Ron K. Jeffries
rjeffries at gmail.com
Sat Sep 21 14:25:09 EDT 2013
Early proto proof of concept (using Ben Nanonote) looks promising.
Surprised at apparent readability of the tiny (Type).
Eventually, a nice(!) UI grace note would be to pop up a larger overlay of
the character the jog wheel is currently pointing at. For people with
non-20-something eyes and sub-optimal vision that will improve usability
approx. one gazillion percent.
Thanks for posting these Anelok progress reports!
Ron K Jeffries
Ron K. Jeffries
On Sat, Sep 21, 2013 at 8:22 AM, Werner Almesberger
<werner at almesberger.net>wrote:
> I put together a simple test board for display and wheel. It's called
> "DUI", not for Developing Under the Influence but for "Development
> board, User Interface".
> Files live here:
> The board connects via a short cable and UBB to a Ben. The Ben
> provides power and all control. The board only has the display, the
> capacitors and resistors required for operating the display, the jog
> wheel, and a few diodes for multiplexing display and wheel. There is
> no MCU, RF, or any of the other complicated stuff.
> This is what the electronics look like:
> The board has the size I'm currently aiming for for the final
> device. (Note that this is likely to change. I've already grown it
> by a few mm over the last days, to better accommodate the display.)
> First impressions of the assembly:
> - the display's FPC ("Flexible Printed Circuit", colloquially
> "Flexible Plastic Cable"), while small, was very easy to solder
> - the data sheet doesn't make it clear, but the contacts are plated
> on both sides and seem to be connected (didn't test that). This
> means that one could also run the FPC under the PCB or (in a
> larger device) run the cable flat, without bending.
> - that critter is tiny ! It's basically two thin glass plates with a
> film of magic in between. I was afraid of breaking it, especially
> when bringing adhesives into the game, but despite its delicate
> appearance it has resisted all my efforts at destruction so far.
> - when checking the current setting resistors (R1 and R2, together
> 760 kOhm), I found that they read far too low. I first suspected
> that I may have picked the wrong components. But it was probably
> just the flux. I've seen flux form conductive paths of some 100
> kOhms in the past, e.g., keeping chips in reset for a short
> while (long enough to make the other chip that depends on it fail
> to come up, yet short enough to destroy all evidence by the time
> one starts to measure), so this is something to take into account
> when building this sort of circuit.
> - the wheel didn't pose any undue problems
> Then I wrote a little test program on the Ben (using libubb) and
> brought up the display.
> The only problem there was that the Ben reset when turning on power
> on the card slot. This is something that happens quite often when
> connecting anything but a memory card. I did allow for a generous
> "charge period" (driving all the data pins high to pre-charge any
> caps through the pull-ups and only then turn on power), but this
> wasn't enough in this case.
> Not sure why the pre-charging trick didn't work this time. The board
> has only about 11 uF in total and most of that is switched off on
> reset. Fortunately, turning on uSD power on the Ben with the DUI
> board present and then hot-inserting it did the trick.
> The rest of the bringup went smoothly. I made my program display an
> X bitmap file:
> This picture was taken at regular lab hours, i.e., at night.
> Readability is as good as one could hope for. Today's weather is
> cloudy and the forecast says it'll stay that way for the next few
> days. So I won't have a good daylight test for a while.
> Contrast stays constant at any angle, very e-paperish and unlike
> LCDs. The display does reflect bright light.
> I then added Ron's nightmare, some tiny text (5x3 pixels) about 1.1
> mm (3.3 pt) in height:
> Even that is barely readable. I then wrote a bit of code that reads
> the wheel and tries to make sense of its inputs. That code is very
> primitive (e.g., no debouncing) and it sometimes gets the direction
> wrong, but it's good enough for demonstrating the concept:
> Xiangfu has uploaded the video to YouTube. I can't get it to load,
> but this is where it should be:
> Don't read too much into what's happening there. That's not a real
> GUI. All the program knows is how to display a bitmap and to draw a
> little triangle. It has no concept of characters, fonts, etc.
> - I like the display. Works without a fuss and performs well.
> - the wheel also seems to be fine. Debouncing needs some looking
> into. Since one can't grip the board very well with a Ben
> dangling off it, it's hard to tell whether the wheel will "feel
> right", but I'm optimistic about that.
> - the PCB (0.8 mm) doesn't flex too much, even without a case
> supporting it.
> - the wheel may be a bit too close to the display. I'll probably
> either move the display by a few mm to the left or enlarge the
> board by a few mm to the right. Depends on how the layout goes.
> - I initially thought to have a some rigid structure for the spacer
> between display and PCB but given the flimsy nature of the
> display, I think just a bit of foam with a weak adhesive (the kind
> you find on Post-it(r) notes) will do.
> - the display is susceptible to smudging and scratching. May need a
> silicone seal when put into a case.
> Still not tested/checked:
> - power consumption,
> - voltage levels, especially the level of the high voltage (the OLED
> has a DC-DC converter to generate ~12 V),
> - behaviour when turning on more than 50% of the pixels. This OLED
> has the known issue of its DC-DC converter being too weak for
> driving all the pixels at the same time. This shouldn't be a
> problem for normal white-on-black use, but we'd still want to know
> what happens when exceeding that limit.
> - shutdown behaviour. The controller data sheet describes bringing
> down the rails one by one, but that doesn't seem to be a
> requirement. Need to check whether anything odd happens if I just
> do the proper software shutdown, assert reset, then cut all the
> rails in parallel. I don't expect any issues with that.
> The next big item will be getting the MCU to work.
> - Werner
> Qi Hardware Discussion List
> Mail to list (members only): discussion at lists.en.qi-hardware.com
> Subscribe or Unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discussion