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.

CC2540EMK-USB: Sniffer only displays advertising packets

Part Number: CC2540EMK-USB

I am trying to observe the packet stream between a low cost BLE POS receipt printer and a Bluetooth radio USB adapter on a PC.  This is a clean RF environment with no other 2.4GHz sources.  I am using two PCs for my testing.  PC A contains the radio and Teraterm software to send data to the printer.  PC B contains the CC2540EMK-USB and your sniffer software V2.18.1.  Both PCs are running Windows 7 64bit Pro.  The PCs are located about 2 M from each other the printer is located next to PC B.  The printer works fine and properly prints data strings entered via Teraterm. 

From an earlier post that reported this problem I have set the initiator address in the Radio Configuration tab to PC A radio MAC address to no avail.  I only receive advertising packets.  I created a filter file to limit the packets displayed but when it is active, no packets are displayed.  The file content is as follows.

[LM58]
AA4=0x001A7DDA7113
SA1=0x001A7DDA7113
AA5=0x001A7DDA7113
AA6=0x001A7DDA7113
IA2=0x001A7DDA7113
PTY=0x001A7DDA7113

I have also used the printer MAC address also to no avail.  What am I doing wrong?

Best regards,


Al

  • Hi Al,

    The format of the initiator address is 0xXXXXXXXX where XXXXXXXX is the BDA.

    Sometimes you have to try a couple of times before the sniffer is able to capture the connection.
  • Marie,


    Thank you for you prompt reply.  I am very new to Bluetooth so is "BDA"  the Bluetooth Device Address?  Please confirm or explain what it is.  Using other tools I have verified the BDA of the printer and it is the 48 bit value 0x0F0217519268.  Windows reports this as the printer's "Unique identifier" and it appears in the "AdvA" column of the discovery packets reported by the sniffer.  Windows also reports the printer function as "Standard Serial over Bluetooth link" and the service as "Serial port (SPP) 'SPP slave'" in case that helps.

    You say I might have to try a couple of times before the sniffer will capture the connection.  I have tried this at least 20 times and the only packets shown are discovery packets.  They are issued by the printer at approximately 170 ms intervals.  Even with the printer connected through Windows, it continues to issue advertising packets.

    Is the sniffer and its software to slow to capture the connection and data packets?  My PC uses an Intel i7 processor with 4 cores and 8 instruction streams and has 16 GB of RAM.

    Where do I go from here?

    Best regards,

    Al

  • Marie,

    More information.  I was incorrect regarding my statement about the printer continuously advertising.  Once the associated COM port is opened by Teraterm (or I would guess any application) the printer stops advertising.  However there are no new packets shown when the port is open.  Once the port is closed, advertising packets are again captured.  I have read both the SmartRF Packet Sniffer User's Manual and the Wiki User's Guide.  I believe I have set up all controls properly.  Setting the initiator address to the radio value (or turning it off) has no effect.

    What am I doing wrong?

    Best regards,

    Al

  • Hi Al,

    The BDA is the Bluetooth Device Address (which is also used as Advertiser Address AdvA).

    Just to be clear: You need one BLE device which is advertising (a BLE peripheral).
    You need a second device which is scanning and connecting (BLE central).
    Then you need a third device which is the sniffer device.

    You should give the BLE central BDA to the sniffer to follow the connection. You must also make sure that the BLE central is successfully connecting to the peripheral.
  • Marie,

    I have done a reset and am now using new tools.  In my previous attempts I was using a CSR 4.0 dongle to allow my PC to connect to the Bluetooth printer under test.  Unfortunately both the dongle and printer are dual mode devices which default to classic BT under Windows 7 since Windows 7 does not handle the BLE stack.  Now I have replaced the dongle with a u-blox EVK-NINA-B1 device that only communicates using BLE and maintains its own internal stacks.  The EVK is controlled from a PC program and is set up as a central device.  In addition I have added a BLE only keyboard and an BLE selectable barcode scanner as peripherals.  This has not solved my sniffer problem.

    The sniffer is configured to listen to channel 37 and to connect to the initiator address (BDA) of the central (EVK).  When I turn on the scanner, its advertising packets are reported.  When the central connects to the scanner advertising stops and no further packets are detected by the sniffer.  Just like my previous attempts but now with only BLE activated.  Some questions are as follows.

    1)  I would expect that enabling the initiator address would force the sniffer to listen report only the packets sent/received by that address but apparently that is not the case.  How are the advertising channel and initiator addresses interrelated?

    2)  If the initiator address overrides the advertising channel, how does the sniffer find the communication channel being used by the central?

    3)  A related question is when the central connects to the peripheral, how does the sniffer know what channel has been selected for the connection?

    4)  Is the initiator address entered high order byte first?


    Best regards,

    Al

  • Hi Al,

    1) The sniffer is just a radio. It's just listening on the channel for BLE packets. You have explicitly told it to follow connections initiated by that address, but if the connection is formed on a different channel or there is some noise prohibiting the sniffer from recording the connection request packet it won't be able to follow the connection.

    Initiator address is the address of the device that is initiating a connection. The initiator address is sent as part of the connection request packet. The connection request packet is sent as a reply to a connectible advertisement packet, immediately after the advertisement packet on the same channel.

    2) This question does not make any sense.

    You told the sniffer to listen on channel 37, so that is what it will do. If the sniffer sees the device with the initiator address you have specified form a connection, the sniffer will start following the connection in stead of listening on channel 37.

    3) This is specified in the connection request packet, along with the connection interval, clock accuracy etc.

    4) The address is given the same order as in hardware.

    You can set your peripheral device to only advertise on channel 37, this will increase the chances of the sniffer seeing the connection request packet.
  • Hi Al,

    Did you manage to sniff what you wanted?

    I will lock this thread due to inactivity.
  • Marie,

    I have not been able to see any packets other than advertising packets with the TI sniffer.  I do not have control of the advertising process in my project and cannot restrict it to a single advertising channel.  So I am abandoning use of the sniffer.  The next step would be the LeCroy Compro BLE Protocol Analyzer when I have $1K to spare.  It simultaneously monitors all three channels.

    Please lock this case.

    Thanks for your help.

    Al