,

All Golioth Hardware is Now Open Source

Golioth is all about sharing ideas and knowledge. This now includes our hardware, which today has been released as open source under the CERN OHL-P license. The Aludel Elixir and Ostentus are available on GitHub as KiCad projects and you can use them to start building your own designs.

The Aludel Platform

As an IoT platform that doesn’t build or sell commercial hardware, we still need to find ways to highlight the capabilities our platform offers. This often includes building on top of development boards from our various partners. Engineers are used to starting from well known vendor platforms, like some of our favorites which are in the list of Continuously Verified Boards (CVBs) on the Golioth platform:

When you’re ready to start building devices that look more like real-world products, however, it becomes a bit bulky to use the easy-to-access development platforms. We knew we wanted to capture this “magic in a box”, which was the genesis of the name — an “aludel” was a sublimating pot in alchemy.

We started using alternative boards like the nRF9160 Feather from Circuit Dojo and encapsulating the Feather form factor in a box. The early Aludel boxes were much larger and included headers to plug in different boards. Over time, we knew we wanted to more closely approximate designs that will go out into the field, so we downsized to the current ‘Mini’ version that utilizes the Bud Industries CU-1937-MB Utilibox and then we started modifying it and adding 3D printing elements. That formed the basis of the new Aludel platform, which includes two boards we’re releasing today.

Elixir


The Elixir Hardware Repository is now open source on GitHub

The Elixir board is a natural offshoot of the Aludel Mini form factor, including the new case we adopted. We had first created a board called the aludel-mini which you’ll see mentioned in some of our reference design repositories. This was an interposer board between a soldered down nRF9160 Feather and some mikroBUS Click headers. However, we started to experience some limitations with how the board operated and wanting to add other features. This is when we planned to build the Elixir.

The Elixir has many of the same elements from the OSHW Feather board, and adds on new capabilities that are common to many of our designs:

  • nRF9160 – Cat M1 / NB-IOT / GPS chip with dual core Cortex M33 processing
  • ESP32-C3 – Running ESP-AT firmware, interfaced to the nRF9160 over UART
  • BME280 – Weather sensor from Bosch, common to many Golioth designs
  • Power
    • Low quiescent buck circuit, inherited from Feather Board
    • 5V boost to service the 5V output on the mikroBUS
    • Battery charging
    • Fuel gauge
    • High voltage input (5.5V to 48V) for powering from things like OBD-II and industrial supplies
  • LIS2DH – Accelerometer, inherited from Feather board
  • PWM Buzzer – Allow audible indication similar to the Thingy91
  • Real Time Clock
  • Secure Element (ATECC608B)
  • Power Switching – Power switch of 3V3 for sensor nodes to shut down in low power situations
  • QWIIC / STEMMA Headers – External sensors and peripherals including the Aludel Ostentus
  • mikroBUS headers
  • USB C interface and power
  • External SIM connector
  • Multiple programming interfaces
    • 10 pin SWD (02×05 .127mm pitch), accessible from outside the case
    • 10 pin SWD Tag-Connect (accessible from the top side of the board)
    • USB using the serial bootloader / MCUBoot

Ostentus


The Ostentus Hardware Repository is now open source on GitHub

Early Reference Designs were simply aludel-mini boards in the Utilicase. We utilized vinyl stickers to differentiate between designs, but this didn’t have the impact we were looking for when we went to tradeshows or shared photos on our projects site. What’s more, it didn’t represent a product that might be on-site at an industrial facility (more on the ‘field readiness’ in a bit).

If you walk up to a sensor monitor at a plant, you likely don’t want to pull out a phone and require a network in order to interact with the device in front of you. Having a simple, power efficient, persistent display that is visible in high brightness environments felt really useful. In fact, our early design hypothesis is that you’d still want to have readings on the screen, which is why the Ostentus continues displaying data even when the QWIIC header has been powered down from the main board (in low power modes). That trick is handles using ePaper displays.

Over different iterations we added other capabilities to allow user interactivity. Capacitive touch buttons around the bezel of the screen and an accelerometer for sensing double tap actions through the case deliver user input in the field.

  • Raspberry Pi Pico – Originally chosen during the part shortages of 2022-23, the RP2040 on the Pico provides a low cost solution including a programming interface over the USB port + MicroPython ease-of-use
  • ePaper interface – This design was derived from the Pimoroni Badger 2040 and that had a reference circuit for interfacing to a Good Display 1.54in square ePaper display (not cheap!)
  • Accelerometer (LIS2DH12) — Currently unimplemented but targeting “double tap” behaviors in the future
  • 3 button capacitive touch controller (CAP-1203-1)
  • QWIIC header for incoming power and i2c
  • Downward firing LEDs

Two critical pieces of firmware power this part of the platform. We utilized i2c in order to cut down on the number of I/O required on the main board (in this case the Elixir) and also to abstract it for future boards that might differ from the Elixir:

License and certification

These designs are being released under the CERN Open Hardware License – Permissive, version 2. This is one of the most permissive hardware licenses available. This board has not yet been certified by OSHWA, but we believe the hardware and files comply with the OHSWA definition. No FCC, CE, or cellular carrier certification is guaranteed with these boards and users should expect to take any resulting product through the proper regulatory channels.

Field Readiness

One thing to note is that the Ostentus plus the cut-out version of the Bud Industries case results in an unrealistic deployment option for the platform. I would never feel comfortable sending these boards out into a harsh environment, let alone a slightly damp one, due to the fact that there are gaps in the case and there is no IP rating. However, we didn’t design it for high reliability or even production: the Aludel platform is truly to showcase the widest variety of use cases and maximum flexibility.

This is why you’ll often hear us discussing how this is an “80% done design”. We expect our users to take these designs and shrink them, harden them for environments, and extend them for specific use cases. This could also include doing rounds of Design for Manufacturing (DfM), doing cost optimization, and improving testing for high volume production. Also important are taking the designs through FCC Part 15B certification and any required cellular carrier certification (which depends on which carrier you use and their requirements).

