A new Pipelines data destination for Memfault is now generally available for Golioth users. It enables devices to leverage their existing secure connection to Golioth to deliver data containing coredumps, heartbeats, events, and more to Memfault. To see this integration in action, check out the example firmware application, read the documentation, and tune into this week’s Friday Afternoon Stream, where we will be joined by a special guest from Memfault.

Golioth + Memfault

We have long been impressed with the functionality offered by Memfault’s platform, as well as the embedded developer community they have cultivated with the Interrupt blog. In our mission to build a platform that makes connecting constrained devices to the cloud simple, secure, and efficient, we have continuously expanded the set of cloud services that devices can target. This goal has been furthered by the recent launch of Golioth Pipelines.

Memfault’s observability features are highly desired by embedded developers, but leveraging them has typically required establishing a separate HTTP connection from a device to Memfault’s cloud, building custom functionality to relay data from an existing device service to Memfault, or utilizing an intermediate gateway device to provide connectivity. With Golioth, devices already have a secure connection to the cloud for table-stakes device management services and flexible data routing. By adding a Memfault data destination to Golioth Pipelines, that same connection can be used to route a subset of streaming data to Memfault. Leveraging this existing connection saves power and bandwidth on the device, and removes the need to store fleet-wide secrets on deployed devices.

How It Works

The Memfault Firmware SDK provides observability data to an application serialized in the form of chunks. An application can periodically query the packetizer to see if there are new chunks available.

bool data_available = memfault_packetizer_begin(&cfg, &metadata);

When data is available, it can be obtained from thepacketizer by either obtaining a single chunk via memfault_packetizer_get_chunk, or by setting enable_multi_packet_chunk to true in configuration and repeatedly invoking memfault_packetizer_get_next  until a kMemfaultPacketizerStatus_EndOfChunk status is returned. The latter strategy allows for obtaining all data in a single chunk that would exceed the default size limitations. Golioth leverages this functionality to upload both large and small chunks using CoAP blockwise transfers, a feature that was enabled in our recent v0.14.0 Golioth Firmware SDK release.

golioth_stream_set_blockwise_sync(client,
                                  "mflt",
                                  GOLIOTH_CONTENT_TYPE_OCTET_STREAM,
                                  read_memfault_chunk,
                                  NULL);

The read_memfault_chunk callback will be called repeatedly to populate blocks for upload until the entire chunk has been obtained from the packetizer.

static enum golioth_status read_memfault_chunk(uint32_t block_idx,
                                               uint8_t *block_buffer,
                                               size_t *block_size,
                                               bool *is_last,
                                               void *arg)
{
    eMemfaultPacketizerStatus mflt_status;
    mflt_status = memfault_packetizer_get_next(block_buffer, block_size);
    if (kMemfaultPacketizerStatus_NoMoreData == mflt_status)
    {
        LOG_WRN("Unexpected end of Memfault data");
        *block_size = 0;
        *is_last = true;
    }
    else if (kMemfaultPacketizerStatus_EndOfChunk == mflt_status)
    {
        /* Last block */
        *is_last = true;
    }
    else if (kMemfaultPacketizerStatus_MoreDataForChunk == mflt_status)
    {
        *is_last = false;
    }

    return GOLIOTH_OK;
}

Golioth views the data as any other stream data, which can be delivered to a path of the user’s choosing. In this case, the data is being streamed to the /mflt path, which can be used as a filter in a pipeline.

filter:
  path: "/mflt"
  content_type: application/octet-stream
steps:
  - name: step0
    destination:
      type: memfault
      version: v1
      parameters:
        project_key: $MEMFAULT_PROJECT_KEY

Click here to use this pipeline in your Golioth project!

Because the Memfault Firmware SDK is producing this data, it does not need to be transformed prior to delivery to Memfault’s cloud. Creating the pipeline shown above, as well as a secret with name MEMFAULT_PROJECT_KEY that contains a project key for the desired Memfault project, will result in all streaming data on the /mflt path to be delivered to the Memfault platform.

Livestream demo with Memfault

Dan from Golioth did a livestream with Noah from Memfault showcasing how this interaction works, check it out below:

What’s Next

We will be continuing to roll out more Pipelines data destinations and transformers in the coming weeks. If you have a use-case in mind, feel free to reach out to us on the forum!

We’re excited to be taking part in a webinar with our partner Nordic Semiconductor on June 20th, 2024. Note that on the signup page, there are two different timezones available! As with many webinars, the content will be available “on demand” after the fact.

Highlighting Reference Designs

The main focus of the webinar is how Golioth helps engineers get started quickly with our Reference Designs. Three of the designs we’ll featuring are:

