[TriEmbed] TriEmbed Digest, Vol 18, Issue 20

Pete Soper pete at soper.us
Mon Nov 24 13:46:33 CST 2014


You might try 50.23.124.68 instead of "things.ubidots.com" and see what 
difference it makes.
-Pete
On 11/24/2014 1:51 PM, Charles McClelland wrote:
> 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 
>> <mailto:triembed-request at triembed.org> wrote:
>>
>> Send TriEmbed mailing list submissions to
>> triembed at triembed.org <mailto: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
>> ****************************************
>
>
>
> _______________________________________________
> 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/0a93749b/attachment-0001.html>


More information about the TriEmbed mailing list