CC Blog Projects Research & Design Hub

Cellular, The Forgotten Wi-Fi

Written by Jeff Bachiochi

Part 3: Using NoteCard, an Embedded Communications Module

In Parts 1 and 2 of this series, Jeff introduced us to a novel method of providing light in a meeting place located in a remote area without electricity, by using a low-voltage solar energy system. Last month he described the use of Wi-Fi for communicating the system’s performance. In Part 3, he uses NoteCard, a cost-effective embeddable cellular module for sending data to his home from a remote area.

  • How can I use NoteCard in a project?
  • Why might I want to use a cellular module for embedded communications?
  • What is an interesting solar project I could build at home?
  • HUZZAH32 Feather
  • NoteCard module

When I got my first Motorola flip cell phone, it was like Star Trek come alive. The Star Ship Enterprise’s communicator was similar in size. I installed a sound clip to imitate the familiar opening of the communicator when I opened my Star Tac flip phone. In the beginning you couldn’t call to the next town with out incurring toll changes. When you left your cell network coverage, there were extra roaming charges. Today we have unlimited calling, text, and data plans. Streaming your favorite movie/series requires a rather large bandwidth of streaming data. Everything today is data-oriented.

In my September 2023 article (”Local Isolation: Using the Sun’s Energy,” Circuit Cellar 398, September 2023) [1], I described a low-voltage solar energy system I built for lighting my Scout troop’s large storage shed. I described the battery I chose, and the Modbus protocol with RS-485 serial communication used for remote monitoring of the system’s performance (”sniffing” or listening to communication on the bus, and decoding each message). Then, in my October article (”Local Isolation Using the Sun’s Energy: Part 2: Modbus Client,” Circuit Cellar 399, October 2023) [2], I expanded on this node’s ability to do more than just listen and decode. This month, I discuss my use of a modern module, to make use of cellular networks for communication.

I initially considered repurposing an older cell phone to make a connection with the ”Eagle’s Nest” solar project. However, the monthly fee for that would be greater than $100 a year. While that would certainly make a worthy project, there are much less expensive options today. Like the Wi-Fi transceivers that allow us to connect to a wireless network at home, modules are now available to make use of the cellular networks that are growing in connectivity everywhere. The data bandwidth we need for most applications is extremely low. We can therefore take advantage of the cellular system without the steep monthly charges.

RED, WHITE, AND BLUES

One of the companies that provides this service is Blues Inc. [3]. Let’s start with development tools. These are divided into two parts: the ”Notecard” and the ”NoteCarrier.” The Notecard (Figure 1) is an embeddable communications module; it has all the necessary hardware to handle global cellular communications over LTE-M, NB-IoT, or Cat-1. The NoteCarrier is a prototyping PCB that contains a socket for the Notecard and for a microcontroller (MCU).

FIGURE 1
The NoteCard contains a complete cellular and GNSS (Global Navigation Satellite System) you can use in your own circuit or in a NoteCarrier via the M.2 high-density (0.5mm pitch) edge connector.
FIGURE 1
The NoteCard contains a complete cellular and GNSS (Global Navigation Satellite System) you can use in your own circuit or in a NoteCarrier via the M.2 high-density (0.5mm pitch) edge connector.

While you can put a NoteCard on your own circuitry and save some more cash, I will take advantage of the NoteCarrier, because it supports a 24-pin Adafruit Feather breakout header. You’ll recall that I have been using the Adafruit Huzzah 32 module for this project since day one! If you want to use this with other MCUs, there are breakout points for every necessary connection to the NoteCard. NOTE: The newer starter kits feature a Feather-compatible MCU, the Swan, based on an ARM Cortex-M4.

The NoteCard can provide communications via one or more of these data networks, LTE-M, NB-IoT, GPRS, LTE Cat-1, and WCDMA. I am using the LTE CAT-M NoteCard for North America, which is perfect for medium-throughput applications requiring low power, low latency, and/or mobility, such as asset tracking, wearables, medical, POS and home security applications. In my application, I have power via solar, but no Internet. Cell coverage in the area makes this solution possible. Let’s see how the NoteCard/Carrier combination is used.

