Felix wrote:Everything is cheap in China ;-) The challenge is to find out if
> Wow, they're sooooo cheap! I said the LCD one because it has built-in
> character display, so it's easy (at least for me) to interact with it.
it also works ...
Regarding USB, there the the following options:
> Also can be developed in the future a usb powered mcu with usb-host (again
> for keyboad plug-in) and radio that will communicate with the device :P
0) device only. This is what I drew in the block diagram.
1) unpowered OTG: constrains choice of MCU, but there are good and
inexpensive MCUs with OTG now, and it'll only get better in the
future. To attach a USB device, you need a Y cable that provides
power from another source (e.g., a PC) and you lose USB device
functionality while operating as host.
2) powered OTG. Add a boost converter for Vbat -> 5 V, but still
require a Y cable and external power source if the device we
connect draws more than very little. I.e., it would be fine for
pairing a dongle but not for some/most/all(?) keyboards.
A device that draws little power would be connected either via
the same Y cable but without needing an external power source,
or via a Micro-AB to A cable.
3) more power. Switch to a stronger battery, at least for keyboards.
Since a stronger battery (AAA, AA) has a low voltage,
a) the system would need to run a boost converter also while in
standby, or
b) we'd need to have two battery cells (yuck), or
c) we'd add a second battery (CR2032) for standby (so that the
MCU can listen for a wakeup signal and also maintain time).
Being able to maintain time would be desirable for any "code
token", e.g., TOTP (RFC 6238).
4) separate USB A receptacle. This considerably constrains the
choice of MCU or requires two USB-capable MCUs. Power could come
from
a) an external source, plugged into the USB device port. So the
password safe basically acts like a Y cable itself.
b) a weak internal source (or an external source).
c) a strong internal source (or an external source).
5) USB A receptacle plus dongle bay. This adds an empty space in
the password safe's case to transport an RF dongle. This was the
original proposal.
A purely mechanical bay could also be added to any of the other
designs, if there is room.
So, assuming we want to use this with power-hungry devices, each of
these solutions would require the following features:
Feature required 0 1 2 3a 3b 3c 4a 4b 4c 5
----------------------- --- --- --- --- --- --- --- --- --- ------
MCU USB dev OTG OTG OTG OTG OTG D+H D+H D+H D+H
Y cable - Y Y opt opt opt - - - -
AB Host cable (or Y) - - - Y Y Y - - - -
External power source - Y Y opt opt opt Y Y opt see 4*
Bigger battery - - - Y Y Y - - Y see 4*
USB A receptacle - - - - - - Y Y Y Y
Dongle bay - - - - - - - - - Y
1) would be an easy upgrade for the device-only design. People who
are comfortable with the treacherous safety of their PC as their
interface to set up the password safe and those who don't mind to
do such things through a possibly quite clumsy dial-and-push
interface would see no difference to solution 0).
Those who want the extra security of using a "dumb" keyboard would
be able to do that, but at the cost of somewhat messy cabling and
the occasional hunt for a power source.
Also pairing the dongle would require either trust in the PC, a Y
cable, or the use of an over-the-air pairing protocol.
I kinda like that for a first round. All the powered solutions
that don't also include a second port still need fancy cables and
thus don't really improve usability all that much. And the second
port is a bit of a burden.
Dropping the bay may have a usability impact. On the other hand,
it decouples the mechanical design of safe and dongle, which is
nice from an engineering point of view.
I'm a bit wary of capacitive sensors. I did a design that runs
> Agree with that. I remember to see a curious design in TI documentation[3]
> using tactile sensors.
from a unregulated battery, not too dissimilar from what we'd have
here, that uses a small sensor through some 3 mm of acrylic and it
performs very unevenly. But maybe it's just my algorithm that
sucks. Should look at TI's :)
BTW, their code [1] is under 3-clause BSD. None of that "use this
only with our hardware" others are so fond of. Nice.
Another drawback of having only a capacitative sensor is that,
when in standby, the MCU has to wake up from time to time to take
a sample and see if the user demands its attention.
- Werner
[1] http://www.ti.com/tool/capsenselibrary
_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): discussion@lists.en.qi-hardware.com
Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion