If you’re making that choice now, this article is your go-to guide. We’ll delve into the important factors and provide you with the context you need to make an informed decision. Let’s get started!

What is a cellular module?

So you’ve compared connectivity options for your IoT project, decided on cellular, and now you need a cellular module – well done! But what exactly is a cellular module?

Essentially, it’s the hardware component that enables wireless communication between your device and the internet. The module includes a modem, RF antenna, chipset, and other supporting circuitry, and connects to a cellular network such as AT&T, T-Mobile, or Verizon. This provides the necessary bridge between your device and the cloud-based applications or other devices that it needs to communicate with.

Cellular System-on-Module from Blues

Entering the build vs buy debate

One of the earliest and biggest decisions you might face in your IoT project is whether to build your own cellular module or purchase a pre-built one from a vendor. Building your own module can provide greater control and customization, but it requires significant time, resources, and expertise, resulting in higher short-term costs. On the other hand, buying a pre-built module can offer faster time-to-market, lower development costs, and potentially better performance due to the vendor’s expertise and resources, but it may limit your customization options.

To make the best decision for your organization, you need to carefully evaluate factors such as project requirements, cost, time-to-market, technical expertise, and timeline. By considering these factors, you can make an informed decision that aligns with your unique circumstances and helps you achieve success in your IoT project.

What are the IoT project requirements for building a cellular module?

In general, building a cellular module can be a good option only if you have highly specific project requirements, as well as the budget, time, and access to required resources.

Some instances that might require a custom cellular module:

• highly customized device that cannot be supported by any off-the-shelf modules
• complete control over the firmware and software and need to code everything in-house
• ultra-low power consumption
• specific form factors 
• specific connectivity needs
• Specialized sensor packages

Do your research though, because you can often find many of these in pre-built modules.

How much would it cost to build a cellular module?

While building a cellular module offers complete control over the design and functionality, it is an extensive design project that requires a significant investment of time, effort, and money. The average costs associated with building a cellular module can vary widely, depending on the complexity of the project, the number of components required, and the level of customization needed. 

As laid out in this IoT For All article covering the topic, “designing a cellular module requires intense work on all four of these elements”:

1. Hardware Design: sourcing third-party modems, antennas, and microcontrollers, which can cost tens of thousands of dollars*.
2. Firmware Development: requiring expertise in modem drivers, encryption technologies, and data formats.
3. Cloud Development: requiring defining and integrating the back-end system for data storage and remote updates.
4. Carrier Certification: most carriers/telcos require hardware that is in their network to be certified. Not doing so can mean devices being booted off the network, and lack of support from the carrier.
5. Carrier Integration: deciding on a carrier and SIM – contract lock-ins and data rates can be cost-prohibitive.

* Not to mention the additional costs of integration, optimization, and certification for regulatory compliance.

In addition to the material costs of building the components, the time and effort of a highly specialized team required to execute these tasks adds a considerable expense to the project.  

Gartner projected that 75% of IoT projects will take about twice as long as initially planned and a great portion will fail at the pre-launch stage and a lot of this can be attributed to the unexpected complexity of building an IoT solution.

How many engineers does it take to build a cellular module?

That is not the beginning of a joke, building a cellular module is a complex undertaking that requires a team of specialists from different engineering fields. 

Depending on the scope and complexity of the project, the number of engineers needed can vary, but in general, you will want to have the following experts on your team:

• Electrical engineers, who design and develop the hardware of the module, including the circuitry, power supply, and antennas.
• Firmware engineers, who write and maintain the software that runs on the cellular module throughout its lifetime.
• Cloud engineers, who ensure that the IoT device and cellular module function seamlessly with cloud-based services, including data storage and analysis.
• Mechanical engineers, who design the physical enclosure and packaging for the module, ensuring that it meets your product’s aesthetic and functional requirements.

To manage the project and ensure that it stays on track, you will also need a project manager who can coordinate the efforts of the different teams and ensure that the project is completed on time and within budget. The size and composition of your team will depend on the complexity of your project and the level of expertise required to achieve your goals.

How long does it take to build and certify a cellular module?

Building a cellular module from scratch can take months or even years to complete. Much of that depends on the complexity of the module, the experience and resources of the engineering team, and the regulatory requirements of the target markets. However, it’s essential to ensure that the final product meets regulatory requirements and performs flawlessly prior to deployment.

It’s worth noting that testing and certification are still required, regardless of whether you build or buy a cellular module. These can add significant expense and time to the project. By working with a module supplier that has already completed some of the necessary certifications, such as PTCRB, carrier, or FCC (in the US), you can reduce your time to market and ensure regulatory compliance.

So when is it actually better to build a cellular module?

There’s no one-size-fits-all answer for deciding whether to build or buy a cellular module. If you’re looking for a highly customized IoT device that can’t be supported by any off-the-shelf module, then building your own cellular module might be the best option. With complete control over the firmware and software running on the device, you can create unique features and capabilities that are tailored to your specific needs.

But, building a cellular module is not for the faint-hearted – it’s a better option for businesses who have the scale and resources to justify the challenging process.

When is it better to buy a cellular module?

For the majority of use cases, buying a cellular module is the better option. By buying off-the-shelf modules, you can save time, reduce risk, and integrate easily with your project. For most businesses, partnering with an IoT module provider is a more cost-effective way of adding cellular connectivity to their IoT products.

Consider buying if: 

• Your project doesn’t require highly specialized functionality.
• You’re dealing with tight schedules or lack of expertise.
• You’re not willing to go through the expensive, complex, and time-consuming certification process.

Reliable, flexible, and cost-effective cellular modules with pre-provisioned network access, eSIMs, ultra-low power management firmware, and even prepaid connectivity through MVNOs are readily available. It’s just a matter of budget and needs.

How much does it cost to buy a cellular module?

When it comes to the actual cost, a basic economy cellular module can be relatively inexpensive, ranging from $10-30, with a more advanced and feature-rich module costing up to $100 or more.

Multiple factors can affect the price of a module, including but not limited to:

• Brand: well-known brands can charge more.
• Cellular network: the technology the module is designed for, such as LTE-M, NB-IoT, or 3G/4G/5G.
• Certifications: pre-certified modules can be more expensive but save you time and money.
• Security: built-in features that make it harder for data to be stolen or corrupted.
• Quantity ordered: bulk purchases may offer discounts or special pricing.
• Technical support: some charge a premium for ongoing product support before and after deployment.

Before making a decision, it’s important to take a closer look at the capabilities of a cellular module vs. your needs, and compare pricing from different providers to ensure you get the best value and features for your project.

What else can you get with a module supplier?

