[bookport] Re: TO LOCK OR NOT TO LOCK, THAT IS THE QUESTION

  • From: "Lou Kolb" <loukolb@xxxxxxxxxxx>
  • To: <bookport@xxxxxxxxxxxxx>
  • Date: Sat, 7 Jan 2006 11:35:19 -0500

I think the sensitivity setting determines how long you have to hold a key
down before the unit beeps and it goes to the alternate command.  The lock
command is, by default, not a delayed command so sensitivity should not have
any effect on it.  Lou
----- Original Message ----- 
From: "howard wolcott" <hwolcott@xxxxxxxxxxx>
To: <bookport@xxxxxxxxxxxxx>
Sent: Saturday, January 07, 2006 11:31 AM
Subject: [bookport] Re: TO LOCK OR NOT TO LOCK, THAT IS THE QUESTION


> hi    that's what the sensitivity selection is for.    by default it is
set
> to 15 but you can lengthen it out to 75.
> expeeriment with the settings.    it may solve your problems without
adding
> an extremely difficult keystroke.
> hth
>
>      howard wolcott
> ----- Original Message ----- 
> From: "Walt Smith" <walt@xxxxxxxxxx>
> To: <bookport@xxxxxxxxxxxxx>
> Sent: Saturday, January 07, 2006 10:50 AM
> Subject: [bookport] Re: TO LOCK OR NOT TO LOCK, THAT IS THE QUESTION
>
>
> > While I've never actually experienced the problem, if it's common
enough,
> > I
> > like either the four-key approach; although I think I'd suggest 2+4+6+0;
> > or
> > keeping the current two-key combination with a built-in mandatory
holddown
> > time. In general, I think a four-key combination would be less likely to
> > occur inadvertently than even a two-key combination with extended
timeout.
> >
> > ----- Original Message ----- 
> > From: "Brian Buhrow" <buhrow@xxxxxxxxxxxxxxxxxxxxx>
> > To: <bookport@xxxxxxxxxxxxx>
> > Cc: <buhrow@xxxxxxxxxxxxxxxxxxxxx>
> > Sent: Saturday, January 07, 2006 4:26 AM
> > Subject: [bookport] TO LOCK OR NOT TO LOCK, THAT IS THE QUESTION
> >
> >
> > Hello folks.  I confess to being a bit nervous about starting a debate
> > on this list, but I've spent a lot of time thinking about this issue,
and
> > I
> > realize that I could go either way, so I'm interested in what others
think
> > before I float a change request on this list.
> > As many of you know, pressing the 2 + B keys simultaneously resets
> > your bookport to its factory default settings.  Did you know, however,
> > that
> > this key combination still works even when the unit is locked?  When I
> > first discovered this fact, I thought, "well, that makes sense, if the
> > unit
> > is mis-behaving, it's useful to be able to reset it regardless of
whether
> > it's locked or not."  However, on a couple of occasions since, I've
locked
> > the unit while playing, dropped it in my pocket for easy listening and
> > carrying, only to have something bump the keys of the unit in such a way
> > as
> > to trigger the magic reset option.  This is, to say the least while
> > listening, a rather disconcerting event.  Upon further reflection, I
> > realized that the two keys which need to be pressed to cause a reset are
> > in
> > a vertical line when juxtapose to each other.  And, so, it began to
occur
> > to me that this iis a fairly likely scenario.  If a straight edge bumps
> > you
> > which happens to press the center line of keys while you're listening,
> > even
> > for a brief second, all bets are off.  You're resetting the unit, and
> > you'll have to pick up reading at the point where you began your most
> > recent reading session, rather than at the point the unit reset.
> >
> > I don't know about anyone else, but I find this behavior somewhat
> > annoying.  So, I began to think, and I came up with three possible
> > solutions to the problem, which is where the debate begins.  Below are
my
> > three ideas.  What are other's thoughts on this issue?
> >
> >
> > 1.  Leave things as they are, living with the not unlikely event that
> > you'll stop your reading session on occasion by resetting the unit
> > inadvertently.
> >
> > 2.  Change the behavior of the firmware such that reset requests are
only
> > honored when the unit is unlocked.  The idea here is that if the unit is
> > really and truly crashed, keyboard input probably doesn't work anyway,
and
> > so a power cycling, i.e. battery pull, is in order afterall.
> >
> > 3.  Change the sequence of keys used to reset the unit.  I'd suggest a
> > 4-key sequence, like: 4 + 6 + A  + C.  This idea stems from the
> > observation
> > that I've found that if the unit is dropped on its back, even a short
> > distance, the weight of the keys impacting the unit as they stop causes
> > them to be activated.  Further, I've noticed that the keys which seem to
> > be
> > activated most are those in the center of the keyboard.  I attribute
this
> > to the notion that the keyboard flexes most in the middle, and that this
> > causes more motion between the keys and the board behind them on impact.
> > By utilizing multiple keys at the edge of the keyboard to accomplish a
> > reset, the likelihood that a reset could be triggered by dropping the
unit
> > is much lower.
> >
> > Am I just particularly picky, or have others noticed this problem,
> > and, if so, do they have thoughts about it?
> >
> > -thanks
> > -Brian
> >
> >
> >
> >
>
>

Other related posts:

  1. Home
  2. bookport
  3. Archive
  4. 01-2006