All of those things are left to you, dear reader. We followed the best design practices that we know, though we are always open to learning more and receiving feedback on our forum and issues filed on our GitHub repositories. You can start to evaluate whether this custom hardware is the right path by starting from our range of Follow-Along Hardware and open source firmware on the Golioth Reference Design Project site.

/by
, , ,

OpenThread Demo: From Cellular to Thread with Zephyr

Golioth is expanding its Reference Design portfolio by adding an OpenThread Demo, a Reference Design based on our known and well-tested Reference Design Template. The purpose of the OpenThread Demo is to add Thread networking capability to the RD Template so anyone using Thread and Golioth can start development immediately, use it as a basis for their project, and take full advantage of Golioth’s Device Management, Data Routing, and Application Service capabilities.

Thread Recap

Thread is an IPv6-based networking protocol designed for low-power Internet of Things devices. It uses the IEEE 802.15.4 mesh network as the foundation for providing reliable message transmission between individual Thread Devices at the link level. The 6LoWPAN network layer sits on top of 802.15.4, created to apply Internet Protocol (IP) to smaller devices. In almost all cases, it’s used to transmit IPv6 Packets.

If you need a network of devices that can communicate with each other and connect to the Internet securely, Thread might be the solution you’re looking for.

Built it yourself

The follow-along guide shows how to build your own OpenThread Demo using widely available off-the-shelf components from our partners. We call this Follow-Along Hardware, and we think it’s one of the quickest and easiest ways to start building an IoT proof-of-concept with Golioth.

Hardware

Every mesh network needs some hardware, and for the OpenThread Demo, you will need a Thread Border Router and a Thread node. This demo doesn’t need additional sensors or an actuator, as there are generated values created by the code in the Reference Design Template (ie simulated values). Later you can modify our other Reference Designs and their hardware to get to a prototype or production device that is more specific to a vertical like Air Quality Monitoring or DC Power Monitoring.

Border Router

A Thread Border Router connects a Thread network to other IP-based networks, such as Wi-Fi or Ethernet, and it configures a Thread network for external connectivity. It also forwards information between a Thread network and a non-Thread network (from Thread nodes to the Internet). The Border Router should be completely invisible to Thread Devices, much like a Wi-Fi router is in a home or corporate network.

In this demo, we use a commercially available GL-S200 Thread Border Router designed for users to host and manage low-power and reliable IoT mesh networks.

GL-S200 provides a simple Admin Panel UI to configure the Border Router and a Topology Graph to see all the end node devices and their relationship. As a bonus, it also does NAT64 translation between IPv6 and IPv4, making it a real plug-and-play solution.

 

Thread Node

Now that the centerpiece of our Thread network is sorted, the next part is a Thread node. In the follow-along guide, we built a Thread node based on the nRF52840 DK. The node is built using Zephyr, and the OpenThread stack will be compiled into it. The GitHub repository used in the guide is open source, so you can build the application yourself, or you can use the pre-built images for the nRF52840 DK or Adafruit Feather nRF52840.

Firmware

Thread node firmware is based on the Reference Design Template, a starting point for all our Reference Designs. With all Golioth features implemented in their basic form, you can now use Device Management, Data Routing, and Application Services with Thread network connectivity.

OTA Updates

Adding Thread support to a device is not cheap, memory-wise. The firmware image is larger than 500kB, and the on-chip flash of the nRF52840 DK has a size of 1MB. Luckily, both the nRF52840 DK and the Adafurit Feather have an external flash chip, making the OTA updates possible. Any custom hardware you create in the future should also follow this model of having external flash mapped to the nRF52840.

To create a secondary partition for MCUBoot in an external flash, we must first enable it in the nrf52840dk_nrf52840.overlay file:

/ { 
    chosen { 
        nordic,pm-ext-flash = &mx25r64; 
    };
};

The CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARYKconfig option is set by default to place the secondary partition of MCUboot in the external flash instead of the internal flash (this option should only be enabled in the parent image).

To pass the image-specific variables (device-tree overlay file and Kconfig symbols) to the MCUBoot child image, we need to create a child-image folder in which we  need to update the CONFIG_BOOT_MAX_IMG_SECTORS Kconfig option. This option defines the maximum number of image sectors MCUboot can handle, as MCUboot typically increases slot sizes when external flash is enabled. Otherwise, it defaults to the value used for internal flash, and the application may not boot if the value is set too low. In our case, we updated it to 256in the child_image/mcuboot/boards/nrf52840dk_nrf52840.conf file.

CONFIG_BOOT_MAX_IMG_SECTORS=256

Connecting to Golioth Cloud

Thread nodes utilize IPv6 address space, and the question is how to communicate with IPv4 hosts, such as Golioth Cloud.

Golioth Cloud has an IPv4 address, and the Thread node needs to synthesize the server’s IPv6 address in order to connect to it. OpenThread doesn’t use the NAT64 well-known prefix 64:ff9b::/96; instead, Thread Border Routers publish their dynamically generated NAT64 prefix used by the NAT64 translator in the Thread Network Data. Thread nodes must obtain this NAT64 prefix and synthesize the IPv6 addresses.

While the process of synthesizing IPv6 addresses is automatically handled in the OpenThread CLI when using the Zephyr shell and pinging an IPv4 address (e.g. ot ping 8.8.8.8), it’s important to note that this process needs to be specifically implemented in applications.

As part of the Firmware SDK, the Golioth IPv6 address is automatically synthesized from the CONFIG_GOLIOTH_COAP_HOST_URI Kconfig symbol using the advertised NAT64 prefix by leveraging the OpenThread DNS. Even if the Golioth host URI changes within the SDK, you won’t need to change your application.

Learn more

For detailed information about the OpenThread Demo, check out more details the project page! Additionally, you can drop us a note on our Forum if you have questions about this design. If you would like a demo of this reference design, contact [email protected].

 

/by
, ,

Nordic Webinar with Golioth on June 20th, 2024

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!

/by
,

Modbus Vibration Monitor: A Golioth Reference Design

Today, we’re announcing a new Modbus-based reference design targeting industrial vibration monitoring solutions: the Golioth Modbus Vibration Monitor.

