I am making a code changes to a Boron on OS V 3.1.0 from build.particle.io console. I have to be honest, it is a slow and terrible experience compared to the competitor, and I am wondering if I am doing something wrong.
First, is it normal that every single flash causes an entire green-flashing cellular reconnect? Why can’t it just start with the same code? Competitor does not force full reconnect for minor code change from cloud. I am using SYSTEM_MODE(AUTOMATIC) and not doing anything fancy to the connection.
Second and more disconcertingly, I notice repeatedly that it takes far longer for it to reconnect after a code flash (minutes flashing green) than if I just pull the plug after it downloads the new code flash. From a cold start, it will connect much faster. Why is this the case? Is this an intentional impediment or a bug?
Third, is it normal that it takes up a whole minute for a flash to propagate to Boron from a de minimis code change? Competitor takes a handful of seconds, using same LTE CAT-M connectivity.
Fourth, why does the Particle cloud have so much apparent overhead that even after it has established internet connection and goes into flashing blue, it sometimes takes forever to connect? I have even seen it connect to internet with modem (done flashing green), and then take so long to connect to “cloud” (an abstraction which shouldn’t require any additional connectivity but is 100% software-imposed) that it stops flashing blue, says “well that didn’t work, I’ve been trying to connect to particle.io for so long that I will back off for now and try again later, even though my UBlox SARA modem is fully connected to internet”, and goes to solid green? Am I doing something wrong or is this standard experience on 3.1.0?
I don’t have an answer to some of your statements and I understand you have some valid points and/or opinions.
What I can address, anytime you make a code change, small or not, a new firmware needs to be built which includes the desired OS version and that binary gets flashed. It’s not just a program you’re putting on to the device with a pre-installed OS.
In regards to cellular reconnection, this can vary as to why this occurs but sometimes it has to deal with the Cellular provider, the region, cellular tower you’re trying to connect to, signal strength, and quality, as well as other causes could exist potentially (e.g. loose antenna, antenna placement).
Have you also tried using our CLI (Workbench) to send over a firmware upgrade? If yes, did you notice the same amount of lag in actually transferring the firmware?
If you want to privately message me your Device ID, maybe I can look further into this for you and potentially shine some light on this, if anything is going on that seems abnormal.
I do not think you are doing something wrong when you flash the device from a browser.
But since you have your device with you, how about improving your workflow?
Thanks @lanceseidman and @gusgonnet for the helpful input. I think installing the local Workbench option is the best bet for me and will obviate having to further debug the cellular inconveniences. I understand it has to recompile and reflash the entire system binary as opposed to executing a scripting language on top of the device OS, so my comparison to competitor (which uses scripting language) was not analogous in this case.
Thanks for the pointer. I use VSCode for other MCU programming and it will be much nicer than the cloud interface for Boron programming.