You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I told it to filter down to only the BDADDR 13:37:be:ef:00:01 of the advertiser, just so I could see its approximate advertisement frequency (even though I'm only listening on 1 channel, not all 3). So what is shown in Sniffle should be a subset of the other potential packets that occurred on channel 38 during the same time period. Dumping the pcap from Sniffle, we can see it captured a lot more packets over the same basic timeframe:
tshark -r sniffleCH38.pcap
1 0.000000 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
2 0.102657 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
3 0.204705 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
4 0.313130 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
5 0.418778 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
6 0.520613 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
7 0.627543 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
8 0.735420 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
9 0.842593 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
10 0.947235 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
11 1.048949 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
12 1.153651 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
13 1.256522 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
14 1.361315 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
15 1.468398 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
16 1.571697 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
17 1.678842 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
18 1.781896 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
19 1.888094 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
20 1.992278 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
21 2.094020 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
22 2.195733 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
23 2.300375 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
24 2.405046 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
25 2.513868 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
26 2.615305 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
27 2.716012 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
28 2.822606 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
29 2.928223 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
30 3.031615 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
31 3.137903 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
32 3.240623 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
33 3.347339 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
34 3.448990 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
35 3.552258 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
36 3.654001 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
37 3.761817 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
38 3.868412 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
39 3.971771 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
40 4.076931 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
41 4.182976 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
42 4.288716 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
43 4.388721 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
44 4.493057 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
45 4.596813 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
46 4.702675 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
47 4.806981 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
48 5.014159 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
49 5.118618 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
50 5.219872 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
51 5.325001 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
52 5.430804 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
53 5.533705 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
54 5.642040 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
55 5.751807 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
56 5.858433 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
57 5.960510 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
58 6.070218 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
59 6.175622 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
60 6.280111 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
61 6.385790 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
62 6.495741 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
63 6.597088 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
64 6.806096 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
65 6.906312 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
66 7.015623 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
67 7.123379 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
68 7.228630 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
69 7.333119 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
70 7.436905 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
71 7.542127 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
72 7.652048 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
73 7.760901 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
74 7.868472 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
75 7.974854 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
76 8.081966 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
77 8.187341 13:37:be:ef:00:01 → Broadcast LE LL 36 ADV_IND
Are there any things about the design of ice9-sniffer software or bladeRF hardware that would lead to this apparent rate limit of seeing packets only once per 1.5 when the actual rate is more like .1s?
The text was updated successfully, but these errors were encountered:
There aren't any fundamental design limits that should be causing this. It's likely a case of my packet detection algorithms just not being very good. I have a few ideas for how to improve them and now seems like a good time to investigate that.
Do you still have base_name set to something? If so, clear out all the fc32/f32/txt files it's generated, and capture 1-2 seconds of your advertiser. Send me the generated fc32/f32/txt files and I can investigate in which part of the RX chain they're getting lost.
I set up capture for just channel 38 with ice9-sniffer as follows (from ticket #24):
./ice9-bluetooth -l -c 2427 -C 8 -sv -i bladerf0 -w ice9CH38.pcap
And then I let it run for ~10 seconds, because I know it is in direct physical proximity to a custom advertiser.
When I dump a summary of the pcap with tshark, I see very few packets, despite the fact that I know the advertiser is sending a lot of ADV_INDs:
I set up Sniffle to sniff only channel 38 with a Sonoff TI1352 dongle as follows:
sudo python3 sniff_receiver.py -s /dev/ttyUSB0 -m 13:37:be:ef:00:01 -c 38 -o sniffleCH38.pca
I told it to filter down to only the BDADDR 13:37:be:ef:00:01 of the advertiser, just so I could see its approximate advertisement frequency (even though I'm only listening on 1 channel, not all 3). So what is shown in Sniffle should be a subset of the other potential packets that occurred on channel 38 during the same time period. Dumping the pcap from Sniffle, we can see it captured a lot more packets over the same basic timeframe:
Are there any things about the design of ice9-sniffer software or bladeRF hardware that would lead to this apparent rate limit of seeing packets only once per 1.5 when the actual rate is more like .1s?
The text was updated successfully, but these errors were encountered: