#28 Proximity loops over

v1.2
closed
Backend (20)
5
2008-03-14
2008-02-11
Fred Blaise
No

Hello,

I am using v. 1.2.3 tarball, with a sony-ericsson w880i.

Everything is fine, except that, when i take my phone above locking distance, the proximity detected by the software is looping over.. so it goes from 0 to 6 to 18 (where it should stay at the phone is not moving), but it goes back to 0, etc... hence unlocking the screen or not doing anything at all, since the software doesn't think it stays far away for enough time.

Discussion

  • Logged In: YES
    user_id=114903
    Originator: NO

    hm, that is probably one of the stranger bluetooth things to happen. there's always a little black magic within the bluetooth hard- and software. Does it actually stay at 0 or just cycle through there? If cycling is your problem you may set the unlocking threshold to a value of 3s and the distance to like 5 if it would cycle 0/6/18. Try to play with the settings.
    I've noticed that sometimes if bluetooth thinks it's loosing a connection it reconnects by itself which will reset the rssi value calculation (which always starts at 0 after the connection is done) If it falls back fro such a high value to 0 i guess the reconnect is a possible cause. Then again playing with the unlocking values might help there.

     
    • assigned_to: nobody --> highno
    • status: open --> pending
     
  • Fred Blaise
    Fred Blaise
    2008-02-13

    • status: pending --> open
     
  • Fred Blaise
    Fred Blaise
    2008-02-13

    Logged In: YES
    user_id=759577
    Originator: YES

    Yes, I think it is indeed related to very frequent disconnections... If I try other rfcomm channels that I use with other devices (but which never disconnect!), my phone bluetooth is connected, disconnected, connected, etc... I must add also that, when transferring files over BT with my computer, the connection never drops.

    Playing with values is not good enough, unfortunately, because even when the phone is right next to the computer, distance jumps to 15 or so, comes back to 0, 5, then 8, etc... :/

    I am attaching the results of a sdptool browse for my phone, just in case...

    Thank you.
    File Added: w880i.out

     
  • Fred Blaise
    Fred Blaise
    2008-02-13

    sdptool browse w880i

     
    Attachments
  • Logged In: YES
    user_id=114903
    Originator: NO

    I've always wanted to support better logging :-) But I don't have any time to implement that now. What could be the cause for this might be that there is actually not a single byte of payload on the connection. It might be the phone waiting for some protocol data there and is running into a timeout. Solving that would mean implementing part of a protocol here. It would clearly help to give the output of the hcitool rssi calls (one per second) for at least three complete cycles so I could maybe give optimized values.

    Did you check all other open rfcomm channels for similar problems?
    If you have a bluetooth headset you might also use that one too :-)

    Bye
    Lars

     
  • Fred Blaise
    Fred Blaise
    2008-02-14

    Logged In: YES
    user_id=759577
    Originator: YES

    Hi again,

    Here is the rssi output. Phone was about 25cm from my laptop:

    fblaise@fredb-opensuse:~> while [ 1 ]; do hcitool rssi 00:1A:75:DF:D1:62; sleep 1; done
    RSSI return value: 0
    RSSI return value: 0
    RSSI return value: -5
    RSSI return value: 0
    RSSI return value: 0
    RSSI return value: -16
    RSSI return value: -10
    RSSI return value: -6
    RSSI return value: -17
    RSSI return value: -7
    RSSI return value: 0
    RSSI return value: -16
    RSSI return value: -14
    RSSI return value: 0
    RSSI return value: 0
    RSSI return value: 0
    RSSI return value: -11
    RSSI return value: 0
    RSSI return value: 0
    RSSI return value: 0
    RSSI return value: -5
    RSSI return value: 0
    RSSI return value: 0
    RSSI return value: 0
    RSSI return value: 0
    RSSI return value: -7
    RSSI return value: 0
    RSSI return value: -6
    RSSI return value: -2
    RSSI return value: 0
    RSSI return value: -15

    I have tried all other rfcomm channels, same problem.

    No headset, the phone is the only bluetooth device I have. What is odd is that I never have any issues with other devices.. I use the phone with a GPS on my motorbike to phone, never cuts, transfer files with the computer, never cuts... odd..

    I wish I could help to have better logging, but I only am starting to learn python (from perl) and know next to nothing with bluetooth protocol.. but I guess it could be fun, if I had enough time too :)

     
  • Logged In: YES
    user_id=114903
    Originator: NO

    Hi,

    I see the problem. Though it should still work if you try these values for
    -locking:
    distance: 8
    delay: 7
    -unlocking:
    distance: 6
    delay: 2
    Try these values please.

    Bye
    Lars

     
  • Fred Blaise
    Fred Blaise
    2008-02-14

    Logged In: YES
    user_id=759577
    Originator: YES

    Doesn't work.. phone is at 10m distance, but distance goes from 3 to 15, but never stays above 8 long enough to lock (never more than 1 sec)... Actually most of the time, it is at 0-3. It seems that, whereever the phone is, i have the same rssi values than when it is next to the computer... :/

    Actually, what do the distance number actually means? meters? or?

     
  • Logged In: YES
    user_id=114903
    Originator: NO

    Hm, does not sound nice. Could you do the same experiment as before with the phone at a distance it should lock?

    The distance value is the value of the rssi (Rsomething signal strength indicator) field during bt transmission. the rssi value is just the signal strength and does not directly relate to certain distances. It may (in most cases) give a hint at the distance but no absolute values. Additionally it is calculated over a period of time so it 'loosely relates' to distance values.

    Bye
    Lars

     
    • status: open --> pending
     
    • status: pending --> closed
     
  • Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).