Periodic mode and `hub.sync`

Notecard API
1

Hi!

My project uses Notecard in periodic mode, with a relatively long inbound/output period (several hours.). The host wakes up periodically and performs a “manual” sync using hub.sync.

From the docs, I understand that the hub.sync request doesn’t alter the cadence of the automatic sync in periodic mode.

I’d like to minimize power usage, and hence why the automatic sync is set to a fairly large value, since the firmware on the host manages synching to Notehub. However, I don’t want to use “minimal” mode, in case the firmware goes AWOL and we still need to connect to Notecard to perform DFU updates.

Is there a way to have the manual sync alter the cadence of the automatic sync? If that were possible, that would mean Notecard wouldn’t need to perform an automatic sync so long as the host firmware periodically performs a manual sync, but should the firmware become inoperative, then Notecard would sync automatically at the requested inbound/outbound interval.

Thanks!

1 Like
2

Hey @devElert,

There’s no way to have a manual sync change the cadence of the interval-based syncs.

However, the Notecard is smart enough to skip an outbound sync if there’s nothing queued, which might help save power in your scenario.

I’m curious why you’re using the manual syncs at all though—why not just let the Notecard handle syncs on its own?

Thanks,
TJ VanToll

3

Thanks TJ for the info. Is this something that could be changed, such as via a new property on hub.sync so that the next automatic sync period is reset?

My intent with the manual syncs is to reduce power use while also providing the latest data in a timely manner.

The device is battery powered (with solar), and spends the majority of its time asleep, then wakes up hourly and publishes a note. At the same time, we also want to sync inbound queues and have Notecard pick up the latest environment variables, as well as publishing the new note while the device is awake. Ideally we want the publish to happen shortly after the data is gathered (notwithstanding any connectivity issues.)

I figured the simplest way to achieve this was to add the note (with sync:false), then perform a manual sync, and then inspect the inbound queues before going to sleep again, so that the modem is started just once.

My thinking is then that automatic syncs from Notecard serve as a safety net to maintain connectivity should the firmware become inoperative. Otherwise, they are essentially redundant while firmware is waking up periodically and performing its own sync, yet they still consume power.

I hope that clarifies things. I’d be happy to hear of alternatives if there’s a more effective approach.

Thanks!

4

This is good to know. Unfortunately, notecard will still check for inbound data at the requested interval, which in this scenario, would be redundant unless the firmware is inoperative.

5

You can take this approach, but I feel like you’re adding extra complexity to your firmware without a ton of benefit.

With manual syncs your host will stay awake while the Notecard makes its full network connection, which has a cost, especially if your Notecard has trouble connecting. Whereas if you let the Notecard work in the background with inbound / outbound, its connection is not tied to your host at all.

If you stick to the Notecard’s API it makes it easier to use other power-savings features of the Notecard, like voltage-variable intervals, which let you configure different synchronization intervals based on the amount of battery power you have.

The main exception to all of this is for time-sensitive data. If you need your sensor readings to be synchronized as soon as they’re taken, you must use hub.sync or use sync: true on your Notes.

Thanks,
TJ

6

Thanks for these pointers.

With manual syncs your host will stay awake while the Notecard makes its full network connection, which has a cost, especially if your Notecard has trouble connecting.

Yes, that’s true, although while waiting for the sync, we can put the host into light sleep mode. Or deep sleep, and have the attention pin fire on successful cellular connection to wake up the device.

In areas of poor cellular service, how long will notecard attempt to connect for? Is there some way we can control this? Our device has it’s own GPS and so we could build up knowledge of known problem areas and reduce connection time accordingly to save power.

My aim is to reduce power consumption to a minimum, since this is a key value for the product. I figured if the notecard syncs were only done when the firmware hasn’t, that would give some power reduction.

In a few weeks when I have the latest spin of our hardware, I’ll do some A/B testing with periodic vs minimal mode to see how much the automatic syncs contribute to power use. Although this is just for evaluating the difference - in our case, using minimal mode isn’t an option, since this would render the device disconnected should firmware become inoperative, and notecard would never sync to initiate an ODFU update - at least as I understand it.

7

Yes, that’s true, although while waiting for the sync, we can put the host into light sleep mode. Or deep sleep, and have the attention pin fire on successful cellular connection to wake up the device.

Gotcha, yeah that would definitely help. It still seems a lot of complexity to me, because if you let the Notecard work in the background your host wouldn’t need to be involved at all.

But if the complexity helps you be a bit more power efficient it might be worth it. When you get around to A/B testing this you’ll have to report back because I’m very curious now :slight_smile:

In areas of poor cellular service, how long will notecard attempt to connect for? Is there some way we can control this? Our device has it’s own GPS and so we could build up knowledge of known problem areas and reduce connection time accordingly to save power.

This article goes through the algorithm the Notecard uses in quite a bit of detail: Understanding Notecard Penalty Boxes - Blues Developers.

Although this is just for evaluating the difference - in our case, using minimal mode isn’t an option, since this would render the device disconnected should firmware become inoperative, and notecard would never sync to initiate an ODFU update - at least as I understand it.

Correct.

Another thing you could consider is setting your inbound and outbound to somewhat big values (once a day?). That would reduce the energy cost of the scheduled syncs, while still giving you the backup you’re looking for.

TJ

8

Thanks for that link, it was very informative.

Absolutely :+1: , that’s what I landed on if no other option opens up.

If you wouldn’t mind, perhaps you could ask the team to have this use case in their backlog, so that developers have the option of pushing forward the next automatic sync time as the result of a manual sync. I can get you the power usage info when I have it, which hopefully will add some validity to the request (or not, as the case may be.)

9

Yep, I’ll pass it along :+1:

10

Hello,

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. I agree from this thread, 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!

11

Hey @briancarter,

Since you have a lot of questions here, could you post your reply in a new topic? Once I see that come through I’ll chime in.

Thanks,
TJ