First I have heard of this issue with the Photons. What exactly needs to be changed to get everything working without further issues?
@RWB, I have split off your last post out of the original thread as it wasn’t addressing the OPs question.
I think it’s best if you ask @mterrill in this thread dedicated to the actual issue in question.
…Interesting, I work on and test our project primarily in 2 locations.
At our main office where it connects to either a Draytek configured to a/b/g/n (which I’m going to assume means mixed 20/40Mhz) but primarily to an Asus RT-N56U in simultaneous 2.4/5G mode, the 2.4Ghz is set to 20Mhz only. Both of these seem to work OK, although I did encounter an issue moving between the two I mentioned a while back where the unit got completely stuck on attempting to connect and didn’t time-out.
However at home I am connected to a notoriously &^*|& VDSL router supplied by Vodafone, its locked down tighter than a squirrels nuts and in that instance I have no idea how its 2.4Ghz is configured, Photons really don’t like talking to that one, they drop out or refuse to connect for no apparent reason. If this is an issue, maybe that’s why…
Hi RWB, customers have to login to their wifi router and enforce 20Mhz bandwidth.
Two ways this happens:
- A proper ‘bandwidth’ setting in the wifi router. Called a few things but I suggest to customers to look for a bandwidth setting that typically has options such as ‘20Mhz’, ‘40Mhz’ and ‘auto’. The last is effectively 40Mhz with fallback to spec, more on that soon.
- A speed setting. Some brands use 150mbps / 300 / 450 to infer what bandwidth is being chosen. 150Mbps is the safe 1 20mhz bandwidth setting.
The underlying issue is 40Mhz bandwidth is actually 2 adjoining full width wireless channels (ie 1 & 6) being used together to logically double throughput. Google yielded this article with some nice analysis shots if you’re more curious. https://www.smallnetbuilder.com/wireless/wireless-features/31743-bye-bye-40-mhz-mode-in-24-ghz-part-1
The issue with that is the poor ol’ Particle doesn’t understand 40mhz so once the conversation drifts out of the correct channel the Particle is effectively dropped out and starts its reconnection again and sometimes this doesn’t work because the AP is still happily talking throughout the wider 2 channels. One thing I did pickup from the above particular article is its reference to how clients could potentially have a " ‘fat channel’ intolerant bit set". I’m guessing the Particle fails to do this because it’s a very old wifi stack or incomplete, or as this (https://prettyflyforwifi.net/2017/03/17/40-mhz-intolerant-a-wastefully-good-feature/) article suggests, the soho style wifi routers simply ignore it
Try explaining that to someone who normally gets their kids ‘to configure the tv & internet’, and try explaining “that’s just the way things are” to people who actually know what they’re talking about and wondering why your product is using 1990’s wifi. You either end up with 1-3 hours consumed in supporting a single customer setting up a remote support session as they inevitably need to workout how to install teamviewer and get their actual wifi router password.
This issue is just getting worse as most of my customers are Australian or NZ. We’ve had a national broadband project called NBN running for the past 6 years or so, and while its a travesty akin to building a mexican wall (you literally get 100x better internet from a rice paddy farm in vietnam than here, pretty much only Brazil is worse), the main outcome is folk have received new fancy wifi routers. They generally default to 40mhz bandwidth because thats how you make Facebook and the playstation go faster
By the way, its kind of lucky I spent 10 years in network engineering. Average punter on these forums is unlikely to figure out the reason why their Particle is randomly dropping offline and reconnecting.
@Viscacha, if you have a Mac, its really easy to know. Open up ‘wireless diagnostics’, don’t bother clicking through the ‘introduction’ pop up that appears when it first loads, go straight to the top menu and choose ‘Window’ and then Scan . (or press option + cmd + 4).
Scroll sideways in the scan results to the ‘width’ column. That’s the magic. Note how my b/g/n networks are set (manually) to 20Mhz?
Hah! that screenshot highlighted that my router by default would allow insecure WPA as well. Fixed.
A screenshot of a typical modern wifi router (TPLink Archer C9 in this case)
(yes I fixed the WPA/WPA2 security to WPA2 only after taking the screenshot, another example of modern router defaults opting for ‘fast, just works’)
Thanks for the reply! I’m glad I asked.
I’m mainly running my Androids unlimited Wifi Hotspot for most of my testing and have not encountered this issue so far.
Considering I have designs that I want to push out that use the P0 or P1 I would certainly come across this issue eventually and like you said I would have no idea what was going on initially.
Do you have any idea if the ESP32 wifi modules have this same behavior?
Well, strap yourself in for hours of customer support if you go with P0 or P1 (which we use).
ESP32 has 40mhz. I’m not sure about you, but theres been zero communication on when scale friendly versions will become available (ie I’m not redesigning the entire board to fit the dev board and paying the premium).
the only thing really keeping me on particle platform is:
- the few days it’d take to add webhook style logic to a mqtt server to catch interesting post events and then send them on. Seen as my use cases are nearly all firebase related and Google IoT works nicely, I’m not even sure these days if thats much of a concern either.
- building a factory process for burning device UIDs
- confirmation that OTA updates and fallback would work well on my own esp32 implementation.
- other dragons. I know esp32 adc simply doesn’t work, that’s ok, external i2c adc and thats solved. I’ve been following the espressif forums since the beginning and asked Zach over a year ago when they’d finally make the jump, and i’m sure they’ve bumped into a few other dragons aside from ADC being less than 8 bit useful after having to calibrate each port (!).
i’d personally quite like running my own webhook system, if it was still opensource I’d do that next week.
@mterrill so if you weren’t using the particle platform with the new featherwing footprint, what would you switch to for your product? I’m just curious, I don’t have plans for switching platforms.
I’ve spent a lot of time investigating this as the official word is “Production hardware for the new line is still in concept and won’t be available until late in the year at best.”
Also the pricing of such hardware was "Pricing has yet to be defined on the argon at scale, but it will reflect the value created for mesh deployments as opposed to being a module optimized for wifi based deployments. "
So, combine these two statements and the other commentary about the mesh series being for industrial and corporate use (when asked about ANT connectivity), its clear there must be some corporate end customer this series is being designed for. I feel the traditional Particle base is being ignored, perhaps thats for survival, but either way it seems we’ve outgrown each other.
Rolling your own isn’t too hard, so I’ve been getting pricing on:
- MQTT integration via Google IoT, I already have an automatic software update process
- OTA software updates
- BT central transparent UART (ie mobile phone sending commands to this device)
- Factory flashing (ie unique burned in serial) and chip testing
PS with the ESP32 you’d need external ADC(s) as even after 18 months no one can get the esp32 adc to read at more than 8 bit accuracy without individual port calibration(!).