These are fully featured end-to-end demos that highlight typical industrial use cases. I like to think that a past version of myself working as a hardware engineer at a product company would have really benefited from this model of learning. I know I would appreciate seeing an entire design that includes:

  • Hardware (both custom and off-the-shelf)
  • Firmware (open source, running on top of the Golioth Firmware SDK and the nRF Connect SDK)
  • Cloud side software
  • Visualization
  • Automation and Data routing (using the new Golioth Pipelines feature)

A generous helping of nRF Connect SDK (and Zephyr)

None of this would be possible without the great work from the Nordic team supporting all their wonderful hardware with the nRF Connect SDK. It unlocks many of the features on devices like the nRF9x family (cellular), the nRF7x family (Wi-Fi), and the nRF5x family (Bluetooth). We will talk about how we build the Golioth SDK to work alongside the Nordic SDK to make a connection to the cloud seamless for users.

Build it yourself

We will go over how you can build your own version of the Reference Designs. This is made easier by using our “Follow Along Hardware” guides, which include a parts list to buy modules “off-the-shelf” from popular distributors and a firmware binary that immediately shows the functionality of said hardware. Once you have a working design on your desk, you can also pull the code in from the Nordic SDK add-on directory in VS Code, which includes the Golioth reference designs. This is a super fast method for downloading the entire project and beginning to modify as needed. Finally, you can connect your project to Golioth and see the same data flowing out to your other Cloud services. Go from zero to hero in no time!

Don’t forget to register

Sign up today for the Nordic webinar with Golioth on June 20th, 2024. We’ll see you there!

We got an early look at Nordic’s new cellular modem, the nRF9151, and it already works with Golioth!

With any new board, we ask ourselves “can we connect it to Golioth?”. You may remember a similar post when the nRF7002-DK first came out. Of course the answer for these two boards, and pretty much all other network-enabled embedded systems, is: yes, you can use them with Golioth. So today we’ll walk though the experience of connecting the nRF9151 to Golioth for the first time.

What’s new with the nRF9151?

We love the nRF9160 cellular modem and have support for it in all of the Golioth Firmware SDK samples, as well as using it in the Hardware-in-the-Loop (HIL) testing that is connected to our continuous integration infrastructure. So what’s the deal with the new part?

Finger pointing at a small rectangular chip (SOC)Most obviously, it’s really really small. The 9151 is about a 20% size reduction from the 9160 (new dimensions are approximately 11×12 mm). Here you can see it’s smaller than the fingernail on my pointer finger. The smaller sized also delivers lower peak current consumption. As with the recently announced nRF9161, the nRF9151 supports DECT NR+. And Nordic indicates the new design is fully compatible with the existing nRF91 family of chips.

This is also the first Nordic dev board I’ve seen that uses a USB-C connector. While you can’t get your hands on one of these just yet, since Golioth is partners with Nordic they were kind enough to send us one of these nRF9151 Development Kits to take for a test drive.

Building Golioth examples with the nRF9151

This board is not yet available to order, but support has already been added to Zephyr. To get it working with Golioth, we needed a fix that Nordic merged after their v2.6.1 release of the nRF Connect SDK (NCS). So today I’ll be checking out a commit in between releases. When Nordic releases v2.7.0 everything will work without this extra step.

0. Install the Golioth Firmware SDK

You will need an NCS build environment along with the Golioth SDK. You can follow the Golioth Docs to install an NCS workspace, or add Golioth to your existing NCS workspace.

1. Update NCS version (if needed)

If you are using NCS v2.7.0 (not yet released at the time of writing) or newer, you can skip this step. Otherwise, edit your west manifest and update the NCS version. Below is the west-nrf.yml file from the Golioth SDK with the changed line highlighted.

manifest:
  projects:
    - name: nrf
      revision: 85097eb933d93374fe270ce4c004bea10ee80e97
      url: http://github.com/nrfconnect/sdk-nrf
      import: true

  self:
    path: modules/lib/golioth-firmware-sdk

This happened to be the commit at the tip of main when writing this post. We usually recommend against targeting commits in between releases, so consider this experimental.

2. Add a board Kconfig file for the nRF9151

Add the board-specific configuration to the boards’ directory. For today’s post, I’m building the Golioth stream sample so I’ve added this nrf9151dk_nrf9151_ns.conf board file to that sample directory.

# General config
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_NEWLIB_LIBC=y

# Networking
CONFIG_NET_SOCKETS_OFFLOAD=y
CONFIG_NET_IPV6=y
CONFIG_NET_IPV6_NBR_CACHE=n
CONFIG_NET_IPV6_MLD=n

# Increase native TLS socket implementation, so that it is chosen instead of
# offloaded nRF91 sockets
CONFIG_NET_SOCKETS_TLS_PRIORITY=35

# Modem library
CONFIG_NRF_MODEM_LIB=y
CONFIG_NRF_MODEM_LIB_ON_FAULT_APPLICATION_SPECIFIC=y

