DeviceDiscoveryRequest parameter

Hi,

1) I do not know, but perhaps the sniffer scans in the 3 channels but only provides you the info from a single one when ticking that in the GUI.

2) Yes, as long as I know.

1) I don't think he is listening on 3 channels, because he doesn't miss any advertising packet. I can see, that he gets all the packets. Even when I send an advertising-packet every 5ms.

I'm sorry I do not understand the question.

Too many work hours, I'm afraid :)

Bye.

1)Is ist possible to set some parameters on the workspace "Host Test Release---CC2540USB Master" to scan just on one of the three advertising channels?

3)Is there a possibility to connect the USB-Dongle in the sniffing mode with a Java-application?

Hi,

HD-BLE said:

1)Is ist possible to set some parameters on the workspace "Host Test Release---CC2540USB Master" to scan just on one of the three advertising channels?

Unfortunately no (Bluetooth Core Specification)

BR

Hi Nick

First thanks for your answer, I was looking for such a parameter, but I didn't find any.

So I got no possibilities to set the scanner on just one channel?

a)Your "SmartRF Packet Sniffer" is able to scan one channel continously... So it is possible somehow?

My big goal is to get all the advertising packets. Currently I'm trying to set the scanWindow and the scanInterval... There are a lot of this parameters:

OPCODE: 0xFE30
ParamID:12...19
Discribed a bit in Verdor_Specific_HCI_Guide

b)Is there an exact documation of all these parameters?

I can set them with the BTool in an interesting setup:

The scanner is scanning for the whole 10s on channel 37, if there is an advertiser. It there is no advertiser he goes to 38 and looks there. If there is an advertiser he stays on this channel.
c)By the way is there a possibility to scan continously without a timeout?

I'm verifying this with active scanning with the dongle and BTool and sniffing on different channels.

BR

Hi,

HD-BLE said:

a)Your "SmartRF Packet Sniffer" is able to scan one channel continously... So it is possible somehow?

I am pretty sure that the Packet Sniffer scans all three channels but only utilizes the response on one of them. I don't know if this "filtering" is made in the CC2540 Dongle firmware or in the application on the PC though.

HD-BLE said:

OPCODE: 0xFE30
ParamID:12...19
Discribed a bit in Verdor_Specific_HCI_Guide

b)Is there an exact documation of all these parameters?

the OPCODE: 0xFE30 is the GAP_SetParam which is used (as the name says) to set a parameter in the GAP. In the documentation "TI_BLE_Vendor_Specific_HCI_Guide.pdf" you will find the list of the parameters (Scan Window, Scan interval..) you can set. For further details I would refer to the Bluetooth Core Spec.

HD-BLE said:

c)By the way is there a possibility to scan continously without a timeout?

From the Core Spec: The scanWindow and scanInterval parameters shall be less than or equal to 10.24 s. The scanWindow shall be less than or equal to the scanInterval. If the scanWindow and the scanInterval parameters are set to the same value by the Host, the Link Layer should scan continuously. So yes you can scan continuously. 

BR

Hi

Nick L said:

From the Core Spec: The scanWindow and scanInterval parameters shall be less than or equal to 10.24 s. The scanWindow shall be less than or equal to the scanInterval. If the scanWindow and the scanInterval parameters are set to the same value by the Host, the Link Layer should scan continuously. So yes you can scan continuously. 

I read this also in the BLE-spec and in the "Host Test Release---CC2540USB Master"  (function: LL_SetScanParam). But I was not able to scan longer than this 10.24s... Which scanWindow and scanInterval do I have to set? There are four scanIntervals and four scan Windows in paramID 12...19. When I look in the Firmware there are not that many scanWindows and scanIntervals...

Nick L said:

the OPCODE: 0xFE30 is the GAP_SetParam which is used (as the name says) to set a parameter in the GAP. In the documentation "TI_BLE_Vendor_Specific_HCI_Guide.pdf" you will find the list of the parameters (Scan Window, Scan interval..) you can set. For further details I would refer to the Bluetooth Core Spec.

I was searching in the Bluetooth Core Spec for some hours, but there is very few about this scanWindows.

BR

Nick L said:

a)Your "SmartRF Packet Sniffer" is able to scan one channel continously... So it is possible somehow?

I am pretty sure that the Packet Sniffer scans all three channels but only utilizes the response on one of them. I don't know if this "filtering" is made in the CC2540 Dongle firmware or in the application on the PC though.

[/quote]

The packet sniffer uses special software different from the BLE stack. This software can not be used for normal BLE operation, only for packet sniffing.

 

HD-BLE said:

But I was not able to scan longer than this 10.24s...

When I set the paramID 2 (Minimum time to perform scanning, when performing General Discovery proc (mSec).) to 60'000 then the dongle scans for 60 seconds. This is no good with the spec, but great!

But I still don't understand the different scanWindows and scanIntervals in paramID 12...19.

HD-BLE said:

But I was not able to scan longer than this 10.24s...

This is the maximum for one scan procedure, the "continuous scan" means that the scanning is performed continuously during this procedure, instead of a percentage (ScanWindow < scanInterval). Sorry if I mislead you before.

HD-BLE said:

But I still don't understand the different scanWindows and scanIntervals in paramID 12...19

The different parameters are used for different GAP discovery modes (Limited/General) and Link Layer states (Initiating/Scanning). I think It is easier to understand these if you take a look at the simpleBLECentral project included in the BLEv1.1 and the TI_BLE_Software_Developer's_Guide.pdf. 

BR

Hi Nick

Nick L said:

This is the maximum for one scan procedure, the "continuous scan" means that the scanning is performed continuously during this procedure, instead of a percentage (ScanWindow < scanInterval).

Ok, now I got it. I was a bit confused by the formulation "continuous".

I'm still working with this scanWindows and the way the BLE-stack chooses its scan-channel. But I think now I know how it works:

• If the scanWindow and the scanInterval is set the same, then the dongle is scanning continuous until the end of the scanning (10.24s).
  But he can change the channel (see next points)
• He starts fist on channel 37
• If the dongle gets no advertising-packet in the scanWindow, then the dongle goes to the next channel. Else he stays on the channel.
  I think this is made by the LinkLayer?

I tested the following situations:

When I set the scanWindow and the scanInterval to 1s in the dongle and the advertising-time to 100ms in the advertiser (Advertising just on channel 37), the dongle stays on channel 37 during the whole time. He gets every advertising-packet.

When I set the scanWindow and the scanInterval to 1s in the dongle and the advertising-time to 100ms in the advertiser (Advertising just on channel 38), the dongle stays for 1 second on channel 37. After it goes to channel 38 and stays there during the whole time (10s-1s=9s). He gets every advertising-packet after the fist second.

Am I right with my speculations?

According to the BLE-Spec 4.4.3 Scanning Stat:

The Link Layer should listen for the complete scanWindow every scanInterval
as directed by the Host unless there is a scheduling conflict. In each scan window,
the Link Layer should scan on a different advertising channel index. The
Link Layer shall use all the advertising channel indices.

In my case, the LinkLayer doesn't change the channel. Is there a failure in the dongle-software?

I still belive I found a fault in the Link Layer. Is somebody able to proof this?

Did you ever get anywhere on this problem?

I am tryng to do the same thing you were trying to do which is get all the advertiement packets.

Hi John

I was talking to ti directly with about this problem. The answer was the following:

Thank you for contacting Texas Instruments. Your request has been received and Service Request number 1-693889658 has been assigned to your inquiry.

We have replicated the issue and found the root cause of the bug. Scanning of channels is not being properly handled at the link layer. We will work on a fix. Thank you for catching this.

 This bug will be fixed in next version.