Low-Power Asset Tracking: Using Notecard to Monitor Dumpster Locations

Hardware
1

Rental Dumpster Tracking

I’m working on a project to track the location of rental dumpsters using the Blues Notecard. The system will be battery-powered, so efficient power consumption is important. I plan to use Periodic Mode to send updates at regular intervals, but I want to ensure that location updates are reliable and that data syncs efficiently with notehub. I have many fixed sites where this is working out great but this is my first product where my device will be fixed on a mobile/movable asset. Most of the below should be able to be done with the Notecard avoiding adding the complexity to my MCU.

ASK: specific Notecard JSON commands to provision for Notecard Cell for the below requirements.

Here are my main questions:

  1. Periodic Mode & Hub Sync: What is the best approach to balance update frequency and power consumption? Should I rely only on periodic mode, or should I also use motion- or event-based sync triggers?
  2. GPS Performance & Battery Life: Given that the dumpsters may be stationary for long periods, how should I configure GPS acquisition and sync behavior to optimize power usage while still maintaining useful location updates?
  3. Connection Considerations: Since dumpsters may be in areas with weak cellular coverage, how does Notecard handle failed sync attempts in Periodic Mode? Will it retry on its own, or should I configure alternate sync strategies?
  4. Best Practices: Are there any specific low-power optimizations or settings that work well for asset tracking applications like this?

Any insights or recommendations would be greatly appreciated! If I could get detailed direction to meet my requirements:

For tracking rental dumpsters, I have the following requirements:

1. Power Efficiency

  • Low Power Consumption: Battery-powered operation should last for months or years.
  • Efficient GPS Usage: Minimize GPS fix time and avoid unnecessary power drain.
  • Optimized Syncing: Reduce unnecessary data transmissions while ensuring critical updates are sent.

2. Location Tracking & Reporting

  • Periodic Updates: Send location at set intervals (e.g., every few hours or once a day).
  • Event-Based Updates: Report movement (e.g., when the dumpster is picked up or dropped off).
  • Last Known Location: Retain last GPS fix if a new one isn’t available.

3. Connectivity & Data Sync

  • Reliable Communication: Ensure data syncs via cellular (or LoRa if applicable).
  • Offline Storage & Retry: Cache data if no signal is available and retry later.
  • Minimal Data Usage: Reduce bandwidth costs by sending only essential updates.

4. Durability & Environmental Resistance

  • Weatherproofing: The tracker should withstand rain, snow, and extreme temperatures.
  • Vibration & Shock Resistance: Must handle rough handling during transport.

5. Security & Maintenance

  • Tamper Detection: If someone tries to remove or disable the tracker, send an alert.
  • Firmware Updates: Ability to update firmware remotely to fix bugs or improve performance.
  • Battery Monitoring: Report battery levels to plan maintenance/replacements.

Thanks!

2

Hey @briancarter,

I’ll see what I can do to help.

Periodic Mode & Hub Sync: What is the best approach to balance update frequency and power consumption? Should I rely only on periodic mode, or should I also use motion- or event-based sync triggers?

Your project is going to be as battery efficient as possible if you rely only on periodic mode. I would only use other triggers if you need to send data immediately for whatever reason.

GPS Performance & Battery Life: Given that the dumpsters may be stationary for long periods, how should I configure GPS acquisition and sync behavior to optimize power usage while still maintaining useful location updates?

The Notecard is smart enough to only do attempt to get a new location if it moves (as detected by its onboard accelerometer).

You’ll want to set your card.location.mode to "mode":"periodic", and configure the seconds for how often you want to attempt to get a new location when the Notecard is in motion.

Connection Considerations: Since dumpsters may be in areas with weak cellular coverage, how does Notecard handle failed sync attempts in Periodic Mode? Will it retry on its own, or should I configure alternate sync strategies?

There’s a full discussion of the algorithm the Notecard uses here: Understanding Notecard Penalty Boxes - Blues Developers.

But in short, the Notecard will retry a cellular connection on its own at certain intervals doing the best it can to preserve battery life. It’ll do a similar set of steps for GPS fixes as well.

Best Practices: Are there any specific low-power optimizations or settings that work well for asset tracking applications like this?