# LTE connectivity with network connection manager
CONFIG_NRF_MODEM_LIB_NET_IF=y
CONFIG_NRF_MODEM_LIB_NET_IF_AUTO_START=y
CONFIG_NRF_MODEM_LIB_NET_IF_AUTO_CONNECT=y
CONFIG_NRF_MODEM_LIB_NET_IF_AUTO_DOWN=y

CONFIG_NET_CONNECTION_MANAGER=y
CONFIG_NET_CONNECTION_MANAGER_MONITOR_STACK_SIZE=1024

# Increased sysworkq size, due to LTE connectivity
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Disable options y-selected by NCS for no good reason
CONFIG_MBEDTLS_KEY_EXCHANGE_DHE_PSK_ENABLED=n
CONFIG_MBEDTLS_KEY_EXCHANGE_DHE_RSA_ENABLED=n

# Generate MCUboot compatible images
CONFIG_BOOTLOADER_MCUBOOT=y

3. Build the Golioth stream sample

Building and running this sample is now quite simple. I have included the option to use runtime credentials in this build so that we can provision the device from the Zephyr shell.

$ cd examples/zephyr/stream
$ west build -b nrf9151dk/nrf9151/ns -- -DEXTRA_CONF_FILE=../common/runtime_settings.conf
$ west flash

4. Provision and run the sample

Golioth is free for individual use so sign up for an account if you have not already done so. After creating a project and device we can provision the PSK-ID/PSK by opening a serial connection to the device.

uart:~$ settings set golioth/psk-id <your-psk-id>
uart:~$ settings set golioth/psk <your-psk>

Here’s the terminal output during my tests:

*** Booting nRF Connect SDK v2.6.99-85097eb933d9 ***
*** Using Zephyr OS v3.6.99-18285a0ea4b9 ***
[00:00:00.538,452] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:00.538,482] <inf> fs_nvs: alloc wra: 0, fb8
[00:00:00.538,482] <inf> fs_nvs: data wra: 0, 68
[00:00:00.538,879] <dbg> golioth_stream: main: Start Golioth stream sample
[00:00:00.539,001] <inf> golioth_samples: Bringing up network interface
[00:00:00.539,001] <inf> golioth_samples: Waiting to obtain IP address
[00:00:01.691,894] <inf> lte_monitor: Network: Searching
uart:~$ settings set golioth/psk-id 20240603190757-nrf9151dk@nrf9151-demo
Setting golioth/psk-id to 20240603190757-nrf9151dk@nrf9151-demo
Setting golioth/psk-id saved as 20240603190757-nrf9151dk@nrf9151-demo
uart:~$ settings set golioth/psk e487ea809e5fa705c2af4050150f822c
Setting golioth/psk to e487ea809e5fa705c2af4050150f822c
Setting golioth/psk saved as e487ea809e5fa705c2af4050150f822c
[00:01:10.748,168] <inf> lte_monitor: Network: Registered (roaming)
[00:01:10.748,901] <inf> golioth_mbox: Mbox created, bufsize: 1232, num_items: 10, item_size: 112
[00:01:12.994,964] <inf> golioth_coap_client_zephyr: Golioth CoAP client connected
[00:01:12.995,025] <inf> golioth_stream: Sending temperature 20.000000 (sync)
[00:01:12.995,269] <inf> golioth_stream: Golioth client connected
[00:01:12.995,269] <inf> golioth_coap_client_zephyr: Entering CoAP I/O loop
[00:01:13.543,975] <dbg> golioth_stream: temperature_push_cbor: Temperature successfully pushed
[00:01:18.544,067] <inf> golioth_stream: Sending temperature 20.500000 (async)
[00:01:20.953,582] <wrn> golioth_coap_client: Resending request 0x2001e2c0 (reply 0x2001e308) (retries 2)
[00:01:23.544,311] <inf> golioth_stream: Sending temperature 21.000000 (sync)
[00:01:25.544,677] <wrn> golioth_stream: Failed to push temperature: 9
[00:01:25.772,186] <wrn> golioth_coap_client: Resending request 0x2001e2c0 (reply 0x2001e308) (retries 1)
[00:01:25.947,631] <wrn> golioth_coap_client: Resending request 0x2001e440 (reply 0x2001e488) (retries 2)
[00:01:30.544,738] <inf> golioth_stream: Sending temperature 21.500000 (async)
[00:01:30.581,359] <dbg> golioth_stream: temperature_async_push_handler: Temperature successfully pushed
[00:01:30.949,401] <dbg> golioth_stream: temperature_async_push_handler: Temperature successfully pushed
[00:01:35.544,952] <inf> golioth_stream: Sending temperature 22.000000 (sync)
[00:01:36.326,812] <dbg> golioth_stream: temperature_push_cbor: Temperature successfully pushed
[00:01:41.326,873] <inf> golioth_stream: Sending temperature 22.500000 (async)
[00:01:42.582,946] <dbg> golioth_stream: temperature_async_push_handler: Temperature successfully pushed
[00:01:46.327,117] <inf> golioth_stream: Sending temperature 23.000000 (sync)
[00:01:46.947,204] <dbg> golioth_stream: temperature_push_cbor: Temperature successfully pushed
[00:01:51.947,296] <inf> golioth_stream: Sending temperature 23.500000 (async)
[00:01:52.718,261] <dbg> golioth_stream: temperature_async_push_handler: Temperature successfully pushed
[00:01:56.947,540] <inf> golioth_stream: Sending temperature 24.000000 (sync)
[00:01:57.663,665] <dbg> golioth_stream: temperature_push_cbor: Temperature successfully pushed
[00:02:02.663,726] <inf> golioth_stream: Sending temperature 24.500000 (async)
[00:02:03.725,708] <dbg> golioth_stream: temperature_async_push_handler: Temperature successfully pushed
[00:02:07.663,970] <inf> golioth_stream: Sending temperature 25.000000 (sync)
[00:02:08.589,111] <dbg> golioth_stream: temperature_push_cbor: Temperature successfully pushed
[00:02:13.589,172] <inf> golioth_stream: Sending temperature 25.500000 (async)