On day one of your IoT project, you need to be thinking about deployment and scaling, so find a supplier who is capable of providing solutions at scale. Buying the right module not only makes building a device easier, but also the cloud integration, and commissioning. Some solutions to look for are hardware auto-provisions to the cell carrier, a software layer that offloads the data straight to the cloud, easy data egress (output) to the platform of your choice (either cloud, on-premise, or hybrid), and more.

Making the decision to buy or build a cellular module

While IoT engineers have the necessary expertise to design and align features with specific use cases, building every element from scratch isn’t always the best approach. The complexity of cellular connectivity and the modules that create these connections require extensive knowledge in hardware design, firmware development, cloud development, and MVNO carrier integration. 

The smarter choice for most use cases is to opt for a pre-built module. By partnering with a trusted IoT module provider, you can focus on enhancing user applications and device features that customers experience firsthand, rather than worrying about cellular connectivity and module design complexities.

Don’t let the complexities of cellular connectivity and module design hold you back. Contact our team of IoT experts to learn more about selecting the right cellular module for your project.

The post Building vs Buying Cellular Modules: Which Option is Right for Your IoT Project? appeared first on Blues.

The Notehub JS Backstory

Blues aims to make cloud-connected Internet of Things development easier by providing the crucial device-to-cloud connection all IoT products need regardless of if there is a reliable Internet connection or not. We do this through the use of Notecards and Notehub.

Notecards are low-power, 30mm x 35mm, prepaid cellular-connected devices designed to integrate with any IoT device, and Notecards know, out of the box, how to connect with the Notehub cloud to send as well as receive data from it.

Notehub.io is a cloud-based service for securely connecting to Notecard devices and storing data from them before sending it on to your cloud application of choice.

Here’s a diagram of how the whole setup works: start with your IoT sensors, choose the microcontroller host of you prefer, the Blues Notecard sends that sensor data to the Notehub cloud, and the Notehub cloud routes that IoT data out to your cloud provider, low code dashboard, or custom web app of your choice.

Users can interact with Notehub through its web interface or they can use the Notehub API to interact with it through HTTP requests.

The Notehub API is great for getting going, but as developers building lots of JavaScript-based dashboards and web apps to monitor and display the IoT data stored in Notehub, it quickly becomes apparent rewriting the same HTTP calls in multiple projects to fetch data from the native Notehub API endpoints isn’t easy to reuse or keep up to date as the API grows and evolves.

So we created our own open source, JavaScript-based library for the Notehub API and published it on npm for anyone to use for free. Notehub JS is designed to get you connected to the Notehub API quickly, and allow you to access all of the API routes relevant to interacting with Notehub in a JavaScript-friendly way.

If you’re not as familiar with Notehub.io and the Notehub API, check out this link to learn more.

Notehub JS Features and Benefits

Aside from being open source and JavaScript-based, the Notehub JS library boasts some significant features for users.

Extensive, up-to-date documentation of all API methods available in the Notehub JS GitHub repo and on the Blues Developer Experience website.

Let’s say you want to see how to fetch a list of devices associated with a particular Notehub project. From the Developer Experience site’s Tools & SDKs section, you can click on Notehub JS Library > Devices API and then click the method you’re looking for to see the JavaScript code implementation.

JavaScript-based code examples of every API call including authorization tokens and required and optional arguments, and real world use cases showing the implementation of the library in working code bases.

Building off the previous example, here is the JavaScript code on the Developer Experience site showing exactly how to access the Devices API method getProjectDevices() , complete with authorization and arguments.

You can copy this code line for line, replace the api_key.apiKey and projectUID strings with your own auth token and Notehub project UID, drop it into your JavaScript app, and be off to the races.

ES6-forward syntax making use of newer features like import(), async/await, and Promises, in addition to more traditional JavaScript syntax like require().

Whether you’re using this Notehub JS in a Node.js application, a web application, a TypeScript project, or even serverless functions on the edge, this library is compatible.

We built this library to be compatible with as many different sorts of JavaScript-based applications as possible: install it with your preferred package manager and use it as you see fit.

Get Started with Notehub JS Today

Anyone building applications for displaying and managing IoT data knows how tough it can be sometimes to access and shape that information into something providing useful, actionable insights. We hope that by providing the Notehub JS library for interacting with the Notehub API to the Blues community, we can make that experience a bit smoother and easier.

If you’d like to get started with Notehub JS and try it out for yourself you can:

• Visit our Developer Experience site for more information,
• Download the Notehub JS library from npm,
• Explore our real world projects using Notehub JS,
• Or check out the Notehub JS repo and consider contributing to it – we’re always looking to improve!

Happy hacking!

The post Introducing Notehub JS – the JavaScript Library for the Notehub API appeared first on Blues.

---

About Device Solutions

Device Solutions is an engineering consulting firm located in Morrisville, NC. They understand certification requirements and shepherd you through the process to expedite approvals.

Device Solutions identifies the required certifications and approvals and tests the high-risk parameters to ensure success at the time of submittal.  The testing and certification sector of their business includes FCC, UL, Bluetooth and other certifications, as well as cellular carrier approvals.

With a long history in wireless, Device Solutions has developed excellent relationships with cellular carriers, and they understand their unique requirements and processes.

They provide numerous services to get your device ready for FCC certification and carrier approval, including:

• Design reviews and consulting during the development process
• Assistance with antenna design, prototyping, and evaluation
• Pre-screening in local labs
• Management of carrier certification and approval activities

To continue your learning journey about wireless IoT device certification, watch our YouTube interview series with Device Solutions co-founder, Chris Lamb.

The post A Beginner’s Guide to IoT Device Certification appeared first on Blues.

While ascertaining location is usually handled with a GNSS/GPS module, there are scenarios where GPS is not reliable or practical. In fact, I’ll give you three exact scenarios:

1. Indoor deployments where getting a GPS satellite fix is impossible.
2. Use of a physical enclosure that prevents a GPS fix.
3. Low-power solutions that can’t afford the power drain of GPS.

Here at Blues Wireless, when we talk about gathering lat/lon coordinates, we usually refer people to the onboard GPS capabilities of the Cellular Notecard, which we highly recommend as the first (and often only) way of ascertaining location.

However, today I want to look more closely at a lesser-known capability of the Notecard: Cell Tower and Wi-Fi Triangulation.

Triangulation

If you’ve taken basic trigonometry or geometry courses, you already know that triangulation is the process of determining a location by forming triangles to the point of interest, from a series of other known points.

The Notecard provides built-in capabilities of utilizing triangulation in a few different ways: cell tower triangulation, Wi-Fi triangulation, or both!

Cell Tower Location

If you’re experienced with the Cellular Notecard, you’ve likely noticed the tower_ parameters that show up in Notehub events:

"tower_when": 1656000634,
"tower_lat": 43.074087500000005,
"tower_lon": -89.44282812499999,
"tower_country": "US",
"tower_location": "Shorewood Hills WI",
"tower_timezone": "America/Chicago",
"tower_id": "310,410,17169,77315594",