To complement this hardware, Blues Inc. has a cloud-based site (”NoteHub”) that communicates with the NoteCard and syncs data both to and from the NoteCard. Last month’s project ended with our Modbus data sent via Wi-Fi to a MQTT server, using JSON objects [2]. At the time, you may have been thinking that there may have been better ways of sending this data. That was actually a setup for this month’s use of the cellular service. A JSON object is simply a way of passing data in a readable form, as in {solarPower:4}. While an object can contain multiple messages separated by commas, this single message indicates the variable solarPower is equal to a value of 4. On the NoteCard end we have functions that can be called to pass and retrieve data. Data from NoteCard is placed into a NoteFile (.qo extension ) on NoteHub, and once received is added to a NoteFile with a .db extension. Data from a NoteFile with a .qi extension on NoteHub is sent to the NoteCard on any sync.

One powerful feature of NoteHub is event routing, which allows one to forward data from NoteHub to a public/private cloud, including AWS, Azure, Google Cloud, a messaging platform like MQTT, or a custom HTTP/HTTPS endpoint. Note that MQTT is supported. Let’s take a step back and look at how our solar project is now configured to use the NoteCard.

NOTECARRIER

I’m using a NoteCarrier-AF for this project. The present offering, the NoteCarrier-F, is just a slight variation of this, it uses an external antenna, for instance. The Huzzah32 plugs into the Feather socket. We can continue to use the RS-485 converter described the initial project column [1]. This only needs a 6-wire connection to the NoteCarrier-F. Note that the schematic (Figure 2) consists of adding the RS-485 chip to the NoteCarrier, so that we can make the Modbus connection to the Eagle Nest’s solar system.

FIGURE 2
Only 6 (4) connections from NoteCarrier are required to interface with the RS-485 converter. The solar energy system used Modbus (using RS-485) for inter-module communications.
FIGURE 2
Only 6 (4) connections from NoteCarrier are required to interface with the RS-485 converter. The solar energy system used Modbus (using RS-485) for inter-module communications.

Since I am using the Huzzah Serial1port for Modbus and the serial USB port is being used as the debug port, I will be using the I2C interface to the NoteCarrier/Card. Either serial or I2C can be used to communicate with the NoteCarrier-F. All connections between the Note Card and my Huzzah 32 are made through the NoteCarrier. I just added the six connections to my RS-485 circuit module [1].

You will need to install the note-arduino library available on Blues GitHub page [5]. This library gives the user about a dozen functions. For this project we’ll only use six. Like many libraries, one of the first functions you place in the setup() function is Notecard.begin(0x17, 0x20, Wire). The parameters for this function define whether the NoteCard interface will be via a serial port or I2C; here the setup is for the I2C interface. Once I’ve started the primary serial port with Serial.begin(115200), I can command the Notecard to use this port for debug messages with Notecard.setDebugOutPutStream(Serial).

All communication between our micro and the NoteCard will be JSON objects. We’ve already used JSON objects in our Arduino code to identify a register source and its value. Objects are a group of one or more members (name:values pairs), surrounded by braces, {}. An object with multiple members are separated by a comma.

The purpose of the NoteCard is to form a communication path between our micro and the NoteHub, which is the cloud-based receiver of our cellular data. We need to inform NoteHub who we are and how we will communicate with it. This is accomplished by creating a JSON object. A hubRequest command is used to configure and monitor the connection between the Notecard and Notehub.

J *req = Notecard.newRequest(”hub.set”) ;

will initialize this object with a member identifying the command.

Next, we can add some JSON members to the object. The second member identifies us and ties us to our specific NoteCard, JaddStringToObject(req, ”product”, myproductID). The string variable, myproductID, will be discussed further in the NoteHub section to follow. Next we’ll configure how the communication channel will be used by defining the ”mode”, JaddStringToObject(req, ”mode”, ”continuous”). There are basically two modes: ”periodic” (default) and ”continuous”. Periodic is used to keep NoteCard in a low power mode (µA) and connect with NoteHub periodically. The continuous mode (tens of mA) keeps a communication path open for immediate transfer of data. In either mode, the current draw is 250mA when the modem is active. I’ll be transferring data once per minute.