5. View the data sent from the device

In the Golioth web console I can navigate to the LightDB Stream tab for the device and see the data as it arrives on the cloud. Try out Pipelines to transform and send that data to a destination.

A table of temperature data displayed on the Golioth web console

What will you do with the nRF9151?

We see a lot of IoT deployments using the nRF9160 to provide a cellular connection. They’re versatile parts with plenty of peripherals. The new nRF9151 part number is nice for your board footprint, and your power budget. And of course, every fleet needs management and data handling. Golioth already works with this SoC and so many more!

An Internet of Things (IoT) device is a special snowflake of a device (seasonal reference, happy holidays!). It has many more requirements than a piece of hardware that doesn’t connect to the internet. In this post (and the video above), we talk through pitfalls when manufacturing a new piece of electronics. One topic that is particularly important in the IoT space is the provisioning process once a piece of hardware has been manufactured. As it so happens, this is a strength of Macrofab and Golioth working together.

What is Macrofab?

Macrofab is an online service that helps engineers manufacture electronics without the normal back-and-forth with traditional Contract Manufacturers (CMs). They are a web layer on top of two different resources:

  • Their own in-house manufacturing, based out of Houston
  • A range of different CMs, of increasing size and capabilities as you scale

As you decide to build more and more devices, your assembly will be built by larger and larger manufacturing outlets, without any interruption to the workflow that you’re used to. One benefit that I like, and one discussed in the video, is the ability to view different price breaks on an assembled board. Entering different numbers of desired assemblies will trigger recalculation of the end price and lead times:

Pricing 1 unit vs 100 units at Macrofab

Macrofab prices out parts and take things into consideration such as the price break of individual components, as well as targeting different scale manufacturing capabilities (again, all invisible to the user). They have calculated the “per part” cost of attaching the part to a board as well—an 0603 resistor costs less per part than a more complex BGA component which costs less than a hand-soldered connector.

I spoke with Brenden Duncombe, who is the Director of Customer Engineering at MacroFab. On any given day you might find him working with a customer on test fixtures, or helping to improve Macrofab capabilities to make a more seamless hardware ordering experience.

What we are building

You can see an early look at the Aludel Elixir in the video (please note this is Rev A and subject to change…including soldermask color!), but we’re creating a test platform for our reference designs. The Elixir’s predecessor, the Aludel Mini, is featured in many Golioth Reference Design videos and project pages, but it is a combination of different off-the shelf development boards that requires a lot of hand soldering. We wanted something that can be produced in higher volume, as well as including additional hardware that isn’t present on some of the off-the-shelf boards that are available (including extra GPIOs).

 

One benefit for you, the reader, is we will be showcasing a more holistic picture of what it looks like to build an IoT device for production. We still employ Mikroelectronica Click boards to tap into the flexibility of that ecosystem. But more sensors are included “by default” on this board to increase capabilities. We still provide multiple build targets in our reference design repositories, in order to allow people to use entirely off-the-shelf hardware in their own evaluation. We call this “Follow Along Hardware“.

When it came time to build up some early prototypes, Macrofab immediately sprung to mind. I wanted to be able to get budgetary pricing and make decisions around including different parts in a dynamic fashion. I also wanted to hand over the design and feel comfortable sitting back and letting someone else do the work.

Special considerations with IoT