Many modern industrial facilities are turning to predictive maintenance strategies to increase uptime and reduce the cost of maintenance programs. Core to these strategies is condition monitoring, a maintenance approach that uses data collected from sensors to continuously monitor machine “health” and predict failures.

For rotating machinery—e.g. motors and turbines—the analysis of vibration data (vibration diagnostics) has proven to be the most effective method of condition monitoring and early fault detection. By continuously comparing the measured vibration signature against the “natural” vibration signature of the equipment, it’s possible to detect premature failure conditions due to shaft misalignment, rotor balance issues, bearing failures, etc.

Modbus Vibration Monitor

In this reference design, we demonstrate how to build a remotely-managed Industrial IoT vibration monitor designed for rotating machinery.

Firmware

The Modbus Vibration Monitor firmware uses the Golioth Zephyr SDK to securely connect to the Golioth Cloud.

Periodically, the device reads temperature and vibration measurements from an off-the-shelf Banner QM30VT industrial vibration sensor using the Modbus protocol.

(Note that with Modbus, it’s possible to target a wide range of different industrial sensors. The Banner sensor is simply a starting point for this example.)

It then streams these vibration measurements directly to the Golioth Cloud over a cellular LTE connection, enabling the device to operate without connecting to internal facility networks.

The firmware source code for this reference design is available on GitHub at the following URL:

https://github.com/golioth/reference-design-modbus-vibration-monitor

Hardware

The vibration monitor hardware is built using the Golioth Aludel Mini prototyping platform. Additionally, it includes the Ostentus front panel featuring an ePaper display for sensor readings, back-lit LED indicators, and capacitive touch buttons.

Inside the box is the custom-designed Aludel carrier board. Specifically, the carrier board integrates a SparkFun nRF9160 Thing Plus cellular LTE module and a MikroE RS485 8 Click board.

The off-the-shelf Banner QM30VT Modbus vibration sensor connects to the Aludel platform via an industrial cabling system with M12 connectors. Although we’re using the QM30VT vibration sensor in this reference design, we can easily connect any other industrial RS-485 sensor to this design using the same M12 connector interface.

Cloud Management

The Golioth Cloud provides all the services needed for deploying and remotely managing a fleet of condition monitoring devices:

  • LightDB State: bidirectional real-time device state database
  • LightDB Stream: database for storing time-series data
  • Logging: centralized device log storage
  • Settings: device settings management
  • OTA: over-the-air firmware updates with one-click rollback

You can manage devices by logging into the Golioth web console, as well as using the REST API or the Command Line Tools.

Data Visualization​

The Golioth REST API makes it easy for external applications or services to access the sensor data streamed from devices.

For example, we created a Grafana dashboard that displays the temperature & vibration measurements reported by each device:

Build it yourself

What’s more, you can build your own Modbus Vibration Monitor using widely available off-the-shelf development boards from our partners!

We call this Follow-Along Hardware, and we think it’s one of the easiest ways to get started building an IoT proof-of-concept with Golioth.

Specifically, you will learn how to assemble the hardware, flash a pre-built firmware image onto the device, and connect to the Golioth cloud in minutes. The follow-along hardware runs the same open-source firmware as the custom Golioth hardware described above. We also provide instructions for building the firmware yourself if you want to make changes for your specific application.

We are releasing the nRF9160 DK Follow-Along Hardware Guide today, and plan to add support for additional development kits soon.

Project Page

For detailed information about the Modbus Vibration Monitor reference design, check out the project page at the following URL:

https://projects.golioth.io/reference-designs/modbus-vibration-monitor/

Additionally, you can drop us a note on our Forum if you have questions about this design.

Finally, if you would like a demo of this reference design, contact [email protected].

/by

OBD-II / CAN Asset Tracker: A Golioth Reference Design

Organizations that manage fleets of vehicles are increasingly turning to IoT solutions to enable real-time management and monitoring across their entire fleet. Analysis of the data provided by IoT telematics can provide valuable insights that can be used to improve operations efficiency, increase safety, and assist in maintaining regulatory compliance.

Golioth makes it easy to prototype, deploy, and manage vehicle telematics solutions: connect and secure devices, send vehicle data to the web, update device firmware Over-the-Air, and scale your fleet with our instant IoT cloud.

OBD-II / CAN Asset Tracker

This reference design provides an end-to-end “proof of concept” showing how to securely stream real-time vehicle location and speed data to the Golioth cloud. We also provide an example of how to use the Golioth REST API to display this data in an external online dashboard.

We started with our existing Cold Chain Tracker reference design and added a controller area network (CAN) interface, enabling the device to communicate on a vehicle’s CAN bus. We initially wanted to make a “generic” CAN asset tracker that could work with any vehicle. However, for passenger cars, each manufacturer defines its own standard for the higher-layer protocols used on the CAN bus. To decode the raw CAN bus data into physical values that could be displayed in an online dashboard, we would need to use a proprietary “DBC” database file, which are not typically published by the vehicle manufacturers.

Thankfully, most modern cars have a legally mandated on-board diagnostic interface known as OBD-II. Since 2008, a CAN-based protocol (defined in ISO 15765) has been the mandatory protocol for OBD-II in all cars sold in the US. Other standards (SAE J1979/ISO 15031-5) define a set of OBD-II Parameter IDs (PIDs) which are required to be supported across manufacturers. These PIDs provide a standardized way for diagnostic test equipment to monitor real-time data like the vehicle speed or engine RPM.

To enable the OBD-II / CAN Asset Tracker to work generically across vehicle manufacturers, the hardware connects to the standard OBD-II port in a vehicle, and the firmware requests the “vehicle speed” PID via the OBD-II CAN protocol. The vehicle speed is combined with precise GPS location/time data and streamed back to the Golioth Cloud via a low-power LTE cellular connection.

While the example firmware in this reference design has been tailored specifically for use with the OBD-II protocol, the same underlying hardware, Zephyr RTOS, and Golioth Zephyr SDK can be used to build connected devices that support any CAN-based protocol. This includes J1939 for heavy-duty vehicles, CANopen for industrial machinery, and NMEA 2000 for maritime vessels.

Hardware

