Connectivity in an Iot World: Part 2 - A Guide to Long Range

In my previous article, I went into detail about the short range possibilities for connecting a device to the outside world. But sometimes you need to go the distance; and when I’m talking about distance, i’m talking about 1-12 miles line of sight!

In this article, I go into the details about the different types of long-distance embedded communication. These are the types of protocols that get your sensor data to the cloud so they can be consumed by your service and transformed into something useful for the end customer.

Let’s start.

Weightless P


Websites can be full of jargon but when it comes to the implementation and support that’s where things get hairy. Weightless P touts some serious functionality including AES encryption, variable data-rate up to 100kbps, and firmware over-the-air updates.

There are things though that just irk me which give you an idea of the priorities these folk have. It boils down to the following:

1. I may be getting too picky here but their website is not HTTPS. For anyone who takes security seriously, making their website HTTPS for their viewers and potential customers is one of the easiest things they can do to protect them.

2. Their implementation is rather young and their development boards are built on FPGA designs. I’m not sure why there is this added complexity. Most of the competition can be implemented in unison with a low power ARM chips and a separate radio. There is also no clear design path as to what chips, designs or modules to integrate into end products. That is particularly troublesome.

3. Speaking of development boards, they’re being released for the first time this month for $1250 USD.. Comparing to other solutions that’s a high cost to start implementing an end solution.

My conclusion: there isn’t enough documentation or information behind the use of their platform. Which leads me to believe it would be tough to adopt. Without examples to build end products on, they may find themselves with little to no community following them.

RPMA

RPMA has some serious promise. They tout long range, low power and security to boot. RPMA additionally operates in the 2.4GHz band which makes it easy to bring to other counties without too much of a fuss. That matters because 2.4GHz band is universally accepted. It’s what Bluetooth, Wifi and Zigbee operate on.

It was also re-assuring to see a rather prominent module developer, U-Blox, engineer a pre-certified module for RPMA. That is always a good sign that the technology is going in the right direction!

Unfortunately, here’s where things fall off:

1. RPMA is a closed standard and currently there is only one company to take on the initiative to develop the technology.
2. Not as low power as you may think: when I went and looked at the NANO-S100’s datasheet. It touted a 0.99 W full transmit power versus the the 0.475 W of U-Blox’s CAT M1 LTE module. At this point, the only way to stay “low power” is to play games with duty cycles. Though 2.4Ghz is inherently faster than 900mHz, without an empirical test, we really don’t know what’s more power efficient.
3. As it is a closed standard, there is little to no documentation on the gateway side of things or how Ingenu’s technology or required service works. Which is a huge turn off for anyone who’s trying to build something that will last in the field 2-5 years. Here is some pictures from Github of their dev kits. Note the size of their gateway!

 

5. Finally, to put the icing on the cake, their service is closed and all your valuable data has to go through their servers before ever hitting yours. It is simplicity at the cost of customer data privacy and your intellectual property.

My conclusion

As someone who wants complete control over the data that his devices are producing, I’m going to stay far away from any solution that is closed and requires me to connect to a third party API to get our customer data. There’s just not enough value in what they’re offering to justify giving up that freedom.

On the other hand, I’m very excited about the capabilities of the technology and could be a global competitor to some of the other technologies on this page. Without being able to test this solution, the jury is still out. My gut feeling is that the technology isn’t quite there considering all the secrecy and lack of public information.

Cat 1 and Cat M1 LTE


Verizon has made some serious strides into the IoT world. I recently was on the phone with one of the regional sales reps and was surprised as to how many customers they had in that particular region.

There are two categories of transfer speeds that are available in the USA right now. They serve different needs as one is particularly useful for low data-rate applications versus high data rate. More information below:

First, Cat M1 is the cell-phone industry’s answer to all the other technologies on this page. It’s a rather slow data rate at 1 Mbps along with that though is a much lower required power compared to it’s big brothers.

Additionally, Cat 1 is also available for designs that need more throughput. Cat 1 modules are specified for 10Mbps down and 5 Mbps down. I would consider Cat 1 the type of module you may place in a security camera that is one 24/7 and doesn’t have as many power constraints like an embedded system.

