@wizard - just adding to this thread. ive noticed a higher rate of failure in reaching the PB as of lately, either it fails to connect to the PB or gets stuck on the loading screen.
inspecting the network in my browser’s debug console shows that the browser is connecting and it starts receiving data, but then PB is closing the connection (maybe too aggressive timeout).
This seems particularly acute with my v3 picos that are enclosed in projects and likely because of materials interference and lack of antenna.
thankfully - it seems the browser does cache the data thats been downloaded and if i reload the page enough times, it will eventually complete. (at about 1.5MB of data)
it also has an impact on the interface usability … clicks seem to go missing, user actions get dropped etc.
i’m not that much of an expert on PB’s networking stack but mabye there are some settings you can adjust to give network operations a bit more time or maybe try packing or reducing the size of the interface that must load during the “Loading” screen.
I believe you should be able to reproduce this by setting up a v3 pico in an enclosure or a box where its signal is barely reachable and you can see how it leads to what I’m experiencing.
LMK if theres anything else I can do re: debugging.
@jeff - i’m running the latest version of v3, im pretty religious about clicking that “check for latest updates” button haha.
im also seeing a number of new posts complaining about difficulties w/ loading the interface. im thinking theres something that changed in a recent version?
Yeah, I think ongoing wifi/browser issues with v3 are (as per usual software development) a series of fixes and narrowing in the real problem, but I suspect the esp32 based system continues have odd bugs it’ll take some time to shake out completely. As similar as the esp8266 (v2) and esp32 (v3) architectures are, they aren’t identical and so the bugs in v3 are still showing up as more people use them in different use cases (and particular equipment, so routers/wifi systems, browsers, and so on)
It might be useful for make a walkthrough faq, @wizard, for people wanting to report issues, including both specific exact steps to diagnose/debug/simplify and how to concrete provide specific info on their particular setup/equipment for forum help in figuring out where it’s broken and how.
Most people have no idea how to do this, and need handholding and doing it repeatedly is hard to scale, supportwise.
This would include clear explanation of how to run it without any LEDs, on a clean working power supply (USB), make it reset to a standalone mode, and connect to 192.168.4.1, ensure that works (with clean steps of what to test there), then how to make it NON-standalone (ie getting a local IP, found via discover.electromage.com), etc.
I see many people confused about these steps, which is often half the problem…
@timster,
FredEBear’s issues ended up being something related to the router’s settings and/or support for 2.4GHz. He switched to a different router and the problems went away (at least the problems in that thread). I’m not sure if it was a device incompatibility, or just a router setting that prevents access. I do know that some routers have settings that prevent one client from accessing another, or don’t put every WiFi network on the same IP subnet, which wouldn’t work with Pixelblaze since it is all local.
Since your issue is different – your setup was known to work and still works sometimes – I think this is worth moving to another thread. As I do, I want to mention another recent thread with similar symptoms that ended up being power supply related.
This isn’t really something I can optimize around much more than I already have. If your signal is too weak for the bandwidth of live previews, it will eventually kick the connection (rather than stall the entire system), and the app will reconnect. You can click the live preview to disable that, which can help.
@Scruffynerf ,
Yes, the ESP32 has been much more difficult. I recently saw that espressif is specifically hiring for a software networking engineer to work on their LwIP fork. So I’m hopeful that they realize they have some issues and are looking to address the underlying problems.
Right, perhaps just copy paste from the last several connectivity issues, and maybe there’s a way to get Discourse to start the Troubleshooting category topics with a template like used for bug reporting, read this FAQ, try these things first, collecting basic info, steps to reproduce, etc.