The tower_lat and tower_lon values are an approximate location of the single cell tower this Notecard was connected to at the given tower_when timestamp. While this is a nice (rough) location, it’s not useful on its own when trying to determine the precise location of a device.

For example, here is the approximate position of the cell tower used in a recent request, relative to my location:

Cell Tower Triangulation

In scenarios where GPS is unusable, performing cell tower triangulation with the Notecard can provide a massive improvement, thanks to the magic of the card.triangulate API.

To enable cell tower triangulation on a Cellular Notecard, simply issue this request:

{
  "req": "card.triangulate",
  "mode": "cell"
}

The next time the Notecard establishes a new session with Notehub, information about every visible cell tower will be uploaded and processed. A new set of location data will appear in every Notehub event, prepended with tri_, like so:

"tri_when": 1656011112,
"tri_lat": 43.07113895,
"tri_lon": -89.43272533,
"tri_location": "Shorewood Hills WI",
"tri_country": "US",
"tri_timezone": "America/Chicago",
"tri_points": 16,

Here is the updated location estimate, based on cell tower triangulation only:

As you can see, the actual location has improved significantly, and will only improve as more cell towers are visible.

NOTE: It’s important to know that cell tower triangulation comes with a non-trivial power penalty because the modem scan for nearby cell towers can take almost as long as an entire sync. Triangulation also only occurs during a connection to Notehub and there is no way to “re-triangulate” during a continuous Notehub session.

Wi-Fi Triangulation

If your host MCU has an onboard Wi-Fi module (like the ESP32), you can perform a Wi-Fi access point (AP) scan and send this data to the Notecard to perform Wi-Fi triangulation.

NOTE: Wi-Fi triangulation is an experimental, technical preview feature from Blues Wireless that is free for use today, but may use Consumption Credits in the future.

The format of the card.triangulate call is a little different when using Wi-Fi triangulation. Note that you can use cell, wifi, or both with wifi,cell when enabling triangulation.

{
  "req": "card.triangulate",
  "mode": "wifi",
  "text": "+CWLAP:(4,\"Blues\",-51,\"74:ac:b9:12:12:f8\",1)\n+CWLAP:(3,\"AAAA-62DD\",-70,\"6c:55:e8:91:62:e1\",11)\n+CWLAP:(4,\"Blues\",-81,\"74:ac:b9:11:12:23\",1)\n+CWLAP:(4,\"Blues\",-82,\"74:ac:a9:12:19:48\",11)\n+CWLAP:(4,\"Free Parking\",-83,\"02:18:4a:11:60:31\",6)\n+CWLAP:(5,\"GO\",-84,\"01:13:6a:13:90:30\",6)\n+CWLAP:(4,\"AAAA-5C62-2.4\",-85,\"d8:97:ba:7b:fd:60\",1)\n+CWLAP:(3,\"DIRECT-a5-HP MLP50\",-86,\"fa:da:0c:1b:16:a5\",6)\n+CWLAP:(3,\"DIRECT-c6-HP M182 LaserJet\",-88,\"da:12:65:44:31:c6\",6)\n\n"
}

What’s that scary-looking text field? It’s a newline-terminated list of Wi-Fi access points that follows a pattern similar to the ESP32’s AT+CWLAP command output.

Deriving Access Point Data with Arduino

If you’re comfortable issuing AT commands to your host MCU, you can send AT+CWLAP and format the response per the above requirements. However, not many of us are so cozy with AT syntax, which is why we provide the Notecard Auxiliary Wi-Fi Arduino library for an easier way of programmatically pulling a list of Wi-Fi access points with your Wi-Fi enabled host MCU, and sending them to the Notecard in one command:

// Update Notecard Triangulation Data
aux_wifi.updateTriangulationData();

Deriving Access Point Data with CircuitPython

Developing with CircuitPython? Here is an example function that uses the built-in wifi library to gather the same WAP data when used with an ESP32 MCU:

import wifi
import binascii

def get_wifi_access_points():
    """ returns a set of visible access points, corresponds to esp32 AT+CWLAP format """
    # https://docs.espressif.com/projects/esp-at/en/latest/esp32/AT_Command_Set/Wi-Fi_AT_Commands.html#cmd-lap

    all_wifi_aps = ""
    
    for network in wifi.radio.start_scanning_networks():
        
        wifi_ap = "+CWLAP:("
        
        if wifi.AuthMode.ENTERPRISE in network.authmode:
            wifi_ap += "5"
        elif wifi.AuthMode.PSK in network.authmode:
            wifi_ap += "6"
        elif wifi.AuthMode.WPA3 in network.authmode:
            wifi_ap += "6"
        elif wifi.AuthMode.WPA2 in network.authmode:
            wifi_ap += "3"
        elif wifi.AuthMode.WPA in network.authmode:
            wifi_ap += "2"
        elif wifi.AuthMode.WEP in network.authmode:
            wifi_ap += "1"
        else:
            wifi_ap += "0"
            
        bssid = binascii.hexlify(network.bssid).decode("ascii")
        bssid = ':'.join(bssid[i:i+2] for i in range(0,12,2))
            
        wifi_ap = wifi_ap + ",\"" + str(network.ssid) + "\"," + str(network.rssi) + ",\"" + bssid + "\"," + str(network.channel) + ")\n"
        
        all_wifi_aps += wifi_ap
        
    wifi.radio.stop_scanning_networks()
    
    return all_wifi_aps

Wi-Fi Triangulation in Action

How different are my results when using Wi-Fi triangulation? Well the only access point my ESP32 was able to find was my own router. However, even with just that one AP, here are the results:

"tri_when": 1656011112,
"tri_lat": 43.07113895,
"tri_lon": -89.43272533,
"tri_location": "Shorewood Hills WI",
"tri_country": "US",
"tri_timezone": "America/Chicago",
"tri_points": 16,

Which becomes amazingly accurate when displayed on a map!

Wi-Fi triangulation becomes even more valuable when you realize the power requirements are minimal, and it adds only 1-2 seconds to the sync time with Notehub.

Be sure to consult the developer documentation on Cell Tower and Wi-Fi Triangulation as there are additional settings in Notehub that you may want to change, depending on how you use triangulation in your solution.

Triangulation with Wi-Fi Notecard

Up until now, all of these instructions have revolved around using the Cellular Notecard. What about if you’re using the Wi-Fi Notecard (which doesn’t have an onboard GNSS/GPS module)?

Luckily enough, Wi-Fi triangulation is enabled on the Wi-Fi Notecard by default, no configuration changes required!

After setting up a Wi-Fi Notecard, here were the results in a given event:

"tri_when": 47,
"tri_lat": 43.07121864,
"tri_lon": -89.43263674,
"tri_location": "Shorewood Hills WI",
"tri_country": "US",
"tri_timezone": "America/Chicago",
"tri_points": 3,

