• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 782 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2650: Different responses to BLE Scan, from same peripheral device?

John Whitmore
Intellectual 270 points
Part Number: CC2650

I have a CC2650 which I'm scanning from two identical Ubuntu 16.04 base devices, both with identical system software, including Bluez 5.37. All this is on a bench so distance between the BLE master and the CC2650 peripheral is less then a meter, in both cases. I'm using the bluepy library at the moment to talk to the periperal device, which is not perfect but it is working in most cases.

The problem I'm encountering is that when one device scans for peripherals the CC2650 response with MAC address and description string. Whilst when the other device scans the CC2650 only responds with its MAC address. The only difference I can see in the logged messages is the response. I'll have to get 'btmon' running to get a better idea of what is happening, but apart from RSS I can't see what the issue is:

[bluepy.btle:37] Got: 'rsp=$scan\x1eaddr=b546C0E530068\x1etype=h1\x1erssi=h43\x1eflag=h0\x1ed=b020105030280AA06FF0D0003000011094343323635302053656E736F72546167051208002003020A00\n'

[bluepy.btle:37] Got: 'rsp=$scan\x1eaddr=b546C0E530068\x1etype=h1\x1erssi=h28\x1eflag=h0\x1ed=b020105030280AA06FF0D00030000\n'

Perhaps this is actually a feature of the BLE Stack that it has a truncated response if RSS is lower. Any ideas or hints as to the issue would be very greatfully received.

  • 0
    TI__Guru 57865 points
    Hi John,
    Could it be that the first string is the advertisement data whilst the second row is the scan response data? I am not familiar with BlueZ and the syntax of the messages you provide but it might explain your situation. mac/iOS devices has a similar situation where the scanned device name can vary depending on if it's parsed through advertising data or scanning data (when applicable). Does this make sense?
  • 0 in reply to J Lindh
    Intellectual 270 points
    Sorry I should have explained those lines of output a bit better. I stripped those two lines out of the logging from the two different scans. From one device scan the CC2650 returns the single full response but for the other device scanning the single truncated message, is sent in response. Nothing is different the two Ubuntu 16.04 are identical hardware platforms running identical system SW.

    I have run a scan from a Ubuntu 16.04 laptop and in that case I have got two response messages from the CC2650, the first truncated but the second, immediately after, containing the description.

    So there we have three different responses from the same CC2650:

    - a single truncated message in response to a scan
    - a single extended message, containing description field, in response to a scan
    - two messages the first truncated, but immediately followed by an extended response, to the scan.

    Three Ubuntu 16.04 devices running Bluez16.04 all receive different responses from the same CC2650.

    Currently my code is using the description field to connect to CC2650 devices but since the response to a scan does no contain a description the devices are never connected.
  • 0 in reply to John Whitmore
    TI__Guru 57865 points
    Hi John,
    I see. Again, I have no experience with BlueZ and it seems like that's the side where things become weird. Would you be able to sniff the communication to compare air logs? www.ti.com/.../PACKET-SNIFFER
  • 0 in reply to J Lindh
    TI__Guru 57865 points

    Hey,

    I used a hex to ASCII translator and it seems like your first response contains the ASCII  for "CC2650 SensorT" (0x4343323635302053656E736F7254). Is that part of the advertising data or scan response in your project?

  • 0 in reply to J Lindh
    Prodigy 180 points

    That's the point. One response to a scan from a device contains that description string in Ascii, whilst a different device initiating a scan results in the second response which is different in that it's missing the description.

  • 0 in reply to John Whitmore2
    Prodigy 180 points

    I found what might be the source of the problem. I'd assumed that the two master devices I'm scanning from are the same but they have two different BT Chipsets installed. One is using an Intel chip, which works but the other is using a Realtek BT Chip which appears to maybe filter the responses from the CC2650. 

    I wonder it this a know issue?

  • 0 in reply to John Whitmore2
    TI__Guru 57865 points

    Hi John,

    From an interoperability standpoint, they should both obviously be able to operate in the same manner. Especially something fundamental as receiving advertisement packets. Have you tried modifying the advertisement data or maybe change the type?