A couple of ideas:

  • You can provide Voltage-variable values for your inbound, outbound, and for how often you want to sample the GPS.

  • You can use the Notecard to put your host to sleep so that your host uses as little power as possible.

  • Wi-Fi triangulation uses significantly less power than GPS/GNSS. If you’re using a Cell+WiFi Notecard, it can give you fairly accurate locations in areas where GPS is not available (e.g. inside a building).

ASK: specific Notecard JSON commands to provision for Notecard Cell for the below requirements.

You’ll want to play with these values, but something like this should get you started:

# Tell the Notecard what type of battery you’re using.
{"req":"card.voltage","mode":"lipo"}

# Using voltage-variable values for inbound/outbound.
# The Notecard is smart enough to only do an outbound sync if there’s data queued.
# Inbound syncs will always happen as configured.
{"req": "hub.set","product": "your-productuid","mode": "periodic",
"voutbound":"usb:60;high:60;normal:120;low:360;dead:0",
"vinbound":"usb:1440;high:1440;normal:2880;low:10080;dead:0"}

# Enable the GPS and use voltage-variable values to determine how often the
# Notecard should attempt to get a new location when in motion.
# This config has the Notecard perform hourly GPS fixes with high battery, which
might be too aggressive depending on your battery requirements.
{"req":"card.location.mode","mode":"periodic",
"vseconds":"usb:3600;high:3600;normal:14400;low:86400;dead:0"}

# Enable location tracking. Setting heartbeat uses battery, as it tells the Notecard
# send a “heartbeat” event at the configured “hours” interval. BUT, this
# is a nice way to ensure your Notecard still has a connection, and this
# daily checkin will include your device’s voltage.
{"req":"card.location.track","start": true,"heartbeat": true,"hours": 24}

TJ

1 Like
3

The last part of your reply with the settings is a great help. Few more questions for you:

  1. With hub.set, should “uperiodic”: true be set - if the notecard is connected/powered via USB I would like more frequent inbound/outbound sending of the notes

  2. Does {“req”: “card.time”} request just return the time from the notecard or does the notecard perform a backend request call to get update time? My MCU goes into deep sleep and doesn’t retain time across sleep cycles so I would like to pull the time from the notecard each time it wakes up.

  3. My MCU has its own sleep cycle, should I set card.attn - {“req”:“card.attn”,“off”:true}

  4. On notehub, what field in the json body is for when the note was created on the notecard? With the outbound sync delay, I need to forward the time captured on the notecard (not the time uploaded to notehub) to my backend.

4

With hub.set, should “uperiodic”: true be set - if the notecard is connected/powered via USB I would like more frequent inbound/outbound sending of the notes

uperiodic sets the Notecard to continuous mode, which enables a continuous connection, but does _not _ alter the inbound/outbound.

Depending on how often you want to see data updates when you have USB power, you might need to additionally lower the usb:x numbers of voutbound, vinbound. (And maybe also lower the usb:x of vseconds if you want to take more frequent GPS readings when using USB power.)

Does {“req”: “card.time”} request just return the time from the notecard or does the notecard perform a backend request call to get update time? My MCU goes into deep sleep and doesn’t retain time across sleep cycles so I would like to pull the time from the notecard each time it wakes up.

It just gets the time locally, and does not perform a backend request. However, the Notecard has to have connected to Notehub at least once, otherwise the request will return {"err": "time is not yet set {no-time}"}.

My MCU has its own sleep cycle, should I set card.attn - {“req”:“card.attn”,“off”:true}

Setting "off" is fine if you don’t plan to use card.attn, but it doesn’t unlock much (if any) power savings. I asked someone on our firmware team and this is what I got back:

“It’s something we do for the lowest possible current testing, but to be honest I don’t really need to set it when testing. The amount of current that bleeds through a very high pull-up resistor is negligible. If you are not using it then you can save that, but it’s practically nothing.”

On notehub, what field in the json body is for when the note was created on the notecard? With the outbound sync delay, I need to forward the time captured on the notecard (not the time uploaded to notehub) to my backend.

when is a timestamp that indicates when the Note was created on the Notecard. received is a timestamp that indicates when Notehub received the Note.

TJ