The OBD-II / CAN Asset Tracker hardware is built using the Golioth Aludel Mini prototyping platform, which integrates an Adafruit Feather-compatible processor module and two MikroE Click sensor boards into a compact enclosure. We designed this platform to demonstrate how it’s possible to quickly develop a proof-of-concept using widely available off-the-shelf modules.

It also includes the new Ostentus front panel that provides an ePaper display for sensor readings, back-lit LED indicators, and capacitive touch buttons.

For low-power cellular connectivity, we’re using the same SparkFun nRF9160 Thing Plus module used in other Golioth reference designs (such as the IoT Trashcan Monitor). This feather-compatible module integrates the Nordic nRF9160 System-in-Package (SiP), featuring an ARM Cortex-M33 application processor, an integrated LTE modem, and a GNSS receiver for cellular-based location-tracking. The nRF9160 is fully supported in Zephyr, and has the highest level of support in the Golioth platform (Continuously Verified).

This reference design integrates two off-the-shelf MikroE Click sensor boards:

  1. GNSS 7 Click board with a u-blox NEO-M9N GNSS module
  2. CAN SPI Click 3.3V board with a Microchip MCP2515 CAN controller & TI SN65HVD230 CAN transceiver

Check out the Project Page for the full parts list.

Firmware

The firmware for this reference design uses the Golioth Zephyr SDK to implement device management features. This includes device authentication, streaming sensor data to Golioth’s LightDB Stream time-series database, logging, and over-the-air (OTA) firmware updates.

The Golioth Settings Service is used to implement custom run-time configurable device settings that can be managed from the Golioth Cloud. Settings can be configured at the project or individual device level and can be managed via the web console or the REST API.

For example, the OBD-II / CAN Asset Tracker firmware implements a VEHICLE_SPEED_DELAY_S setting that controls how often the vehicle speed is requested from the OBD-II port.

The firmware also uses the Golioth LightDB State service. We’re using this reference design at trade shows and for customer demos in conference rooms where it’s not always possible to get a GPS signal. As a fallback, we can set a “fake” GPS location in the Golioth Console, and the device will use that location when a real GPS location is not available.

Finally, the firmware implements the Golioth Remote Procedure Call (RPC) service. For example, the set_log_level RPC command can be called to enable debug logging for a specific device.

Cloud

The Golioth Cloud provides a tightly integrated set of services specifically designed for managing fleets of IoT devices at scale:

  • LightDB State: bidirectional real-time device state database
  • LightDB Stream: database for storing time-series data
  • Logging: centralized device log storage
  • Settings: device settings management
  • OTA: Over-the-Air firmware updates with one-click rollback

You can access these services by logging into the Golioth web console, or programmatically from an authenticated device via the REST API or the Command Line Tools.

Data Visualization

The Golioth REST API makes it easy for external applications or services to access the sensor data streamed from the devices to the LightDB Stream time-series database.

We created a Grafana dashboard that displays the vehicle location and speed sent by each device:

More Information

For more information about the OBD-II / CAN Asset Tracker reference design, check out the project page:

https://projects.golioth.io/reference-designs/can-asset-tracker/

Please contact [email protected] for access to the hardware design files and firmware source code for this and other Golioth reference designs. You can also drop us a note on our Forum or on our Discord if you would like to suggest ideas for other IoT reference designs you would like to see us build.

/by

DC Power Monitor: A Golioth Reference Design

How full is your battery? How much current is your USB device drawing? What is your energy usage of your bank of devices?

Gaining granular feedback on your electricity usage is a valuable tool. We have previously discussed this as part of our AC Power Monitor. We took that concept and extended it for DC Power Monitoring. The changes were surprisingly simple, but open up a whole world of new applications.

DC Power Monitor vs AC Power Monitor

Because there are so many similarities between these reference designs, we thought it would be useful to compare and contrast. We’ll talk about some of the differences implemented below, but first off, a quick discussion about differences in how we measure power.

In AC Power Monitoring, it’s “non-contact”. The power passing through AC wires can get up to considerable amounts, and often we don’t want to measure this “in line”. Also, it’s often not a requirement to have precise measurement levels. In both of these scenarios, we can get away with using a current clamp, which uses the magnetic fields around a wire to induce a reference current, and then couples that reference into a secondary measurement circuit.

DC Power doesn’t have the same characteristics. Though there is a magnetic field that develops around a wire, the non-alternating nature of DC current means it is not possible to stimulate a current in the secondary of a measurement circuit using an inductive element. Instead, we need to measure current “in-line”, which means the current we’re measuring passes through a resistive element and we measure the voltage that develops across that resistor. The benefit is we can measure much lower current and get better resolution. This is what we were doing when we did a webinar about measuring power consumption of cellular in different modes. Now we’re taking that same idea and scaling it up for higher current devices like battery charging or measuring power consumption of a USB device.

In both designs, two channels stream readings back to Golioth where they are stored along with their timestamp. The power monitor tracks “run” time—how long the device being monitored has been running without a break. The system also records the cumulative “run” time so that you can track the service life of your equipment. This data is invaluable in planning maintenance and identifying the most used equipment to inform future investment in your production abilities.

Hardware

We were mostly swapping out Click headers when we converted this from an AC measurement device to a DC measurement device. We also added a new “quick disconnect” cabling setup to make it easier to transport demos to conferences.

The full parts list is on our Golioth Projects page, but the new element used to measure current “in-line” is the MikroElectronika VCP Click, which is based around the INA260AIPWR from Texas Instruments. The datasheet calls out a range of target applications, which could be rich areas to target with this overall reference design:

  • Test Equipment
  • Servers
  • Telecom Equipment
  • Computing
  • Power Management
  • Battery Chargers
  • Power Supplies

This class of chip is well suited to measure DC power and includes a voltage measurement circuit. Since it’s on the i2c bus, retrieval of measurements is quite easy. The driver for this chip is not in-tree for Zephyr, so it came down to i2c calls from our Zephyr firmware.

The cellular modem (nRF9160) is one of our best supported parts on Golioth and is powered from both a local power supply and a lithium battery so that power outages can be remotely detected.

