REGISTER | LOGIN
Breaking News
News & Analysis

Spiraling Data Costs Imperil IoT

Data compression, protocol conversion tools
4/14/2016 07:17 PM EDT
4 comments
NO RATINGS
1 saves
Page 1 / 3 Next >
More Related Links
View Comments: Newest First | Oldest First | Threaded View
wilfrednilsen
User Rank
Author
Re: interesting but useful?
wilfrednilsen   5/2/2016 11:19:33 AM
NO RATINGS

The article makes the assumption that all IoT solutions require (cloud) data storage. There will be plenty of IoT solutions that will not require any storage at all. For example, a garage door manufacturer that IoT enables his garage door to make it possible to open/close the door via a (phone/web) app will not need any storage. The cloud solution is only required to allow both the garage door and app to work via a NAT enabled network.

 

For smaller scale operations, a very modest solution can be designed. We put together a whitepaper that explains how it is possible to setup a low end cloud server that can manage up to 10,000 devices at a yearly cost of $8.

https://makoserver.net/blog/2016/04/Setting-up-a-Low-Cost-SMQ-IoT-Broker

 

rsabharwal94001
User Rank
Rookie
Re: interesting but useful?
rsabharwal94001   4/16/2016 8:26:54 PM
NO RATINGS
Even the math does not work for that extremely chatty smart meter.

If the meter produces a data record of 40 bytes every second, then over a day it will need to send 3.5MB not 400MB. Even if you add networking overhead you wont get to 400MB per day.

Also it should not be too hard to send a data record only if there is a difference from the previous record. For Smart Water Meters that reduces data by a factor of 100 as most of the time there is no water flowing. For power meters there should be some reduction even a factor of 2 will help.

The other points in the article are quite valid.

junko.yoshida
User Rank
Author
Re: interesting but useful?
junko.yoshida   4/15/2016 1:59:12 PM
NO RATINGS
@RoweBots1, thanks for chiming in.

You do lay out a very good point here.

You wrote: 400MB/day for a smart meter is a good example of a poor design in my experience.


That's probably true. But at the same time, it seems to me that inexperienced device vendorrs and service providers -- and I assume that there will be many of those coming into the IoT market -- could benefit from IoT tools, if they are commercially available.

RoweBots1
User Rank
Author
interesting but useful?
RoweBots1   4/15/2016 9:03:25 AM
 

It seems that since the beginning of electronics, efficiency in communications has been defined by sending a reference set of data and delta or change information.  By designing a poor protocol to start with, compression becomes a necessity but through quality design, much of this data is easily eliminated.  In many cases, a focus on a quality design will minimize compression requirements.  400MB/day for a smart meter is a good example of a poor design in my experience.

Privacy by design and security by design need to be incorporated into the system.  For consumer applications, privacy standards and designing for these standards would eliminate saving data at such a fine level of detail which would minimize such requirements for compression if properly applied.  

Clearly bandwidth is a problem in these networks and protocol conversion is required in gateways.  A quality design with privacy and security included up front is a desirable solution as a first step and then if necessary further compression may be necessary.  

As for protocol conversion, this is a gateway feature required for connecting to the cloud and from the cloud.   The problem is  connecting from a a lightweight leaf node to the cloud protocol ie  CoAP - AMQP but only if you have multiple different devices connected to your gateway - some running CoAP others running native AMQP.  The reverse connection is also required.  An N to M solution here seems overly complex when a 1:2 solution is all most applications might need.

 

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed