Howto: NB-IoT with Boron LTE in Germany (Telekom)

Tags: #<Tag:0x00007fe2264a1158>


I have seen serveral posts here asking for NB-IoT support for Boron LTE in Europe, but could not find any success reports or working code. I was able to successfully establish a connection to the Particle cloud over NB-IoT and would like to share the code here.

Please note that NB-IoT is not officially supported by Particle. This means that there is no guarantee for reliability and compatibility with future DeviceOS versions.
Particle supports LTE Cat M1 which is the leading LTE low power variant in North America. In Germany (and other european countries) the carriers have decided to roll out NB-IoT instead, so we have to go this way here.

My code shows that supporting NB-IoT seems to require (relativly) simple software only changes. I would like to see Particle adding official support for this.

#include "dct.h"


void setup() {

  // Optional: This clears the setup done flag on brand new devices so it won't stay in listening mode
  const uint8_t val = 0x01;
  dct_write_app_data(&val, DCT_SETUP_DONE_OFFSET, 1);

void loop() { }

The code is quite simple. Only two AT commands are needed to reconfigure the modem:

  • AT+URAT=8 switches the modem from Cat M1 (7) to NB-IoT (8) [1, p.45]
  • AT+COPS=1,2,"26201" selects the operator. [1, p.42]. Without this command it did not work for me.


  • The time from power on to cloud connected is about 30-40s
  • All cloud stuff including firmware update seems to work as usual, tested multiple hours. Even the vitals look good:
  • I am using a NB-IoT third party sim from Deutsche Telekom
  • APN and MCC+MNC must be adapted for other carriers
  • Necessary keep alive interval has not been tested yet
  • DeviceOS version is 1.4.0
  • The usual setup via Particle app does not work here because of the third party sim and custom code. I installed system, bootloader and softdevice via CLI. I verified the versions with particle serial inspect

Changing the modem settings via AT commands is no big deal, but I am not entirely happy with that because I don’t know if there are potential situations where the DeviceOS undoes some of these changes. Perhaps when the modem is restarted in case of a failure?
To build reliable software, we would need to know all of this cases, check for them and resend the AT commands, which is not nice.

I would love to see official commands for switching to NB-IoT and setting the operator which take care of all internal corner cases. @rickkas7: Perhaps this is something you can initiate?
I did this research because of customers asking me explicitly for NB-IoT. I’m sure there are more Particle users interested in NB-IoT.

Marking some people who might be interested in this because of asking about NB-IoT in other threads:
@4np @chrisg112 @manumonti @abrilevskiy @conoro @hbierau @Alph @T1mS


Product News: Expanded LTE M1 connectivity, Bluetooth and NFC APIs are now generally available
LTE-M and NB-IoT support

This is bloody brilliant! Just need to find an NB-IoT SIM card in the UK now :-/




Hi Nils,

Awesome write up. Thanks for sharing.

With regards to why NB-IoT is disabled by default on our platform. Originally, Particle’s LTE devices did support both CAT M1 and NB-IoT bands by default. However, due to some odd nuances, there were some connectivity issues that made for a bad user experience for users on CAT M1. If memory serves correctly, the issue was that the device could get into a state where it would only scan for NB-IoT until the modem was restarted. This lead to odd fringe scenarios that took away from the user experience for customers on Particle’s SIM.

The other concern with NB-IoT is that by nature of NB-IoT’s protocol standards, certain high volume transfers have a tougher time. The primary use case we saw difficulties was with OTAs. If you have not already, I would be curious to see some testing around Device OS OTAs under NB-IoT as a follow up to this write up.


Well done Man !!! you rock !!! :clap: :clap: :clap:


This is very valuable, @nils.
Thank you so much for the work.


I tried testing Device OS OTA updates. My NB-IoT test didn’t connect with a Device OS older than 1.4.0-rc.1, so I tried a OTA update from 1.4.0-rc.1 to 1.4.0. The update starts and my app gets updated, then the device starts reconnecting which never succeeds. The Device OS did not update (checked with particle serial inspect).
I am not sure about the internal update handling, but I think the Device OS should get updated after this reconnect without launching my app. But without my app the Boron is not able to connect as the necessary NB-IoT AT commands are missing.
Perhaps this is the reason I can not test Device OS OTA updates over NB-IoT. I would have to save the two settings permanently to the modem and make sure that Device OS does not overwrite them. Is this possible?

App only updates over NB-IoT are working as normal.


If you can it would be best to update the device OS via USB.

However, when your application requires a Safe Mode Healer update the common behaviour would be that the cellular modem is not reset during the process and hence your previously set 3rd party credentials should remain in tact even when your application is not run again (which it couldn’t anyway due to the lack of the required device OS).

Having said that, it’s of course possible that your previous device OS version did have a bug in that respect and erronously performs a modem reset, which would bring us back to the USB route to overcome that.


Very interesting experiments.

As I understand it NB-IoT may only have a 10-20kbit/s data rate (up to <250kbit/s) as opposed to LTE Cat M1’s <1Mbit/s. If the OTA update is big it could take quite a while, so firmware timeouts also needs to be prolonged.

Hmm, could be interesting to learn how long it takes to download an “OTA update amount” of data with a real world NB-IoT setup


I am using USB to upload new versions all the time for the NB-IoT tests, this is the only initial way as NB-IoT is not supported out of the box.
But the case here was @mstanley asking for Device OS OTA update experiences, USB won’t help me therefore :wink:

Thank you, I would also not expect a modem reset as I can’t imagine a reason for that. I am experiencing the following behavior for a OTA update with new Device OS over NB-IoT:

  1. Boron blinks magenta for a while (App seems to be updated here)
  2. Boron starts blinking green (-> Modem connecting)
    This does never change. After a reset the Boron starts blinking green immediately, which indicates this is not my app running, as my app starts breathing blue for some time until I configured the modem. My app also has some serial logging, which does not appear in this state. particle serial inspect shows the Device OS not updated and thus a dependency fail for the user module:
  3. Only way to get Boron back to work is by flashing Device OS and application over USB.

I don’t know why the Boron does a modem reconnect after flashing the application and before flashing the new Device OS, but in this state my application is not executed and the Boron never connects, probably due to wrong modem settings.


Is there a way to get a NB-IoT-Sim-Card as a non-commercial customer (especially in Germany)?

Or is there a plan to provide it via the Borons build-in Sim? That would be even nicer :blush:.


I finally managed to get a SIM-card for my Boron LTE (with DeviceOS 1.4.2) and got it up and running here in germany :slight_smile:.
It works as @nils nicely described with T-Mobile as carrier.
OTA updates were working fine (I didn’t update the DeviceOS itself OTA until now, but my individual firmwares worked as good as with my Boron 2G/3G).
I noticed two downsides so far, the first is, I can’t locate my device by using the google-maps webhook, but since it replies with a “404 error” I think that’s not device-dependent but Google simply doesn’t know the cell-tower. So I’d say this is more bad luck than a real downside. The more critical thing is the really short keepalive-time that is needed to maintain a connection to the cloud with about 30 seconds (more doesn’t work reliably) that generates huge amounts of (unnecessary) traffic.
The general response-time to cloud-functions is comparable to the Boron in the 3G network.
A really nice thing is, that the SIMs can be IMEI-locked, so they can be deployed with a better feeling than other third-party-SIMs.