The nRf9160 Feather Connects to the Outside World!

Jared Wolff · 2020.6.11 · 6 Minute Read · engineering · hardware · nrf9160 feather

This week, the nRF9160 Feather got some more attention. I even got it to roll over. 😇 To top it all off, my hardware validation list is looking good!


In this post i’ll discuss the state of things and where hardware, firmware and more are going next.

Let’s do this!

What’s in the box.

There’s a ton to Zephyr. Let’s face it, there’s an overwhelming large amount of libraries, sub-libraries, and samples. Nordic’s Connect SDK requires several different repositories to make things work.

Here’s what a typical top level directory looks like:

  • bootloader - the MCUboot bootloader used for the nRF9160 (and other boards)
  • mbedtls - a library imported by the SDK. Used for encrypting/decrypting data
  • modules - modularized external libraries (littlefs, etc)
  • nrf - most Nordic samples live here
  • nrfxlib - the main set of Nordic based libraries and code.
  • test - testing infrastructure
  • zephyr - the main OS libraries, board definitions and more samples

The biggest difference between the Nordic’s standard and Connect SDK is the sample code. For the standard SDK, they’re all located in one place. Whereas for the NRF Connect SDK, they’re scattered throughout every repository involved. For instance, the basic blinky example is in zephyr/samples/basic/blinky. The complex Nordic specific samples are in the /nrf/samples directory.

Why is this?

The folks behind Zephyr were smart and make their samples generic. Meaning that you can run them on any piece of hardware. The only limitation is to make sure you have a hardware definition for your board!

An important sample

The most important sample that I had found in the nrf directory was the at_client firmware. (under ncs/nrf/samples/nrf9160/at_client) Along with nRF Connect (for Desktop), it makes a potent combo for debugging. Plus it’s a great tool for surveying your current area for M1/NB1 service.

For me, it was a great tool to make sure that the nRF9160 Feather was working a-ok. The only change I had to make was to the prj.conf file. I added a section that allows you to set the PDP context (i.e. set the APN)

# Set the PDP context

In my case, I was testing holigram. Their APN is also named holigram. For other providers, like Twilio, theirs is different. Twillio’s “Super” SIM uses super. Their standard wireless service is In some cases, like AT&T and Verizon, you do not have to set the APN. It’s set for you by the modem firmware.

Building and flashing the firmware is a breeze. Here’s what it looked like on my end:

west build -b circuitdojo_feather_nrf9160_ns
west flash && nrfjprog -r

Then opening up the serial console, as I talked about previously and typing in AT. You should get an OK back. Disconnect from the terminal though, the LTE Link Monitor will need it!

You use the Link Monitor to connect directly to the at_client firmware. You can either enter AT codes manually or have the Link Monitor run through them. As of this writing though, the LTE Monitor does not support connections that do not have flow control!

Oh but I didn’t know that going into it. After a few hours of debugging, and posting to Devzone I found my answer. The ModemPort library, used in LTE Link Monitor, initializes with rtscts support always on.

Not great for non-flow control boards, right?

What I ended up doing was cloning the modemtalk library to a local directory, make the change there.

Then, update my dependencies section from:

"dependencies": {
  "electron-store": "^2.0.0",
  "modemtalk": "^1.1.5"


"dependencies": {
  "electron-store": "^2.0.0",
  "modemtalk": "file:/path/to/modemtalk"

Then you can see the exact edit below:


Fortunately, rebuilding with rstcts to false fixed things. That wasn’t a piece of cake though.

There was yet another set of problems that turned me intro a giant stress ball. Fortunately changing some of the dependencies in package.json seemed to fix it!

After that, I was off to the races!

Here’s what things look like when you first make a connection.


If you haven’t already, select your serial port in the top left. If it’s not showing up make sure that you un-check Auto device/port filter. That’s located in the bottom right. (See the above picture). In my case, it’s called /dev/tty.SLAB_USBtoUART.


Once you select your port, it should start streaming commands. Pay attention to the right side of the screen. When the Link Monitor receives updates, it reflects that in the status area.


You should see a ton of activity. If not make sure you enable Automatic Requests (bottom right side checkbox, checked by default). If you are using flow control, then UART will be green as well. If not, it will remain red.

Imagine for a second, the happy dance I did after a successful connection. This was only after several unsuccessful attempts using other cards.

When you’re ready to start testing with any nRF9160 based board, (including the nRF9160 Feather), the LTE Link Monitor is your friend. For more information about how to use, you can download the LTE Link Monitor guide here.

SIM Testing Update

As you can imagine, testing hardware and firmware is one thing. Testing wireless services is a completely separate prospect! I have some notes in the table below on the services and SIMs that i’ve tested thus far. Your mileage may vary, especially if you’re not within the USA.

Provider Name Connected To Notes Testing Complete
Holigram Sprint The only SIM card I have data workin with right now. Yes
Soracom AT&T Tested previously with a different module in this location. Will test again with the nRF9160 No
Verizon Verizon Only works in administrative mode. (No internet). Connects much faster than Holigram/Sprint. Will test some more when I get data access. No
Twilio (Standard Wireles) ? Supposedly T-Mobile has M1 deployments. I was unable to connect with my module. Other folks on Devzone don’t seem to have this problem. Twilio support… was not particularly great. T-Mobile technically does not support the nRF9160. No
Twilio (Standard Narrowband) ? Untested. Waiting for SIM cards. No
AT&T AT&T Untested. AT&T, right now, technically does not support the nRF9160. No

Overall, the results were frustrating. This is most likely due to the fact that either

  1. There is no service in my area
  2. Or, the service is blocking your device from connecting because of an invalid IMEI.

In either case, i’ll be making more progress in the weeks to come!

Upcoming Updates

There’s still a ton to do on the nRF9160. It’s coming along about as good as expected though. I anticipate more celluar testing and more firmware testing. Stay tuned and don’t forget to subscribe to stay up to date on development.

Last Modified: 2020.10.9

Subscribe here!

You may also like

How to Connect the nRF9160 Feather to Mosquitto

One thing that’s always tripped me up as an IoT developer is figuring the best way to transmit data. There are many different kinds of radios and mediums. On top of that, there are…

The nRF9160 Feather Launch

I was a complete failure. My prototype wasn’t working. I spent at least an hour trying to rework a frustratingly large LTE module on an impossibly small circuit board. It wasn’t…

The nRF9160 Feather with Bluetooth

One of the cool things about Zephyr is its modularity. It’s also one of things that makes development on the platform difficult. This is especially true if you’re not use to the…