Prev: Saving C structures to file -- best practices
Next: What is happening to Atmel EEPROMs?
From: D Yuniskis on 11 Apr 2010 13:20
Hi Robert,

Robert Roland wrote:
> On Tue, 30 Mar 2010 19:16:44 +0200, I wrote:
>
>> I'll test and see if I can answer the call from the phone.
>
> Ok, I have tested. I can answer the call from the phone, but I cannot
> re-establish the connection after having been out of range.

<frown> While I'll admit that I expected you would need to
explicitly pair the device *initially*, I guess I am
surprised that you have to repeat this procedure, again,
when you "simply" move out of range.

Or, am I misreading your statement: the device may
remain paired but this *session* is "broken"? I.e.,
you can "answer" the next call but can't "reconnect"
to the current?

(sorry, I don't mean to be splitting hairs -- but I
*think* there is a difference?)
From: Robert Roland on 11 Apr 2010 14:22
On Sun, 11 Apr 2010 10:20:16 -0700, D Yuniskis
<not.going.to.be(a)seen.com> wrote:

><frown> While I'll admit that I expected you would need to
>explicitly pair the device *initially*, I guess I am
>surprised that you have to repeat this procedure, again,
>when you "simply" move out of range.

You don't have to repeat the pairing (with PIN codes etc.). But it
seems the phone is not aware that the headset is in range until the
headset sends some sort of notification.

>Or, am I misreading your statement: the device may
>remain paired but this *session* is "broken"? I.e.,
>you can "answer" the next call but can't "reconnect"
>to the current?

I've never tried to go out of range during an ongoing call.

There is a small icon (a headphone surrounding the BT logo) on the
phone that shows that a BT headset is connected. If that icon is shown
when an incoming call arrives, the BT speaker beeps to indicate the
incoming call, and the call can be answered from the headset with a
short press of the button.

If the phone goes out of range, the headset icon disappears and does
not automatically come back when the phone comes back into range. In
this state, an incoming call cannot be heard or picked up from the
headset. What you can do, is to press and hold the button for a couple
of seconds to initiate the reconnect. That takes a few more seconds,
and then you can answer the call.

I know some BT hands-free units (which is essentially the same thing)
will reconnect automatically when the phone comes into range. I once
was in a conversation with a person who was walking towards his car.
As he got close enough, the audio was automatically transferred to the
HF inside the car, and we could not hear each other until he opened
the door and got into the car.
--
RoRo
From: D Yuniskis on 12 Apr 2010 00:37
Hi Robert,

Robert Roland wrote:
> On Sun, 11 Apr 2010 10:20:16 -0700, D Yuniskis
> <not.going.to.be(a)seen.com> wrote:
>
>> <frown> While I'll admit that I expected you would need to
>> explicitly pair the device *initially*, I guess I am
>> surprised that you have to repeat this procedure, again,
>> when you "simply" move out of range.
>
> You don't have to repeat the pairing (with PIN codes etc.). But it
> seems the phone is not aware that the headset is in range until the
> headset sends some sort of notification.

But, once the connection was made, why wouldn't it persist/resume
*after* interrupted? Or, is it a duplex channel and the phone
decides that it should close the session once the channel is
broken (does your phone then reactivate the speaker/microphone
in the phone "automagically" once the connection is "interrupted"?

>> Or, am I misreading your statement: the device may
>> remain paired but this *session* is "broken"? I.e.,
>> you can "answer" the next call but can't "reconnect"
>> to the current?
>
> I've never tried to go out of range during an ongoing call.

<grin>

> There is a small icon (a headphone surrounding the BT logo) on the
> phone that shows that a BT headset is connected. If that icon is shown
> when an incoming call arrives, the BT speaker beeps to indicate the
> incoming call, and the call can be answered from the headset with a
> short press of the button.
>
> If the phone goes out of range, the headset icon disappears and does
> not automatically come back when the phone comes back into range. In
> this state, an incoming call cannot be heard or picked up from the
> headset. What you can do, is to press and hold the button for a couple
> of seconds to initiate the reconnect. That takes a few more seconds,
> and then you can answer the call.

OK. So, the headset creates another "session" with the phone
at that time.

> I know some BT hands-free units (which is essentially the same thing)
> will reconnect automatically when the phone comes into range. I once
> was in a conversation with a person who was walking towards his car.
> As he got close enough, the audio was automatically transferred to the
> HF inside the car, and we could not hear each other until he opened
> the door and got into the car.

Hmmm... so, maybe the issue is in the *headset* trying to
prolong battery life? I.e., when *it* no longer senses
the BT connection as "live", perhaps it powers down? And,
repressing the button powers it up and sets it hunting
for its paired mate?

<frown> I will have to play a bit to identify where the
disconnect is happening.

Thanks!
From: Robert Roland on 12 Apr 2010 16:23
On Sun, 11 Apr 2010 21:37:35 -0700, D Yuniskis
<not.going.to.be(a)seen.com> wrote:
>But, once the connection was made, why wouldn't it persist/resume
>*after* interrupted?

I don't know, but I presume it is to avoid spontaneous transfer to the
BT unit if it should happen to come in range. Say I am talking on the
phone while walking towards my office (where my BT unit is located).
Once I get a few yards outside the door, I'd lose all audio.

>Or, is it a duplex channel and the phone
>decides that it should close the session once the channel is
>broken (does your phone then reactivate the speaker/microphone
>in the phone "automagically" once the connection is "interrupted"?

Yes, the phone automatically transfers to the on-board microphone and
speaker. I don't have to do anything on the phone to get it working
normally.

>Hmmm... so, maybe the issue is in the *headset* trying to
>prolong battery life?

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.
--
RoRo
From: D Yuniskis on 13 Apr 2010 09:30
Hi Robert,

Robert Roland wrote:
> On Sun, 11 Apr 2010 21:37:35 -0700, D Yuniskis
> <not.going.to.be(a)seen.com> wrote:
>> But, once the connection was made, why wouldn't it persist/resume
>> *after* interrupted?
>
> I don't know, but I presume it is to avoid spontaneous transfer to the
> BT unit if it should happen to come in range. Say I am talking on the
> phone while walking towards my office (where my BT unit is located).
> Once I get a few yards outside the door, I'd lose all audio.

But, presumably, you can deliberately tell the connection
to be made/broken. 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"?

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.

>> Or, is it a duplex channel and the phone
>> decides that it should close the session once the channel is
>> broken (does your phone then reactivate the speaker/microphone
>> in the phone "automagically" once the connection is "interrupted"?
>
> Yes, the phone automatically transfers to the on-board microphone and
> speaker. I don't have to do anything on the phone to get it working
> normally.
>
>> Hmmm... so, maybe the issue is in the *headset* trying to
>> prolong battery life?
>
> 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?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Saving C structures to file -- best practices
Next: What is happening to Atmel EEPROMs?