Firmware

The primary changeover from AC to DC power monitoring was the code to extract readings from the VCP Click, mentioned above. After that, most of the rest of the plumbing was left in place.

Much like the AC Power Monitor, the firmware for the Power Monitor reference design uses the Golioth Settings Service. This service can update a single device’s settings, and also provides fleet-wide control via our web console (and our REST API if you need it).

Golioth Settings Service for the Power Monitor reference design

Golioth Settings Service for the Power Monitor reference design

Here you can see the loop delay which indicates how long the device should sleep between sensor readings (in seconds). There is also an ADC “floor” setting available for each channel. This accommodates equipment that has some current draw when in standby mode, allowing you to configure the threshold at which the machine is consider to be running.

All of the Golioth reference designs include Over-the-Air (OTA) firmware updates. Though it was not the case when we built it, it’s feasible that we could have instructed a technician to swap out the Click headers and we could have pushed an OTA update and changed a device from AC to DC in the field. Modular hardware paired with an OTA system creates an endlessly customizable end product.

Cloud Software / Dashboard

A quick recap of the features in both the AC and DC Power Monitor designs:

  • Sensor readings are stored as time-series data on LightDB Stream
  • Device settings are monitored in real-time, with the device reacting to your changes as soon as you make them.
  • The Golioth Console tracks the latest device state, including device health
  • Current firmware version is monitored, with the ability to rollout new OTA updates, and one-click rollback if you need it
  • Golioth’s convenient REST API delivers easy access to the data for visualization or export to any of your favorite cloud server platforms.

Our Grafana interface looks a little different than before, namely in the units we’re tracking (DC Power Monitor envelopes are much smaller) and the background image:

More Golioth Reference Designs

A recent refresh to the Golioth Projects page shows the range of different Reference Designs we make available for our customers. We continue to add new designs and would love to hear about application spaces we could target next. Reach out on our forum or over email if you’d like to send us suggestions. Don’t worry, we have ideas if we don’t hear from you.

 

/by

Cold Chain Asset Tracker: A Golioth Reference Design

Asset tracing is arguably the number one cellular IoT application. Fleet vehicles in everything from commercial delivery services to public transportation, and every micro-mobility rental option (bikes, scooters, etc) includes asset tracking as core parts of their business model. One important variation on this applying asset tracking to the Cold Chain. It became a household when distributing vaccines in 2020, but it’s not new. Everything from raw meat to ice cream is transported using cold chain protocols.

This technology is particularly interesting when it comes to managing critical cargo, like refrigerated food and medicine. The Golioth Cold Chain Asset Tracker demonstrates how regular temperature readings can be recorded on the cloud along with a timestamp and GNSS (GPS) location. It enables your company to prove proper handling of these goods at any time during their transport and storage.

The Cold Chain Asset Tracker

With Golioth, keeping track of temperature and location data is both simple and configurable. This reference design is capable of taking readings as often as once per second, but the rate at which data is recorded, and the frequency at which it is uploaded to the cloud is remotely configurable.

Location data shown on map along with a temperature graph.

Temperature and location data is stored on the Golioth cloud, or any of your preferred cloud platforms.

In this application, latitude, longitude, temperature, pressure, and humidity data are all recorded along with a precision timestamp. Readings are cached on the device, a crucial feature that ensure data is not lost when the cellular network is unavailable. Most mobile asset trackers operate on a strict power budget and this caching also enables you to turn the cellular radio on and off on a schedule of your choosing to conserve power.

All Golioth Reference Designs include Over-the-Air (OTA) firmware updates. Your asset tracker may be in the field for months or years and you will still have the ability to update with new features.

Hardware

Our reference designs use off-the-shelf hardware to help get your proof-of-concept up and running as quickly as possible.

Cold chain asset tracker displaying GPS location and temperature reading.

The Cold Chain Asset Tracker is based around a Nordic nRF9160 cellular modem, uBlox NEO-M8H GPS module, and Bosch BME380 temperature/pressure/humidity sensor.

The full parts list is on our Golioth Projects page, but the key components involved are the Nordic Semiconductor nRF9160 cellular system-in-package (SIP), the u-blox NEO-M9N GNSS module, and a Bosche BME280 temperature/pressure/humidity sensor.

The cellular modem (nRF9160) is one of our best supported parts on Golioth and is powered from either a local power supply or a lithium battery.

Cold Chain Asset Tracker reference design block diagram

Cold Chain Asset Tracker reference design block diagram

Firmware

The firmware for the Cold Chain Asset Tracker reference design receives NMEA strings from the GNSS unit once-per-second that contain satellite fix data. Each valid reading is associated with the current reading from the BME280 sensor before the data is cached for secure upload to our servers.

The Golioth Settings Service is used to update a single device’s settings, a group of devices, or to make fleet-wide changes from our web console (and our REST API if you need it).

Golioth Settings Service for the Cold Chain Asset Tracker reference design

Golioth Settings Service for the Cold Chain Asset Tracker reference design

Here you can see the loop delay which indicates how long the device should sleep between uploading cached data to Golioth (in seconds). The gps delay tells the device how many seconds to wait between recording location data. In this, our test device has been configured separately from the rest of the fleet to take as many GPS readings as possible (no delay between readings) and upload that data once every three minutes.

Cloud Software / Dashboard

The Golioth Zephyr SDK takes care of the cloud connection for all of your devices. When writing firmware, just use the API to set/get/observe your data and Golioth handles the rest:

  • Sensor readings are stored as time-series data on LightDB Stream
  • Device settings are monitored in real-time, with the device reacting to your changes as soon as you make them.
  • The Golioth Console tracks the latest device state, including device health
  • Current firmware version is monitored, with the ability to rollout new OTA updates, and one-click rollback if you need it
  • Golioth’s convenient REST API delivers easy access to the data for visualization or export to any of your favorite cloud server platforms.

More Golioth Reference Designs

We want every customer that tries Golioth to experience the value of our device management cloud from day one. Golioth reference designs get you up and running in hours (not weeks) with the major IoT components necessary to your use case. Your prototypes are running on an instant IoT cloud built to scale, with the same infrastructure in place on day one that you need on the day you deploy your 1000th device.