We have a complete command (JSON object) built now, and it looks like this:

{

”req” : ”hub.set”,

”product” : myProductID,

”mode” : ”continuous”

}

We are now ready to send this JSON object to the NoteHub. The sendRequest function handles this. Initially, we are coming out of a power-up, and we don’t know if the NoteCard has finished all of its initialization (it has its own application to execute). If we ask it to send a request to NoteHub before it is ready, it could fail. We can either check for that or use the sendRequestWithRetry function. I’ll let the NoteCard handle any error and use the function sendRequestWithRetry(req, 5). This will retry the send command every 5 seconds.

Let’s take advantage of the NoteCard’s time service. Once it has completed a sync with NoteHub, it will have a reference epoch (number of seconds since January 1, 1970.) This requires a second JSON object, one that holds the response from the NoteCard. The command J *rsp = Notecard.requestAndResponse(Notecard.newRequest(”card.time”)) is used to initialize the rsp object to the response of the function. The NoteCard’s card.time function returns an object containing multiple members. We want the member ”time” : reference epoch, where reference epoch is a number (signed 32-bit integer). This number can be easily extracted from the object using the command myEpoch = JgetNumber(rsp, ”Time”). After we have what we want, we can delete the rsp object from the NoteCard with Notecard.deleteResponse(rsp). I adjust myEpoch for my local time zone. I’m using the TimeLib.h to handle the time on the Arduino.

We’re now finished with all the necessary NoteCard initialization in the Arduino’s setup() function, so it’s on to the loop() function where we have previously gathered data via the Modbus connection to the solar system. We don’t have a lot of things to do in our loop() function. We do need to decide how often to request data from any of our devices in the solar system. The variable sampleDelay constant determines this timing, and our function requestRegisters() asks for 20 registers in the solar controller, starting with register address 0x100. Besides requesting data in a timely fashion, our loop also checks for any activity on the Modbus (excluding any requests we make). If we have activity, hopefully a response to our request, we call the mbProcess() function to dissect the response. If this response was due to our request, the data is placed into the appropriate group of defined variables. Our previous programs have initialized local holding registers for every piece of data we might be interested in from any of the devices connected on the Modbus. For this program we are interested in just 20 of these.

With data collected, we are now ready to have this data transferred via cellular communication to the notehub.io cloud. We’ll use the now familiar newRequest function to handle this. The last request was for the hub.set command, now our JSON object will use the note.add command, J *req = Notecard.newRequest(”note.add”). We’ll add a sync member to the object, JaddBoolToObject(req, ”sync”, true) to force the NoteHub to handle this immediately. Then all our data is added as additional members, which will all be sent in one fell swoop (Listing 1).

When we’ve added all the data we want to include, we issue a command to send the data, Notecard.sendRequest(req). You may have noticed that the member data was added to ”body” and not to ”req” as in our hub.set command. This alters the JSON object by adding a member ”body” that is an array of the data. Because I enabled the debug port, we can see this sent to the USB serial port (Serial). See Listing 2.

LISTING 1
This is where each variable is added to the JSON object body. Each member will contain the variable name and its value.

JAddNumberToObject(body, “batterySOC”, batterySOC);JAddNumberToObject(body, “batteryVoltage”, batteryVoltage);JAddNumberToObject(body, “batteryCurrent”, batteryCurrent);JAddNumberToObject(body, “controllerTemperature”, controllerTemperature);JAddNumberToObject(body, “batteryTemperature”, batteryTemperature); JAddNumberToObject(body, “loadVoltage”, loadVoltage);JAddNumberToObject(body, “loadCurrent”, loadCurrent); JAddNumberToObject(body, “loadPower”, loadPower);JAddNumberToObject(body, “solarVoltage”, solarVoltage);JAddNumberToObject(body, “solarCurrent”, solarCurrent); JAddNumberToObject(body, “solarPower”, solarPower); JAddNumberToObject(body, “batteryCumulativeChargeHours”, batteryCumulativeChargeHours); JAddNumberToObject(body, “batteryCumulativeDischargeHours”, batteryCumulativeDischargeHours); JAddNumberToObject(body, “solarCumulativePowerGenerated”, solarCumulativePowerGenerated); JAddNumberToObject(body, “solarCumulativePowerConsumed”, solarCumulativePowerConsumed);
LISTING 2
You can see a copy of the complete JSON object that's sent via the debug serial output on the HUZZAH32 micro. Once connected to the solar system's modbus, these values will be pulled from the solar controller.

