CurieBLE: no access to scan response data when scanning

[sandeepmistry]

I think this one is already in JIRA, however I'm opening this for other preview testers to track the progress.

When using the scan example with the my TI SensorTag I'm not able to see the local name it advertises. However, using LightBlue on iOS I can see "CC2650 SensorTag" as the local name.

[kitsunami]

Addressed by #402

[sandeepmistry]

I've tested this with the 2.0.1 RC 1 things are a bit better. However, the results are a bit strange if I call BLE.scan() with the change from PR #476.

BLE Central scan
Discovered a peripheral
-----------------------
Address: 69:0D:D0:1D:01:B8
RSSI: -57

Discovered a peripheral
-----------------------
Address: 30:8C:FB:D7:6C:A1
Service UUID's: d2d3f8ef-9c99-4d9c-a2b3-91c85d44326c 
RSSI: -92

Discovered a peripheral
-----------------------
Address: 17:16:01:7B:A4:FB
RSSI: -79

Discovered a peripheral
-----------------------
Address: C8:69:CD:41:84:A2
Local Name: Dropcam
RSSI: -71

Discovered a peripheral
-----------------------
Address: 68:C9:0B:06:BC:81
Local Name: Dropcam
Service UUID's: aa80 
RSSI: -61

Discovered a peripheral
-----------------------
Address: 32:05:CE:B1:95:A2
Local Name: CC2650 SensorTag
RSSI: -46

Discovered a peripheral
-----------------------
Address: CA:F9:64:CC:73:4A
Local Name: CC2650 SensorTag
RSSI: -100

Discovered a peripheral
-----------------------
Address: AC:BC:32:7C:FA:26
RSSI: -49

I expect to see the following for my TI SensorTag:

Discovered a peripheral
-----------------------
Address: 68:C9:0B:06:BC:81
Local Name: CC2650 SensorTag 
Service UUID's: aa80
RSSI: -61

However, the fields for my Dropcam and SensorTag are mixed up. I also only have one Dropcam but the local name is seen multiple time.

[sgbihu]

Hi @sandeepmistry ,

I have test the scan sketch with latest code. The test result like this:

Discovered a peripheral

-----------------------

Address: 24:71:89:08:AB:03

Service UUID's: aa80

RSSI: -62



Discovered a peripheral

-----------------------

Address: 24:71:89:08:AB:03

Local Name: CC2650 SensorTag

Service UUID's: aa80

RSSI: -62

Their has 2 type ADVs. The first type is because the scan response not coming and the local name are in the scan response. If the buffer doesn't override, the followed available will return full of ADV data.

Can you capture the ADV data about the device that MAC address is C8:69:CD:41:84:A2? I'm also interest about the problem you faced. From the output, I think the serial is stable, it shouldn't be include d in another device. I need check the ADV first.

Thanks!

[SidLeung]

@sgbihu @russmcinnis @noelpaz, please perform the scan test with multiple boards with long LocalName so that Scan Response Data will be used. Please check the correct MAC address to the LocalName detected. Please use unique LocalName for each board. Please use Ellisys to capture the traffic too.

[russmcinnis]

I can reproduce this issue. This seems similar to the issue where scanForName() is returning the name of the previous device scanned. So I am seeing these errors. Sometimes the local name is not returned which causes some of the errors in my test. I will hook up Ellisys when I get it.
84:68:3E:03:5C:94 BLELONG84683E034C3C Error local name: BLELONG84683E034C3C not correct for 84:68:3E:03:5C:94
84:68:3E:03:5C:94 BLELONG84683E035C94 PASS
84:68:3E:03:4C:3C Error local name: not correct for 84:68:3E:03:4C:3C
84:68:3E:03:4C:3C BLELONG84683E034C3C PASS
B0:B4:48:C8:5F:03 CC2650 SensorTag PASS
84:68:3E:03:5C:94 BLELONG84683E035C94 PASS
B0:B4:48:C8:5F:03 CC2650 SensorTag PASS
84:68:3E:03:5C:94 Error local name: not correct for 84:68:3E:03:5C:94
84:68:3E:03:5C:94 BLELONG84683E035C94 PASS
B0:B4:48:C8:5F:03 BLELONG84683E035C94 Error local name: BLELONG84683E035C94 not correct for B0:B4:48:C8:5F:03

[SidLeung]

Tracked by Jira 893.

[sandeepmistry]

This looks better now with the 2.0.2 RC JSON @SidLeung provided me.

However, as I mentioned in #385 and #368, when BLE.scan() is called, I'm not getting the scan response data. I will leave this issue open until this is resolved. (I believe we discussed post-Deneb?)

[sandeepmistry]

This is working for me now with the 2.0.1-rc2.1 JSON @yashaswini-hanji provided us. Closing.

There's still an edge case where a peripheral would be be reported, see #500 (comment). However, @SidLeung has opened #508 to track this. It's also not a very common edge case from my experience with BLE.