I’ve been digging around in the forum trying to figure out if anyone has actually been able to build a working application that uses access point mode and the basic socket networking features together. I’ve run across several discussions, none of which seem to get all the way to, “And it worked!”
Here’s the use case:
My company builds a suite of avionics for the light aircraft market. Several of our products include Particle P1 hardware. The P1 is primarily as a standard microcontroller - it reads sensors and forwards the resulting data to one or more flight computer over RS232 or RS485 depending on the device. We also have the ability to fall back to a Wifi link to the flight computer if the wired link fails. All that works as intended.
We’ve recently had a customer ask if the sensor modules can be reconfigured for use as stand-alone devices that are accessed over Wifi in access point mode. In this case, rather than using the P1’s wifi radio as a backup link to the controller (in client mode), it would be used as an independent network that could be accessed from an app on a mobile device. The P1 would need to create an access point and a basic TCP server to relay the sensor data.
Has anyone ever heard of that working on the Particle platform? I know it’s a bit off topic for the Particle community (we don’t use any of the Particle cloud functions) but I’m hoping to figure out if its worth exploring or not.
Thanks in advance for any thoughts / suggestions / advice.
What if you left the soft-ap out and you used the Photon’s TCP Server to share the sensor data?
Yes, it would require a custom app on the phone that connects to that tcp server and interprets the data (as you mentioned).
There is a BIG IF here: this could work if and only if the TCP server can work even in the absence of any wifi connection.
I have no idea. I looked quickly at the docs but could not find anything relevant.
Maybe you have tried this and know the answer and that is the reason you are posting your question?
My experience is that this will not work (maybe @marekparticle knows better).
Although my last encounter with this topic is a while back I doubt anything has changed since as the Particle focus has shifted away from adding new Gen2 features towards getting the most out of Gen3.
SoftAP is handled by the closed source WICED stack Particle uses as is and that only supports HTTP communication and does not allow concurrent use of TCPServer/TCPClient or UDP.
Nope, TCPServer needs a preexisting WiFi connection, although internet connection is not required.
Although I'd rather stick with wired connection rather than radio as the former is definitely more reliable than the latter an alternative approach might be using the mobile device as AP.
Without a mobile AP present the entire setup would default to wired communication but when a known AP comes into reach it could be detected by the P1 and it can decide to jump onto that network and open communication with any application running on that gateway devices.
The goal is to be able to use the sensor units in a different environment which does not have an existing Wifi network for the P1 to join. For TCP to work, you have to have the underlying physical network (the 802.11 RF signaling) and the base IP infrastructure (DHCP server, IP addresses, ARP, etc), otherwise there is no way to move the data between the devices.
I was afraid that might be the case. The mobile-device-as-AP option works (I actually prototyped a version of it) but I can’t make it meet security requirements and it becomes a bit of a nightmare if you have two techs both with their phones’ SSIDs set to be “EMS-SENSOR-NET”.
Oh well. At the time we did the initial design for these things the Photon / P1 was the most accessible option for building a low volume product with a Wifi-enabled MCU. I can’t blame Particle for focusing on use cases that support their cloud service business model, and this is definitely an “off label” use of their hardware.
This also goes against the SoftAP route as it - by design - only exposes an unsecured/open WiFi network.
As it currently stands this use-case is probably better served with a controller like the ESP32.
unless each device will connect to a different AP, depending on something you know before hand about it, like your serial number, device id, etc, so you can say device A will connect to EMS-SENSOR-NET-AAA and device B will connect to EMS-SENSOR-NET-BBB, where AAA and BBB are marked in the sensor packaging or something one could easily see from looking at it.