Here’s a handy chart from a post on Ericsson’s blog about the speeds:

There’s always tradeoffs though. Here’s where things start to fall off:

1. Service subscription’s mean $$$ and Verizon is not going to stop that anytime soon. This means as a product engineer, you will have to be creative about how to save costs and keep overhead low.
2. Modules are on the pricey side but you get what you pay for! In my research, I’ve seen modules priced anywhere from $36 USD to $80 USD in small volumes. Many cost sensitive engineers would start crying right around here but there is an advantage: they take all the hassle in the development of your own LTE enabled device out of the equation. From FCC certification all the way to the final Verizon Post-Certification you are covered so you can focus on the application rather than the cringeworthy process of getting everything certified once they work. Thus being able to LTE enable your product in a board spin is extremely powerful and fun. The more complicated part is getting a Verizon account and negotiating monthly data costs.

My conclusion

This, of course, is the money shot right now. Many companies are rallying around the use of CAT 1 or M1 for IoT. It makes sense as most of the infrastructure is already in place. Verizon is leading the way with AT&T hot on their heels.

The subscription model sucks but when you combine LTE with another technology on this page, that’s when things start getting interesting.

LoRa


I originally latched on to LoRa early in my research process. It’s the most widely supported protocol with companies like Microchip making pre-certified modules for end products. It seemed like the best solution to the long-range problem of embedded devices.

Though it’s had a wider adoption, I see lots of hackers and fly-by-night engineers building devices with LoRa and not so much engineers and prominent companies and startups.

Here’s where I think the wheels have come off:

1. Restrictive open band: there is no universal LoRa band. If you want to take your finished product and bring it to another country, it’s very likely you will have to integrate a completely different radio. That leads to interesting integration and testing problems down the road at an added costs of engineering solutions for every country. Some counties though don’t even have a band for LoRa to operate on. Taiwan is a good example. They have no open bands for these types of devices to operate.
2. Security: i’ve talked to some leading industry experts and their concerns are all centered around data and device security. Unlike some of the other protocols in this post and the previous, LoRa fails to be robust in this area. Most folks who care about their data security often engineer a second layer of encryption to keep their data safe.
3. No off-the-shelf support for OTA updates. One of the most important criteria as an application engineer is to ensure that the device i’m building can be improved even when attached to a skyscraper or 30 ft underground.

My conclusion:

LoRa is a good solution if you’re willing to be responsible for it’s weaknesses and take advantage of it’s strengths. Depending on if you plan on going global or at least have a presence in multiple countries, it’s worth to think about all the other solutions before moving forward.

Symphony Link

Symphony Link is built on top of LoRa and brings some interesting improvements.

An improvement over standard LoRa. I think these guys have the right idea by adding another layer of functionality to the LoRa stack. If I were to go with a LoRa implementation, I would go with these guys.

With a focus on security and also out-of-the-box OTA functionality Symphony Link seems to have the right mix of what’s needed for a fully polished design.

Where things fall off:

1. The same problems for global operation apply to Symphony Link as they use the same base level hardware as LoRa. Bear that in mind when going global.
2. It’s a bit confusing whether or not their “Conductor Internet Platform” required. If it is, much like Ingenu, all bets are off!

My conclusion

If you’re willing to pay the extra premiums for Symphony link (Gateways and Modules are 3-4x what normal LoRa hardware is). I have yet to actually hit the ground with any of their modules so I can’t speak to how easy or hard they are to bring up and start using. My conservative assumption from their documentation is that it takes about the same amount of effort to implement as standard LoRa if not faster.

Conclusion

All of these technologies have a place though some are still quite young in the implementation phase. If you’re going to market and need something mature and stable look no further than CAT 1 or M1 LTE. Looking to save some operating costs, go towards a pre-designed gateway or design one yourself.

In the next part of the series, I will review some design resources and also will look at some related future technologies that may change everything. Stay tuned until next time.

Last Modified: 2020.3.7