Hiya. Yeah not sure where the problem lies. Logically it sounds like the CC3000 can’t cope with the BTLE scanning then subsequent conversation that goes on between the Pi and the beacon (be it a phone or a tag, whatever). However the module in the Photon seems better able to coexist with the scanning?
I’m not sure if the issues I’ve been having with my Ubiquiti + Photon setup are related, but I found a solution to mine. By Block LAN to WLAN Mutlicast and Broadcast data. No clue if related, but thought id drop this here.
1 Like
@netpex have a look at @mterrill’s posts here: 40MHz vs. 20MHz WiFi bands - possible issue
What bandwidth have you got selected?
Yep. You need 20mhz bandwidth to stop the p1/p0/photon from being dropped quietly from the network as the router will happily be conversing across the full 40mhz bandwidth channel while the little ol’ particle can only hear the conversation in the 20mhz band.
it’s been my #1 customer support issue with this platform. I’ve lost count of the number of customer support issues, but generally 2/3’rds of our customer base have had the issue.
1 Like
by the way, customer facing companies like LIFX have the issue but they haven’t diagnosed the issue. a common forum suggestion is for folk to light up an old BGN router and use that for their lights etc. That quietly provides the solution as the older BGN routers use 20mhz.
2 Likes
@mterrill, would be great to be able to solve from the Particle end, but from the sound of it, it is all in the Access Point (?)
Well, the new generation 3 have 40mhz bandwidth so it’ll be solved for those devices.
Particle can’t do much about it, the hardware is what the hardware is. They’ve never highlighted in the documentation how to identify devices going quietly offline (they’ll be cyan but actually not sending data, eventually will disconnect and reconnect).
The solution is to set the 2.4ghz radio to use 20mhz bandwidth. Or less than 210mbps network speed if using a Netgear. I’ve had to explain this thousands of times.
Interestingly, a lot of devices with this issue fly under the radar. It doesn’t matter if your soil moisture sensor spends 15% of the time in limbo land. It does matter when you’re cooking a brisket and waiting for it to get close to target and looking at it every 30 seconds, or like LIFX customers (they have their own hardware stack) trying to turn on/off a light.
Good news re Gen 3 devices at least!
Just waiting on @netpex now to confirm, or not, whether this fixes the issue in this ticket…
also, ubiquity routers need recent firmware. one firmware about a year ago played havoc with 2.4ghz clients.
So the Argon just automatically switches between 2.4GHz / 20 & 40 MHz bandwidth modes?
Yes. Argon uses the ESP32 for wifi. it’s HT40. So it’d start off using 40, but would downswitch to 20 if that’s what the wifi network uses.
I’ve explained in another thread, but effectively its a product of modern wifi routers not doing what’s in the wifi specification. They should be downgrading to 20mhz as soon as a 20mhz constrained device (like the P1) joins. 40mhz clients send a ‘fat bit’ from memory to flag they’re 40mhz, whereas 20mhz clients don’t.
3 Likes