nRF9160-DK running Golioth Cold Chain Asset Tracker

The flexibility of Golioth Reference Designs makes it possible to run them on stock hardware, not just custom boards. The Cold Chain Asset Tracker can be validated on this combination of the Nordic nRF9160-DK with an adapter board and two Click modules form MikroElectronika.

We’re always working on more reference material for you to take and customize for your business needs. Check out the Industries section of the Golioth website, which discusses areas we are targeting and Reference Designs we are building. If any of them interest you, click the “Schedule Demo” button for the one that best matches your needs. You can also drop a note on our Forum or on our Discord if you have ideas of other IoT prototypes you need help with or would like to see us build.

/by

IoT Air Quality Monitor: A Golioth Reference Design

There is a growing cultural awareness of the significant health impacts of poor air quality, especially in the wake of the COVID-19 pandemic and natural disasters like the wildfires in California. Indoor air quality is an often overlooked aspect of workplace health and safety. Yet it has been shown to have a significant impact on employee productivity and wellbeing. By implementing an IoT air quality monitoring system, businesses can proactively measure and track air quality parameters such as CO2 and particulate matter levels. They can identify and address potential issues before they become problematic.

There are also significant business benefits that can be realized through the implementation of demand-based ventilation systems. According to the Department of Energy, HVAC systems use about 35% of a building’s energy on average. Businesses can optimize ventilation rates based on real-time occupancy levels and air quality parameters using indoor air quality monitors. This demand-based approach to ventilation can lead to significant energy savings and reduce HVAC maintenance costs.

Golioth makes it easy to develop and deploy a cloud-managed fleet of air quality monitors that can provide valuable insights into the air quality in your workspace.

The IoT Air Quality Monitor

Golioth’s latest IoT reference design provides an end-to-end example of how to quickly build an indoor air quality monitor proof-of-concept. The reference design measures temperature, humidity, relative pressure, as well as CO2 and particulate matter concentrations. These sensor measurements are periodically streamed to the Golioth cloud via a low-power LTE cellular connection. Using the Golioth REST API, the air quality data enables real-time control and visualization.

Let’s take a look at the hardware and software components of this reference design.

Hardware

The Air Quality Monitor hardware is built using the new Golioth Aludel Mini prototyping platform, which integrates an Adafruit Feather-compatible processor module and two MikroE Click sensor boards into a compact enclosure. We designed this platform to demonstrate how it’s possible to quickly develop a proof-of-concept using widely available off-the-shelf modules.

It also includes the brand new Ostentus front panel that provides an ePaper display for sensor readings, back-lit LED indicators, and capacitive touch buttons.

For low-power cellular connectivity, we’re using the same SparkFun nRF9160 Thing Plus module used in other Golioth reference designs (such as the IoT Trashcan Monitor). This feather-compatible module integrates the Nordic nRF9160 System-in-Package (SiP), featuring an Arm Cortex-M33 application processor, an integrated LTE modem, and a GNSS receiver for cellular-based location-tracking. The nRF9160 is fully supported in Zephyr, and has the highest level of support in the Golioth platform (Continuously Verified).

This reference design integrates two off-the-shelf MikroE Click sensor boards:

  1. MikroE Weather Click with a Bosch BME280 humidity (+temperature/pressure) sensor
  2. MikroE HVAC Click with a Sensirion SCD41 CO2 sensor and Sensirion SPS30 particulate matter (PM) sensor

Check out the Project Page for the full parts list.

Firmware

The firmware for this reference design uses the Golioth Zephyr SDK to implement device management features. This includes device authentication, streaming sensor data to Golioth’s LightDB Stream time-series database, logging, and over-the-air (OTA) firmware updates.

The Golioth Settings Service is used to implement custom run-time configurable device settings that can be managed from the Golioth Cloud. Settings can be configured at the project or individual device level and can be managed via the web console or the REST API.

For example, the Air Quality Monitor firmware implements a CO2_SENSOR_ALTITUDE setting that can be configured for each device to achieve the highest accuracy of the CO2 output signal across a large pressure range.

The firmware also implements the Golioth Remote Procedure Call (RPC) service. For example, the clean_pm_sensor RPC command can be called to trigger an on-demand cleaning of the particulate matter sensor.

Cloud Software

The Golioth Cloud provides a tightly integrated set of services specifically designed for managing fleets of IoT devices at scale:

  • LightDB State: bidirectional real-time device state database
  • LightDB Stream: database for storing time-series data
  • Logging: centralized device log storage
  • Settings: device settings management
  • OTA: Over-the-Air firmware updates with one-click rollback

You can access these services by logging into the Golioth web console, or programmatically from an authenticated device via the REST API or the Command Line Tools.

Data Visualization

The Golioth REST API makes it easy for external applications or services to access the sensor data streamed from the devices to the LightDB Stream time-series database.

We created a Grafana dashboard for the Air Quality Monitor that displays the real-time temperature, humidity, pressure, CO2, and particulate matter measurements sent by each device:

More Information

For more information about the Air Quality Monitor reference design, check out the project page:

https://projects.golioth.io/reference-designs/air-quality-monitor/

Please contact [email protected] for access to the hardware design files and firmware source code for this and other Golioth reference designs. You can also drop us a note on our Forum or on our Discord if you would like to suggest ideas for other IoT reference designs you would like to see us build.

 

/by
, ,

Golioth Showcases Reference Designs at Embedded World 2023

Golioth returned to Embedded World in 2023 to showcase at the Zephyr booth. We brought a range of designs built with Zephyr and connected to the Golioth Cloud. Each of our Reference Designs show how Golioth technology can target verticals throughout the industry. We are regularly creating new designs and posting about them, both on this blog and on the Golioth Projects site.

Moving To Common Elements With Our 2023 Designs

We had a more standardized form factor and design elements with our 2023 designs than our demos at Embedded World 2022. Last year, we wanted to differentiate the functions and features of the Golioth Cloud when showcasing the “color demos”. Each of these demonstrated the different parts of our platform.