Which, again, when plotted on a map, comes shockingly close to landing on my location:

Summary

While GPS is the de facto standard for identifying the precise location of an IoT device, and should always be the first option when gathering location data, the Notecard’s triangulation capabilities provide options when GPS isn’t available.

Happy Mapping with the Notecard and Notehub! 

The post Use Cell Tower and Wi-Fi Triangulation to Achieve Pin-Point Locations, without GPS appeared first on Blues.

For instance, you may want to make sure your dog remains in your yard, or that your kids stay in your neighborhood, or that your fleet of commercial trucks stay on their scheduled routes.

The most common way to enforce these boundaries is with geofences, which are virtual fences or perimeters around a physical location.

In this article you’ll learn how to build an asset tracking solution that can take GPS readings, and send out alerts when the tracker leaves a configured geofence. You’ll do all this using a product that requires no subscription fees, and which allows you to completely customize to meet your needs.

Let’s get started by looking at the hardware you’ll need.

How to build the asset tracker

Here at Blues we make the Notecard, a small System-on-Module that makes IoT connectivity dead simple.

To help you get up and running with the Notecard quickly we also make Notecarriers, which are companion boards that let you plug in a Notecard, and immediately get both GPS and cellular connectivity (through on-board antennas).

By combining the Notecard with a Notecarrier, you can have everything you need to build a fully functional and customizable asset tracker for around $80.

If you don’t have hardware yet, no worries. I’ll do my best to explain how each geofencing step works so you can get an idea of how things work before you buy.

If you do have a Notecard and Notecarrier, you next need to run a few commands to get the Notecard and its cloud backend, Notehub, configured for asset tracking.

You can watch the video below for a detailed guide on the steps you need to take, or if you prefer written instructions, you can also read through the steps on the Notecard’s asset tracking documentation.

Once you complete the asset-tracking setup, your Notecard should be taking regular GPS readings, and you should be able to view them as _track.qo events in your Notehub backend. Your event list in Notehub should look something like the following.

At this point you have a simple asset tracker working, which is cool, but the point of this article is to implement geofencing, so we have some more work to do. Specifically, to implement geofencing on top of these readings you need to take three steps.

1. Route your data from Notehub to an external server or service to handle events.
2. Determine whether the GPS coordinates in those events are in, or out, of a geofence.
3. Send alerts when an asset is not within a geofence.

Let’s start by tackling the first step, and look at how to route data from Notehub.

How to route the data

One great thing about using the Notecard is once you have data in Notehub, it’s trivial to route that data to other services or servers that you want to use. That service could be one of the big clouds like AWS or Azure, it could be an IoT protocol like MQTT, or it could be your own server with at an HTTP/HTTPS endpoint.

NOTE: If you’re new to Notehub, I’d recommend taking a few minutes to complete the Blues routing tutorial, as it’ll walk you through how routes work, and how to create a simple one so you can see it in action.

Because you have a lot of options, there are also a lot of different ways you can add geofencing logic—meaning you can get geofencing working with virtually any platform or service you like using.

That being said, sometimes it’s nice to see a specific example of how to implement a solution. With that in mind, I’m going to show how to build a geofencing route using a service I like—Netlify. If you have a different platform in mind, you can use my example as an outline of how to implement the same sort of logic on other platforms.

Let’s look at how it works.

How to build a serverless function in Netlify

Netlify is an easy-to-use hosting platform. Netlify makes it simple to spin up web sites and apps, and to host serverless functions when all you need is a bit of logic at an HTTPS endpoint.

And a serverless function is a great fit for geofencing, as all you need is an endpoint that can accept incoming GPS coordinates, and determine whether those coordinates live within a geofence.

NOTE: You may find it handy to refer to my completed cloud function throughout the rest of this guide. The code is open source, and free to clone or alter as much you need.

To get started you’ll want to refer to Netlify’s documentation on starting a new site. Once you have a site, Netlify expects any cloud functions to live a netlify/functions directory within your app. For example, here’s the folder structure I used for my geolocation function.

.
├── netlify
│   └── functions
│       └── boundary-check
│           └── boundary-check.js
└── package.json

NOTE: Netlify’s Cloud Functions also support TypeScript and Go, if you prefer those languages over JavaScript.

If you’re following along you’ll want to create that folder structure, and then use the code below as the contents of boundary-check.js—which at the moment just returns a simple message and a 200 response code when you hit the endpoint.

exports.handler = async function (event, context) {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: "Hello World" }),
  };
}

To test it you can install the Netlify CLI and run netlify dev from your command prompt or terminal, which start up a local server that runs your cloud function.

Next you’ll want to hit the endpoint, http://localhost:8888/.netlify/functions/boundary-check, using curl or any HTTP testing tool and ensure that you get a 200 response back.

Eventually you’ll want deploy this function so you can hit the endpoint from a Notehub route. But first let’s look at how to change this code to create and enforce a geofence.

How to create and enforce a geofencing

As discussed earlier, a geofence is a virtual fence or boundary around a physical area. In code, we’ll represent a geofence as an array of latitude/longitude coordinates that form a shape.

Luckily there are online tools to make deriving these coordinates fairly trivial. (I like using this polyline tool from Keene State College.)

For example, these coordinates create a geofence around the lower peninsula of Michigan.

-86.6142463, 44.2294566
-86.6142463, 44.2215838
-86.9439933, 41.7549222
-82.3715013, 41.6482883
-82.5034002, 44.0323206
-83.4047087, 45.4524242
-85.0534437, 45.8364541
-86.6142463, 44.2294566

If you’re following along, go ahead and create your own set or coordinates to use as a geofence. I’d recommend picking a fairly small area, like one city block, as it’ll make testing easier when you go to try this out.

Once you have a set a set of coordinates, your next step is to determine whether a given latitude and longitude from your tracker is within that virtual fence.

An algorithm than solves this problem is reasonably complex, but luckily there’s a Stack Overflow thread with solutions in a variety of programming languages, including this JavaScript solution I ended up using.

By adding the pointIsInPoly() function from the Stack Overflow link above, and a bit of logic to call it with a set of coordinates, here’s what my first functional version of boundary-check.js looked like.

// These are the coordinates to create the geofence that I built on
// https://www.keene.edu/campus/maps/tool/.
const geofence = [
  { x: -86.6142463, y: 44.2294566 },
  { x: -86.6142463, y: 44.2215838 },
  { x: -86.9439933, y: 41.7549222 },
  { x: -82.3715013, y: 41.6482883 },
  { x: -82.5034002, y: 44.0323206 },
  { x: -83.4047087, y: 45.4524242 },
  { x: -85.0534437, y: 45.8364541 },
  { x: -86.6142463, y: 44.2294566 },
];