{	“req”:”note.add”,	“sync”:true,	“body”: 	{		“batterySOC”:0,		“batteryVoltage”:0,		“batteryCurrent”:0,		“controllerTemperature”:0,		“batteryTemperature”:0,		“loadVoltage”:0,		“loadCurrent”:0,		“loadPower”:0,		“solarVoltage”:0,		“solarCurrent”:0,		“solarPower”:0,		“batteryCumulativeChargeHours”:0,		“batteryCumulativeDischargeHours”:0,		“solarCumulativePowerGenerated”:0,		“solarCumulativePowerConsumed”:0	},	“crc”:”0002:98F82C2C”}

Note the JSON object contains four members: ”req,” ”sync,” ”body,” and ”crc.” The member ”body” has an array of members associated with it. The ”crc” member ensures that the data is transferred without error.

So far in this project, I’ve collected data from the solar system installed in Troop 96’s equipment shed, which is off the grid. Because we have no way of monitoring the system, except for a Bluetooth app on my cell phone—which only works while I’m near the shed—a cellular connection was added. My MCU, which collects the data, is interfaced with a Blues Inc. NoteCard, which is now sending the collected data to NoteHub.io, Blues’ cloud service [4]. Let’s now see what NoteHub.io does with this data.

NOTEHUB

When you purchase a NoteCard, you get hardware that you can immediately power up, and follow an online tutorial on how to set up your NoteCard and connect to it from the web browser. Open the Blues.io webpage for NoteCard quickstart and NoteCarrier-F [6]. You will get an error message if your browser is not supported. A supported web browser ( Chrome, Opera, or Edge) will connect directly to the NoteCarrier USB port and manipulate the NoteCard directly with it, as if you had a MCU attached to it. This initial connection with the USB cable is used for the tutorial to make it easy to experiment with the Noteard/NoteCarrier kit right out of the box.

When you connect the NoteCarrier via USB to your PC, it should be recognized as a new serial port connection. You can now connect to it, and you should see some messages just under the green bar in the upper right of the screen (Figure 3). The NoteCard is directed to make contact with NoteHub. Once its sign-in is complete, you should see a sign-on message:

Welcome to the Notecard In-Browser Terminal.

Start making requests below.

(For advanced info, use the ‘help’ command.)

************************************

~ Connected to serial

~ DeviceUID dev:864475044208469 (NOTE-NBGL500) running firmware 5.1.1.16026

Your NoteCard’s UID is shown along with the revision of the firmware running on the card. Now you can enter commands. The quickstart suggests entering the following command:

{”req”:”card.version”}

You can copy this into the input terminal at the lower right. Click on ”>” to send the request. You’ll note that the response is in JSON format, and the info is the same as the sign-on message.

FIGURE 3
The NoteHub Quick Start Tutorial will guide you to quickly get connected using your NoteCard/NoteCarrier without the need to write any code. This is a great way to get some hands on experience with the hardware before you begin writing your application.
FIGURE 3
The NoteHub Quick Start Tutorial will guide you to quickly get connected using your NoteCard/NoteCarrier without the need to write any code. This is a great way to get some hands on experience with the hardware before you begin writing your application.

New users are required to set up an account on NoteHub. Under the heading ”Set up Notehub,” see ”Create a Notehub Project” and click on ”Notehub Project Dashboard.” The quickstart guides you through this by opening a new browser window (NoteHub.io), where you can enter your name, email address, and a password. When you have completed this, you are ready to create a project. Click on ”+Create Project’” and add a project name such as ”quickstart” to the New Project card. Note that you are given an account and a UID prefix. The product UID becomes the product UID prefix plus the project name. Remember that earlier, we initialized a variable product_UID in our Arduino sketch? This project’s ”productUID” is what you will use to define that product_UID, so your application will be associated with the NoteCarrier/NoteCard, theNoteCard/NoteHub communication channel, and this project on NoteHub. When you’re happy with the information, click on ”+Create Project” and your browser will go to your project page. Make note of the ”ProductUID” here, and with it you can continue with the quickstart by entering the following command into the input terminal:

{”req”:”hub.set”, ”product”:”com.your-company.your-name:your_product”}

Then substitute your productUID for ”com.your-company.your-name:your_product” in the right-hand member of the JSON pair. When the command is sent you will see the command and response in the output terminal. A no-error response is sent as ”{}”. You can switch back to the Blues.io tab and go on with quickstart entering commands including:

{”req”:”note.add”,”body”:
{”temp”:35.5,”humid”:56.23}}

— ADVERTISMENT—

Advertise Here

At this point, we’ve requested the NoteCard to send some data to our project in NoteHub. Go back to the NoteHub.io tab and click on ”events.” You should now see a list of events or communiques you requested via the NoteCard. Select an event and click ”view” to see the event data. The last command sent was typical data. This is saved as an event in the .qo file. If you select that event and view it, you will see this event’s data under the ”Body” tab (Figure 4).

FIGURE 4
The tutorial shows you how to send data from your NoteCard/NoteCarrier to NoteHub and see the actual data arrive as an event.
FIGURE 4
The tutorial shows you how to send data from your NoteCard/NoteCarrier to NoteHub and see the actual data arrive as an event.

You should investigate all the different screens available on your project’s page, and become familiar with how things are presented, because we will be coming back to this shortly. You should also experiment with sending other commands using the terminal in the Blue.io window.

THE REAL THING

We have enough information to proceed with our project. My Huzzah 32 MCU is chomping at the bit to be programmed with this latest application and be placed on the NoteCarrier’s ”Feather Headers.” We discussed the additions to an application to support NoteCard/NoteHub. These have been added to our project from last month [2]. The use of Wi-Fi last month, as part of the ESP32 MCU, is now replaced by the NoteCard’s cell service communication. Using the Arduino IDE, this new application can now be programmed into the micro. Upon power up, the Huzzah’s application makes itself known to the NoteCard. This NoteCard (NBNA-500) uses a Quectel BG95-M1 modem, which covers the LTE_M Data Networks in United States, Canada, and Mexico. (See other models for global coverage.)

Our product on Notehub.io is receiving our data periodically, based on the constant reportDelay, once an hour. However samples are taken periodically, based on the constant sampleDelay, here every 10 seconds. Each sample is saved along with a running total, so that when reported once an hour, the average sample is reported. The equation for the first register of interest, batterySOC, is:

batterySOC = batterySOCTotal/sampleCount;

This is handled in the averageTotals() function prior to adding the data members to the ”body” object. A final command, notecard.sendRequest(req), will request our NoteCard to send our data to NoteHub.

Assuming this has happened and it has arrived as an event, we need to get the events routed to the Raspberry PI installed on my home network. Click on the route tab and then the ”+Create Route” button. Here is a list of the routing destinations you can choose from. Each has a tutorial to help you if necessary.

  • HTTP/HTTPS endpoints
  • AWS
  • Azure
  • Google Cloud function
  • MQTT
  • PROXY
  • ThingWorx
  • RadResponder
  • snowflake
  • twillo
  • Edge Impulse
  • slack
  • amazon S3
  • Datacake

In this case, I am going to choose MQTT. This leads to the MQTT configuration page in Figure 5. Here you can give your route a name. Only two other items are required, Broker URL, and Topic. The Raspberry Pi is on my local WAN, so I can go to my Modem/Router and find my actual IP address. While this is not a static IP, I found it is not likely to change unless you change service provider. You can always use a dynamic DNS (Domain Name Server), if you want to have a static name served to your dynamic IP, like No-IP.com