Golioth Embedded World 2022 Color Demos

This year was all about showcasing how similar many IoT designs can be. By extension, we wanted to show how we can swap some hardware and firmware to target entirely different market segments.

We built a new form factor that contains off-the-shelf hardware but still presents it in a somewhat compact manner. This took the form of the Aludel Mini case and PCB design, as well as our Ostentus front panel, both of which we have written about before. The result is a black box (har har) that allows us to target verticals. Our goals in the near future is to create additional firmware resources to make it easier for our users to replicate these designs using 100% off-the-shelf components.

Asset Tracker Port Side of Aludel Mini with Ostentus

Asset Tracker Connector Side of Aludel Mini with Ostentus

The 2022 designs had explanatory information / diagrams on the top PCB. This year we migrated to putting that information on a laser cut backing plate used as a mounting surface for the actual Reference Designs. These allowed visitors to read more on their own, if they desired, and kept our Reference Designs smaller and more like what might be deployed to the field. See images below for examples of backing plates.

Reference Design Demos

We brought 5 Reference Designs with us to Embedded World. In fact, we had more demos than we had space in the Zephyr booth to showcase them! Alas, we tried our best to highlight each element to the people walking by our booth.

DC Power monitor

This design was based off of our AC Power Monitor Reference Design that we have published about before. However, when thinking about logistics at a conference, we didn’t feel comfortable monitoring AC power in the booth. Instead, Mike took the design and swapped out the Click headers and reworked some of the firmware to instead monitor USB power flowing through the design. In the video above, you can see that we monitored the current of a fan and a USB lightbulb and then were able to dynamically chart the power usage on our bespoke Grafana dashboard.

Air Quality Monitor

Our Air Quality Monitor Reference Design was so new for Embedded World that we had only just published about it on our projects site. We will be doing a blog post and video about it soon. The main focus was capturing and displaying this information both on the Ostentus display (front panel) and then on the associated dashboard.

There are two interesting things that differentiate this design from the others. The first is a Remote Procedure Call (RPC) that directly activates the fan onboard to start a cleaning cycle. This is a great example of how RPCs can be used for one-off activities triggered programmatically on an “as needed” basis.

The second is the use of LightDB State to visualize and trigger warnings from the device. Note the red dotted line in the chart on the CO2 concentration. This is a configurable level in LightDB State on a per-device basis. It could be used to trigger a local alarm (light, sound) or can be used to trigger other notification/alarm activities on the cloud.

Cold Storage Asset Tracker

Last year we brought an asset tracker in the form of the Orange Demo, based upon the Nordic Thingy91. This year we upgraded with a more accurate tracking GPS module that can run simultaneously with the cellular modem.

The unit tracks temperature for “cold storage” applications. This is a common use case for refrigerated trucks and shipping containers, as wells as tracking of vaccines in transit between medical facilities. Demonstrate GPS inside a conference hall is a challenge because of being locked to one position and under a bunch of metal girders, but we were able to showcase the underlying hardware and example paths that recalled historic trip data stored on Golioth.

IoT Trashcan Monitor

Our waste management solution is made to help municipalities and parks departments more efficiently route their diesel trash trucks. As in the rest of our demos, this becomes and exercise in scaling things down to fit on a tabletop in a conference facility. We achieved this by creating a portable (foldable) trashcan that we can setup on conference booth tables.

IoT Trashcan Monitor Demo on the right side

The miniature version of a trashcan helps to illustrate the usefulness of the Golioth Settings Service. The original demo had a trashcan that was roughly 1 meter tall and all of the “percentage-full” levels were based off of that height. Golioth makes it simple to select the individual device we brought to the show and adjust the height for a 300 mm tall trashcan. This “calibration” was instantly sent down to the device and it reported levels in exactly the same way it had for a taller trashcan.

Soil Moisture Monitor

The Soil Moisture Monitor Reference Design measures soil moisture levels and the amount of light reaching the unit. During this conference it barely saw any light, since we ran out of room on the desk! You can find full details in the soil moisture monitor demo video, and project page. We will have this and many new designs on display at the Embedded Open Source Summit in Prague in late June. Please be sure to stop by there to see what we have been working on!

We’ll Train You To Build Your Own Zephyr Design

One of the things we were sure to point out in each of the example videos above is that we are running new training sessions showing people how to design with Zephyr. If you’d like to learn how to build your next design with the popular Open Source RTOS and Ecosystem, sign up at golioth.io/ew23.

/by
,

Low Volume, High Mix Mechanical Enclosures for IoT Projects

Most of the time we’re writing about how to build out the firmware that will go onto your IoT Devices. Our device Software Development Kits (SDKs) are a key offering that Golioth provides to hardware and firmware engineers; we want it to be easier for you to build the code that will go onto the device out in the field. Once the code is ready to go, you need to think about how you are going to enclose the thing you just made, whether it’s a product or a prototype.

We have been building prototypes in the form of Golioth Reference Designs. These are end-to-end demos that include hardware, firmware, software, and visualization, and we’ve been building a bunch of them. That has meant we are developing a “high mix, low volume” set of products (really prototypes) and have needed to figure out how to utilize enclosures for the different things we’re trying to do.

What’s in the box

Most of our current Reference Designs contain a few key things:

  • A development board, such as the Sparkfun Thing Plus nRF9160 (our current most-used board)
  • Sensor boards or interfaces to external items
  • A battery
  • A centralized board that makes it easy to mount each of the above items

Off-the-shelf hardware like this is less a “product” than it is a first round prototype or even Proof-of-Concept. It can be used to test a business idea or to build requirements for a future high volume product.

Requirements influence design

We have tried a few different ways of enclosing our projects so far. As you’ll read below, each time we built something, we took the lessons we learned and modified our next iteration.

Color demos (Aludel)

Our first round of assumptions was that we needed to make everything waterproof and have maximum flexibility. As such, we decided on the Bud model PN-1324-CMB. It’s a normally gray opaque base with a clear polycarbonate lid where we could have a display element on a top PCB. The main function was that we could implement lots of cabling internally but still have access to Click boards (based on the Mikroelectronica MikroBus standard). The cabling would all go through cable glands to keep out moisture. I also liked that the box had flanges so we could screw this unit to a wall or a display stand.

This method worked out OK but had the downside of requiring each sensor to be either outside the box and cabled in or we needed to “break” the waterproof nature to monitor things like air humidity. Most things we were planning to do involved direct monitoring of the environment. This, in combination with the large overall size of the demos, meant that we thought we could improve on future revisions.

You can see these cases in action (including cover plates that hid the base PCB) in the green and blue demos that we took to Embedded World in 2022.

Trashcan Reference Design – First iteration

Since we were monitoring using a time-of-flight sensor on the Trashcan Reference Design, I knew we would need the sensor to be external to the case. Or at least it would need to be pointing outside the envelope of the case, as shown below. I used a Sparkfun breakout board for the VL53L0X sensor from ST Micro and drilled out a hole to allow the signal to point down into a trashcan and reflect off the top of the trash piled up inside that can. Then I hot glued it in place.

Open case

This is unrealistic in a deployment as a trashcan is a harsh environment, especially deployed somewhere like a national park. The moisture and heat inside a trashcan would require the device be more watertight. After building this iteration and realizing we were not designing something deployable, my mindset around how we needed to make our cases began to change. It would be imperative on anyone who utilizes our reference designs to make revisions, optimizing it for manufacture and hardening it for their specific environmental needs. What is the impact if our Reference Designs are no longer planned to be field ready or watertight?

Trashcan Reference Design – Second Iteration

In the second iteration of the Trashcan Reference Design, I started to optimize for some different elements, most noticeably the repeatability of the design. There is nothing special about the PCB shown below, only that it can be manufactured more easily than the hotglue-laden prototype in the first iteration. Again, we see that the design is not water tight. I did focus on maintaining a smaller form factor than the Aludel, with a low cost case.

Side view of case open

The IoT Trashcan Reference Design with the top of the case open

This one is the Bud CU-1937-MB, part of their “Utilibox” line. Not designed to show much of anything, it’s meant to really be screwed to the wall and forgotten (as many IoT things are). I once again chose a design that had flanges as part of the case for easy mounting on a wall; in this case, it’d be mounted on the underside of a trashcan lid.

The difficulty was in a non-standard cutout. Also the fact that I was using a Dremel hand tool instead of something more precise like a milling machine. This goes back to the “high mix” element, it was tough to justify buying a milling machine and then programming it or getting better at manual machining. I took my best shot with a Dremel (spending quite a bit of time in the process) and then 3D printed a thin case over top of the quite ragged holes that I cut.

Side view of case closed

A side view of the IoT Trashcan Reference Design including 3D printed cover

Most people wouldn’t/won’t see this element of the design, but it’s still important not to have holes cut out that are all jagged and rough.

Aludel Mini

In our most current iteration on display at Embedded World coming up in 2 weeks, I decided to take a different tack, based on some brainstorming with my coworker Mike. We had already re-designed the landing board to once again utilize Click boards from Mikroelectronica, and to fit in the same case (CU-1937-MB); this was called the “Aludel mini”, playing off the name of the original Aludel case design.

It was unclear at first if we could fit the size of the headers (in width and height) into that case, but it turns out we can. We really liked that there is a wide variety of sensors available in that form factor and we can also buy things like the Arduino to Click converter boards to make the same sensors available on platforms like the nRF9160-DK.

So now that we know we are using that same case and that we are somewhat OK with a 3D printed element on that case, I decided to take a leap and have Bud modify the boxes to plan for this flexibility. Instead of having them mill out just the button and USB C port cutouts, I decided to have them basically wipe out two of the walls of the case. That might be a bit extreme, but it allows for ultimate flexibility.

This was a custom order (with an upcharge for doing so, understandably), but it was a pretty seamless process to go back and forth with the manufacturer rep (Pinnacle Marketing, based on my location in the US Southeast) and the manufacturer (Bud Industries) and get these made. They did warn that the structural integrity of the case would be impacted, but I moved forward knowing we would be able to reinforce with the inserts we design.

Now the trick was to design something that could fit this shape. They have a high draft angle, ostensibly to make it an easier ejection from injection molding equipment, but that makes for some odd trapezoidal walls. I brought the supplied 3D model into FreeCAD and set to work printing and iterating on the design. Here’s the shape I ended up with:

I utilized the mounting posts for the top case as a reinforcing element. For most of the designs I put this into, I’ll glue the plate in place, but it is also designed to slide in and out for prototypes.

On the other side of the board, we expect there to be much more variation. Often this is where wires or extension cables are interfacing with the case. I took the base plate and was able to draw simple shapes onto the face plate to create a variation for each reference design that we make. This will depend on the type of Click board we have plugged into the Aludel Mini. For the Soil Moisture Reference Design, you can see that I made a cutout that allows the Click Shuttle Expander to go out to individual boards:

Soil Moisture Monitor closed with sensors closed

The obvious question

With all of these modifications, the obvious question is: Why not 3D print the entire thing?

A fair question, and definitely something that I might consider in a future iteration. I would still want to maintain many of the same features that we have put into the existing designs (relatively small envelope, mounting flanges, plain exterior). The cost would be roughly the same if sent to China for 3D printing (depending on material used), when compared to a low volume run of modified cases + printed inserts. I also like the implied constraints of choosing an enclosure and then needing to work around those constraints, although the exercise changes when designing a product. It prevents adding “just one more thing”, when in our case we’re primarily trying to showcase the platform and not the hardware itself.

High mix is not the norm

Most product companies work differently. If you are spending enough money to hire engineers to design a product, you are likely making a higher volume of devices to support the salaries of engineers. In that case, your constraints change quite a bit. When moving to a higher volume manufacturing run, it makes sense to take everything you learn from a Golioth Reference Design and spin it into a higher volume product (custom PCBs, integrated sensors, more complex battery management, bespoke watertight enclosures, etc). If you want to take Reference Designs for a spin and use them as the basis of your next product, we’d love to talk. If you’re more interested in chatting about how to optimize cases for a variety of different designs, post about it on our forum!

/by