const handler = async (event) => {
  let body;

  // I expect a “lat” and “lon” in the body of the request as input.
  // This next bit of code does two checks—one to ensure a body is
  // on the request, and another to ensure there’s a “lat” and “lon”
  // provided.
  try {
    body = JSON.parse(event.body);
  } catch (e) {
    return { statusCode: 500, body: "Invalid JSON body" };
  }

  const lat = body.lat;
  const lon = body.lon;

  if (!lat || !lon) {
    return { statusCode: 500, body: "Invalid GPS coordinates" };
  }

  console.log("Received request for " + lat + ", " + lon);

  // Determines whether the lat/lon from the request is in the geofence
  // using the algorithm from 
  // https://stackoverflow.com/questions/217578/how-can-i-determine-whether-a-2d-point-is-within-a-polygon/43822141#answer-17490923
  const isInGeofence = pointIsInPoly({ x: lon, y: lat }, geofence);

  return {
    statusCode: 200,
    body: JSON.stringify({
      isInGeofence: isInGeofence,
      lat: lat,
      lon: lon,
    }),
  };
};

Once you save this change, you can try sending coordinates and see whether they are within the provided geofence. To do so, you’ll want to send a POST to the same endpoint you used before, and to include a JSON body that includes a valid lat and lon.

For example in the POST below I send a body of { "lat": 42, "lon": -84 }, which is a point right in the middle of Michigan, and correctly get back {"isInGeofence":true}.

And if I bump up the latitude to a value well outside Michigan, I correctly get back {"isInGeofence":false}.

If you’ve been following along you now have a cloud function that can determine whether a set of coordinates is within a geofence. As a next step you’ll want to deploy your cloud function so that it’s available on the public internet.

Once deployed you can see your function’s base URL in the Netlify dashboard.

And you can try POSTing your data to the new endpoint to make sure everything is still working correctly.

With this step done, and the function publicly available, let’s next look at how to send data to your function in Notehub.

Routing your data

Back in your Notehub project, head to the Routes page, click Create Route, and then select the General HTTP/HTTPS Request/Response route.

Next, give your route a name (like “Geofencing”), and paste in your function’s URL in the URL field.

After that, scroll down, and under Filters select the _track.qo Notefile, as that’s the only type of Notefile you need to send to your function.

Under that, set Transform Data to “JSONata Expression”, and set its contents to the following.

{
    "lat": where_lat,
    "lon": where_lon
}

NOTE: JSONata is a handy language that allows you to query and transform JSON objects. The code above selects only the GPS latitude and longitude from a _track.qo event to send to your endpoint. You can learn more about JSONata on the Blues documentation.

With these values in place go ahead and hit Apply changes to save and activate your route.

Now, the next time a _track.qo event comes in from your asset tracker, Notehub will automatically route that event to your cloud function to determine whether it’s within your defined geofence.

To test this you’ll need to generate a _track.qo event, which you can do by taking your Notecard for a quick walk or drive. When that _track.qo event comes in, you’ll be able to view a new Route Log tab, which lists all the places Notehub routed your data, and the result. If all went well, you should see a 200 response from your newly created cloud function.

And at this point, you now have data flowing all the way from the Notecard, to a cloud function which determines whether the location is within a configured geofence—which is pretty cool!

But there’s one last step—although it’s nice to see the isInGeofence result in Notehub, the real power of geofencing is getting an alert when an asset leaves its configured territory. Let’s look at how to set that up.

Sending alerts

Alerts are often critical to geofencing projects, as you usually want to know when your dog leaves your yard, or when your kids leave your neighborhood. The type of alert you want to send can vary based on the project, and there are services for sending email alerts, push notifications, SMS messages and more.

That being said, I again want to show a specific workflow in this article, and my personal favorite way to send alerts is with Twilio.

Twilio is a service that does many things, but I primarily use it as a very easy way to send SMS messages. Twilio’s documentation on sending messages is quite good, and you’ll want to refer to it for information on how to create a Twilio trial account, and how to register a Twilio phone number for testing.

Once you have an account and number, you’ll next want to add code to send Twilio messages to your cloud function. I started by installing the twilio and axios npm packages.

npm install twilio axios

After that I added the following new function, which sends the message itself.

const TWILIO_SMS_TO = "YOUR_PERSONAL_PHONE_NUMBER";
const TWILIO_SMS_FROM = "YOUR_TRIAL_NUMBER_FROM_TWILIO";

const sendTwilioSMS = (lat, lon) => {
  return new Promise((resolve, reject) => {
    console.log("Sending Twilio SMS notification");
    twilio.messages
      .create({
        body: "Your asset left its geofence. Current location: https://maps.google.com/maps?q=" + lat + "," + lon,
        to: TWILIO_SMS_TO,
        from: TWILIO_SMS_FROM,
      })
      .then(() => {
        console.log("SMS message sent successfully");
        resolve();
      })
      .catch((e) => {
        console.error("SMS message send failed", e);
        reject();
      });
  });
};

Then I added the following code to my main handler(), which conditionally sends the message if the coordinates are not within a geofence.

const isInGeofence = pointIsInPoly({ x: lon, y: lat }, coordinates);
if (!isInGeofence) {
  try {
    await sendTwilioSMS(lat, lon);
  } catch (e) {
    return { statusCode: 500, body: "Failed while sending SMS notification" };
  }
}

NOTE: As a reminder the project’s full source is available on GitHub.

At this point we’re almost done, but there’s one last problem to solve.

Rate Limiting

Currently this code sends an SMS message when invoked with a location that lives outside of the geofence—and it does so every time. Meaning, if you take this tracker outside of your geofence, it’ll spam an SMS message every time the tracker takes a reading.

If a tracker being outside a geofence is an emergency situation this might be what you want, but for many projects you only care about the first time a tracker leaves a geofence in a given interval. To implement that you need to introduce some sort of rate limiting.

To rate limit, you have to store the last time you sent a message, and ensure a given amount of time has passed before you send another one.

// Psuedo code to show roughly what you need to do
let lastNotified;
const ONE_HOUR = 1000 * 60 * 60;

if (!isInGeofence) {
  var currentTime = new Date().getTime();
  if ((currentTime + ONE_HOUR) > lastNotified) {
    sendSMSMessage();
    lastNotified = currentTime;
  } else {
    // We’ve already sent a message within the last hour, so do nothing
  }
}

The tricky thing is you’re running code in a stateless cloud function—meaning, you can’t store variables like lastNotified, because the next time the cloud function runs that variable will be gone.

To to get this working you need to store lastNotified outside of the cloud function, and to do that we’re going to use a Notecard’s environment variables.

Using environment variables

Blues environment variables allow you to manage state on Notecards, fleets of Notecards, and even entire Notehub projects.