When your electronics assembly rolls off the line and passes all tests…then what? For many test devices we work on at Golioth offices, the next step is to program in a PSK-ID and PSK. That’s an easy way to provision a new device. Also an easy way to re-provision/change things later, which is great in the prototyping stage. Once you get to production, your requirements change. Sure, you get security by default with Golioth, but you also get efficiency and hands-off provisioning onto the Golioth cloud. That’s where certificates come into play. Programming certificates into your brand new devices allows the device to present credentials the first time it connects to Golioth and a new record is created for that device.

Future Testing and BEOL

The “back end of line” (BEOL) testing is something engineers don’t think about unless they are deep into production, but could benefit from some early planning. One thing that Brenden brought up many times was the importance of creating a test fixture from the early days of a prototype. This includes having copious test points and programming pins on your PCB. This is a step that I thought I could skip because I was on my Rev A hardware. I see the value he is mentioning about reliable, standardized testing from day one. As I move into the next revision of hardware, this will be a major consideration, both for at the factory during assembly and once the boards are on my bench trying out new capabilities.

Other elements we’ll be looking into and writing about are things like serialization (adding a serial number to devices) and adding certificates onto devices being made. Golioth doesn’t sell hardware directly, but we expect to be building many more reference designs in the new year. It will make sense to follow our own advice and make a “product”, even if it’s only an internal one.

CMs that have many layers of service

We know and love many CMs in the electronics ecosystem. But we find ourselves gravitating towards the ones that have a structured approach to taking products to market and strong backgrounds in helping engineers build reliable products. We think both of these elements mesh well with Golioth’s principles. If you’re interested in building your next prototype with Macrofab, check out their online capabilities and get started today.

Around these parts, we refer to Golioth as “the Universal Connector”. Our firmware SDK works seamlessly with your firmware project, our cloud APIs are directly mapped to device APIs within the SDK, and that singular connection from device to cloud allows your data to flow unhampered to the rest of the internet. As a result, we are always looking for the most useful services to route your device data to, while also offering you device management and Over The Air updates.

Memfault is a device diagnostics and telemetry platform that we have been friends with for a long time. If you want deep insight into what’s happening with your device in the field, Memfault is a great way to visualize what’s going right and wrong. We know them from their integrations into the Zephyr ecosystem, as well as their great writing on their Interrupt blog. Last month, we co-announced our partnership with them, working with NXP to integrate using the Zephyr Real-Time Operating System.

Golioth enables connections over CoAP to field devices and routes the data out to services like Memfault

Today, Memfault published a joint piece of content with our Cloud Lead, Dan Mangum, that explains more about how data flows through Golioth to the Memfault platform.

See it in action

If you’re anything like me, a live demo really solidifies how a thing works. NXP’s RT10xx family provides a great platform for showcasing Zephyr applications that can route data up to the cloud. We have been partners with NXP since last year and continue to find their software capabilities and seriously powerful processors a great addition to our Continuously Verified Boards, as well as excellent targets for all kinds of applications.

If you like demos, you’re in luck! We’re doing a joint webinar with Memfault and NXP on November 16th at 9 am PST / 12 pm EST / 6 pm CET. Register now to watch it live, or sign up and get access to the on-demand recording if you can’t make it.

Join our live webinar with NXP and Memfault on Thursday Nov 16th

Use this new integration on your project

The capabilities shown in the blog post linked above and during the webinar this Thursday include some functionality that is still in early preview. If you’re interested in having access to Golioth data routing that instantly enables the Memfault, sign up on our page here. You’ll be among the first to know when this capability is available for your projects. In the meantime, you can attend the webinar, try out other projects on Golioth, and discuss your latest IoT experiments on our forum.

Golioth raises $4.6M seed round

Today, we’re announcing open access to a library of new reference designs for embedded engineers to accelerate their time to market, the launch of a Select Partner Program for energy and construction developers, and the completion of a $4.6M round of seed funding led by Blackhorn Ventures and Differential Ventures with participation from existing investors, Zetta Venture Partners, MongoDB Ventures and Lorimer Ventures. We’ve raised a total of $7.1 million to date. 

This funding will help establish our IoT cloud platform more firmly with embedded engineers, and build toward the company’s goal of helping our customers solve the biggest problem in IoT infrastructure – untangling the messy middle between hardware and the cloud.

A fresh look at the biggest problem in IoT

Almost two years ago when Golioth announced our pre-seed funding, We asked ourselves, “How do you bring 30.9B devices online?” 

This question still drives us today. Eventually, almost every device people use will be connected to the internet, no matter where we are or what we’re doing. Our vision is to enable builders to help get us there faster by connecting “sand” to the internet using our platform. 

Today, Golioth empowers engineers to build secure, reliable, and flexible IoT infrastructure so they can connect devices and move from prototype to production in minutes, instead of months. And we’re excited to keep pushing this vision forward.

Solving for the right problems

When we started Golioth, we planned to be an omni-platform that worked with every standard and technology out of the gate. We quickly found out that we didn’t have to be everything for everyone. We could help engineers faster with a narrower focus and extend the platform as we went along. 

