Prev: Saving C structures to file -- best practices
Next: What is happening to Atmel EEPROMs?
From: Robert Roland on 14 Apr 2010 07:04
On Tue, 13 Apr 2010 06:30:50 -0700, D Yuniskis
<not.going.to.be(a)seen.com> wrote:
>But, presumably, you can deliberately tell the connection
>to be made/broken.

Yes, that decision is made by the phone (or it user). On my phone,
that's relatively cumbersome, so switching the BT unit on and off is
much easier, should the need occur.

>What I am saying is why wouldn't the
>device seek to maintain whatever mode of operation was
>in effect "prior to the (temporary) loss of signal"?

It' probably just a decision made by the firmware programmers. Other
devices may be different.

>I.e., you can pair the devices. Then, decide if (any particular)
>connection (call) should be routed over the headset or the
>phone itself. Once this decision is made, it should persist
>until you explicitly tell it otherwise. Yours seems to
>behave as if "loss of carrier" is the same as "I want you
>to disconnect". The former is something that the user
>has little direct control over ("don't wander *too* far...")
>whereas the latter is a very deliberate action (normally)
>on the user's part.

If I power off the phone to change SIM and then power up again, the BT
connection is not lost. Maybe it has to do with the length of time the
connection was interrupted or something.

>> It does not look like it. The BT unit makes a specific type of beep
>> when it is powered on (also by holding the button for a couple of
>> seconds), but a different beep when only reconnecting a lost
>> connection.
>
>But, the latter is still only done when the user
>"reinitiates" it, right?

Yes, that's correct.
--
RoRo
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Saving C structures to file -- best practices
Next: What is happening to Atmel EEPROMs?