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].

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.

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.

 

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.

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.

 

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.

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!

Farms and growing operations are no strangers to measurement and feedback. Farmers often chart things like rainfall and days of sunshine, as well as taking soil measurements at regular intervals. As operations grow, so too do the cost of operations: you need more people to take readings, the area of coverage grows, you need a more complex logistical operation when trying to do automated readings.

At Golioth, we make it easier to prove the value of creating an IoT device by sharing “reference designs”. These function as your first proof-of-concept that you could take and deploy in a pilot to see whether your farm will benefit from more data about your crops. The Cellular IoT Soil Moisture Monitor reference design aims to be a proof-of-concept for operations that need far-flung sensors throughout an operation that can report back to the cloud on regular intervals. This is a companion to the Greenhouse Controller reference design, which is another in our series of agricultural use cases.

Hardware

This reference design has some familiar sensors. The APDS-9960 is a light quality sensor (reporting intensity, red, green, and blue levels), and the BME280 is a weather sensor (temperature, humidity, pressure). These were in the Green Demo we showcased at Embedded World in 2022, as well as part of the Greenhouse Reference Design. They continue to be our go-to environmental sensors for a simple reason: their sensors are in-tree. And much like we chose hardware with existing firmware support, we also focus on choosing breakout boards that are in the Mikroelectronica MicroBUS form factor. In this case, that was the Hydro Probe Click, built around the MCP3221 ADC. Because this device uses more than 3 Click sensors, we also utilized the MikroBUS Click Shuttle to extend the available ports. This also moves the Hydro Probe sensor outside the envelope of our normal case design.

Hardware going out into a field in a farm needs to survive harsh operating conditions. So why not use more field-ready hardware? In short, because that isn’t the point of reference designs. We are showcasing starting points for designs, often proofs-of-concept. Once the idea is proven and you see data flowing back to your IT or OT system, your next hardware revision can immediately focus on Design-For-Manufacturing (DFM), cost optimization, and hardening for harsh conditions.

Firmware

As in other reference designs, we wrote the firmware for this design in Zephyr, targeting the nRF9160 SIP from Nordic Semiconductor. With Zephyr projects, it is possible to retarget other microcontrollers, including microcontrollers with different communication mechanisms (Wi-Fi, Thread, Ethernet). Depending on your needs for your deployment, this switchover might make more sense.

In addition to the normal features that Golioth offers out of the box (OTA, RPCs, data streaming), this demonstration takes full advantage of the Settings Service from Golioth. The reference design captures only raw data reading from the sensor, doing minimal processing on board. This data is sent to the cloud and the operator can push threshold values back down to each device. This helps to customize for different operating conditions and to send back bucketed data that can be used for visualization platforms like Grafana.

Software

Golioth is ultimately the majority of your software stack: we take care of everything once your device communicates over CoAP to our backend servers. From the perspective of the data moving around the Golioth system, we collect the data on LightDB Stream and make it available via the REST API. It can also be exported to third party platforms using Golioth Output Streams.

For this demonstration, we set up a Grafana dashboard that can query the REST API and show recent readings while also charting all of the sensor data over time:

Monitor things that matter to your business

Like our other reference designs, we aim to show the flexibility of the Golioth Platform and how we think it is useful for common real-world applications. Any of the sensors and actions you see in our growing range of reference designs can be applied to your project. The key thing is understanding what you want to measure and react to in the real world. Golioth can help to make the cloud portion of your IoT project a reality. If you have questions about how to get started or want to talk through your next design, reach out to us at [email protected] or post on our forum.

 

 

Power monitoring is a common Internet of Things (IoT) application. Whether it’s to track the health of manufacturing tools (“Do I have a motor bearing about to give out?”) or to provide consumer insight (“Can I save money by running the clothes dryer during off-peak hours?”), gaining granular feedback on your electricity usage is a valuable tool. This concept inspired Golioth’s latest reference design: an AC power monitor that records reading to the Internet.

The AC Power Monitor

With Golioth, it’s quite easy to add IoT power monitoring to any electrical device. We utilize non-contact current clamps that can be added to a machine tool’s power supply, or at the breaker in an electrical box. The current sensor clamps around a wire, detecting the magnetic field generated when current is flowing to the device being monitored. The readings are uploaded to Golioth where they can be visualized and acted upon.

In this application, 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

Starting from a reference design helps get your proof-of-concept up and running. With that in mind, we like to use off-the-shelf hardware as much as possible.

Power Monitor with two ADCs and an AC current sensor ("current clamp")

Power Monitor with two ADCs and an AC current sensor (“current clamp”)

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) and a pair of MCP3201 analog-to-digital converters (ADCs) which read signals from the 30A-to-1v AC current sensors.

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.

Power Monitor reference design block diagram

Power Monitor reference design block diagram

Firmware

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.

Golioth’s LightDB state system is used to report the live “run” time. It’s one way to monitor if a machine has been left on, or is simply in constant use and may represent a bottleneck in your shop’s workflow. The cumulative “run” time is also reported here, serving as an odometer for the operating life of the equipment.

All of the Golioth reference designs include Over-the-Air (OTA) firmware updates so changes to how the firmware works don’t require an on-site visit.

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.

