anelok: touch slider idea

Felix sucotronic at gmail.com
Wed Dec 4 05:13:52 EST 2013


IMO your approach with the hardware wheel is much better than the "sliding"
surface. The user don't have "touch" feedback of actions, and anything
"touch enabled" is harder to interface and develop. Is just a personal
opinion, but I won't advise to follow that path...


On Tue, Dec 3, 2013 at 10:51 PM, Werner Almesberger
<werner at almesberger.net>wrote:

> Nick brought up an interesting idea: what if Anelok had a slider ?
> We discussed touch sensor ideas before, but more in the style of
> an iPod-like wheel.
>
> Now, that display has a large area at its bottom for its circuit,
> which isn't visible on the outside. There may be just enough room
> for a sensor.
>
>
> Q1: would it fit ?
>
> The vertical stacking of the case is as follows:
>
> - 0.8 mm window (nominal - varies due to machining tolerances),
> - 0.3 mm airgap (so that a bezel can be formed, for stopping the
>   masking fluid),
> - 1.0 mm bezel (constrains the OLED module laterally),
>
> and so on.
>
> An FPC carrying the sensor could go into the airgap. A thin PCB
> (0.4 mm) would also fit if the airgap was marginally larger. This
> airgap would have to be separated from the one under the window
> (we want to be able to have paint above the sensor) by a small
> ridge. Some 0.8 mm plus 0.2 mm of tolerance should do.
>
> Sandwiching the OLED between sensor and main PCB would be a more
> interesting exercise. The OLED is already on the fumbly side (with
> its fragile FPC) and this would make it worse.
>
>
> Q2: could it replace the wheel ?
>
> The wheel is not too dissimilar from a one-dimensional slider with
> a button. On a slider, we could in fact have multiple virtual
> buttons. E.g., consider the arrangement on
>
> http://downloads.qi-hardware.com/people/werner/anelok/tmp/touch.pdf
>
> "V.A" is the visible display area, i.e., the area that's meant to
> be looked at. The display matrix is a bit smaller.
>
> The OLED module ends some 5.2 mm below the bottom border of the
> visible area, and there's also a bit more room (1.6 mm) to bend
> the FPC.
>
> The display width (about 35 mm) is roughly as far as I can swipe a
> thumb while holding Anelok without getting the feeling I'm heading
> for early RSI. The sensor could be a bit wider than the display,
> to accommodate extra buttons.
>
> The drawing shows five zones: left and right button (red), left
> and right swipe touchdown, and center. The touchdown zones could
> only be used to initiate a swipe (and no tap), the button and
> center zones would do the opposite. (But see below.)
>
>
> Q3: how would the signals be interpreted ?
>
> A think a sensor like the slider on the FRDM-KL25Z board basically
> produces one variable (theirs uses two channels, but they're
> correlated): let's assume there is a low value when the slider is
> not touched, a minimum value (well above the "idle" value) on the
> left side, and a high value on the right side.
>
> A few examples:
>
> 1) Center tap. Reading jumps from idle to center, then drops again.
>
> 2) Left tap. The same concept, just the value is a lower.
>
> 3) Tap in touchdown area. We ignore that.
>
> 4) Drag with stop. Value jumps to that of the touchdown position,
>    then changes to that of the lift-off position. Since we stop,
>    the value lingers for a moment at the lift-off position and
>    the rate of change may also decrease before stopping.
>
> 5) Drag inside touchdown area. This is the same as a tap and is
>    ignored.
>
> 6) Another drag, this time with inertia. When quickly flipping
>    through items, one may want to have a "fast forward" mode.
>    This could be selected by lifting the finger off while still
>    moving.
>
>    Anelok could then continue scrolling (or whatever the movement
>    does) while the thumb returns to the touchdown area, and
>    scrolling speed could even be accumulated, as if this was a
>    wheel with inertia.
>
>    This could be detected by the value falling off rapidly after
>    reaching the lift-off position.
>
>    Not sure if this concept can be implemented properly and whether
>    it would even make sense. But it may be an idea worth trying.
>
> 7) What do we do if a swipe begins in the left or right button
>    area ? Not sure. Maybe we should still accept it, i.e., as if
>    the touchdown areas extended all the way to the ends of the
>    sensor.
>
> I think this could work as an input device. It would allow making
> the device more compact and it would eliminate the wheel, which is
> expensive, a sourcing risk, and also constrains the somewhat
> delicate vertical stacking.
>
>
> Q4: is it even possible ?
>
> I don't know. Capacitative sensors in general like to be large.
> This one would be tiny. They also like to be far from fields.
> This one would sit on the glass containing part of the display's
> electronics.
>
> I guess someone would have to try and see if this works.
>
> A fairly simple prototype could be made with the OLED, an MKL25
> (in 32-QFN, for easier soldering), and a FRDM-KL25Z for
> programming and to supply power. The sensor could me made from a
> suitably thin PCB.
>
> Single-sided 0.4 mm PCBs are readily available, e.g.,
>
> http://www.digikey.com/product-detail/en/PC94/PC94-ND/354417
>
> Double-sided would be better since it would allow for a proper
> ground plane.
>
> One could also use the FRDM-KL25Z directly to drive the OLED and
> the sensor, but that may yield a different (and probably worse)
> analog performance. But it may be good enough for a first quick
> test.
>
> The KL25 and beyond have a built-in touch sensor circuit that
> takes care of most of the legwork.
>
> A driver for the sensor on FRDM-KL25Z can be found here:
> https://github.com/payne92/bare-metal-arm/blob/master/touch.c
>
>
> Q5: would it feel right ?
>
> That would have to be explored :-)
>
>
> Opinions ?
>
> - Werner
>
> _______________________________________________
> Qi Hardware Discussion List
> Mail to list (members only): discussion at lists.en.qi-hardware.com
> Subscribe or Unsubscribe:
> http://lists.en.qi-hardware.com/mailman/listinfo/discussion
>



-- 
Felix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.en.qi-hardware.com/pipermail/discussion/attachments/20131204/716b4b5b/attachment.htm>


More information about the discussion mailing list


interactive