Other Parts Discussed in Thread: CC2400, , WL1837
Hi, we are using the WL1837MOD in our Linux Armv7 based thermostat to scan for wireless BLE temperature sensors, which send a set of three advertisements (not connection oriented) every 15 seconds. The thermostat scans indefinitely with the maximum scan interval set via HCI and is connected to a wired power source, so the CPU never sleeps and the WL1837MOD never stops scanning. During testing, we have seen random periods of 5-10 minutes where other Bluetooth LE advertisements are seen by the WL1837MOD, but not our sensors. What makes this even more confusing, is the fact that in the same environment other Bluetooth hardware, including sniffers, do see the missing advertisement packets during the same period. This data, which was recompiled with hcidump, btmon, and a dedicated sniffer (based on the TI CC2400) indicates that either there is a hardware issue or more likely a firmware issue which filters the LE Advertisement events and never sends them via HCI to Linux.
We've tried long-running scans, and restarting the scan every 2 minutes. Sometimes we have sites that go days without consistent packet loss, other sites have multiple 5-minute gaps per day. We have one environment at a engineer's house that consistently reproduces the problem multiple times a day. As far as signal strength, there appears to be no correlation to performance. The second graph with just one color is the average signal strength for the three sensors. Notice that the period of no data on the right is roughly indistinguishable from the center where's there's strong packet counts. Indeed, even on the left where the signal strength is relatively poor, we have good packet counts. We've also attempted to eliminate wifi co-existance as a contributing factor by disabling the wifi radio entirely and relying on ethernet for one test. This unit has the same patterns as devices with wifi active.
We're not using sleep mode of any kind on the processor, and we can see evidence of other BTLE packets being recieved during this time, but at much, much lower levels. I've attached that graph below as well. (It's using logarithmic scale, because the packet counts are substantially higher; you would be be able to see our sensors without it.) Notice that the average packet count for the entire population of btle traffic is depressed during the period in question. However, it's worth noting that we're still receiving on the order of one thousand packets a second during this period. At this point, I don't see any explanation other than that they're going missing in the WL1937MOD itself.
