Open XenoKovah opened 6 months ago
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.
files are in the attached example_capture.tar.gz, thanks
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?