There’s a lot you can do with environment variables, but for our example we’ll keep things simple, and just store a single variable that tracks the last time you sent out an SMS notification.

This is fairly easy, as Notehub has an HTTP API that makes setting a variable as simple as a quick POST. Here’s the code I used to do the update.

// The current time in seconds
const timestamp = String(new Date().getTime() / 1000);

// Learn how to generate this token at:
// https://dev.blues.io/reference/notehub-api/api-introduction/#authentication
const NOTEHUB_AUTH_TOKEN = "YOUR_VALUE_HERE";

// Make sure to sub in your own project and device ids.
const ENDPOINT = "https://api.notefile.net/v1/projects/app:38591b70-4c0b-40f3-9e0c-c2c319eef1e3/devices/dev:868050040247765/environment_variables";

return new Promise((resolve, reject) => {
  console.log("Updating last notified timestamp in Notehub", timestamp);
  axios
    .put(
      ENDPOINT,
      {
        environment_variables: { last_notified: timestamp },
      },
      {
        headers: {
          "X-SESSION-TOKEN": NOTEHUB_AUTH_TOKEN,
        },
      }
    )
    .then(() => {
      console.log("Last notified timestamp updated successfully");
      resolve();
    })
    .catch((e) => {
      console.error("Failed to update Notehub environment variable", e);
      reject();
    });
  });
};

And back in my main handler(), I added a bit of code that updates the environment variable before sending out the SMS alert.

const isInGeofence = pointIsInPoly({ x: lon, y: lat }, coordinates);
if (!isInGeofence) {
  try {
    await updateEnvVar();
  } catch (e) {
    return { statusCode: 500, body: "Failed while updating Notehub" };
  }
  try {
    await sendTwilioSMS(lat, lon);
  } catch (e) {
    return { statusCode: 500, body: "Failed while sending SMS notification" };
  }
}

This new code handles updating lastNotified, but we still need to read lastNotified and use that to enforce the rate limit. We could do that in our cloud function, but there’s one last trick we can do in Notehub to keep our code cleaner.

Back when you were creating a Notehub route, you included the following JSONata to send only a lat and lon to your cloud function.

{
    "lat": where_lat,
    "lon": where_lon
}

In addition to using JSONata to filter your JSON, Notehub also offers a few custom JSONata features you can use to implement some powerful behavior. And for this project we’re going to use $doNotRoute() a custom function that allows you to not route an event under certain conditions.

To try it out, return to Notehub and edit your geofencing route. Scroll down to your JSONata, and replace it with the following code.

(
  $result := {
    "lat": where_lat,
    "lon": where_lon
  };
  $result := (received > ($number($last_notified) + (60 * 60))) ?
    $result : $doNotRoute();
)

This code implements the rate limiting that we first looked at in pseudo code earlier. We start by storing the result in a JSONata variable.

$result := {
  "lat": where_lat,
  "lon": where_lon
};

Next, we check received, which is a Notecard-included timestamp, against $last_notified, which is the environment variable we set in our cloud function.

If received > ($number($last_notified) + (60 * 60)), aka if it’s been an hour since we last notified, we set $result equal to itself, ensuring the event gets routed as normal. But if it has not been an hour, we set $result to $doNotRoute(), which prevents the route from hitting the cloud function at all.

$result := (received > ($number($last_notified) + (60 * 60))) ?
  $result : $doNotRoute();

Once you have everything in place it’s time to try things out. Make sure you save your updated Notehub route, and that you redeploy your cloud function in Netlify with any changes you’ve made. After that, you’ll need to generate a _track.qo outside of your configured geofence. (Hopefully you made a small geofence earlier to make testing easier )

If everything works correctly, as soon as the Notecard reports a _track.qo outside of your boundaries, you should see a text message come through with a link to the last recorded location.

Wrapping up

The Notecard and Notehub make asset tracking simple, and give you a solid foundation for building custom geofencing solutions.

In this article I showed you one way you can implement geofencing, with a JavaScript cloud function on Netlify—but the power of the Notecard and Notehub is how easy you can customize just about everything, and implement geofencing with your backend and hardware of choice.

The code I used in this article is available on GitHub—feel free to copy or modify it as much as you’d like. And you can purchase the hardware I used from the links below.

• Notecard in Blues Shop
• Notecarrier in Blues Shop

If you have any questions about getting geofencing working, reach out in our community forum and we’ll be happy to help you out.

The post How to Build an Asset Tracker With Geofence-Driven Alerts appeared first on Blues.

In the first year of home ownership 77% of buyers faced unexpected repair costs, and over 2/3 of those surveyed paid upwards of $1,000 on repairs. 

Leaks can happen any time and water can be one of the most destructive substances, especially when it’s where it shouldn’t be and you don’t know about it. Leaks can even happen when the power’s out, meaning Wi-Fi powered leak detectors are out of luck too. 

In this Hackster tutorial, I’ll walk you through how to build your own cellular-enabled, low-code leak detector, with instant SMS alerts via Twilio whenever water is detected. 

How it Works

We’ll take a Blues Wireless Cellular Notecard, slot it into the Blues Wireless Notecarrier-A, add an analog water sensor, and use the newly released Notecard firmware feature that allows for autonomous reporting of GPIO state changes without a host microcontroller.  

A small LiPo battery powers the whole shebang, as well. 

This code will tell our Notecard to watch for changes to its AUX1 pin, and if the pin’s state changes from LOW to HIGH (like when water is detected by the sensor), it will trigger an SMS alert from Twilio. 

And if water is detected? 

Build Your Own Leak Detector

If you’d like to make your own leak detection device, complete instructions are available here in this Hackster tutorial. 

To get started, grab the following hardware: 

• Cellular Notecard 
• Notecarrier-a 
• Songhe water sensor 
• LiPo battery with JST connector (any LiPo will do) 

Happy hacking!  

The post Build an IoT Smart Leak Detector with SMS Alerts when Water is Detected appeared first on Blues.

As an essential component of a smart device, it’s important to understand your connectivity options, know how to avoid associated IoT project pitfalls, and evaluate and implement a wireless connectivity solution.

What is IoT Device Connectivity?

For our purposes, let’s define IoT device connectivity as a bi-directional data pathway between the physical device and the desired cloud application. Connectivity enables device communications, regardless of the hardware or software components. This could be a global asset tracker attached to a shipping container delivering transit data to a customer’s Amazon Web Services deployment. It could also be an Industrial IoT device for predictive maintenance that runs AI at the edge and receives updated machine learning models monthly that trigger SMS alerts on anomalous conditions.

Connectivity on the IoT Project Roadmap

When building a connected device, you are assembling a product with multiple layers of a technology stack. At a high level these include:

• Enclosure design
• Hardware
• Software
• Connectivity
• Cloud platform
• Data visualization

