Cellular Data Service with Particle

Particle provides a number of devices with cellular connectivity including the Tracker, Boron, B Series SoM, E Series, and Electron. These can provide access in areas without Wi-Fi and provide a more seamless solution that does not depend on being able to connect to your customer's Wi-Fi network, which may involve unexpected challenges.

Pricing Tiers

Free Tier

  • Up to 100 devices, any mix of cellular and Wi-Fi
  • 100K Data Operations (100,000) per month, for both cellular and Wi-Fi, pooled across all devices
  • Up to 100 MB of cellular data per month, pooled across all devices, at no charge
  • No credit card required
  • Products can be prototyped in the Free tier
  • Device communication is paused1 when the monthly limit is reached
  • Community support

1During the transition period, a warning will be sent but communication will not be immediately paused.

Growth Tier

  • A block includes 720K Data Operations (720,000) per month and up to 100 devices
  • Add as many blocks as you need for more Data Operations or more devices
  • No limit to the number of blocks you can purchase self-service
  • Up to 540 MB of cellular data per month (1.5 GB for Tracker), pooled across all devices, for each block purchased
  • Email support
  • Available in Summer 2021

Enterprise Tier

  • Enterprise tiers include a maximum number of devices, Data Operations, storage, and cellular data
  • Data Operations and cellular data are pooled across all devices annually
  • Discounts for higher Enterprise tier commitments
  • Contact sales for more information

Data Operations

The central billing element for both cellular and Wi-Fi is the Data Operation:

  • Each publish, subscribe, function, or variable consumes one Data Operation regardless of size
  • The data has a maximum size of 622 to 1024 bytes of UTF-8 characters; see API Field Limits
  • Stored data, such as Tracker geolocation data, consume one Data Operation per location point saved1
  • Certain retransmissions, as described below

1During the transition period, stored data will not be measured, however the publish from the device will be measured.

The following do not count against your Data Operations limit:

  • Over-the-air firmware updates do not count against your Data Operations limit
  • Internal events such as device vitals (beginning with "particle" or "spark") do not count against your Data Operations limit
  • Acknowledgements, session negotiation, keep-alives etc. do not count against your Data Operations limit
  • Webhooks and server-sent-events (SSE) themselves do not count against your Data Operations limit, but the triggering event or response could
  • Particle cloud API calls do not count against your Data Operations limit
Number of devices
Publish every

Webhooks and other integrations

When a device sends an event that triggers a webhook or other integration, that will consume one Data Operation.

If the webhook response is not subscribed to by the device, that will be the only Data Operation.

If the webhook response is subscribed to by the device, it will use one Data Operation for each 512-byte segment of a response. Retransmissions could also increase the number of Data Operations, as described below.


When a device must retransmit data that does not reach the cloud, for example because of poor cellular connectivity, it does not count as additional Data Operations. If it retransmits the data because the acknowledgement was lost, that could count as additional Data Operation as the data was actually received by the cloud twice.

When transmitting from the cloud to a device, such as for a function, variable, or subscription:

If the device is marked as offline, no data transmission will be attempted and no Data Operations will be incurred.

If the device is believed to be online, an attempt will be made, which will consume a Data Operation.

If the transmission is not acknowledged, it is possible that up to two more attempts will be made, each adding a Data Operation. If all three attempts fail, the device will then be marked as offline.

Cellular Data Limit

For cellular devices, there is a data limit depending on your tier. For the Free tier, the cellular data limit is 100 MB , pooled across all devices, which includes all data usage including Data Operations, OTA code flash, overhead, and 3rd-party services. This limit is high relative to the average size of Data Operations, so you probably won't need to worry about the exact number of bytes for each operation.

In the growth tier, 540 MB of cellular data per month (1.5 GB for Tracker) is included for each block purchased, per month.

For Wi-Fi devices (Photon, P1, Argon) there is no limit for direct TCP or UDP data communications, or services that are based on direct communication such as Blynk.

What consumes data?

