cannot talk to dongle after connect

[JimmyD]

I connect to the nRF52840-MDK dongle thru the Serial Terminal (nRF52 Connectivity) it found the comm port and set the baudrate automatically. However, the terminal window constantly fills up the screen with ~/ characters. it repeats every 1 second. What I would like is detailed instructions on how to configure this dongle to be a BT 5 sniffer and read the Extended Advertising for any BT device near the dongle. It would also be helpful to filter the devices seen. Eventually I like to use Python to filter the choices and obtain the advertises data where I can parse the data received. I'm using Windows 10 pro.

Thanks.

[ovrebekk]

Hi James

The nRF Sniffer is documented here. In particular you can refer to the chapter caller nRF Sniffer Usage.

The dongle needs to be programmed with the hex file included in the sniffer download, most likely it has the wrong firmware. This will be described in the documentation I linked to above. 

The sniffer does provide a Python interface, and you can find it documented in the Sniffer API Guide document included in the doc folder of the sniffer download. 

Best regards
Torbjørn

[JimmyD]

Torbjørn,

            The instruction for installation is very hard to follow and leads to a dead end.

First your link takes me to nRF Sniffer usage. The index on the side “Installing the nRF Sniffer starts off as if it is already installed. Very confusing!!

Another is the SnifferAPI.

I cannot find it anywhere.

Since I took too long to try and get this working, I have other priorities, But will circle back to try and get this to work.

Due to my time allocation for this project is short.

Please give me some dummy proof steps to get this working.

 

 

I see a bunch of python code under the nrf_sniffer_for_bluetooth_le_4.1.1 directory I downloaded, but I don’t know which one I need for my application.

 

Greatly appreciate it.

 

James DeLorenzo

[ovrebekk]

Hi Jim

Most likely the packet containing the name and the packet containing the manufacturer data is not the same. The first packet containing the name is sent on the primary advertising channels, and this will point to a larger packet sent on one of the secondary advertising channels. The mobile app compiles all the data into one view. 

Are you able to filter on the MAC address in the Python script? Then should see all the packets from the same advertiser, and verify whether or not you can see both the packets on the primary advertising channels, and the ones on the secondary advertising channel. 

Best regards
Torbjørn

[JimmyD]

Since I'm new to Bluetooth, I'll have to research this. I knew that there were channels but I haven't understood fully what they were used for or how to get that information.

Yes,  I can specifically state what MAC address to look for.

[ovrebekk]

Hi 

We provide various online courses as part of the Nordic Developer Academy, and we recently released a specific module for Bluetooth which you might want to check out:
https://www.nordicsemi.com/Support/Nordic-Developer-Academy

The short story is that Bluetooth LE uses 40 dedicated RF channels, 3 of which are designated as primary advertising channels. 

These three channels will be used for advertising only, and legacy (non extended) advertising are limited to these channels exclusively. 

The remaining 37 channels were originally only used for devices in a connection, until the extended advertising feature was introduced in v5 of the Bluetooth specification. 

An extended advertiser will essentially send a small packet on one of the primary advertising channels which contains little data, but points to a larger packet on one of the remaining 37 channels containing the payload. This means that you can advertise a large amount of data without congesting the 3 primary advertising channels, which have to be shared between all Bluetooth LE devices. 

One drawback of this mechanism (that you have to get around now) is that you need to be able to receive both the small packet sent first on one of the primary advertising channels, and the second packet sent on one of the remaining 37 channels, in order to get all the information from the advertiser. 

Best regards
Torbjørn

[JimmyD]

Thanks for that information, it was very useful. I'm hoping that I'll have some time soon to view the course.

Your response leads me to my next question; Is there a way I can get the information I'm looking for using your dongle? and if so how can I modify the python code to do that?

I guess what I'm asking is how to get the information on the remaining 37 channels using your dongle and the python code?

I think the answer may be in the Sniffer.py file. I just can't pin point where.

[JimmyD]

Torbjørn,

I need to know how to do this in Python. Can you help?

(I need to be able to receive both the small packet sent first on one of the primary advertising channels, and the second packet sent on one of the remaining 37 channels, in order to get all the information from the)

Thanks.

Jimmy D.

[ovrebekk]

Hi Jim

Where you unable to filter out both types of packets in your script, either by filtering on RSSI or the MAC address? 

Again, to figure out how the packets are defined and how the first packet leads to the second you can use the Wireshark interface for reference:

As usual I am testing using the periodic_adv sample for reference. 

I can see that three packets are sent on the primary advertising channels, and if I open the Advertiser Aux Pointer under the Extended Advertising Header I can see the information pointing to further data on the secondary advertising channels. 

In this particular case I can see that there is a packet coming on channel index 22, and the time offset from the current packet is 1110 us. By setting the time reference to the current packet I can see that approximately 1110 us later a packet is received on channel 22, containing the actual advertising data:

The Advertiser Sync Info field in the extended advertising packet contains information about the rest of the packets in the periodic advertising stream, meaning it is not strictly necessary to receive all the packets on the primary advertising channels, a scanner could decide to simply listen for the packets on the secondary channels instead (as long as you manage to stay synchronized with the stream). 

When using the sniffer you don't need to manually handle the forwarding from the primary channel packets to the secondary channel packets, the sniffer will try to report all of them. It is more about defining the filters properly to only process the packets that you care about, that you know are sent by the right advertiser. 

What kind of results do you get when trying to filter on MAC address and/or RSSI? 

Are you not able to see the same data that the smart phone reports?

Best regards
Torbjørn

[JimmyD]

My Wireshark setup is different. Unfortunately I don't have time to spend on this issue now, but will need it for phase 2. I still can't seem to get the extended information I need. when I get a chance to get back to this project, I'll take a screen shot so  you see.

[ovrebekk]

Hi Jim

No problem, once you have had time to look into it just let me know. 

Best regards
Torbjørn