Earlier this year we announced Starnote, a cost-effective satellite module with bundled data and transparent pricing that utilizes the same developer experience as the Notecard.
The Starnote is not available in our shop quite yet (although you can sign up to get notified when it is), but today we have a secret to share with you: all the APIs needed to work with Starnote are in the latest Notecard firmware releases, and you can test out how Starnote works without needing any additional hardware.
In this article we’ll discuss the new Notecard APIs that Starnote uses, and how you can use them to get your projects ready for Starnote today.
Introducing NTN Mode
The Notecard firmware’s key new feature for Starnote is NTN (Non-Terrestrial Network) mode. In the wireless IoT world, NTNs are communication networks that rely on elements located outside the Earth's atmosphere, such as satellites or airborne platforms, to provide internet and telecommunications services.
However, on the Notecard, NTN mode is a new transport method we built to send packets over a network using as little data as possible. Although we built NTN mode primarily for usage with Satellite modules like Starnote, you can also use the Notecard’s NTN mode to send data over cellular and Wi-Fi networks.
To use NTN mode on the Notecard you must do three things:
- Define templated Notefiles you wish to use over NTN.
- Sync your templated Notefiles to Notehub.
- Switch your Notecard’s
card.transport
method to"ntn"
.
Let’s cover each of these steps in detail.
If you’d like to follow along make sure you have a Notecard Cellular, a Notecard Cell+WiFi, or a Notecard WiFi, and that your Notecard is running firmware version 6.2.2 or 7.2.2. If you’re not, the Notecard Firmware Updates page has instructions for how to update your device.
1) Define templated Notefiles you wish to use over NTN
We designed the Notecard’s NTN mode to use as little data as possible. And for good reason—while a Cellular Notecard comes with 500MB of bundled data, the Starnote comes with 18KB—meaning, you want to make every byte count!
As such, all NTN communications require the use of templated Notefiles that include the "format":"compact"
argument. Here’s an example of a very minimal template you can use in NTN mode.
{
"req": "note.template",
"file": "sos.qo",
"format": "compact",
"port": 1,
"body": {"_lat": 14.1,"_lon": 14.1,"_ltime": 14}
}
This request defines a template for the sos.qo
Notefile.
- The
"format":"compact"
argument (which remember, is required for NTN mode) tells the Notecard to omit all metadata it normally automatically associates with Notes. - The
port
argument provides a unique integer to refer to the Notefile, and allows the Notecard to transmit a simple integer over NTN instead of a full Notefile name (remember—every byte matters). - The
body
argument tells the Notecard about the structure of your data. In this case we’re using some special identifiers—_lat
,_lon
,_ltime
—to tell the Notecard we would like our Note to include the device’s last-known latitude and longitude, as well as a timestamp for when that location was determined.
The name sos.qo
on this Notefile is no accident. This Notefile is intended to provide an NTN fallback for a device that stores and transmit the Notecard’s last-known location—one of the problems satellite-powered devices can uniquely solve.
To start testing this Notefile let’s continue to our next step.
2) Sync your templated Notefiles to Notehub
This is a quick step, but you must synchronize any Notefile templates you intended to use over NTN to Notehub, and you must do so before you start using NTN mode itself.
Performing the sync is as simple as running a quick hub.sync
request.
{"req":"hub.sync"}
Make sure the sync completes before you move on to step #3. You’ll know the sync is done when the hub.sync.status
request returns a completed
field.
{"req":"hub.sync.status"}
{
"mode": "{modem-off}",
"completed": 4,
...
}
3) Switch your Notecard’s card.transport method to "ntn"
With your template defined and synchronized you’re ready to start using the Notecard’s NTN mode.
Through the Notecard API, NTN mode is available as a new method you can switch to using the card.transport
request. You can view your current transport method by running the request with no arguments.
{"req":"card.transport"}
On the Notecard Cellular this returns "cell"
; on the Notecard WiFi this returns "wifi"
; and on Notecard Cell+WiFi this returns "dual-wifi-cell"
by default (prioritize Wi-Fi connectivity and fallback to cellular).
With the introduction of NTN there are four additional transport methods you can use.
"ntn"
: Always use NTN."cell-ntn"
: Use cellular by default, fallback to NTN."wifi-ntn"
: Use Wi-Fi by default, fallback to NTN."wifi-cell-ntn"
: Use Wi-Fi by default, fallback to cellular, and lastly fallback to NTN.
In a production setting with a physical Starnote you will likely want to use one of the modes that includes a fallback. For example, a Notecard Cellular with a Starnote attached would likely want to use cell-ntn
to use cellular when available, with a fallback to NTN for emergency data when out of cellular range.
However, for testing purposes (like we’re doing today) the "ntn"
method is a great way to try out NTN communication over a cellular or Wi-Fi connection.
To switch to NTN mode send your Notecard a card.transport
request with a "method"
of "ntn"
.
{"req":"card.transport","method":"ntn"}
Testing NTN mode
Now that you’re in NTN mode, go ahead and add a Note to the sos.qo
Notefile we created earlier. It’s ok that the body
is empty because we used the special _lat
, _lon
, and _ltime
identifiers in this Notefile’s template, and you’ll see what those do momentarily.
{"req":"note.add","file":"sos.qo","body":{}}
Next, synchronize this Note to Notehub using the hub.sync
request.
{"req":"hub.sync"}
After the sync completes, visit your Notehub project and you should see a new event in your project’s events listing. Notice how because we included _lat
, _lon
, and _ltime
in the sos.qo
Notefile’s template, the event includes the device’s latitude (best_lat
), the device’s longitude (best_lon
), and a timestamp for when the location was last determined (best_location_when
).
If you’re following along and do not have a GPS/GNSS location, you may need to enable location sampling on your Notecard using the card.location.mode
request. For example:
{"req":"card.location.mode","mode":"periodic","seconds":3600}
And with that, you’ve sent your first Note over the Notecard’s NTN mode! And what’s cool about this is—this is the exact set of steps you’ll need to follow when you have a physical Starnote. When in NTN mode, the Notecard will use the Starnote if it detects one, and instead use a cellular or Wi-Fi connection if a Starnote is not available.
When you’re done testing you will likely want to switch your Notecard back to its default transport method, which you can do by calling the card.transport
request with a method
of "-"
.
{"req":"card.transport","method":"-"}
Using NTN Mode and Starnote in Real Projects
Now that you’ve seen NTN mode in action, let’s discuss a few things about how you might actually use Starnote and NTN mode in real applications. Let’s start by talking about data usage, as minimizing data usage is critical to any IoT projects that leverages satellite networks.
Each Starnote comes with 18KB of packaged data, and beyond that data costs 75 cents per KB. Additionally, any individual packet will be rounded up to a minimum of 50 bytes per packet. To give you a sense of how that adds up, sending a 50-byte packet once a day would use up the prepackaged data in roughly in a year (50 bytes * 360 days = 18KB).
Given these constraints it’s important to aim for two things when building Starnote applications:
- Keep your Notes small, ideally under 50KB.
- Minimize how often you send data over satellite.
Let’s discuss each.
1) Keep your Notes small, ideally under 50KB
When you create a Notefile template using the note.template
request you can see how much data it will take to store each Note in the response. For example, here’s the response from the template we created early in this article, showing that each Note in this Notefile will take 15 bytes to store.
{"req":"note.template","file":"sos.qo","format":"compact",...}
{
"bytes": 15,
"format": "compact"
}
There is a small bit of overhead required to transmit the Note to add the necessary encryption and identity management, but this Note will easily take under 50 bytes to send.
2) Minimize how often you send data over satellite
Compact Notefile templates make keeping individual Notes small reasonably easy, so the far larger concern is how often you send data in satellite-backed projects.
If you’re deploying a project to an area that has zero cellular or Wi-Fi connectivity this calculation becomes a simple math problem. You figure out the size of your Notes, take into account the cost per byte using Starnote, and decide how often you wish to transmit.
However, if you’re deploying to an area that will use mixed connectivity—e.g. cellular with a fallback to satellite—how you structure your Notefiles and synching cadence becomes more interesting. As a hypothetical example, you could create a project that used the two templates below.
{
"req":"note.template",
"file":"all-data.qo",
"body":{"essentialField1":14.1,"essentialField2":14.1,"otherField1":14.1,"otherField2":15.1,...}
}
{
"req":"note.template",
"file":"vital-data.qo",
"format":"compact",
"port":2,
"body":{"essentialField1":14.1,"essentialField2":14.1}
}
This example defines two Notefile templates: all-data.qo
, which contains a rich set of data, and vital-data.qo
, an NTN-compatible compact template that only contains a few essential fields.
When using cellular connectivity the Notecard would transmit both of these Notefiles, as there are no restrictions when using cellular for transmission. However, when using satellite connectivity, the Notecard would only transmit Notes in the vital-data.qo
Notefile, as it is the only NTN-compatible Notefile.
This is just one of the many ways you may wish to approach a Starnote-backed project. As always, we tried to design the Notecard APIs to give you the flexibility to configure data storage and transmission cadences for whatever makes sense for your project. For a full discussion on defining templates for Starnote usage, see Define NTN vs non-NTN Templates.
Wrapping Up
In this article we took a look at how you can prepare for Starnote by trying out NTN mode today. We looked at how you can test NTN mode over a cellular or Wi-Fi connection, and then had a bit of a discussion on how you might want to approach satellite connectivity in a real project.
We’re excited about Starnote and can’t wait to see what you build with it. Make sure to sign up for our newsletter to get notified as soon as Starnote is available for general purchase. And keep tabs on this blog—we have some fun ideas for future Starnote content 🛰️👀