We’ve set up a dashboard on Grafana, one of our favorite visualization tools. It queries the Golioth REST API for device data and presents it as a handsome web interface.

Grafana dashboard to visualize data from the Power Monitor reference design

Grafana dashboard to visualize data from the Power Monitor reference design

The dashboard collects both the persistent data stored in LightDB State (live runtime as well as cumulative) and the time-series data stored in LightDB Stream (the periodic sensor readings). We push the ADC readings as raw values and they are converted to Amps for display on the dashboard. You could just as easily display current power consumption which would be about 600 Watts for the toaster oven readings being shown above on Channel 0.

More Golioth Reference Designs

Our reference designs are like a business in a box. Using Golioth as your device management cloud, your first prototype will be running within hours, not weeks. These designs are built to scale, with the same infrastructure in place on day one that you need on the day you deploy your 1000th device.

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.

The Internet of Things (IoT) can make existing infrastructure more useful and easier to operate, with the added benefit that you don’t need to be on-site to make changes. This is the case with Golioth’s latest reference design: a greenhouse controller that adjusts ventilation and grow lighting based on sensor readings. It also provides manual control from the cloud.

Whether it’s too hot or too cold, tightly monitoring and regulating greenhouse temperature has a huge effect on crop yield and growing time. The same can be said for lighting conditions. At this time of year (winter), consider the poinsettia: it requires intense light during the day, and at least 12 hours of total darkness over night in order to turn a vibrant shade of red. Sounds like a great job for an automated controller.

But think beyond one type of plant and one time of year. The agriculture industry uses automated control to implement different growing conditions based on the cultivar. A cloud-connected controller makes it much easier to update (and keep track of) the growth profiles.

The IoT Greenhouse Controller

An IoT Greenhouse Controller continues to show that simply connecting sensors to the internet is impactful. From one online dashboard you can see how the light, temperature, pressure, and humidity is trending across all of your planthouses. For this reference design we added two mains-rated relays to add control to the equation.

The cellular modem sends sensor data back to Golioth, and monitors the cloud for updates in target temperature and light intensity. A threshold setting for light level automatically controls when the grow lights are turned on or off. The same is true for a temperature threshold that is monitored for control of the ventilation system. Of course both of these relays can be controlled manually.

Let’s take a look at the hardware involved in this Reference Design

Hardware

We’re favoring off-the-shelf hardware for ease of implementation. Most of the modules that we use are simple breakout boards that aren’t much more than a sensor or two, some power handling, and interconnects like cabling. The idea is that someone could take this setup and choose which sensors they want to put onto their custom hardware design that will go out in the field.

IoT Greenhouse controller internals

Golioth Greenhouse Controller reference design internals.
Left to right: light sensor, weather sensor, relays

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), a BME280 weather sensor, an APDS9960 light intensity sensor, and a set of relays.

The nRF9160 was chosen because it is one of our best supported parts on Golioth. A cellular modem may seem like an odd choice for infrastructure-based controllers, but in combination with the lithium battery you will still be able to monitor greenhouse conditions during a power outage. There is no better peace of mind than being able to answer the question: when the power was out, how cold did my plants get and for how long?

As with many Golioth designs, our wide ranging SDK support means you can retarget the same control code to different hardware in the future. If you want to take the reference design and target a Wi-Fi, Ethernet, or Thread solution, it’s a couple of files configured differently and you have similar functionality with a whole new connectivity medium.

Greenhouse Controller block diagram

Firmware

The firmware for the Greenhouse Controller reference design uses the Golioth Settings Service. This is ideal as it facilitates control of a large fleet of these devices, allowing settings to be adjust for all at once, in groups, and of course down to individual units.

Golioth Settings Service for the Greenhouse Controller reference design

Golioth Settings Service for the Greenhouse Controller reference design

Here you can see the loop delay which indicates how long the device should sleep between sensor readings (in seconds). The light and temperature thresholds control the on/off point of the relays, and finally the auto settings indicate if the relays should be switched automatically based on those thresholds. The controller monitors Golioth’s LightDB state system for manual control commands, which do not interfere when the automated option is enabled.

All of the Golioth reference designs include Over-the-Air (OTA) firmware updates so changes to how the firmware works don’t require an on-site visit. While the current firmware doesn’t implement a schedule-based system, the concept is easy to add and install on the device using OTA.

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 roll-back 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.

We love using Grafana dashboards to visualize IoT data. The dashboard talks to the Golioth REST API to monitor the IoT sensors and the state of the lighting/ventilation. Of course you could use WebSockets to get live updates as the data arrives at the Golioth servers. For this application, it’s likely that sensor readings are being recorded every few minutes so a dashboard that reloads on its own works well.

Golioth Greenhouse Controller Grafana dashboard

More Golioth Reference Designs

Our reference designs are meant to get you through the initial steps of proving out your IoT-based business. You can buy the readily-available parts used for this Greenhouse controller and with our reference design resources you’ll be on your way to a proof of concept in days instead of weeks. This means you’re fleshing out features and heading toward a hardware prototype with actual performance data. Golioth is designed to scale, so the same connections and features that you use for your first prototype remain in place, with a platform that can handle a number of devices beyond your wildest imagination.

We are busy building out more reference material for you to take and customize for your business needs. We recently launched an Industries section of the Golioth website, which lays out some of the other 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.