Boron - High Cellular Usage

Troubleshooting
21

While I obviously can't guarantee anything (and I haven't done exhaustive testing with multiple SIMs in multiple locations, etc.), the process was quite smooth for me. I didn't have to do anything special other than the documented steps of setting APN information and the keepalive time. See, e.g.

The keepalive time apparently varies from carrier to carrier and may need to be as low as 30 seconds for some of them. I'm using 200 seconds with Freedompop. 300 seemed to be problematicm so I backed it down to 200.

And don't forget to cancel the trials of all the non-free services, or you'll end up paying for them.

22

@Backpacker87 Thanks for sharing!

Quick question, if you had the devices powered by the grid would you still take same approach of moving to SEMI_AUTOMATIC connection?

Are the consistent full handshakes what made you use so much data?

23

Yes, even with grid power I would still implement SEMI_AUTOMATIC. Below is a rough calc. I performed based off numbers @ScruffR provided and as you can see a full handshake is expensive.

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.

The one thing I would upgrade in my setup that I read about in another post was the potential to include a cloud update window. For example, let the system connect to the cloud once a day for 10mins. This would allow the system to provide optimal data efficiency;however, the system would still maintain a daily window for OTA code changes/updates. I have not implimented this because I have not researched if the Boron has the ability to know time like a RTC would provide (A simple 24hr delay could be a moving target).

24

RESULTS - Cellular Usage over Month

Conditions:
5 Borons operating within a few hundred feet of each other
SEMI_AUTOMATIC with no connection to cloud
TPL5110 timer used to wake up every 5mins and send two float variables to Ubidots then power down.

The usage from Feb. 4th through Mar. 4th. was as follows:
Boron 1 = 4.64 MB
Boron 2 = 5.10 MB
Boron 3 = 4.77 MB
Boron 4 = 4.83 MB
Boron 5 = 5.16 MB

I am very pleased with this usage, and this is manageable for me. I believe that the use of SIMI_AUTOMATIC and forgoing any cloud connects is what has resulted in this low usage.

Future improvement would be attempting to create a scheduled cloud connect window (say 10mins) that occurs once a day at a specific time to provide the opportunity for OTA updates, which would overcome the main negative for me resulting from never connecting to the cloud.

5 Likes
25

@Backpacker87, Thanks for sharing those results !

26

This is a great thread. This evening I just finished an Adafruit TPL5111 integration with a Boron LTE Device OS 0.9.0, SLEEP_MODE_DEEP. One lesson learned, skip the trim pot on the board and go with resistors. :slight_smile: I’m using D8 to wake up every 10 minutes. Our use case includes a Particle Webhook call. The device is powered by an Adafruit 6600mAh Li-ion battery pack. The goal is 1 year without a recharge. I’ll post power and data usage after a few days of testing.

1 Like
27

Power and data usage update based on:

  • Hourly wake (gave up on 10 minutes)
  • 6600mAh Li-ion battery pack
  • One DS18B20 probe
  • One Particle.Publish call to webhook per cycle
  • SYSTEM_THREAD(ENABLED);
  • SYSTEM_MODE(SEMI_AUTOMATIC);

TPL5111 Approach (turns Boron off):

digitalWrite(DONEPIN, HIGH);
delay(5000);
digitalWrite(DONEPIN, LOW);
System.sleep(SLEEP_MODE_DEEP);
  • (according to Adafruit) 20uAh during sleep. Hourly wake/boot on EN rise.
  • Hourly percentage battery decline as measured by fuel.getSoc(): 0.02%/hour
  • Estimated time before recharge (assuming linear battery decline): 6+ months
  • Data volume per cycle: 5KB
  • Data volume per month: 3.5MB

DeviceOS sleep() Approach:

Cellular.off();
System.sleep({}, {}, 3540); 
Cellular.on();
Cellular.connect()
  • 2mAh during sleep. Hourly wake in-loop.
  • Hourly percentage battery decline as measured by fuel.getSoc(): 0.04%/hour
  • Estimated time before recharge: ~3 months
  • Data volume per cycle: 1KB
  • Data volume per month: 720KB

DeviceOS delay() with cell off Approach:

Cellular.off();
delay(3540000);
Cellular.on();
Cellular.connect()
  • 5mAh during delay. Hourly wake in-loop.
  • Hourly percentage battery decline as measured by fuel.getSoc(): 0.13%/hour
  • Estimated time before recharge: ~30 days
  • Data volume per hourly cycle: 1KB bytes
  • Data volume per month: 720KB

DeviceOS delay() Approach:

delay(3540000);
  • 18mAh during delay. Hourly wake in-loop.
  • Hourly percentage battery decline as measured by fuel.getSoc(): 0.42%/hour
  • Estimated time before recharge: 10 days
  • Data volume per hourly cycle: (approx) 300 bytes
  • Data volume per month: 210KB
3 Likes
28

@sensorcheck, excellent analysis, thank you for sharing. This data could benefit many members to come!

29

Thanks so much! Since that post I’ve been looking for ways to lower power consumption even more on the DeviceOS sleep() Approach. I am now lowering the DS18B20 pin when not in use and have added fuel.sleep() to the loop. Due to limitations in my power supply readout it is hard to say at this point how much this is helping (still shows 0.002mAh, a 4th digit could tell the story). :slight_smile:

30

Backpacker87,

Thanks for sharing - very useful.

Do you mind sharing your test code and connections to the TPL5110?

Would love to repeat this experiment with my setup.

Thanks