FIGURE 5
My application data wants to eventually end up being sent to my Raspberry Pi, running an MQTT server. NoteHub can be used to route events to an external data sink. My choice is MQTT, and NoteHub makes it happen by answering a few questions.
FIGURE 5
My application data wants to eventually end up being sent to my Raspberry Pi, running an MQTT server. NoteHub can be used to route events to an external data sink. My choice is MQTT, and NoteHub makes it happen by answering a few questions.

Topic defines the topic for each messages routed (forwarded to my Pi); the payload will be your event data. I use the [product]/[device] which substitutes my ProductUID ”/” DeviceUID as the topic. These can be found on the Device tab by double clicking on the appropriate device. You’ll need this for the MQTT IN node in your Node-REDflow [7]. Last month I used the Huzzah’s Wi-Fi and showed how, if your system was in range of Wi-Fi service, you could send the data directly to the MQTT server. There is little to change to that Node-RED flow. The difference is in how the data comes in.

In the Wi-FI project [2], each JSON object contained one member (name/value pair) per packet. NoteHub will route the whole event, consisting of multiple members (including more than just the data), in one packet. You can see most of this in Node-RED in the debug panel on the right of Figure 6. We just need to change the Topic in the MQTT In node to the one used in the NoteHub MQTT setup. Because each event sent to NoteHub from NoteCard contains all our data in a single packet, the event is routed to our MQTT server all at once. If you viewed an event on NoteHub (events, click on an event, then view), you can choose ”body”, to see the data members (Figure 7), or ”JSON” to see the complete event information. Note that the JSON object contains multiple members (name/value pairs), one of which is ”body.” This member has an object as its value. The ”body” object contains multiple members, our data

All of this is sent to the MQTT server, so each event will need to be disassembled into separate messages. The first split node divides the single message into multiple messages. If enabled, Debug 20 will show the separated messages in the debug panel on the right. They are ”event,” ”session,” ”best_id,” ”device,” and so on. Note that the message ”body” contains all of our data. The second split node divides the ”body” message into separate messages, as can be seen using debug 12. Now we have a whole lot of individual messages, just like the ones sent using Wi-Fi in last month’s project. The ”switch’” node routes only those that are our data messages to separate outputs, where they can be massaged and displayed on the Node-RED dashboard (Figure 8).

FIGURE 6
Events are routed by NoteHub to my Raspberry Pi. I'm using Node-RED to take each MQTT packet sent and split the JSON object into individual members.
FIGURE 6
Events are routed by NoteHub to my Raspberry Pi. I’m using Node-RED to take each MQTT packet sent and split the JSON object into individual members.
FIGURE 7
Each of the 20 variables pulled from the Solar Controller via the Modbus and recorded by the Huzzah 32 are transferred to the NoteCard and sent to NoteHub. There you can see an event's body contains 20 members (name/value pairs).
FIGURE 7
Each of the 20 variables pulled from the Solar Controller via the Modbus and recorded by the Huzzah 32 are transferred to the NoteCard and sent to NoteHub. There you can see an event’s body contains 20 members (name/value pairs).
FIGURE 8
Once Node-RED has received the MQTT JSON packet and split it into individual members, each members is sent to the appropriate chart or textbox for display on the Node-RED Dashboard.
FIGURE 8
Once Node-RED has received the MQTT JSON packet and split it into individual members, each members is sent to the appropriate chart or textbox for display on the Node-RED Dashboard.
COST OF SERVICE

Today you can get a starter kit for North America for $99 or the EMEA (Europe, Middle Asia, and Africa) starter kit for $109 from Blues.io. This includes NoteCard, NoteCarrier, Swan (Feather-compatible micro), and 10 years of cell service! The cell service includes 500MB of free cellular data and 5,000 free Consumption Credits. Yup! For about a hundred bucks you can get started with a cellular connection that will give you up to 10 years of service. Renewals and extra data are equally valued.

So how can Blues make any money on this stuff? Naturally, offering a development kit and service at such a low cost removes any initial hesitation to try out their hardware. Their real income will come from reoccurring revenue. This is measured by cellular data limit and the consumption credits (CC). Each of my events is about 1.5KB. If we divide the cellular data cap by my event packet size we get 500,000,000B/15,00B = >300,000 messages. If I sent this every minute, that would be ~200 days. Cellular data and CC are renewed each month, so I should never run out. You can think of consumption credits as NoteHub requests, of which an event route costs 1 credit, that would be 5,000 routes. Again, if we send an event every minute, that would be 60 minutes * 24 hours * 31 days = 44,640 routes per month. That is a bit over our 5,000 CC budget. 40,000 extra CC’s cost about $30. If you limited the routes to every 10 seconds, you would stay under budget. You’ll notice I’m only updating things once an hour so that’s only 24 routes/day * 31 days = 744 routes/month. It’s easy to see that in some applications you may need to purchase additional credits.

UNCOVERED

There are so many things that I have not covered here. I think if you are at all intrigued by this, you should visit the Blues website and look a little deeper. I’m not sending any data to the NoteCard from my Pi. This cellular solution is closed loop, and can be used for both monitoring and control. So I could be using the cellular connection to say, turn ON/OFF the power to the lighting units, but at this point there is nothing I want to control at the shed. You’ll be fascinated with some of the applications listed on the Solutions tab of the Blues website.

If you are contemplating any kind of project that won’t have a permanent home on some Wi-Fi network, you should consider using cellular communication. You don’t have to fool around with connection requirements of SSID and security key each time you move to a new location. You may have noticed that one of the object members returned in the MQTT packet is the longitude and latitude of the cell tower picking up our cellular transmission.

Once you have learned the fundamentals by following the tutorials, you will find it easy to tack this cellular system onto any project. I’m excited to get to use the new solar lighting system in our Troop’s shed. We’re starting up regular meetings again after the summer break. Our first meeting is this Monday night, and with the sun beginning to set earlier each night, having adequate lighting will surprise everyone. Everything is in place just in time. I’ll be adding weekly meetings and monthly camp outs to my fall schedule. Yep, there is too much to do and so little time. 

REFERENCES
[1] Jeff Bachiochi, ”From The Bench: Local Isolation: Using the Sun’s Energy.” Circuit Cellar 398, September 2023, pp. 52-62.[2] Jeff Bachiochi, ”From the Bench: Local Isolation Using the Sun’s Energy: Part 2: Modbus Client,” Circuit Cellar 399, October 2023, pp. 50-61.[3] Blues, Inc. helps you create reliable and innovative connectivity solutions via cellular and Wi-Fi IoT-driven data systems
https://www.blues.io.[4] A hosted service for securely routing Notecard data to your cloud application of choice. Manage fleets of devices and update host and Notecard firmware over-the-air.
https://blues.io/products/notehub/[5] The note-arduino library is available on Blues’ GitHub page
https://github.com/blues/note-arduino[6] Blues Inc. Quickstart page for NoteCard and NoteCarrier-F
https://dev.blues.io/quickstart/notecard-quickstart/notecard-and-notecarrier-f/[7] Node-RED is a browser-based editor that makes it easy to wire together flows using the wide range of nodes in the palette that can be deployed to its runtime in a single-click.
https://nodered.org/

RESOURCES
Adafruit | adafruit.com
Arduino | www.arduino.cc
Renergy, Inc. | renergy.com

Code and Supporting Files

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • NOVEMBER 2023 #400 – Get a PDF of the issue

Keep up-to-date with our FREE Weekly Newsletter!

Don't miss out on upcoming issues of Circuit Cellar.

— ADVERTISMENT—

Advertise Here


Note: We’ve made the Dec 2022 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Would you like to write for Circuit Cellar? We are always accepting articles/posts from the technical community. Get in touch with us and let's discuss your ideas.

Sponsor this Article
Website | + posts

Jeff Bachiochi (pronounced BAH-key-AH-key) has been writing for Circuit Cellar since 1988. His background includes product design and manufacturing. You can reach him at: jeff.bachiochi@imaginethatnow.com or at: www.imaginethatnow.com.

Supporting Companies

Upcoming Events


Copyright © KCK Media Corp.
All Rights Reserved

Copyright © 2024 KCK Media Corp.

Cellular, The Forgotten Wi-Fi

by Jeff Bachiochi time to read: 20 min