More than anything else, engineers struggle with the complexity of connecting their sensors to the web. With limited resources, they must choose between getting a device connected to the internet, or creating a more useful device. And there’s not much time to consider if any of it is secure. 

Our platform is focused on solving that problem. Golioth shortens the time from prototype to production and easily scales that process. This includes tooling and workflows for securing devices, sending software updates over the air, and routing data to the web, all critical problems every IoT developer needs to solve. 

But getting devices online doesn’t start and stop with Golioth. To solve other critical problems developers are facing we’re partnering with leaders across the IoT ecosystem including components manufacturers, developer tools, cloud services, solutions partners, and others. 

In short, engineers do better work, faster with Golioth. 

Helping engineers get ahead with the right references

So what does “building faster” look like? It includes working with partners and companies to build a more resilient platform for industries including climate and energy, shipping and logistics, micromobility, building automation, and others. And with the IoT market expected to hit over $2.7T by 2028, engineers will need a lot of support.

To support embedded engineers in these areas, we created a library of free reference designs using our platform including: 

Golioth’s tight integrations with companies like Nordic Semiconductor, Infineon, NXP Semiconductor, Ubidots and others, lets engineers build with better support, seamless integrations, and faster enablement for all types of projects. In particular we see increasing usage in cellular IoT, 5G, and Thread as the driving force for IoT applications that enable resource efficiency in use cases such as energy and utilities, environmental cases, micromobility and others. 

As part of our seed announcement, we’ve launched a Select Partner Program, which will accept 15 new design partners building solutions for the energy and utility sector, and 15 design partners building solutions for the construction industry by June 1st. To learn more and apply to be a Select Design Partner, go here.

Looking forward to connecting more sand to the cloud, together.

Making sense of IoT sensor data with the Golioth ModusToolbox SDK

Please join us on Wednesday, April 19th 2023 for a webinar about using Golioth to collect IoT sensor data. The session will detail how to use the Infineon ModusToolbox™ to add Golioth device management.

This webinar will include Golioth team members alongside Clark Jarvis, a Senior Staff Technical Marketer at Infineon Technologies. He will present an overview of ModusToolbox™, the software support tool that helps combine and configure multiple repositories into a single embedded device firmware project. We’ll then demonstrate how to get a PSOC™ 6 connected via WiFi and streaming IoT sensor data back to Golioth.

What to Expect from this Webinar

As always, Golioth loves to present dynamic and interactive webinars. (No one will be reading Powerpoint slides in a monotone voice here!) The session will cover:

  • An overview on using ModusToolbox™
  • How to add software libraries with ModusToolbox™
  • How to use Golioth SDK functions to send time-series and stateful data to the cloud
  • How to view and interact with IoT data on the cloud-side
  • An overview on techniques for building scalable IoT Fleets

Sign up now!

This webinar is at 12 pm EDT / 9 am PDT on April 19th, 2023. If you can’t make it the day of, you can still still sign up to access the on-demand content. Those who attend will have an opportunity to ask questions towards the end of the presentation.

 

We’re excited to announce a partnership between Golioth and Nordic Semiconductor. As long-time fans of and friends with Nordic Semiconductor, we officially joined as a Solution Partners in the Nordic Partner Program in 2023.

Nordic Semiconductor parts and development kit solutions work well with the Golioth platform, many of which are featured throughout this blog and in our documentation. Briefly:

  • nRF9160-DK is a continuously verified board that we use to test and deploy cellular applications on Golioth.
  • nRF52840-DK is a Continuously Verified Board when used in conjunction with an add-on Wi-Fi modem.
  • nRF52840 chipset is the basis of our OpenThread-based demos, which connect back through Linux-based Border Routers.
  • The recently released nRF7002 already works on Golioth in conjunction with the nRF5340.

Our customers are also well-versed in using Nordic Semiconductor components. One of our largest clients in the micromobility space is using the nRF9160 for connectivity over cellular. Another is using the nRF52 using Thread to network devices in the commercial real estate space. Both of these customers cited ease-of-use and tight coupling of Golioth services with Nordic hardware in their decision to pursue their hardware and IoT path.

What this partnership means for you

We’re taking our collaboration to the next level with faster enablement, seamless integrations, and more comprehensive training.

By partnering with Nordic Semiconductor, we’ll be able to offer a more comprehensive suite of IoT solutions than ever before. As new elements and components are introduced by Nordic Semiconductor, we will enable these technologies on the Golioth platform even quicker.

We are working on integrating cloud components to make it a seamless process to consume Nordic data for your products and act at the device level on that data.

Our training is migrating to use Nordic Semiconductor components so that we can offer direct training in Zephyr using Golioth and the nRF Connect SDK. All of these will enable our customers to accelerate their IoT projects, reduce development costs, and bring their products to market faster.

