Photon SoftAP mode - mobile cannot obtain address

@ScruffR, don’t have one unfortunately for WiFi.

Tried the antenna that came with the Electron (Hexa Band Cellular), but no improvement.

No joy with the logging - looks the same (except for timings - bad Photon is quicker…).

Here is the log from the Photon with the issue:

0000003667 [hal.wlan] INFO: Using internal antenna
0000003869 [system] INFO: Network Connect: SPARK_CLOUD_CONNECT && !network.connected()
0000003869 [system] INFO: ready(): 0; connecting(): 0; listening(): 0; WLAN_SMART_CONFIG_START: 0
0000003869 [system] INFO: ARM_WLAN_WD 1
0000005413 [system] INFO: ARM_WLAN_WD 2
0000005413 [hal.wlan] INFO: Bringing WiFi interface up with DHCP
0000005437 [system] INFO: CLR_WLAN_WD 1, DHCP success
0000005439 [system] INFO: Cloud: connecting
0000005826 [system] INFO: Resolved host device.spark.io to 52.91.48.237
0000006078 [system] INFO: connected to cloud 52.91.48.237:5683
0000006080 [system] INFO: Cloud socket connected
0000007320 [comm] INFO: Hanshake: completed
0000007333 [system] INFO: Cloud connected
0000009035 [system] INFO: ready(): 1; connecting(): 0; listening(): 0; WLAN_SMART_CONFIG_START: 0

And here is the log from the okay Photon:

0000003673 [hal.wlan] INFO: Using internal antenna
0000003675 [system] INFO: Network Connect: SPARK_CLOUD_CONNECT && !network.connected()
0000003676 [system] INFO: ready(): 0; connecting(): 0; listening(): 0; WLAN_SMART_CONFIG_START: 0
0000003676 [system] INFO: ARM_WLAN_WD 1
0000011802 [system] INFO: ARM_WLAN_WD 2
0000011802 [hal.wlan] INFO: Bringing WiFi interface up with DHCP
0000011826 [system] INFO: CLR_WLAN_WD 1, DHCP success
0000011828 [system] INFO: Cloud: connecting
0000011839 [system] INFO: Resolved host device.spark.io to 54.173.1.44
0000012094 [system] INFO: connected to cloud 54.173.1.44:5683
0000012094 [system] INFO: Cloud socket connected
0000013350 [comm] INFO: Hanshake: completed
0000013362 [system] INFO: Cloud connected
0000015065 [system] INFO: ready(): 1; connecting(): 0; listening(): 0; WLAN_SMART_CONFIG_START: 0

@UMD, @ScruffR, We had identical issue with surface mounted Photon. You need to remove ground loops on the board which somehow interact with the wifi module making the DHCP not working. I will post our board design for inspiration.

1 Like

@dfarny, spooky ground loops… See the picture with this post above:

What I am hoping for is some sort of software work around to this issue. Everything else work fine, including WiFi comms.

@ScruffR, finally got a proper patch antenna (Adafruit 2.4GHz Mini Flex) to perform the experiment as you suggested some weeks ago.

Have first repeated the experiment with the “bad” Photon (ie Photon on PCB) without the patch antenna - it did not serve an address (as expected).

With the patch antenna, an address was served and I could connect using a HTC One.

Do you think this is fixable via firmware?

I doubt that’s fixable via firmware, but @BDub might know better.
I’ve got a Photon that just doesn’t like connecting - it always takes ages no matter what FW or system. I’ve even swapped chip antennas between two devices, but the stubbord device was just as stubborn and the good one just as good.
No clue what’s wrong with the one :confused:

@ScruffR, am thinking that it could be fixable because other than the SoftAP issue, it connects a.ok to WiFi and communicates with the cloud.

I sent a PCB to @mdma so that he can reproduce the fault back in April 2016.

I also noticed this issue with a surface mount photon and custom pcb

The problem is random. Sometimes it work well, sometime less. But it always work with my laptop.

Sometimes I’m not able to connect with my android phone, and if I try with an iphone, it works.

Wifi always work well and connect easily to the cloud.

Try setting antenna selection to AUTO.

STARTUP(WiFi.selectAntenna(ANT_AUTO)); // continually switches at high speed between antennas

The problems started popping up after particle changed the default to ANT_INTERNAL, so in some cases changing back to AUTO allows your board to be used.

And since you can set a static IP and allow the softAP process to complete, while the board runs perfectly for months on end, its obviously something than can be fixed or improved in software, but not much interest from particle in the matter.

I shipped a board to norway as requested so they had a sample of a board which showed the problems, but never heard back :confused:

2 Likes

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.

@dan.s, have a look at this post I made some time ago:

Does this help?

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?