[TriEmbed] TriEmbed Digest, Vol 18, Issue 20

Charles McClelland chip at mcclellands.org
Mon Nov 24 12:51:44 CST 2014


Shane and Bill, 

Bill, Thanks for your notes - would love to have a discussion on this topic.  I am using the DNS names as you will see in the example below.

Shane, 

Yes, I think you could reduce the overhead by sending multiple data points.  Using Ubidots as the example - but most services use a similar structure.  One way to see what this looks like is to example the commands using CURL - the Arduino sketch will simply break this up into bite sized pieces.  Happy to share the sketch but the CURL command does a better job illustrating the point.

For a single data point (documentation <http://ubidots.com/docs/get_started/quickstart/tutorial.html>) - the command and response looks like this:
# Request.
$ curl -XPOST -H 'Content-Type: application/json;' -H 'X-Auth-Token: XEcxqx3GTAWGTr4UJiWKk2RiiWEl04kZMSspFeW2BDBgdIe4Dj9CqCXvKLEA' -d '{"value": 23}' http://things.ubidots.com/api/v1.6/variables/5423a49e76254239d3c55718/values

# Response.
{
    "url": "http:///things.ubidots.com/api/v1.6/values/5423a49e76254239d3c55718",
    "value": 23.0,
    "timestamp": 1369847742302,
    "created_at": "2013-08-29T17:15:42.302"
}

For multiple data points (documentation <http://ubidots.com/docs/get_started/quickstart/tutorial-collections.html>) - it would look like this:
# Request.
$ curl -XPOST -H 'Content-Type: application/json;' -H 'X-Auth-Token: f6j9QGZqzsobNHZMFZ8UNWpPXOadv8LCtu3UuZyS32KbUwJyA2RRBhEsJpci' -d '[{"variable": "52656099f91b2878f1d81f1e", "value": 23}, {"variable": "5265608ef91b2878f05d75ba", "value": 22}]' http://things.ubidots.com/api/v1.6/collections/values

# Response.
[{"status_code": 201}, {"status_code": 201}]

Seems like this will be more efficient if only because you will exchange less API keys.

Other thoughts?

Chip


> On Nov 24, 2014, at 1:00 PM, triembed-request at triembed.org wrote:
> 
> Send TriEmbed mailing list submissions to
> 	triembed at triembed.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> or, via email, send a message with subject or body 'help' to
> 	triembed-request at triembed.org
> 
> You can reach the person managing the list at
> 	triembed-owner at triembed.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of TriEmbed digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Did anyone discuss M2M data plans? (Charles McClelland)
>   2. Re: Did anyone discuss M2M data plans? (Shane Trent)
>   3. Re: Did anyone discuss M2M data plans? (Bill Farrow)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 23 Nov 2014 23:47:16 -0500
> From: Charles McClelland <chip at mcclellands.org>
> To: triembed at triembed.org
> Subject: Re: [TriEmbed] Did anyone discuss M2M data plans?
> Message-ID: <E56F49E4-F936-4277-A0EF-75B5E2A05D15 at mcclellands.org>
> Content-Type: text/plain; charset="utf-8"
> 
> Shane, 
> 
> I fired up my IOT device and did a test to see how much data is used on the GPRS network when a data packet is sent.  
> 
> I sent data 51 times and used 215kb of data traffic according to my T-Mobile portal.   Here is the payload from one of those transmissions:
> 	- Traffic count - ?10"
> 	- Location - "lat:35.89, lng:-78.81"
> 	- Battery - ?4083"
> 	- Retries - ?0?
> 
> Seems like a lot of overhead -  ~4kb to send about 28 bytes.  Here is what I can see in looking at the code:
> 	- There is a 64 bit API key
> 	- Then a 16 bit identifier for each data stream
> 	- There is also limited back and forth exchanging commands and result codes
> 	- Looking at T-Mobile?s numbers, it may be that they count their data in chunks and round up.  Kind of like billing a 30 second call as 1 minute.
> 
> I hope this helps with your planning.
> 
> Chip
> 
> 
> 
>> On Nov 21, 2014, at 8:26 PM, triembed-request at triembed.org wrote:
>> 
>> Re: Did anyone discuss M2M data plans?
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20141123/4e6b8763/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 24 Nov 2014 08:25:50 -0500
> From: Shane Trent <shanedtrent at gmail.com>
> Cc: TriEmbed Discussion <triembed at triembed.org>
> Subject: Re: [TriEmbed] Did anyone discuss M2M data plans?
> Message-ID:
> 	<CAAFjd3qawUOnEVkz+FGw3W=6fLdwmvJe=siRJ-P8Ut=UrujTiA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Chip,
> 
> Thanks for the great information. That does seem like a lot of overhead. It
> sounds like collecting the data and sending up a group of data points at
> one time might be required to make the most of a modest data plan. Any idea
> how much data it would take to send the 51 data points at one time?
> Guessing from the numbers it might be only 6-7k.
> 
> Shane
> 
> 
> 
> On Sun, Nov 23, 2014 at 11:47 PM, Charles McClelland <chip at mcclellands.org>
> wrote:
> 
>> Shane,
>> 
>> I fired up my IOT device and did a test to see how much data is used on
>> the GPRS network when a data packet is sent.
>> 
>> I sent data 51 times and used 215kb of data traffic according to my
>> T-Mobile portal.   Here is the payload from one of those transmissions:
>> - Traffic count - ?10"
>> - Location - "lat:35.89, lng:-78.81"
>> - Battery - ?4083"
>> - Retries - ?0?
>> 
>> Seems like a lot of overhead -  ~4kb to send about 28 bytes.  Here is
>> what I can see in looking at the code:
>> - There is a 64 bit API key
>> - Then a 16 bit identifier for each data stream
>> - There is also limited back and forth exchanging commands and result codes
>> - Looking at T-Mobile?s numbers, it may be that they count their data in
>> chunks and round up.  Kind of like billing a 30 second call as 1 minute.
>> 
>> I hope this helps with your planning.
>> 
>> Chip
>> 
>> 
>> 
>> On Nov 21, 2014, at 8:26 PM, triembed-request at triembed.org wrote:
>> 
>> Re: Did anyone discuss M2M data plans?
>> 
>> 
>> 
>> _______________________________________________
>> Triangle, NC Embedded Computing mailing list
>> TriEmbed at triembed.org
>> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>> TriEmbed web site: http://TriEmbed.org
>> 
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20141124/62ef06de/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 24 Nov 2014 09:19:49 -0500
> From: Bill Farrow <bill at arrowsreach.com>
> To: Charles McClelland <chip at mcclellands.org>
> Cc: TriEmbed Discussion <triembed at triembed.org>
> Subject: Re: [TriEmbed] Did anyone discuss M2M data plans?
> Message-ID:
> 	<CAPm8Nr0CcapohaA+qc_yOcz+8nxVHcrygGjz9VxTVTFrHPor0w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On Sun, Nov 23, 2014 at 11:47 PM, Charles McClelland
> <chip at mcclellands.org> wrote:
>> Seems like a lot of overhead -  ~4kb to send about 28 bytes.  Here is what I
> 
> Is your device doing a DNS lookup as well ? Are you sending this
> directly to an IP address ?
> 
> A single datagram on the physical layer requires a header, ie ethernet header.
> A single IP Packet has a 20 byte header.
> A single TCP/IP packet has a 20 byte IP header plus a 20+ byte TCP header.
> 
> TCP is a connection based protocol, so to establish a connection and
> send a small number of bytes and then close the connection would
> require several packets in both directions.
> 
> Example:
> ========
> Using Wireshark and netcat, I got the following data for single 1 byte
> TCP transfer:
>  SYN  Device --> Host = 74 bytes
>  SYN-ACK  Host --> Device = 74 bytes
>  ACK Device --> Host = 66 bytes
>  PSH-ACK Device-->Host = 67 bytes
>  ACK Host-->Device = 66 bytes
> 
> The Ethernet header is 14 bytes, IP is 20 bytes, TCP in my case is 32
> bytes. Therefore the minimum packet size is 66 bytes. The above TCP
> transaction to send 1 byte of data took 347 bytes.
> 
> The smallest IPv6 header is 40 bytes, and there are various extensions
> to the header to add routing and security, which would make it even
> larger.
> 
> M2M:
> ========
> The Machine to Machine protocol is then going to add more overhead to
> the data transfer, plus SSL or TLS encryption headers, which also need
> an accurate UTC time, typically fetched via NTP (Chip could probably
> use the GPS time).
> 
> 
> This would make a great mini talk !
> 
> Bill
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> TriEmbed mailing list
> TriEmbed at triembed.org
> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> 
> 
> ------------------------------
> 
> End of TriEmbed Digest, Vol 18, Issue 20
> ****************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20141124/6ccd82f1/attachment.html>


More information about the TriEmbed mailing list