Any time a Particle cellular device talks to the Internet or the Internet talks back, that data travels though the cellular network and is metered. There's also unavoidable overhead on all communications because of the structure of the Internet and the necessity of security and reliability. Many of these communications are intentional and obvious, like calling Particle.publish() or flashing code over the air. There are other communications that you may not even be aware of. For instance, when a cellular device turns on or is reset it has to register with the cell towers and the Particle Device Cloud, and this set of messages can use as much as 6KB! The following all use data:

Functions from or registered by firmware:

  • Publish (smallest communication)
  • Function calls from the API
  • Variable calls from the API
  • Subscribe to events or webhook response
  • Direct network connections through TCPClient or UDP
  • DNS name resolution

Background connectivity:

  • Pings (once every 23 minutes if no other communications happen and device is awake. 122 bytes)
  • Handshakes (when the device comes online initially, and then every 3 days. up to 6kB)

Flashing code:

  • Flashing code over the air including Device OS upgrades.

Starting a connection: Whenever a cellular has to join the cellular network it will "handshake" and register itself and your functions and variables.

  • Startup
  • Reset
  • Wake from deep sleep
  • Wake from stop mode (when not using SLEEP_NETWORK_STANDBY)
  • Cellular modem is turned off and on again

Ways to reduce data use

There are lots of things you can do to save data!

Use Shorter Names This applies to Particle.publish, .variable, and .function. Those longer names have to be sent to/from the cloud, so you're much better off using Particle.publish("x") than Particle.publish("xylophone_is_now_playing_a_song").

Use Serial() for Development When you're first testing and debugging your code, you can avoid costly and embarrassing runaway data publishing scenarios by sending sensor readings, alerts, etc over a USB cable. Comment out your Particle.publish() line, add Serial.begin(9600); to setup() and instead use Serial.println(your_data_here") to log data out to a serial terminal. You can use Particle Workbench, the Arduino IDE, screen or any other terminal program. Find out more in the Serial reference

Event-Driven Publishing One of the very common structures we see in code is a loop() with a sensor reading, then a publish and delay. This calls the publish (and uses data) at some regular interval, but the data being reported may not have changed! Picture a temperature sensor in your yard- the temperature is unlikely to have changed much after 1 second, 1 minute, or even 10 minutes. The data-efficient thing to do is to save the temperature you last published and compare the current reading to that previous one. If it's more than a few degrees different, then publish the new one.

// We're also using absolute value here, so may need to #include "math.h"

Combining Publishes Are you sending data that isn't time-critical? Consider combining many data points into a single publish. Instead of using the 100+ bytes of overhead for every data point, you'll only use it once and save a ton! Sample the data based on change or frequency, store them in a string or array, and then send them out as one publish when you've collected as many as you want (or fit in the data field of a Particle.publish). We often add commas between data points so they're easy to separate. The data has a maximum length of 622 to 1024 bytes of UTF-8 characters; see API Field Limits.

Particle.publish("T", String::format("%d,%d,%d,%d,%d", temperatures[0],temperatures[1],temperatures[2],temperatures[3],temperatures[4]));

On-Device Logic Most of the behaviors you'd like to implement can live right on the device. For example, if you have a greenhouse with a motorized vent, and you want the vent to turn on if the temperature exceeds a user-set threshold, then there are two options. You could send the temperature reading to the cloud from time to time, compare the reading to the threshold, and have the cloud control the vent via a function if the temp is above the threshold. This is much, much less data efficient than using a function to set the threshold on the device when necessary, and otherwise keeping the logic and control entirely on the device. This has the added benefit of being more reliable in the event of a connectivity outage.

Use webhooks Webhooks take a value that you Particle.publish and convert it into a HTTP request to an external server. If the external server is accepting connections by https (TLS/SSL), doing the TLS handshake from the webhook server greatly reduces the data usage from around 6K to the size of the publish, which might be as low as 100 bytes.

Use network sleep modes If you are sleeping for 15 minutes or less, you can save data by keeping the cellular connection alive by using network sleep. This can eliminate the negotiation that would occur to being the device back online after sleep.

Update Device OS over USB Using particle update over USB to upgrade your device's version of Device OS can save a significant amount of data over upgrading over-the-air.

Additional Details

If you're interested in the specific details about data usage, expand this section.

Additional low-level details