BT Connector & Belkin F8T012 working ok, except ... RSSI issue

[sckoman]

I have the Belkin F8T012 working ok with the Bluetooth Connector, except for an eventual issue I believe is related to the RSSI vaules and an arithmetic operation going bad.

HomeSeer 2.3.0.0 on WinXPpro SP3 and quite stable
BTConnector hspi_bt.dll 2.48.2.2 registered Using 'Discover Service' for up to 4 devices
Belkin F8T012 dongle
Widcomm BT stack 4.0.1.2401 <- From Device Manager
BT Connector - Network0: WidComm Bluetooth Stack 4.0.1.2401 Enabled= True AutoDiscovery=False AutoDiscoveryInterval=123

The Belkin is working pretty well with poll times around 120 sec. Range is limited by the connected bt device, not the Belkin F8T012, at about 20ft indoors thru multiple floors & walls. Right at 30ft for line of sight thru windows onto the deck. Also of influenece is a 2.4gHz cordless phone system within 6ft (I will replace this with a DECT6 system as soon as I can wean the wife off of her favorite phone).

I disabled any of the services offered by the bt stack/dongle down to just a few, but left the PAN network on and ocassionally connected to a 5th bt device which does not leave the area and is not polled or setup for use with the BT Connector. The Belkin dongle is on one of the legacy 12mbs usb ports and is the only device on that root hub.

I tweaked the boolean as follows (minor) based on signal strengths:
3 Strong Device Signal @(Network0)>0
2 Device Signal OK @(Network0)>-10
1 Device Signal Low @(Network0)>-25

One can watch the device values move between states by moving the devices around the house.

I have the 'report lost' values set at 5, which is about 10-12 minutes to determine the 'away' state. I use a premisis alarm system ARM/DISARM STAY/AWAY outputs to distinguish the primary HOME AWAY state. I use the BT Connector to distinguish *who* is home. So the 10-12 minutes is an acceptable time for me.

It helps tremendously if, once you are done configuring the bt parameters on the configuration page, to exit gacefully out, close HomeSeer and restart it and then leave all the bluetooth things alone. Do not even check status on the bt devices until several poll cycles have elapsed. If you can reboot after you exit out of HomeSeer and let the usb interface reset, so much the better I have found.

Here is the problem: If a device 'leaves' or is on the fringe, about 75% of the time (but not always), the BTConnector & dongle combination reports a VERY LARGE but negative signal level. The second device that enters the 'away' state *and* results in the same VERY LARGE but negative signal level, then something goes awry and the plugin dongle combination goes south. Many times the main HS log will report 'BT dongle not found' .

So far, if the bt devices remain in range, there are no issues. Something related to that VERY LARGE but negative signal level (derived from an RSSI from the stack?) reminds me of a "Divide By Zero" issue. Something arithmetic is going wrong somewhere in the handling of the signal level numbers. I am not a programmer type, so I can't tell for sure, but that would be my guess. If we can figure this out and correct, I think we would have a nice improvement to the BT Connector.

Any ideas anyone?

[stipus]

The very large negative number is not the result of a calculation.

Each poll cycle calls an internal plugin function GetSignalStrength() that returns an integer value.

If the BT stack reports it couldn't find the device, or in case of any error, the function just returns Int32.MinValue


--> Unfortunately, this answer is not going to help you much...

I really don't know why your BT stack suddenly stop reporting to the BT Lib, and the BT Lib then reports to the plugin that the Hardware is not available.

It looks like the BT Stack or BT dongle is stuck trying to discover the BT services on the BT device, and then goes south.

The real problem is the DiscoverService function of the Widcomm BT stack has been coded to be called once or twice manualy from the Bluetooth Neighborhood GUI ... and unfortunately not thoroughly tested... when it's called several hundred times by the plugin... bad things can happen.

It works fine with some rare BT stack version / BT dongle hardware, but it looks like there are many problem with most Widcomm BT stack.

You could try to check the Belkin site for an updated BT stack...

[sckoman]

Closeout of thread

Stipus -
Thanks much for the clarification. I did some more testing with this Belkin F8T012 and a number of things to permutate on. I also ended up trying a D-Link DBT-120 ... it did not work well either. The DBT-120 was reported to work on one of the posts, but I found that it did not. I tried a couple of Widcomm stack versions with these two devices and that did not matter much.

I think you are right about the discover service and the stack interaction. I found some phones to be more problematic than others when doing 'discover service'. A Motorola Razr was bugging out the BT Connector repeatedly. A Motorola Q, a Pantech 820, and some HTC devices and others were perfectly fine. The Razr is the wifes phone, so ditching it was not an option.

I did find a new device (micro-dongle) that so far seems to work really well. I will put that in another thread. That device is Rocketfish Micro Bluetooth 21 EDR USB Adapter. Rocketfish is a private label of BestBuy stores ... I do not know who the OEM is yet. But his boy rocks.

At any rate to close this out thread, I will post here what else I tried that seemed to help.
Some of this may be helpful to others at some point:

- The HS 'Status' page does not update realtime. So I watch the log scroll out the
events in the main HS window instead.
- Turn OFF discovery at the bt stack for the dongle using the Widcomm utility. Also,
turn off any and all services offered by the dongle except 1 or 2; this seemed to help.
- Stagger the poll times for each device, eg Device 0 123 sec device 1 141 sec etc.
This seems to help a real lot.
- Unplug the BT dongle wait 2 min for PnP, then wait 30 sec replug and wait for PnP
sense. This seemed to work often and was easier than rebooting.
- In my virtual devices, I needed 3 states of HOME and one AWAY to correspond to
the 4 quantized signal levels (1 being 'device gone')