Would love an update to this issue, we have installed 100s of the older photons (with 4 random letters in the softAP instead of 6) no problem. Now we have just made 200 more, exactly the same circuit, but now getting “couldn’t get IP address” issues!!! Please help, this is really bad for us.
Clearly an update to firmware caused this, specifically changing the startup antenna to internal.
Context?
Where does that message from?
What version were you using before, which now?
@Dan.s, are you using an external or internal antenna? If internal, try an external one and report back (of course setting WiFi.selectAntenna() appropriately).
I have not touched SoftAP since way back then, now much preferring to use USB serial configuration.
Message appears similar to the exact way everyone else has experienced in this thread - that’s why I’m responding to this one instead of creating a new thread!
The previous working version was 0.6.3 where the softAP had 4 random letters in it after “Photon-”, whilst the new version has 6 letters. I don’t have one of the new ones in front of me so cannot say specifically which version it comes with, I think it was v0.8.0 which first introduced this.
@UMD yes we use an external antenna on all our units, and our firmware has the appropriate startup command to select it. However our firmware only gets installed once it is connected online! It is fine once this happens.
The factory installed firmware really ought to allow both onboard and external antenna by default. What was wrong with leaving it as STARTUP(WiFi.selectAntenna(ANT_AUTO)) ?
USB serial configuration is a no-go as it is a customer facing product.
@ScruffR, (assume) the message is from the Mobile.
@Dan.s, another complicating factor is the O/S on the mobile and what brand/model it is… a huge amount of variability there. Are you testing against the same mobile(s), with the same version of O/S, for your second batch as you did for the first? This is very hard ask, I know.
Have you enabled the (excellent) logger so as to see the DeviceOS events?
1 Like
Tested with 4 different devices but broadly speaking the main difference is android vs iOS. We had to stop using iOS because it was just taking too long to accept that we did not want internet connectivity after connecting to the photon softap, which meant it was still connected to 4G (which throws errors when setting up). It would work eventually but compared with the android devices which took between 6-8s to “check the quality of the internet connection”, iOS took over a minute! iOS never used to be this bad but I attribute that to the phone software rather than the photon. If you’d like to see what is supposed to happen when setting up on an android device, have a look at the video in our docs: https://docs.flowreporter.com/index.php/documentation/2-registering-a-device/b-a-device/
Anyway I’ve just come back from commissioning 90 of the new units (my messages were written after installing 3 units with the same problem) and have an interesting update; only about 1/3 of the units had the documented issue - the first 3 must have been coincidence. Furthermore, after experimentation, I found a workaround where if the IP address wasn’t found within the first 2 seconds, I would forget softAP network on the phone, power cycle the photon (not time dependent, could literally be half a second power off), and on second connection it would miraculously work fine.
Why this is I still don’t know, all units are made the same, and were in very similar environments. I guess it’s just the magic of electromagnetism playing with certain transistors in the chips!
That being said, this is still annoying for an end-customer (setting up themselves) to experience and I still think it could be avoided if the factory installed firmware allowed both onboard and external antenna by default. Can we please reinstate STARTUP(WiFi.selectAntenna(ANT_AUTO)) for future firmware?
2 Likes
IIRC, the reason for opting for ANT_INTERNAL as default back then was that you obviously cannont have both parallel and the switching frequency between internal and external and the arbitrary time to establish a connection (including retries) cannot easily be synced.
On the other hand if you happen to use the “wrong” antenna first and keep the switching frequency too low (for above reason) you may create more problems than you solve.
Hence, opting for ANT_INTERNAL seemd the safest bet.
After all, for first setup you most likely are near the device and hence the extra “range” of ANT_EXTERNAL should not be that important.
However, when a product creator knows that ANT_INTERNAL won’t work (e.g. due to shielded casing) the factory image can/should explicitly set ANT_EXTERNAL.
Having that said, HW revisions (e.g. opting for a better switch) and device OS improvements may have solved the issue for newer devices, but early batches are still out in the wild and may not react to well to a change on that front when a device OS update would bring back that initial issue.
PS - really liked your instructional website and video!
1 Like
It would have helped 2 years ago when we were first building the product! We also realised the problem with devices checking for a “real internet connection” when creating our own web app - the particle app manages this function very well, but only because it has access to the device’s networking facilities; we did not want to spend significant amounts of resource creating android + iOS (+ windows back then) apps.
You just have to inform the user to WAIT for the device to work out internet connectivity is not required - and hope they do!
@dan.s, we are up against it because the issue resides in the mobile OS.
Perhaps there are some Android or IOS experts in the community who could give some pointers/work arounds?