For customers who are new to Golioth, but longtime users of Nordic Semiconductor components, they will see immediate benefit to trying out our IoT Platform with their hardware. Pulling in Golioth as a feature of a nRF Connect SDK (Zephyr) project gives access to features like:

We believe that this partnership will drive innovation in the IoT space. By working together, we’ll be able to push the boundaries of what’s possible in IoT and create solutions that are more secure, reliable, and scalable than ever before. We’re excited to see what we can accomplish together, and we’re confident that our customers will benefit greatly from this partnership.

Partnership, in action

We showcased our Reference Designs at Embedded World 2023. Each of these solutions integrated the nRF9160 cellular SIP, in addition to customized sensors. The direct integration into the Golioth / Zephyr SDK meant development time was minimal for each additional design. Our team was able to create designs targeting a wide range of customer verticals, all using the same great underlying hardware.

Golioth Reference Designs using the Nordic Semiconductor nRF9160 at Embedded World 2023

At Golioth, we’re committed to providing you with the best possible IoT solutions. Our partnership with Nordic Semiconductor is a major step forward in achieving that goal. We’re excited to continue working closely with the teams at Nordic Semiconductor headquarters and their various FAEs throughout the world to develop and deliver innovative IoT solutions to our customers. Stay tuned for more updates as we continue to push the boundaries of what’s possible in IoT.

We are excited to announce a partnership between Golioth and NXP Semiconductor. The result is a leap forward in your IoT design that will save you time while preparing your fleet to scale.

NXP’s line of Ethernet-enabled parts are feature rich and well supported in the Zephyr ecosystem. When paired with the next-generation device management tools from Golioth, you get to skip the awkward growing pains in IoT. Power up your first proof of concept hardware and immediately do something meaningful with it from the Cloud side. Your i.MX RT based devices will suddenly include Over-the-Air (OTA) updates, command and control, data management, remote logging, and more.

Built on Zephyr

NXP development board

NXP i.MX RT1060 EVKB development board

NXP is a founding and platinum member of the Zephyr project. The engineering team at NXP has spent years actively developing the RTOS. When you choose to build around an NXP part, you can expect excellent stability and up-to-date functionality with Zephyr. This meshes perfectly with Golioth’s embrace of the Zephyr platform (we are silver members of the project).

Mike previously wrote about how much we enjoy working with the MIMXRT1060-EVKB board. As part of this new partnership, we’re excited to add it as a Continuously Verified Board (CVB) on Golioth. This means that our engineering team thoroughly tests this hardware against every release, and we’ve even included it in our Hardware-in-the-Loop (HIL) testing that runs with every commit. You will always enjoy the latest and greatest Golioth support on this hardware.

NXP hardware is industrial at heart

The RT106x line of chips are some of the most powerful microcontrollers on the market. With a 600 MHz clock and huge range of peripherals (CAN, USB, audio, video, display), it is as large a system you might get without a jump to Linux. For the vast majority of IoT applications, operating without Linux is ideal. For instance, as a microcontroller, the RT106x delivers lower-latency response, low-power operation, and it will save on your Bill of Materials (BOM) cost.

If you’re contemplating connectivity in an industrial setting, it’s hard to beat NXP chips with their built-in Ethernet. From a development board standpoint, the EVKB is a great bet. You can use the built-in magnetics and jack for Ethernet, or pop a WiFi module into the m.2 slot. There’s a 20-pin J-Link programming header or you can flash the J-Link firmware to the on-board debugger and it’s ready to program via USB. Since this board has great Zephyr support, the west flash command is all it takes to flash the compiled binary.

Golioth enables microcontroller platforms, large and small

Golioth has already built all of the device management features your IoT fleet needs. Not only for your test fleet in the lab, but for when you scale to millions of devices. It starts with a connection to the cloud that is secure by default. Over this connection we make it easy to perform OTA firmware updates, even on fleets made up of multiple hardware configurations.  Golioth is designed for fleets of constrained devices, so efficient delivery of updates and data are top of mind for all features we provide.

What happens when a device in the field starts acting odd? Remotely adjust the logging levels so you get more information on the problem, or use a remote procedure call (RPC) to reboot.

Now you’ve discovered you need your fleet of 10,000 devices to take sensor readings twice as frequently. If you’re using the Golioth Settings Service, that’s a one-click change that can modify unit. If you’re not using the Settings Service, push an OTA update to enable it… now it’s a one click change.

And what about all that data? Do you have a plan to keep the data from your devices in Decatur, Texas organized and easy to query separately from the devices in Decatur, Georgia? We do, with our flat system of tagging devices in our fleet management console.

These are problems that everyone building IoT must address. Why boostrap your own device management when Golioth makes it secure, dependable, and easy? Take Golioth for a test-drive. With our Dev Tier your first 50 devices are free.

