Boron + 3rd Party Sim (SORACOM)

Has anyone had any luck using 3rd party SIM cards with LTE Boron? I’ve run through the tutorial but it seems a few months out of date. Not sure if there’s anything else that must be done. :frowning:

I did throw the SIM in my phone and it appears to connect just fine. Also, the internal SIM connects as well. (SORACOM should be using AT&T. Just as the Particle SIM should…)

I have had success with Hologram SIM cards, but not with Soracom or Things Mobile. The latter two never seem to connect. I’ve tried Soracom on a couple of Pycom devices as well with no luck.

Thanks @picsil I’m glad I’m not the only one here!

It's possible that you need to manually select AT&T as your provider. Try following the instructions here, but set mnoProf to 2 to manually select AT&T instead of Verizon.

@rickkas7 Thanks. I’ve read that post, and do set AT+UMNOPROF=2 to try attaching to AT&T, and AT+UMNOPROF=3 for Verizon. On Hologram it works as expected. I can switch between AT&T and Verizon with those settings, or be connected automatically to one or the other with AT+UMNOPROF=0. With Things Mobile and Soracom nothing I have tried connects to any carrier. I have used Things Mobile on the Pycom platform with some success. It only seemed to attach to AT&T, even if Verizon had a MUCH better signal. The few times the Pycom board actually tried to attach to Verizon on TM, it just hung the device. That’s actually the reason I switched to the Particle Boron. I am able to use both Verizon and AT&T. Unfortunately it’s only with Hologram so far, with is vastly more expensive than Soracom or Things Mobile.

So for SORACOM, it requires a username and password to go along with the APN. The only place in the HAL driver that I saw referencing the password and username was in SaraNcpClient::configureApn.

Unless I’m missing something, this is why it’s not working. The username and password is not getting set via the proper AT commands. Looks like AT+UAUTHREQ should be it but I’m still fiddling with it. Will keep y’all updated. :slight_smile:

You can pass Cellular.setCredentials the APN, username, and password. The definition is Cellular.setCredentials(const char *apn, const char *username, const char *password).


That should work, but it doesn’t for me.

1 Like

Alright, 6 hours later. The conclusion is the following:

The firmware, by default, does not set the APN credentials. The best way to do it without making changes to the baseline firmware itself is to run the following after a Cellular.on() (make sure Cellular is off before this)


I put it in printf format so other folks can insert their own APN information. 2 is the authentication type (in this case CHAP). For UAUTHREQ the password is before the username. (doesn’t matter for SORACOM in this case)

Also, as you can tell I set up a separate context for the SORACOM APN. Despite this, the device then defaults to CID 1 (for whatever reason). But it connects and authenticates and that’s all that matters!

Also… be sure to clear your credentials. That will muck things up!


(The above technically only needs to be done once)

Also, (one more thing!) make sure your device is in MANUAL or SEMI_AUTOMATIC mode. AUTOMATIC will not work.


I did some preliminary testing with ThingsMobile (I’ll try Soracom next) and have it connected to AT&T successfully in the US.

I’m using a modified boron-clouddebug that adds the following commands before Cellular.connect():


It takes about 2 minutes to connect, but it works! I’ll see if I can get it on Verizon, and then test Soracom.

On a related note, do you know if Soracom also supports Verizon in the US?

1 Like

I think they only support AT&T. Verizon, in my experience, has been difficult to work with on CAT M1 deployments…

To give more context for my response: there are companies out there that have CAT M1 service for Verizon.


Their interfaces are not nearly as nice as these other guys but you do get Verizon service. (Their pricing is also not nearly as competitive!) One issue that I’ve seen, unless they’ve fixed it, is that you need special SIM from Verizon for your CAT M1 device to work on their network. It’s bizarre but I guess that’s how they’re managing it. (Unless they’ve made sweeping changes since I’ve last used that stuff)

Another main issue is that their automation API for provisioning/de-provisioning was non-existent not to long ago. I think companies can now provision automatically but it wasn’t always the case.

Put in a pull request for the fix!

1 Like

So, I just got a fresh Boron and I was attempting to do the same thing. I ran into trouble real quick. I’m not sure if this procedure needs to be run over and over until it sticks. The configuration that finally connected was set with:


Where the CGDCONT were:

0000130462 [] TRACE: > AT+CGDCONT?
0000130509 [] TRACE: < +CGDCONT: 1,"IP","","",0,0,0,0

and the AUTH was:

0000006160 [] TRACE: > AT+UAUTHREQ?
0000006207 [] TRACE: < +UAUTHREQ: 1,2,"sora"

(Password is removed from response)

I tried this for a good chunk of time the biggest thing I changed from all my fiddling was running a AT+CFUN=15. So run the configuration commands and the CFUN=15, wait a sec, power down, remove those config commands from your code (as they should now be retained in the modem) and boot back up.

Do you set Particle.keepAlive(XXX); ? It’s required or not ?

Hey @steeves

DeviceOS, the last time I looked into it, does not support the authentication method required to use Soracom’s APN. If you’re looking to experiment with a different provider, I recommend Hologram. I’ve been playing around with it a bunch and it’s been working great. Plus if your device is end certified with Verizon, you can use Verizon’s network as well!

Hey, forget Hologram, it’s old school and not fast. I running fine soracom with my Boron LTE without problem, pricing is a log better. I wanted to know if you use Particle.keepAlive because for me i don’t set this parameter and I have no problem. Just wanted to know

I don't know what Soracom's default keep alive is, but it greatly depends on your other code whether you need to set Particle.keepAlive() or not.
If your code regularly (i.e. well within the default keep alive period) publishes data, you wouldn't need to tell the device OS about the required period, but if your code fails to regularly "reopen" the channel with the provider you cannot rely on the device OS to do that for you.

Also, without Particle.keepAlive() your device will typically always be able to communicate with the cloud, but the path back may close over time and the cloud will not be able to access the device until the device opens the path again from its end.