These components involve different people or teams, and each has their own development cycle. During each development cycle new information and constraints will be discovered, potentially impacting the project with delays and additional costs. These can include device security, testing, and certification. According to a survey by Cisco, 75% of IoT projects are unsuccessful.

To IoT builders, this isn’t news. After all, each project is bespoke, building something that has never been built exactly in this manner before. There are endless possibilities in device design, and these independently managed parts of the project must all function together.

It’s not surprising that a piece of advice we hear often in the IoT space is to find ways to reduce the complexity of development cycles. Project risk and uncertainty grows in relation to the number of project tasks that must be built.

Consider building the elements of the device that add unique value to your project and buying the functional elements, like connectivity. Then you can decide how to proceed with customization when deploying and scaling your IoT project.

Challenges of IoT Connectivity

For those who don’t build internet-connected devices, connectivity is an assumed given. It’s an easy perspective to adopt. After all, we walk around with portable supercomputers in our pockets that are always connected to the internet. We are almost always under a cellular network connectivity umbrella, so we assume connecting any device to the internet should be as simple as turning on our smartphone.

For the builders of cellular IoT in particular, this isn’t as true as we’d like. Adding connectivity is a highly nuanced and often time-consuming portion of an IoT project. Here at Blues Wireless, we like to refer to this complexity as “the strings of cellular IoT.” These are the things that are out of a developer’s control when building IoT solutions. They slow developers down, cut off choice, or provide unnecessary complexity and duplication of effort.

These are some of the biggest challenges of cellular IoT:

• Difficult-to-program modems.
• Developer guardrails.
• Device lifecycle management pitfalls.
• Security risks.
• Going from prototype to scale.

Evaluating a Connectivity Solution

When it comes to network connectivity, there are an intimidating number of options and it can be confusing to determine the best network solution for your IoT project. Every IoT application has unique requirements, and there are many pros and cons when determining which option (or combination thereof) is right for your project.

Even seemingly obvious choices are nuanced. Let’s look at some considerations for Wi-Fi connectivity. If your device will be deployed in a commercial building, Wi-Fi is often the default choice due to its low cost and broad availability.

For prototyping, it might be easiest to start with Wi-Fi connectivity. But for full deployment, circumstances like power outages have to be taken into consideration if your IoT solution is key to a critical system. In addition, Wi-Fi requires network maintenance and can be seen as less secure than other options if transmitting sensitive information. If your device will be deployed outdoors or for mobile applications, Wi-Fi or Ethernet will not work.

Some of the most popular connectivity options for IoT device deployment are:

• Bluetooth
• Ethernet
• Wi-Fi
• Cellular
• LPWAN (LoRa and LoRAWAN)

In an ideal world, these connectivity options would all be power-conscious, and have excellent range and high bandwidth. Unfortunately, that combination does not exist. Each connectivity option represents a tradeoff between these things. Depending on your use case, you will weigh the needs of data transmission, device placement, and power source against the network constraints.

There are even more decisions to make when it comes to specific connectivity networks, including modern cellular protocols like NB-IoT and LTE-M. You can dig in here to learn what cellular IoT is. This post goes over the advantages of cellular connectivity, which are extensive:

• Low Power Potential: If you are not transmitting large amounts of data, cellular modules can consume ~8μA of power at rest (put into context, most phone chargers are 1 million microAmps, generally understood as 1 Amp).
• Bandwidth: Cellular networks can send large amounts of data.
• Range: There is no other network technology with the global reach of cellular.
• Security: SIM-based authentication and utilization of VPN tunnels makes cellular the most secure option.
• No Power Requirement: Networks are still available in the case of a power outage.

Using Design Cycles Wisely

“If all you have is a hammer…” goes the colloquial saying. When building an IoT project roadmap, it can be tempting to group all device features into a “to build” phase when some of the needs could simply be acquired. Cellular connectivity is one feature that is endlessly complicated to build with very few instances of ROI.

Blues Wireless provides a complete IoT connectivity layer using a global cellular network through a hardware and cloud combination. Integrating the hardware portion of Blues Wireless, (our System-On-Module called Notecard) can be achieved in as few as 2 lines of code.

Data sent outward from the device is sent to the cloud portion of Blues Wireless (called Notehub) and routed onward to any public or private cloud application. Blues hardware modules are pre-certified for FCC and PTCRB and will automatically provision themselves onto the cellular network with no additional development or administrative work required.

Because Blues Wireless encapsulates the connectivity layer from device to customer cloud, development teams can focus their development cycles on the features and capabilities that bring the device to life, rather than spend cycles on utility functionality.

Further, Blues Wireless is a production-ready solution, used by customers who send billions of data transactions annually. This means Blues can be incorporated early into the design cycle, and kept in the production design, avoiding any connectivity rework. Changing cloud endpoints can be done through the Blues Wireless cloud solution Notehub using no-code tools.

Without Blues Wireless

With Blues Wireless

Add Connectivity to Any Device in 30 Minutes

Blues Wireless offers IoT development kits for popular microcontrollers. If you have a preferred microcontroller, simply purchase that kit for evaluation. Each kit has a guided tutorial showing how to assemble the device, connect to the internet, and send data back and forth between device and cloud.

If you don’t have a preferred microcontroller, consider our Swan-based kit. Swan is a Feather-compatible microcontroller with enough physical specifications to run machine learning models at the edge, and supports C/C++, Arduino, and CircuitPython. This means development teams can stick with the platforms they know and prefer, while using the latest in microprocessor technology.

3 Steps to Evaluate Blues Wireless for Your Connectivity

Step 1 – Select a Starter Kit

Select a starter kit based on your preferred MCU: ESP32, Raspberry Pi, or our own Feather-compatible microcontroller, Swan.

Step 2 – Unbox

Plug the Notecard SOM into the provided Notecarrier, then connect to your existing hardware.

Step 3 – Test

Follow along with the Blues Wireless Quickstart Guide. In 30 minutes, you’ll connect your device to the internet via the global cellular network, and data flowing from device to cloud, and back to device again.

More Resources for IoT Device Connectivity

While necessary, IoT device connectivity is a utility that is much less time-consuming, complex, and expensive to buy than build. Take steps to reduce the challenges of your IoT project by taking the time to evaluate the best connectivity solution for your device and learning how to avoid common pitfalls. For more advice and resources on the next steps of your device build, visit the Blues Wireless community forum.

The post How to Add IoT Connectivity to Any Device appeared first on Blues.

While most of the time it is merely an annoyance, losing power (especially when we aren’t aware of it) can lead to disastrous outcomes. This could mean anything from loss of equipment due to current surges when power is restored, to lives literally being on the line in critical care settings.

In this tutorial on Hackster, I walk through how to build a globally-available, cellular-enabled, power outage detector, complete with instant SMS notifications powered by Twilio.

