Spark.process(); data usage

For the moment I am pairing my P1 with a celluar hotspot. I have a program running and found that the celluar hotspot is using a lot of data 53MB in one day.

I am wondering if anyone knows how much data is used for the Spark.process() that is called automatically in semi-automatic mode?


I can’t answer your actual question, but a part (maybe even a big one) might be the granularity your network provider counts your usage.
Some count a junk of several kB even if you’re only transmitting a few byte.

A lot depends on how you’re using the P1.

Can you outline how the firmware behaves in a little more detail ?

@AndyW The firmware is around 2,700 lines of code at the moment, but only publishes data 8-16 times a day. The data is a string of 9 character long.

It is also in semi-automatic mode.
Im not sure how in depth I should go with the explanation?

right now I’m using the hotspot

So a test app that just goes into semi-automatic mode, then calls publish(“123456789”) every 90 mins would be a representative model ?

Yes, that would be a representative model.

Let me run something similar tonight and count bytes in/out


Thanks so much, that will be really helpful.

The cloud is pinged from the device every 15 seconds, so that will add up over the course of a day! For the Electron we will be heavily optimizing bandwidth use for Cellular and backfitting this to photon/P1.


Oh yeah that would do it… A ping every 15 seconds means 5,760 pings per day. The normal MTU gives us 1500 bytes per network packet. If you use 6 packets per ping (open connection, ack, auth, auth ack, data, close? – I’m making stuff up), that would be 51.8MB/day.

Sounds like you might want to use MANUAL mode and see how infrequently you can get away with calling Spark.process(). Though that note about losing data to buffer overruns makes me nervous.


@AndyW, what do you use to count data in/out?

@dougal, Can you explain further about " Though that note about losing data to buffer overruns makes me nervous."? I’m not really sure what this means.

@mdma, from you best guess what do you think is the largest possible Sprark.process(); interval?

I dug out some old data (wasn’t able to set up the test last night, sorry)

For a quiescent core/photon, I measured (in Feb/Mar 2015) ~100KBytes of TCP payload in each direction, per 24 hr period. That’s just the application level keep-alives, not the TCP -level keepalives or the IP overhead.

There’s a world of difference between 100KB of application level data flowing in each direction, and 50MB.

I’ve started a capture on a device that is publishing every 5 mins (which should exceed your conscious data usage by a considerable margin) - I’ll report back on what that usage looks like at the application & raw packet level.

You may be falling foul of the billing practices of the carriers (e.g they round up for a given time interval) - I’ll have more data in a few hours, but at the moment I’d have to say that one or both of these might apply:

  1. Somethings wrong
  2. You’re getting screwed by your carrier

In the US, Verizon and less so others, have service plans for “telemetry”. Far cheaper than consumer service plans for data/voice/SMS. Not sure you can get 1each of these. Last time I checked, Verizon’s price was $5/mo, assuming telemetry type low volumes.

Beware airtime cost of keeping a constant TCP connection on cellular. Or doing frequent TCP connect/data/disconnect.
Better to use UDP for telemetry. The receiving server can timeout and re-request data if the UDP packet is lost.

Yeah - In this app, I think @wesner0019 was simply using his phone as a hotspot, and was surprised by the data usage.

I’m going to try and help understand where the numbers come from.

The electron data plans are more like the one you describe (data only, etc)

Thanks, the device I was using is which is a mobile hotspot with a data plan. The carrier is which uses Sprints network.

1 Like

After 4 hours of testing, snooping on a photon that is in fully automatic mode, publishing an event every 5 mins, I have the following data to share:

  1. Total COAP data transmitted by photon to cloud - 20274 bytes (tcp payload)
  2. Total COAP data received by photon from cloud - 16434 bytes (again, tcp payload)
  3. Most COAP packets are 16 bytes of payload, meaning 18 bytes in the tcp payload of that packet.
  4. TCP header is 20 bytes
  5. IP header is 20 bytes
  6. There are additional TCP keep-alives exchanged in each direction approx every 80 seconds (part of the TCP protocol) - these consist of 20 bytes of TCP header and 20 bytes of IP header.

That extrapolates (roughly) to, per day:

Tx COAP data: ~120KBytes
Rx COAP data: ~96KBytes

Total TX IP data (COAP + TCP (incl. keep alives) + IP): ~400KBytes
Total RX IP data (COAP + TCP (incl keep alives) + IP): ~330KBytes

This is without any network sillyness, retries, new TCP connections etc.

Still a long, long way from the 50MB you reported.

I will try and make time to create a SEMI_AUTOMATIC test case, that just publishes every 90 mins. To see if there is any pathological behaviour introduced that way.

Methodology: I use tcpdump/wireshark to dump the packets directly off my wired network between the access point and the firewall. Then inspect/process the resulting pcap files.


@AndyW, I was able to change the default celluar connection with the Hotpot to 1x from LTE. Since this change hardly any data is being reported as being used in multiple days.

Excellent news. I wonder what was up with the other hotspot, that behavior was definitely off-the-charts bad ( but, I suspect, par for the course in the mobile hotspot business)