Bob continues his article series on LoRa. In Part 3, he looks at Comcast’s LoRaWAN-based commercial network MachineQ. The article explores what it was, what it is now and how we can leverage what MachineQ has to offer to help us design new embedded Internet-of-Things systems.
A few years ago, I came across the following quote:
We are not used to a complicated civilization; we don’t know how to behave when personal contact and eternal authority have disappeared. There are no precedents to guide us, no wisdom that wasn’t made for a simpler age. We have changed our environment more quickly than we know how to change ourselves.
If that sounds a little like your life and mine in today’s world, would it surprise you to learn that it was written by Walter Lippman in 1914? There are several parts of that quote that speak to me. But the part about how our environment is changing faster than we can keep up is especially relevant to our field of embedded systems design. Almost every day I feel as if I cannot keep up with all of the new stuff: new technologies, new tools, new processors and new suppliers—to name just a few. I feel like I’m constantly trying to catch up. I hear about a new technology that everyone is talking about and I don’t even know what it is. And I write about a new technology and find that it changes underneath me.
Certainly, the world of the Internet of Things (IoT) is changing fast. We’re in the midst of an article series on LoRa and LoRaWAN—the Long Range and Low Power modulation technique that is growing in its applicability to a number of projects with which we are involved. In the first article (Circuit Cellar 351, October 2019), I introduced LoRa. Then last month (Circuit Cellar 353, December 2019), we looked at The Things Network (TTN). When I started this article series on LoRa I mentioned that there were three approaches to connect your LoRa device to the cloud. One was to create your own gateway and network using the specifications from the LoRa Alliance. Another approach was to use The Things Network, which I introduced in the last article.
A third way is to make use of an existing commercial network being developed by Comcast called MachineQ (Figure 1). Comcast started with some pilot sites for MachineQ in San Francisco and then Philadelphia. The coverage map for San Francisco and the bay area was impressive. Could they and would they expand this nationwide? In 2017, Comcast announced that it was going to roll out a commercial LoRaWAN network in 12 new cities in addition to the existing networks in San Francisco and Philadelphia [1].
MACHINEQ CHANGES DIRECTION
I was very excited that Comcast was committed to developing a nationwide network much like the worldwide cell network. I thought it was a bold and brilliant business move that would advance the world of IoT sensors beyond what we have even imagined. We could develop our embedded systems using LoRa and tie it into an existing network just like we have been doing with cell technology. We didn’t need to create our own network of gateways nor depend on the more loosely organized TTN. There would be rigid and enforced standards of what our LoRa devices would need to meet essential to commercial success. (I was just reading about a TTN gateway owner who had someone else’s device hogging the network. He was bemoaning the fact that he had no place to report the violator. His only recourse was to shut down the rogue device.) With this bold move by Comcast, IoT sensors would proliferate beyond what some of us were dreaming.
— ADVERTISMENT—
—Advertise Here—
But, somewhere along the line, MachineQ changed direction. By late 2018, it no longer offered a scalable IoT network service. Clearly it would be a major investment to build such an infrastructure. Possibly, since Comcast is not a cell carrier, it realized that it would need towers that it didn’t have. But for whatever reasons, MachineQ has redefined itself. All that said, it still offers us as embedded system designers some distinct advantages. That’s what I’ll cover here in this month’s article.
But that isn’t all that was wrong in that first article. Again, I was embarrassed because, with things changing so fast, I missed the release of three new LoRaWAN specifications in October 2018. After reading my first article, Robert Lacoste, one of Circuit Cellar’s great columnists (The Darker Side) graciously informed me that the LoRa Alliance released these new specifications to support firmware updates over-the-air (FUOTA).
The first specification, the LoRaWAN Remote Multicast Setup v1.0.0 Specification [2] defines how the gateway can set up a group of devices than can receive a broadcast message. In addition, it defines a unique encryption key for this group and a mechanism for conveying the key to the group. Finally, the specification provides the definition for switching devices temporarily from Class A (receive only) to Class B or Class C.
The second specification, the LoRaWAN Fragmented Data Block Transport v1.0.0 Specification [3] defines how large blocks of data can be sent in fragments in a broadcast mode.
The third specification, the LoRaWAN Application Layer Clock Synchronization v1.0.0 Specification [4] defines a means for end devices to synchronize their clocks to within one second of the network’s GPS clock. This is necessary to allow all of the devices to transition from and back to Class A devices at the same time.
These new specifications provide the necessary building blocks for Class A devices (transmit only) to receive a firmware update over-the-air in fragments. This method still has limitations (Robert Lacoste has a project that takes a month to update 100k of firmware OTA using similar specifications), which we will cover in a future article in this series.
WHAT MACHINEQ OFFERS
Gateways: MachineQ’s redefinition has moved it from being a network service provider to a network platform provider. It offers an indoor gateway that enables users to connect up to 8 devices to the cloud with either WiFi, Ethernet or cell. It offers two outdoor gateways: one that supports 16 devices and one that supports 64 devices (Figure 2). Both outdoor gateways support cellular or Ethernet. The cellular based gateways provide the cell service through AT&T for just under $10/month.
Sensors: MachineQ sells a variety of battery-operated sensors packaged in waterproof enclosures for immediate deployment to enable users rapid time to market. The MQFlex sensor can be used to monitor temperature, humidity, acceleration, magnetic flux, orientation and barometric pressure (Figure 3). The Open/Close sensor can be used to monitor window and door access. The Push Button sensor provides a rudimentary human machine interface. The Light sensor can be used to detect motion or measure various ambient light conditions. The Motion, Light and Temperature sensor bundles these three parameters in one package. Two types of temperature and humidity sensors are provided for either indoor or outdoor use (including low temperatures for monitoring freezers or refrigeration). A dust, temperature and humidity sensor can be used to monitor air indoor quality. The Vibration sensor can be used in anti-theft and security settings. Two types of water leak sensors are offered: one is a non-locating rope style leak detector and the other detects water in a specific location.
Software: MachineQ even provides the software to develop and deploy (MQcentral) your LoRa devices and gateways (Figure 4). Don’t want to depend on its dashboards and want to roll your own? MachineQ also provides the APIs to retrieve gateway and device statistics, provision and authenticate your gateways and sensors, send messages to your sensors, obtain the real time data from your sensors and more.
— ADVERTISMENT—
—Advertise Here—
HOW DOES IT HELP ME?
Although I was deeply disappointed that MachineQ didn’t carry through with its initial business plan, it does provide good value for a number of use cases. One of the largest use cases will be for system integrators. As a system integrator, you could sell and deploy specialized LoRa systems to a wide variety of customers using the components provided by MachineQ without a significant investment in non-recurring development.
Imagine that you wanted to help food handlers comply with food safety regulations regarding temperature. Without developing any hardware or software, you could deploy multiple temperature and humidity sensors wherever the food is stored or handled. Install one or more gateways and provide the MachineQ MQcentral software for a dashboard control configured specifically for that customer. Presto! You are ready to sell your product. Requiring no wiring, no hardware or software development and no cell carrier negotiations, system integrators could rapidly meet customer needs at a reasonable cost.
Assuming that you deploy eight temperature sensors (totaling about $400), one eight- channel indoor gateway (about $200), one year license for the software (about $600), plus one year of cell coverage ($120). With all that, you could deploy a very robust system for a cost under $1500. Plus—because the model will require monthly (for cell service) and yearly charges (for the software license)—this product can produce a continuous stream of income.
Another set of use cases where MachineQ can be deployed would be for those developing sensors not covered with the MachineQ offerings or for those who want to reduce the cost of the sensor. In this case, you would utilize the MQspark development kit to provide the LoRa integration. Since the development kit is built around the Arduino platform, you could also pick from among the 280 Grove sensors [5] compatible with the Arduino. Or, you could develop your own sensor. There’s another major advantage of the MachineQ approach over The Things Network approach: MachineQ provides a built-in ability to perform Over-The-Air (OTA) updates to their sensors.
WHERE IT DOESN’T HELP
Certainly, one of the big factors for some will be cost. Anyone deploying 1,000s of sensors every year will be leaving money on the table if they use MachineQ sensors. Most of our customers are looking at costs of less than $25 per node. That’s why MachineQ allows you to build your own end devices. The same could be said for those deploying 100s of gateways. The standard and classic make versus buy trade-offs will need to be made to decide if MachineQ is right for you.
Another concern with the sensors is the “up to 5 years” of battery life. We have had only one project in the last 30 years that would accept having to replace a battery in the product after 5 years. But we are not system integrators. For the system integrator who is billing the customer a monthly charge for the software license, cell service and support, changing the batteries out might not be a big deal.
Right now, MachineQ does not offer any output devices. If you need to turn on a valve or actuator, you will need to develop your own device. Therefore, for the system integrator without development expertise, a lot of projects will not be possible. Again, the MQspark development kit has been set up to be as easy to use as possible. But it just is not a turn-key solution if any output devices are needed.
SUMMARY
MachineQ started out as an answer to one of my IoT dreams—a low power alternative to our cellular IoT network. But even with this shift in focus, MachineQ will still allow system integrators and smaller players to get into the IoT business without a significant amount of non-recurring costs. For larger players, MachineQ provides a great platform for rapidly doing a proof-of-concept.
Next time we’ll discuss a LoRa project using TTN. We will look at the software and hardware for both an end-device and for the gateway. But of course, only in thin slices. 
RESOURCES
References:
[1] https://corporate.comcast.com/news-information/news-feed/machineq-comcasts-enterprise-internet-of-things-service-expanding-to-12-major-us-markets
[2] LoRaWAN Remote Multicast Setup v1.0.0 Specification https://lora-alliance.org/sites/default/files/2018-09/remote_multicast_setup_v1.0.0.pdf
[3] LoRaWAN Fragmented Data Block Transport v1.0.0 Specification https://lora-alliance.org/sites/default/files/2018-09/fragmented_data_block_transport_v1.0.0.pdf
[4] LoRaWAN Application Layer Clock Synchronization v1.0.0 Specification https://lora-alliance.org/sites/default/files/2018-09/application_layer_clock_synchronization_v1.0.0.pdf
[5] Grove Sensors for Arduino https://www.seeedstudio.com/category/Sensor-for-Grove-c-24.html
MachineQ | www.machineq.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • FEBRUARY 2020 #355 – Get a PDF of the issue
— ADVERTISMENT—
—Advertise Here—
Bob Japenga has been designing embedded systems since 1973. From 1988 - 2020, Bob led a small engineering firm specializing in creating a variety of real-time embedded systems. Bob has been awarded 11 patents in many areas of embedded systems and motion control. Now retired, he enjoys building electronic projects with his grandchildren. You can reach him at
Bob@ListeningToGod.org
![Figure 1 The heart is actually two pumps in one. The right side is responsible for pumping blood into the pulmonary circuit, which transports blood to the lungs, where it picks up oxygen and delivers carbon dioxide for exhalation. The pulmonary circuit then returns blood back to the left side of the heart. The left side is responsible for pumping blood to the systemic circuit, which transports oxygenated blood to virtually all the tissues of the body. The systemic circuit then returns deoxygenated blood and carbon dioxide to the right side [1].](https://i0.wp.com/circuitcellar.com/wp-content/uploads/2022/08/383_Bachiochi_Figure_1-e1659683125950.jpg?resize=145%2C100&ssl=1)