What’s in the Box?

We take a Blues Wireless Cellular Notecard, attach it to a Blues Wireless Notecarrier-A, and use a newly-released Notecard firmware feature that allows for autonomous reporting of GPIO state changes without a host microcontroller:

{
   "req":"card.aux",
   "mode":"gpio",
   "usage":[
      "input-pulldown",
      "off",
      "off",
      "off"
   ],
   "sync":true,
   "file":"power-outage.qo"
}

I also use a small LiPo battery with a JST connector (any capacity will do), and a micro USB cable (with a wall outlet adapter):

Let’s Build a Power Outage Detector

Check out the complete instructions in this Hackster tutorial.

Want to build one yourself? All you need to get started is the following hardware:

• Cellular Notecard
• Notecarrier-A
• LiPo battery (any LiPo will do)
• Micro USB cable (with a wall socket adapter)

Also, feel free to take 10% off your order of a Notecard + Notecarrier-A to build your own with this discount code.

Happy Hacking!

The post Build a Cellular-Enabled Power Outage Detector with Twilio SMS Notifications appeared first on Blues.

The Internet of Things (IoT) enables companies to optimize the management and operation of facilities through data visibility, while improving safety and reducing upfront and ongoing expenditures. For liquid terminals operators looking to digitize their businesses with IoT data, it’s best to find ways to remove complexity from the project anywhere possible.

I will be on-site at ILTA’s International Operating Conference & Trade Show and can discuss with you how Blues Wireless simply and affordably connects your assets to the internet to quickly start gaining data insights for your business. Feel free to message me, Raghu Balijepalli, on LinkedIn to ask questions about our edge-to-cloud connectivity solution.

If you would like to discuss your next steps in-person, please set up a meeting with me during the event. I hope to see you there.

About the International Liquid Terminals Association Conference

The International Liquid Terminals Association (ILTA) is an advocacy and professional networking organization for the liquid terminals industry, and it will hold its annual conference and trade show June 13-15 in Houston, TX. ILTA hosts the largest industry gathering, attracting over 4,000 liquid terminals industry professionals.

Participants learn about issues impacting the industry, discuss new ways to improve operations, and foster relationships with other professionals from around the world. A common topic within this year’s session tracks is how to digitalize liquid terminals operations.

The Liquid Terminals Industry is Changing

Employing affordable, user-friendly, innovative technologies will allow businesses to become safer, more profitable, efficient, and sustainable. The Internet of Things (IoT) brings real world assets online by connecting physical and digital environments with hardware and software.

Uses of the IoT within the liquid terminals industry are wide, and some of the applications of new technologies being discussed include:

• Robotic tank cleaning
• Smart glasses for remote worker safety
• Remote terminal and pipeline monitoring
• Digital inspections and data tracking

Top 3 IoT Use Cases for Liquid Terminals

Analog Tank Monitoring with Machine Learning at the Edge

Snapshot: Collecting data from legacy, analog, or closed LNG systems is unobtrusive and affordable with machine learning at the edge. Retrofitting your existing systems with an IoT device powered by Blues Wireless allows you to digitize your assets without overhauling systems. Advantages include digital visualization, data trends, alarming and reporting, and predictive maintenance.

• Project time: 8 hours
• Cost of materials: < $300
• Get started with: Blues Wireless Raspberry Pi Starter Kit

Global Supply Chain Asset Tracking

Snapshot: Adding asset tracking capabilities to an existing device and tracking data on your terms is easy with the integrated GPS and accelerometer of the Blues Wireless Notecard. Essentially functioning off-the-shelf as an asset tracker, you can focus on customizing your device and integrating the data into your existing ecosystem. Advantages include near real-time location monitoring of high value assets, condition monitoring, and asset utilization tracking.

• Project time: 1 hour
• Cost of materials: < $200
• Get started with: Blues Wireless Notecarrier-A and Notecard

Digitization of Legacy Systems with Retrofit IoT Devices

Snapshot: Using a thermal imaging device to detect and alert for anomalies helps prevent major catastrophes, predict maintenance, monitor cold supply chains, and ensure worker safety. The device can be built into a handheld device or retrofitted to legacy systems, eliminating the need for expensive system overhauls.

• Project time: 3 hours
• Cost of materials: < $200
• Get started with: Blues Wireless Raspberry Pi Starter Kit

How Blues Helps Transform IoT Projects

For operators, it can be a challenge to know where to begin the process of digitalization. Blues Wireless has contacts in consulting firms and our own team of experts to help you get started.

For the builders of IoT devices, Blues Wireless provides a fully integrated edge-to-cloud solution. The Notecard, our hardware component, provides instant cellular connectivity on a tiny System-on-Module about the size of a half dollar. We also have a Wi-Fi version for fast prototyping and proof of concept. Our data routing service, Notehub, is a thin cloud communication layer. The JSON-based interface allows you to easily customize when and how your data is transferred, as well as where it is sent. There is no MCU or cloud lock-in, so you can fully customize your device to suit your business needs.

Competitive Pricing

With Blues Wireless, you only pay for what you use, and you’ll never worry about monthly subscription fees or contracts. Usage is based on data routing services and events performed through Notehub, which are paid for using Consumption Credits. The purchase of a Notecard automatically credits 5,000 Consumption Credits to the associated billing account, and each account is refreshed to 5,000 credits each month. This is generally more than enough to get a project off the ground without paying any additional fees. As projects scale, operators can purchase more Consumption Credits with volume discounts available.

Blues Wireless Evaluation Process

3 Steps to Evaluate Blues Wireless:

1. Select a Starter Kit

Each starter kit comes with a Notecard and a Notecarrier compatible with your MCU of choice. You can pick a starter kit based on ESP32, Raspberry Pi, or our own Feather-compatible microcontroller, Swan.

2. Unbox Your New Hardware

Plug the Notecard into the provided Notecarrier, then connect to your existing hardware.

3. Start Collecting Data

Follow along with our quickstart. In 30 minutes, you’ll have a device connected to the global cellular data network, and data flowing from device to cloud, and back to device again.

Pro-Tips

• Feather kit and Swan kit contain MCUs. If you want our Raspberry Pi kit, you’ll need your own Pi.
• Swan lets you write code in C/C++, Arduino, and CircuitPython. It’s also a powerful MCU and ready to run on edge-based machine learning like Edge Impulse. We have a guide for that.

View Development Kits

Make Operations More Efficient with IoT

IoT technology enables the efficient management and operation of liquid terminals facilities through data visibility. When you’re ready to explore IoT solutions for your business, finding ways to remove complexity from your project will be critical to its success. Blues Wireless solves your connectivity challenges with an edge-to-cloud solution that works out of the box. Contact me today to discuss the next steps for your business.

The post IoT Solutions for Liquid Terminals appeared first on Blues.