In partnership for you

The combination of great hardware and an excellent device management cloud means a rock-solid base to build from. Choose NXP hardware, take advantage of Golioth, and focus your time on creating a superb product for your company.

Learn more about our partnership on the Golioth site as well as the NXP site.

 

How to use Ubidots data visualization

Golioth and Ubidots have teamed up to make it easy to visualize your Internet of Things device data. Ubidots makes it easy to white-label visualizations to produce a branded version of your service for end customers; you can also create end-users, in order to allow access to custom dashboards.

Our partnership has produced an integration that makes it a snap to connect your device data to an Ubidots dashboard so that it looks great for you and for your clients. Today I’ll walk you through the process of setting up a connection.

Ubidots data visualization dashboard

What you need to get started

To get started you just need a few basic things:

  • An account on Golioth (sign up)
  • An account on Ubidots (sign up)
  • A device that is sending data to Golioth

Creating your accounts is pretty easy; Golioth has a free dev tier, and Ubidots has a free Educational/Personal use option or a free trial period for their Business users. Everyone who has followed our Getting Started guide will already has a Golioth account.

If you don’t already have a device set up to send data, you can use the Golioth LightDB Stream example. It will simulate temperature data and send it back to the Golioth Cloud, a perfect dataset for your first Ubidots dashboard!

Setting up a connection between Golioth and Ubidots

To connect Golioth and Ubidots we need to take the follow steps:

  1. Configure an Ubidots plugin
  2. Configure a Golioth output stream
  3. Set up an Ubidots dashboard

1. Configure the plugin in Ubidots

Ubidots has a plugin specifically for Golioth. But before configuring the plugin we want to make sure we have a token to use for this project. From the Ubidots dashboard, click your profile picture in the upper right, choose API Credentials and click More under the tokens menu that appears. This will open the API Credentials page.

How to create an ubidots token

Use the plus sign to add a new token, then use the pencil icon to edit the name of the token.

Next, choose DevicesPlugins from the top menu. Click the plus to add a plugin, and choose Golioth. Click the arrow icon to get to the plugin configuration menu.

Choose the token you just created from the dropdown menu. In the LightDB Stream field, use the name of the endpoint where your device is sending data.

If you have a nested JSON, like {"env":{"temp":20.5}}, then you would set this value to “env” and the Ubidots plugin would pick up all of the key/value pairs inside of that JSON object.

If you are following along with the Golioth Stream sample, leave the LightDB Stream field blank, since we publish to the root-level directly. You can see in the code example below, we are setting the temperature value to the root-level “temp” key.

err = golioth_lightdb_set(client,
			GOLIOTH_LIGHTDB_STREAM_PATH(&amp;amp;quot;temp&amp;amp;quot;),
			COAP_CONTENT_FORMAT_TEXT_PLAIN,
			str_temperature,
			strlen(str_temperature));

Click the right arrow, give your plugin a name and description, and click the check mark icon to save. You will be redirected to a list of your plugins.

[screenshot]

Click on the one you just created and then select Decoder from the left sidebar.

Generally speaking, this page is already configured to work. We need to copy the Ubidots HTTPs Endpoint URL and use it to create a Golioth Output Stream in the next step.

If you want to learn more about the data format so that you can customize the decoder on this page, look at the DeviceStreamMessage in our Event Types documentation. For today’s example, the defaults will work.

2. Configure a Golioth output stream

Choose Ubidots as Output Stream

In the Golioth Console, select Output Streams from the left sidebar, click on Create an Output Stream, and choose Ubidots from the list.

Give your new Output Stream a name, and choose DEVICE_STREAM_TYPE as the event filter. The HTTPS Endpoint URL comes from the Ubidots dashboard. So does the auth token, which you can copy from the Ubidots dashboard by clicking your avatar in the upper right and choosing API Credentials(this reveals a panel that lets you copy tokens to the clipboard). Click save to finish setting up your Output Stream.

3. Set up an Ubidots dashboard

We’re ready to start visualizing! At the top of the Ubidots dashboard, select DataDashboards. You can create a new dashboard using the icon (sometimes called a “hamburger menu”) in the upper left.

On your new dashboard, click Add new Widget and choose a Gauge from the list.

Ubidots dashboard gauge settings

In the data section, click Add Variable, choose your device, and select the data you want to show. If your device is not listed, the endpoint may be configured wrong, or the device has not yet sent any data. There is a Logs section in the Ubidots plugins settings page that will be helpful in troubleshooting the issue.

The rest of the settings in this dialog decide how your data will be displayed. Set the name of the widget, and choose the range that suits you best before clicking the check mark icon to save the changes.

Temperature gauge

Now you have a gauge that shows temperature readings from your device. Of course there are many other visualization methods available to match your needs, so spend some time playing around with your new Ubidots dashboard!