I built 6 identical setups that uses a Boron to take a pressure and voltage measurement every 5mins and send the Ubidots to include in a dashboard built there.
Since sleep protocols are not currently available for Boron I use a TPL5110 timer (https://www.adafruit.com/product/3435) to turn the Boron on after 5mins and off when a done comment is received.
I am experiencing on average ~3MB/day of data usage on each device. My gut thinks my variables and frequency should not reach this usage level, so I wanted to see what you all think.
Signal appears to be strong in the area of deployment.
I setup an event trigger in Ubidots to trigger if a new device variable has not been received in a 7min window, and that has been triggered a few times in the middle of the night.
My best theory is that on occasion the Boron wakes up and cannot successfully connect and by default the TPL5110 will not cut power until it receives a done (right after variables sent to Ubidots) or 5min timer is exceeded; therefore, the Boron spends 5mins trying to connect burning through data. This may not be how it works but my best guess.
Wow, sounds like I am already at ~1.7MB for full handshake.
24h * 60min = 1,440min/day
1440/5 = 288 check in’s/day
288 * 6KB = 1,728KB/day for full handshakes.
My deployment location is not solar friendly so I have two 12v SLA 7Ah batteries in parallel trying to get what I calculate ~7mo. of life based on the 5min checkin (deployment timetable is ~1 year so I will need at least one swap and charge). When I was building it I could not think of anyway to get the checkin interval desired and keep the sensor system footprint reasonable.
You might want to check out the following thread. Although it deals with the Electron, the concept for waking up and doing a full handshake is the same. All the different sleep modes consume a different amount of current while sleeping as well as consuming data upon wake up. The Boron doesn't have sleep modes yet but it's a starting reference for why you are burning all that data.
At 5 min intervals, you want the equivalent of SLEEP_NETWORK_STANDBY to conserve data and power… but that doesn’t exist yet. At the moment I think you have to either eat the data, or battery. You have to sacrifice one for the other until sleep modes come about.
All of the 6 sensors are within 100’ of each other (I did not use mesh because of the method since I remove power to “sleep”) so I may need to replace Borons with Argons and have them wake up, connect to a FreedomPop hotspot, send data, then power down. With 500MB/mo I should not have additional data charges which would add up otherwise since these systems will be deployed for ~1yr.
@tve, thank you for thinking of that, but the use-case requires knowing if the system being monitored is down within minutes as it serves critical systems.
Even with an Argon, you may still incur handshake data when connecting to the Particle cloud. You could try to use SYSTEM_MODE(MANUAL) or SEMI_AUTOMATIC to control the connection (on both the Argon and Boron). I don't have enough experience with it but you may be able to wake up and publish to Ubidots without connecting to the cloud. But you would have to explicitly control the connection states so that you don't do an automatic cloud handshake.
@ninjatill, optimizing would be ideal, but my thinking was to get an initial fix in place which has a 500MB/mo free window vs. the (6 Borons * 3MB/mo) 18MB/mo free window. The new angle of attack being use brute force (500MB/mo) for now to buy time to further optimize and to wait for Boron sleep modes.
Not really, on startup the cloud and the device negotiate whether or not the cloud already has a valid understanding of the current state of the device. If not a full handshake is required and by definition the state of a cold-started device is unknown to the cloud.
However, if you really only need to regularly talk to Ubidots you should go with SYSTEM_MODE(SEMI_AUTOMATIC) and only pull up the Cellular connection to send the data to Ubidots and only execute Particle.connect() when you definetly need the Particle cloud to talk to.
@ScruffR, thank you very much for your reply. @ninjatill this response is also in alignment with your suggestion.
I think this is my best route. I really lost all benefit (in my mind) of the Particle cloud interface when I chose to turn the Boron off for battery savings and without a delay window to try and time sending OTA updates and I am OK with that (it was my best attempt at max battery savings).
About the only thing I keep an eye on from the cloud is the cellular use, but I have a feeling this is still going to be reported since I bet its coming from the providers backend and is not dependent on a Particle based handshake (I could be wrong but seems to make sense).
However, if you really only need to regularly talk to Ubidots you should go with SYSTEM_MODE(SEMI_AUTOMATIC) and only pull up the Cellular connection to send the data to Ubidots
Am I correct in assuming that SYSTEM_MODE(SEMI_AUTOMATIC) inherently brings up the cellular connection and that no other calls are needed?
Thank you, I am excited to give this a shot to see if I can bring down the data usage.
Not quite.
This mode starts off without the main radio on.
In order to start the cell connection without the cloud you need to do the following
SYSTEM_MODE(SEMI_AUTOMATIC);
void setup() {
Cellular.on(); // power up the cellular module
Cellular.connect(); // start the actual connection
// then wait up to 5 minutes for the connection
if (waitFor(Cellular.ready, 5*60*1000) {
// do whatever needed once the connection stands
}
else {
// do whatever when not
}
// do the rest
}
So with this mode you start off with the lowest consumption and can bring up the radio only when you actually need it.
While I showed you bringing up the connection in setup() you don't need to do it there, you can do that anywhere in your code - e.g. after you have done all your other jobs that don't require it and then only introduce the extra current demand for the shortest time required to do the actual communication and then power it off again.
However, I'd not just pull the plug on the device but rather power down the cellular module via Cellular.off() and give that a few milliseconds before pulling the plug.
I’ve been using a Freedompop SIM in my Boron and it seems to work for fine. Note that they only have 200MB on their free plans for SIM cards. That’s not a whole lot for someone using it in their phone, but it goes quite a way on the Boron.
You can find out everything you want to know about Freedompop at https://www.cranialborborygmus.com/freedompop-for-dummies.htm
including links to current sales. At the moment, you can get the SIM card for one penny (just the card, no device) and it really does provide 200MB per month with no cost. (I have no connection with that site or with Freedompop other than as a satisfied user)
I wanted to provide an update to my usage as a few things have changed.
I tracked my daily data usage on 7 Boron’s running the same code and I was averaging ~10MB/day total for 7 units. I ended up racking up over ~160MB worth of data by the end of the billing cycle.
For reference I am posting two float variables to Ubidots every 5mins.
Three major things happened that may be related to a significant reduction in data usage:
Per suggestions from this post I am using SYSTEM_MODE(SEMI_AUTOMATIC); and I never connect to the cloud (I do no call Particle.connect(); )
I worked with Ubidots to get their TCP protocol working with Boron’s resulting in me being able to switch from HTTP to TCP. Note: I am currently working with Ubidots to get their UDP protocol working, which will hopefully happen by the end of this week.
I went through my first billing cycle. I worked though some issues with Particle as I received three seperate billing notification emails, two credit card charges (one was refunded), and all my Boron SIM got deactivated at one point due to a system error. Particle worked with me throughout all of this, and it ended up shaking out, but I don’t know if there were usage errors mixed anywhere in there so It could have been adding to the issue.
Result: In the current billing cycle (starting Feb. 4th) to date I have used 6MB across 7 Borons.
This is a significant reduction in usage and my best logical guess is to attribute the reduction to moving to SEMI_AUTOMATIC eliminating the cloud interaction (including the expensive full handshake) and also the move from the Ubidots heavy HTTP to TCP. I think the billing issues were likely unrelated, but it happened so I am documenting because I cannot rule it out.
I am very pleased with this progress and I will continue to track the usage and I will upgrade to UDP when Ubidots gets this fixed for Boron/Argon family.
Thanks for the feedback on your project. It’s interesting to know that a Boron re-connecting every 5 min. and using http traffic can quickly rack up high data usage (high for the Particle’s plan, which is currently, AFAIK, the only one available for Boron LTE).
I’m currently using the Boron LTE in a custom made real time asset tracker and I’m closely monitoring the data usage, although the device is online for a total of less than 2 hours per day.
While waiting for Sleep modes to be added in the next firmware update, I’m simply turning off the cellular module with Cellular.off() for now to save on power. I really hope that the SLEEP_NETWORK_STANDBY mode will be added sometime in the future.
I found out that on the Electron, a combination of this sleeping mode that avoids handshakes if awaken every 23 min. or less plus the use of Particle.publish() to send data and webhooks to relay that data to other servers, is the best one to save on both data and power usage.
The other option that I favored on the Electron is to just use a third party Sim with much cheaper data and worry only about power save Hopefully that will also be possible in the future with Boron LTE.
I’m definitely eager to see what’s coming from Particle for this new cellular device.
@psfales, thank you for the share. From the Boron documentation I interpreted that 3rd party SIM may or may not work. Was there any specific workarounds or anything special you had to do to get it going?
I have used FreedomPop hotspots in the past for other sensor networks and as long as you downgrade I also have experience staying within the free data limit. Using the FreedomPop platform for sensor networks may be a hidden gem, that is after you get over the sketchy feel of their website
Hopefully that will also be possible in the future with Boron LTE.