On 07.09.2013 12:48, Werner Almesberger wrote:
EdorFaus wrote:
This made me think of another (fairly recent) RF standard I've been
interested in, named DASH7
Oh, they opened is now. Nice. I'm not sure about 433 MHz, though.
Don't the antennas get awfully large ?
I don't think they have to be, considering one of the products I've
seen
that uses DASH7 is the HayTag [1] - a pet tag intended for finding lost
pets - which is supposedly just 37 x 34 x 4.5 mm, and that includes not
only the antenna, but also the MCU and the solar cell that powers it.
[1]: http://haytagstore.com/
Also, I've been considering buying a 433MHz development platform that
TI
is selling, which is in a wristwatch form factor. IIRC it's got a
fairly
decent battery life too. (Main reason I haven't yet is lack of time.)
My idea is to simply reuse the atben/atusb work.
That's probably a good idea; starting from scratch with a new
technology
would really just be adding another variable for little reason.
It only allows for sending keypresses (and releases), which is not
quite the same thing, as that only tells you which key (or combo)
was pressed, not what character was printed on that key.
Ah yes, good point. USB HID basically sticks to the virtues of
the good old IBM PC keyboard. It was a pain back then, so why
change it.
Heh. Well, it actually makes sense to do it this way, since it's a good
representation of what a keyboard really is and does - and sometimes,
you don't really care which letter is printed on it, as long as you can
recognize the key; or you might have a need to remap it *anyway*.
That doesn't mean it's not a pain sometimes, though. :P
This means that the device needs to know which keyboard layout is in
use on the PC it is talking to, and the keyboard protocol doesn't
give it that info.
Well, it sort of could. There's the bCountryCode field in the HID
descriptor that could indicate what kind of "localized hardware"
you have. Of course, using that would be uncool, so nobody seems
to.
I wasn't aware of this, but if nobody uses it, I guess it can't really
be
trusted by the OS, which means it would probably be ignored anyway...
The easiest way to do that would probably be to make a setting for
it.
Yes, that seems to be the best choice. Forced QWERTY would also
be hugely unpopular with QWERTZ and AZERTY users.
Yep, anyone who doesn't use QWERTY would be really unhappy, even if
they
did stick with just the basic set of chars.
I guess US QWERTY would be a good place to start though, as long as we
keep in mind that we'll need to be able to map things differently
later.
And I do mean it when I say differently - not just different key, but
different key combinations. (Example: US QWERTY has ; and : on one key,
one shifted one not. My keyboard has them on different keys, both
shifted.
Another example: my layout can generate É, but only by pressing
multiple
keys in sequence; I assume languages that use it often would have it
more
easily available on their layout.)
Actually, now that I think about it, I think we're going to need to be
able
to tell the user that a password can't be typed with the currently
selected
layout, as different layouts can generate different sets of characters.
E.g., I don't think a US layout can generate the Æ, Ø and Å my layout
can.
Hm, there's an idea - I assume the device will be able to recognize
which
dongle it's in the vicinity of (since they're paired with keys etc.),
so
maybe we could have a way to autoselect the layout to use based on
that?
Most people probably wouldn't need it, but it would be nice for those
who
use different layouts in different places (e.g. at work and at home)...
Would still need to have settings for that of course... And a way to
override the autoselection.
... Hm, what should happen if the device is in the vicinity of more
than
one known (and paired) dongle? E.g. if you have one dongle in your work
PC,
and one in your laptop, and then one day you bring the laptop to
work...
Oh well, most of that is just software, so we can deal with those
features
when we have something that works for the basic use case.
Since it would typically operate in a "almost always off" mode,
That's a good point. With a device like this, and a basic RTOS, it's
probably going to be just as fast to boot each time as it would be to
suspend/resume with something more complex (like Linux), and that makes
it perfectly feasible to keep it completely off most of the time, which
saves quite a bit of power.
Assuming about 5 minutes of use per day, at an average of 70 mW,
CR2032 should last about two months, AAA half a year, and AA more
than a year.
If we make sure it's powered completely by USB as long as the device
port
is connected to a host, quite a few people might end up using it on
battery
power even less than 5 minutes per day.
Although, that depends on having them plug it in instead of using the
RF
dongle... So I guess maybe not all that many people after all. Oh well.
I still think it's a good idea though, as it would make the device
usable
even when the battery is dead.
Hm, I wonder - would it be feasible to have the device side USB plug be
a
male A plug on a cord that retracts into the device body? That way the
user
wouldn't need to carry a cable separately... Oh wait, that's what the
RF
dongle is for, duh.
-Frode
_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): [email protected]
Subscribe or Unsubscribe:
http://lists.en.qi-hardware.com/mailman/listinfo/discussion
