Few questions before purchasing the hardware

[rafaribe]

First of all, thank you @sultanqasim for this amazing project, I've seen your Youtube presentation and was very impressed with Sniffle. I have a few questions:

1. Which one of the three TI Boards works more reliably with Sniffle? I'm leaning towards the TI CC1352R.
2. Would it make sense to get 3 sniffers to guarantee absolute BLE Coverage?
3. If the 2) is yes, how hard would it be to modify the python code for this purpose? Do you mean to support such an application in the future, or accept contributions?

Thanks again for this amazing project!

[sultanqasim]

1. For the purposes of running Sniffle, all three are are equally good. For general usefulness and flexibility, I suggest the CC1352R because it also supports sub-1 GHz communications if you want to use it for other things too. The antennas on the CC26x2R and CC2652RB boards are better tuned for 2.4 GHz communications than the longer antenna of the CC1352R board, but in my experience the CC1352R Launchpad's antenna works fine for Bluetooth.

2. You can get three if you absolutely need to capture every advertisement on every channel, but one of my design goals for Sniffle was to make it reasonably reliable in connection detection using only a single sniffer. For BLE 4.x style legacy connection establishment happening on channels 37/38/39, Sniffle can channel hop with advertisers when you specify a target MAC, and it can detect connection establishment with 70-90% reliability depending on the RF environment. This is unlike most low cost sniffers which only sit on a single advertising channel, and usually get connection detection reliability below 30%. For BLE 5.x style connection establishment happening on auxiliary channels, the 37/38/39 advertisements all point to the same aux packet, and Sniffle can detect this type of connection establishment on aux channels with near 100% reliability. For most use cases, I'd say having one sniffer will suffice.

3. I wrote the SniffleHW class to support interfacing with multiple sniffle hardware instances, but the sniffer scripts (like sniff_receiver.py) are only written to talk to one sniffer at a time. If you wanted to to run three sniffers to capture all advertisements on 37/38/39 simultaneously, you could modify these scripts to do that without too much effort, since the hardware interfacing code (SniffleHW class) should work with multiple sniffers. I haven't really documented the hardware API, and it changes a bit between firwmare versions as I add features, but the code is hopefully simple enough for others to understand.

[sultanqasim]

One other thing: right now, the PCAPs don't indicate packet direction, and also don't list some info like which PHY was used to transmit a packet. This is due to a limitation of the BLE RF PCAP link type spec. I'm trying to get the spec ammended, so I can report this info in the PCAP: https://code.wireshark.org/review/#/c/37142/

Hopefully this will be approved soon, so that you can get more useful an easier to understand PCAPs.

[rafaribe]

2. You can get three if you absolutely need to capture every advertisement on every channel, but one of my design goals for Sniffle was to make it reasonably reliable in connection detection using only a single sniffer. For BLE 4.x style legacy connection establishment happening on channels 37/38/39, Sniffle can channel hop with advertisers when you specify a target MAC, and it can detect connection establishment with 70-90% reliability depending on the RF environment. This is unlike most low-cost sniffers which only sit on a single advertising channel, and usually get connection detection reliability below 30%. For BLE 5.x style connection establishment happening on auxiliary channels, the 37/38/39 advertisements all point to the same aux packet, and Sniffle can detect this type of connection establishment on aux channels with near 100% reliability. For most use cases, I'd say having one sniffer will suffice.

I am considering sniffle due to the lower cost compared to enterprise-grade sniffers. I have to conform to the BLE 4.2 spec. One of the reasons for questioning the need for 3 devices is that I would like to capture 100% of BLE packets over the air in a controlled environment (so no office setting with multiple BLE devices advertising and causing RF interference), due to COVID, that's my home-office 😄.

3. I wrote the SniffleHW class to support interfacing with multiple sniffle hardware instances, but the sniffer scripts (like sniff_receiver.py) are only written to talk to one sniffer at a time. If you wanted to run three sniffers to capture all advertisements on 37/38/39 simultaneously, you could modify these scripts to do that without too much effort, since the hardware interfacing code (SniffleHW class) should work with multiple sniffers. I haven't really documented the hardware API, and it changes a bit between firmware versions as I add features, but the code is hopefully simple enough for others to understand.

I saw that you took the pcacp.py code from btlejack. I also own 3 micro:bit and started experimenting with bltejack since last week and I found the Nordic output option to work really well with Wireshark, not sure if this could be an option here, probably not because of the chip manufacturer. As you can probably guess I'm not originally an embedded developer so your advice is greatly appreciated. Thank you👍

[sultanqasim]

Btlejack supports multiple PCAP formats. I based my PCAP writer on one of the PCAP writers in BtleJack with some modifications. Nordic’s PCAP format does support indicating direction and other useful info, but it’s rather specific to the design of Nordic’s sniffer, which differs from mine. I could impersonate Nordic’s sniffer, though I’d rather have a more generic format that’s not specific to the design of Nordic’s sniffer.

If you absolutely need to capture everything transmitted over the air on the advertising channels, you may benefit from three sniffers. The main limitation of using one sniffer that hops is related to timing. The gap between advertising on channel 37 and 38 is usually quite short, and so while Sniffle will capture scan requests/responses on 38 while in adv. hop mode, it will not capture the initial advertising packet sent on 38 (or 39 unless you change the timing params). In general, the exact same advertisement will be sent on all three advertising channels. Unless you’re developing your own Bluetooth controller firmware, you usually don’t need to sniff all three simultaneously, as long as you can hop to capture scan and connect packets on all three channels for your target, the way Sniffle does. For data channels during a connection, there is little benefit to using multiple sniffers, as a single Sniffle will capture all the data packets for a connection.