Low-Power Firmware Design

The Notecard is designed to be battery operated, with low current consumption, making it an ideal choice for low power applications. Because of its low power design, in many applications a host processor and its peripherals will be larger contributors to power drain.

To help designers and developers build low power applications, the Notecard implements two tools:

• A power management technique that allows firmware developers to regulate modem activity on the Notecard as a function of available energy.
• A design technique that allows the Notecard to shut the host processor down completely, for dramatic power savings.

note

As a low-power device (e.g. the Notecard Cellular consumes only ~8µA@5V when idle), the Notecard was built to be continuously powered. This is important to know because certain features of the Notecard require the current time, which is established upon the Notecard successfully connecting to Notehub upon startup.

Consult the Low-Power Hardware Design Application Note for more details on how to design a low-power system that uses the Notecard for wireless communications.

Modem Power Management

In battery-operated systems, and in particular those using energy harvesting approaches like solar power, the energy available to a processor and its peripherals rises and falls, sometimes between extreme levels. Notecard consumes very little power in its idle state, and when staging data with note.add requests, but uses a nontrivial amount of energy when the modem is on and transmitting to and receiving data from a network.

note

Notecard will never go into low power (~8µA@5V) mode if VUSB is present (M.2 pin 13), or if AUX_EN (pin 56) is pulled HIGH (3v3).

When designing a system that utilizes the Notecard, it's a good idea to vary Notehub connection intervals based on the energy available to the system as monitored through a host's use of a fuel gauge or Power management integrated circuit (PMIC). Using the information available to the host, you can use hub.set to configure the Notecard's connection mode, as well as voltage-variable settings for inbound and outbound data synchronization.

For example, when ample energy is available in the system, you may prefer to sync outbound Notes each hour and process inbound data every two hours.

{
  "req": "hub.set",
  "mode": "periodic",
  "outbound": 60,
  "inbound": 120
}

J *req = NoteNewRequest("hub.set");
JAddStringToObject(req, "mode", "periodic");
JAddNumberToObject(req, "outbound", 60);
JAddNumberToObject(req, "inbound", 120);

NoteRequest(req);

req = {"req": "hub.set"}
req["mode"] = "periodic"
req["outbound"] = 60
req["inbound"] = 120

card.Transaction(req)

In a hub.set request, the outbound is the maximum latency between changes made at the Notecard (Notes or environment variables), and when the Notecard attempts to sync changes to Notehub. inbound is the maximum latency between syncs with the Notehub to check for changes to Notefiles and environment variables that need to propagate to the Notecard.

If, as the product is running, the host detects that available energy is low, a subsequent hub.set request can be issued to adjust the inbound and outbound sync intervals accordingly. For instance, the following request instructs the Notecard to sync outbound Notes every eight hours, and process inbound data once per day.

{
  "req": "hub.set",
  "mode": "periodic",
  "outbound": 480,
  "inbound": 1440
}

J *req = NoteNewRequest("hub.set");
JAddStringToObject(req, "mode", "periodic");
JAddNumberToObject(req, "outbound", 480);
JAddNumberToObject(req, "inbound", 1440);

NoteRequest(req);

req = {"req": "hub.set"}
req["mode"] = "periodic"
req["outbound"] = 480
req["inbound"] = 1440

card.Transaction(req)

In extreme cases, available power may be so low that you need to instruct the Notecard to keep the modem off completely, and until instructed otherwise. To do this, use the off mode.

{
  "req": "hub.set",
  "mode": "off"
}

J *req = NoteNewRequest("hub.set");
JAddStringToObject(req, "mode", "off");

NoteRequest(req);

req = {"req": "hub.set"}
req["mode"] = "off"

card.Transaction(req)

Voltage-Variable Sync Behavior

Each of the examples above require the host to track power levels and manually intervene to instruct the Notecard to modify its sync behaviors. Alternatively, the Notecard can automatically adjust its sync behavior with voltage-variable arguments in a hub.set request. Instead of using outbound and inbound to specify sync intervals, you can use voutbound and vinbound.

warning

Setting voltage-variable values is not supported on Notecard for LoRa or Notecard XP.

Both arguments expect semicolon-delimited string values with intervals that correspond to a battery state. The pre-defined Notecard battery states are:

• usb
• high
• normal
• low
• dead

When the Notecard's power source is in a given state, it will adjust the period based on the values defined in the voutbound and vinbound strings.

Using a 0 value for any state disables that timer as a trigger for sync activity.

For instance, if you wanted to sync outbound every 30 minutes and inbound every hour when the battery is at full strength, and throttle back as available power decreases, send a request like this:

{
  "req": "hub.set",
  "mode": "periodic",
  "voutbound": "usb:30;high:60;normal:90;low:120;dead:0",
  "vinbound": "usb:60;high:120;normal:240;low:480;dead:0"
}

J *req = NoteNewRequest("hub.set");
JAddStringToObject(req, "mode", "periodic");
JAddStringToObject(req, "voutbound", "usb:30;high:60;normal:90;low:120;dead:0");
JAddStringToObject(req, "vinbound", "usb:60;high:120;normal:240;low:480;dead:0");

NoteRequest(req);

req = {"req": "hub.set"}
req["mode"] = "periodic"
req["voutbound"] = "usb:30;high:60;normal:90;low:120;dead:0"
req["vinbound"] = "usb:60;high:120;normal:240;low:480;dead:0"

card.Transaction(req)

Likewise, you can use a shorter syntax to express "if USB-powered, sync every 30 minutes, otherwise sync every 60 minutes" with "usb:30;60".

You can confirm these settings with the response from a hub.get request:

{
 "voutbound": "usb:30;high:60;normal:90;low:120;dead:0",
 "vinbound": "usb:60;high:120;normal:240;low:480;dead:0",
 "mode": "periodic",
 "host": "a.notefile.net",
 "product": "com.your-company.your-name:your_product",
 "device": "dev:0000000000000"
}

USB/Line Power Variable Sync Behavior

When in development, you may want to maintain a continuous connection to Notehub when your device is USB/line-powered, but return to periodic, minimum, or off sync modes when USB/line power is disconnected. This capability is available as of the LTS 4.1.1 Notecard firmware release.

Fallback to Periodic Mode

The uperiodic argument in a hub.set request configures the Notecard to use periodic mode when USB/line power is disconnected.

In the following example, when the Notecard has USB/line power it operates in continuous mode, with inbound Notefiles synced immediately and outbound Notefiles synced every minute. If USB/line power is disconnected, the Notecard changes to periodic mode and syncs Notefiles every hour.

{
  "req": "hub.set",
  "mode": "continuous",
  "sync": true,
  "voutbound": "usb:1;60",
  "uperiodic": true
}

J *req = NoteNewRequest("hub.set");
JAddStringToObject(req, "mode", "continuous");
JAddBoolToObject(req, "sync", true);
JAddStringToObject(req, "voutbound", "usb:1;60");
JAddBoolToObject(req, "uperiodic", true);

NoteRequest(req);

req = {"req": "hub.set"}
req["mode"] = "continuous"
req["sync"] = True
req["voutbound"] = "usb:1;60"
req["uperiodic"] = True

card.Transaction(req)

Fallback to Minimum or Off Modes

Likewise, you can fallback to minimum mode or off mode when USB/line power is disconnected with the umin or uoff arguments, respectively.

{
  "req": "hub.set",
  "mode": "continuous",
  "sync": true,
  "voutbound": "usb:1;60",
  "umin": true
}

J *req = NoteNewRequest("hub.set");
JAddStringToObject(req, "mode", "continuous");
JAddBoolToObject(req, "sync", true);
JAddStringToObject(req, "voutbound", "usb:1;60");
JAddBoolToObject(req, "umin", true);

NoteRequest(req);

req = {"req": "hub.set"}
req["mode"] = "continuous"
req["sync"] = True
req["voutbound"] = "usb:1;60"
req["umin"] = True

card.Transaction(req)

Host Power Management

In a well-designed low-power product, the host MCU — not the Notecard — is usually the largest contributor to idle draw. The host should spend the vast majority of its time in a deep-sleep mode (STM32 STOP / STANDBY, ESP32 deep sleep, nRF52 System OFF, etc.), waking only on an RTC tick or an external interrupt.

GPIO Discipline During Sleep

Hitting low current targets on the host depends as much on what it does with its GPIOs and peripherals as on selecting the right sleep mode. Before entering sleep, the firmware must ensure that no pin or peripheral is sinking current from another rail.

The most common offender is I2C: if the host leaves SDA or SCL driven low (or enabled as push-pull outputs) before sleeping, it will drag down Notecard's pull-ups and hold the Notecard out of idle.

For peripherals that cannot be cleanly disabled in firmware (e.g. external UARTs, fixed-drive outputs, or sensors without a shutdown mode) use a level shifter and tie its OE pin to a host GPIO. Deasserting OE before sleep puts the whole bus in high-impedance, isolating the misbehaving peripheral from the Notecard's rails. See the Low-Power Hardware Design Guide for wiring recommendations.

Waking on Notecard Events with card.attn

If needed in your design, Notecard can also manage the power state of its connected host MCU using the card.attn API.

card.attn lets the host sleep until a specific Notecard event occurs, then Notecard pulls ATTN to wake it. Typical wake conditions include:

• Motion: wake on an accelerometer-detected movement
• Inbound data: wake when a Notefile or environment variable update arrives from Notehub
• USB insertion: wake when line power is applied
• Environment variable changes: wake when a Notehub-pushed variable changes
• Timer expiry: wake after a fixed seconds interval

warning

Additional Connection Required

As with the other uses of card.attn, this feature requires an additional physical connection between the Notecard and host beyond the default I2C or Serial connection for communication. In order to leverage the host power management feature described here, the Notecard ATTN pin must be wired to an EN or regulator pin on the host.

To utilize this feature, upon each boot, the host sends card.attn request to determine if the host is in an initial boot, or is being awakened from sleep.

First, the host configures this mode by passing sleep into the mode argument of a card.attn request, as well as a number of seconds to sleep.

{
  "req": "card.attn",
  "mode": "sleep",
  "seconds": 3600
}

J *req = NoteNewRequest("card.attn");
JAddStringToObject(req, "mode", "sleep");
JAddNumberToObject(req, "seconds", 3600);

NoteRequest(req);

req = {"req": "card.attn"}
req["mode"] = "sleep"
req["seconds"] = 3600

card.Transaction(req)

When this request is received, the Notecard pulls the ATTN pin LOW, and the host can respond by placing itself into a sleep or low power mode. After the seconds interval has elapsed, the ATTN pin is pulled HIGH. Upon restart, the host should send a no argument card.attn request. The response will include the value timeout to indicate a timeout as the reason for the pulling the pin HIGH.

{
 "files": [
  "timeout"
 ],
 "set": true
}

Optional: In order to disable the host RESET that is normally performed on the host MCU when the Notecard starts up, use the "stop":true argument in a card.dfu request.

{
  "req": "card.dfu",
  "stop": true
}

J *req = NoteNewRequest("card.dfu");
JAddBoolToObject(req, "stop", true);

NoteRequest(req);

req = {"req": "card.dfu"}
req["stop"] = True

card.Transaction(req)

If nonvolatile memory is at a premium or nonexistent on the host, the Notecard can hold data in memory on behalf of the host in the form of a Base64-encoded string. This string should be provided with a payload argument during the sleep mode call to card.attn.

{
  "req": "card.attn",
  "mode": "sleep",
  "seconds": 3600,
  "payload": "ewogICJpbnRlcnZhbHMiOiI2MCwxMiwxNCIKfQ=="
}

J *req = NoteNewRequest("card.attn");
JAddStringToObject(req, "mode", "sleep");
JAddNumberToObject(req, "seconds", 3600);
JAddStringToObject(req, "payload", "ewogICJpbnRlcnZhbHMiOiI2MCwxMiwxNCIKfQ==");

NoteRequest(req);

req = {"req": "card.attn"}
req["mode"] = "sleep"
req["seconds"] = 3600
req["payload"] = "ewogICJpbnRlcnZhbHMiOiI2MCwxMiwxNCIKfQ=="

card.Transaction(req)

When the host reawakens, the payload is retrieved by setting start to true in a card.attn request.

{
  "req": "card.attn",
  "start": true
}

J *req = NoteNewRequest("card.attn");
JAddBoolToObject(req, "start", true);

NoteRequest(req);

req = {"req": "card.attn"}
req["start"] = True

card.Transaction(req)

The response object also includes the UNIX Epoch time at which the payload was stored.

{
 "payload": "ewogICJpbnRlcnZhbHMiOiI2MCwxMiwxNCIKfQ==",
 "files": [
  "timeout"
 ],
 "time": 1599064794,
 "set": true
}

Voltage Monitoring

In some hardware designs, the Notecard's V+ will be connected directly to a battery. This approach is ideal for ensuring that potential current spikes during wireless transmission are served directly from the product's power source. What's more, the low standby power draw of the Notecard minimizes the potential downsides of this approach.

To measure the voltage on the Notecard's V+ pin, and obtain historical voltage information, use the card.voltage request with "mode":"?".

{
  "req": "card.voltage",
  "mode": "?"
}

J *req = NoteNewRequest("card.voltage");
JAddStringToObject(req, "mode", "?");

NoteRequest(req);

req = {"req": "card.voltage"}
req["mode"] = "?"

rsp = card.Transaction(req)

This request will return an object with the current power mode (or usb if the Notecard is being powered by a USB connection), the current voltage value, and the number of hours available for the Notecard to use for trend analysis. It will also return the minimum (vmin), maximum (vmax), and average (vavg) voltages during that time frame.

As of Notecard firmware v3.2.1, four additional boolean values may appear in the response if the Notecard is connected to USB power ("usb": true), the cellular modem is active ("cell": true), the WiFi radio is active ("wifi": true), and/or the GPS module is active ("gps": true).

Finally, the object includes values indicating the moving average in voltage over the past 24 hours (daily), 7 days (weekly), and 30 days (monthly), if those values are relevant to the time period analyzed.

{
 "usb": true,
 "hours": 120,
 "mode": "usb",
 "value": 5.112190219747135,
 "vmin": 4,
 "vmax": 4,
 "vavg": 4
}

A card.voltage request can be customized to analyze a developer-defined number of hours with the hours argument. This argument can be any whole number up to 720 (30 days) and it defaults to use all of the data available to the Notecard.

{
  "req": "card.voltage",
  "hours": 8
}

J *req = NoteNewRequest("card.voltage");
JAddNumberToObject(req, "hours", 8);

NoteRequest(req);

req = {"req": "card.voltage"}
req["hours"] = 8

rsp = card.Transaction(req)

You can also use the offset argument to instruct the Notecard to go back a set number of hours into the past before starting analysis.

{
  "req": "card.voltage",
  "hours": 24,
  "offset": 48
}

J *req = NoteNewRequest("card.voltage");
JAddNumberToObject(req, "hours", 24);
JAddNumberToObject(req, "offset", 48);

NoteRequest(req);

req = {"req": "card.voltage"}
req["hours"] = 24
req["offset"] = 48

rsp = card.Transaction(req)

Finally, you can use the vmax and vmin arguments to tell the Notecard to ignore voltage measurements above or below a certain level, respectively.

{
  "req": "card.voltage",
  "hours": 300,
  "vmax": 4,
  "vmin": 2.2
}

J *req = NoteNewRequest("card.voltage");
JAddNumberToObject(req, "hours", 300);
JAddNumberToObject(req, "vmax", 4);
JAddNumberToObject(req, "vmin", 2.2);

NoteRequest(req);

req = {"req": "card.voltage"}
req["hours"] = 300
req["vmax"] = 4
req["vmin"] = 2.2

rsp = card.Transaction(req)

Detecting Charge Source on Solar and Energy-Harvesting Designs

On products powered by solar panels or other harvesting sources, knowing whether the battery is currently charging is often as useful as knowing its voltage. Notecard can monitor this directly via its AUX_CHARGING pin, provided the pin is wired to the PMIC's charge-in-progress indicator.

Enable detection with a card.carrier request:

{
  "req": "card.carrier",
  "mode": "charging"
}

J *req = NoteNewRequest("card.carrier");
JAddStringToObject(req, "mode", "charging");

NoteRequest(req);

req = {"req": "card.carrier"}
req["mode"] = "charging"

card.Transaction(req)

Once set, subsequent card.carrier responses will include "charging": true whenever the PMIC is actively charging.

Temperature Monitoring

Sometimes a product will be deployed in environments where extreme temperatures may affect battery performance. In these situations, you may need to know the temperature within the electronics enclosure. The Notecard has a calibrated absolute temperature sensor that can be used to measure the temperature around the Notecard with a card.temp request.

{
  "req": "card.temp"
}

J *req = NoteNewRequest("card.temp");

NoteRequest(req);

req = {"req": "card.temp"}

rsp = card.Transaction(req)

This request returns an object with the temperature in degrees centigrade, and a calibration value. The calibration value, taken together with the temp value means that the Notecard measured a value of 29.3125, which was adjusted to 26.3125 before being returned.

{
 "value": 26.3125,
 "calibration": -3
}

note

Notecard temperature readings are performed by the device's onboard accelerometer. If the accelerometer is disabled with a card.motion.mode request, card.temp will return an error.

COPY

{
  "err": "temperature is not available if accelerometer was disabled with card.motion.mode"
}

Motion Monitoring

The Notecard includes a three-axis accelerometer that can be used to detect the orientation of the module or when the Notecard is in motion with a card.motion request.

note

Motion monitoring is not supported on the Notecard LoRa.

{
  "req": "card.motion"
}

J *req = NoteNewRequest("card.motion");

NoteRequest(req);

req = {"req": "card.motion"}

rsp = card.Transaction(req)

When passed with no arguments, the Notecard responds with a count of the number of motion events since the last time the request was made, a motion field with the UNIX Epoch time of the last motion event, and an alert field if a free-fall was detected since the last call.

The response will also include the current device orientation in the status field. The orientation will be one of the following values:

• face-up
• face-down
• portrait-up
• portrait-down
• landscape-right
• landscape-left

{
  "status": "face-down",
  "motion": 1599073299,
  "count": 1
}

Retrieving Motion Results Over a Time Period

By default, card.motion returns a single orientation status and a count of motion events. You can also use the minutes argument to specify an amount of time to sample for buckets of movement.

{
  "req": "card.motion",
  "minutes": 5
}

J *req = NoteNewRequest("card.motion");
JAddNumberToObject(req, "minutes", 5);

NoteRequest(req);

req = {"req": "card.motion"}
req["minutes"] = 5

rsp = card.Transaction(req)

When card.motion is used in this manner, the Notecard will return a movements field of movement buckets (up to 250 samples). Each character is a base 36 value (0-9, A-Z and * to indicate a value greater than 35) that shows the most-recent to least-recent number of movements for each bucket during the amount of time sampled. A seconds field, which signifies the size of each bucket, is also returned.

{
 "count": 17,
 "seconds": 5,
 "status": "face-up",
 "movements": "520000000000000000000A",
 "motion": 1599074347
}

In the example above, the Notecard detected five movements in the first (or, most-recent) bucket, two in the second, and ten in the last. No movement was detected for all of the other buckets.

Configuring Motion Monitoring

If you need finer-grained control over motion tracking on the Notecard, use the card.motion.mode request. With this request, you can stop motion monitoring with the stop argument. Once sent, subsequent calls to card.motion return an empty JSON object ({}).

{
  "req": "card.motion.mode",
  "stop": true
}

J *req = NoteNewRequest("card.motion.mode");
JAddBoolToObject(req, "stop", true);

NoteRequest(req);

req = {"req": "card.motion.mode"}
req["stop"] = True

card.Transaction(req)

Use the start argument to turn motion monitoring back on:

{
  "req": "card.motion.mode",
  "start": true
}

J *req = NoteNewRequest("card.motion.mode");
JAddBoolToObject(req, "start", true);

NoteRequest(req);

req = {"req": "card.motion.mode"}
req["start"] = True

card.Transaction(req)

note

The Notecard uses its onboard accelerometer to perform temperature readings in response to card.temp requests. If you need this feature in your app, make sure that card.motion.mode is active or card.temp requests will return an error.

You can also use the seconds argument to specify a period for each bucket when using the minutes argument with card.motion. For instance, the following request sets the bucket size to 30 seconds:

{
  "req": "card.motion.mode",
  "seconds": 30
}

J *req = NoteNewRequest("card.motion.mode");
JAddNumberToObject(req, "seconds", 30);

NoteRequest(req);

req = {"req": "card.motion.mode"}
req["seconds"] = 30

card.Transaction(req)

If you then perform another request to card.motion and set the minutes argument to 2, the response will return a movements string with four characters, one for each 30 second bucket of motion.

{
  "req": "card.motion",
  "minutes": 2
}

J *req = NoteNewRequest("card.motion");
JAddNumberToObject(req, "minutes", 2);

NoteRequest(req);

req = {"req": "card.motion"}
req["minutes"] = 2

rsp = card.Transaction(req)

{
  "seconds": 30,
  "status": "face-up",
  "movements": "1010",
  "motion": 1599074347
}

Finally, if you need to adjust the sensitivity of the accelerometer, use the sensitivity field. The default sample rate of 1.6Hz could miss short-duration accelerations (e.g. bumps and jolts), and free fall detection may not work reliably with short falls. The penalty for increasing the sample rate to 25Hz is increased current consumption by ~1.5uA relative to the default -1 setting.

• -1: 1.6Hz, +/-2G range, 1 milli-G sensitivity (default)
• 1: 25Hz, +/- 16G range, 7.8 milli-G sensitivity
• 2: 25Hz, +/- 8G range, 3.9 milli-G sensitivity
• 3: 25Hz, +/- 4G range, 1.95 milli-G sensitivity
• 4: 25Hz, +/- 2G range, 1 milli-G sensitivity
• 5: 25Hz, +/- 2G range, 0.25 milli-G sensitivity

{
  "req": "card.motion.mode",
  "sensitivity": 3
}

J *req = NoteNewRequest("card.motion.mode");
JAddNumberToObject(req, "sensitivity", 3);

NoteRequest(req);

req = {"req": "card.motion.mode"}
req["sensitivity"] = 2

card.Transaction(req)

Automatic Motion Capture

To automatically store motion events as Notes in a Notefile, use the card.motion.track request and the start argument. If successful, calls to this request return an empty JSON object ({}).

{
  "req": "card.motion.track",
  "start": true
}

J *req = NoteNewRequest("card.motion.track");
JAddBoolToObject(req, "start", true);

NoteRequest(req);

req = {"req": "card.motion.track"}
req["start"] = True

card.Transaction(req)

By default, the Notecard stores motion events in a Notefile called _motion.qo. You can specify your own Notefile with the file argument. You can also use the minutes to specify the maximum frequency at which Notes will be recorded, count for the number of most recent buckets to examine, and threshold to specify the number of buckets that must indicate motion in order for a tracking Note to be added.

{
  "req": "card.motion.track",
  "start": true,
  "minutes": 5,
  "count": 10,
  "threshold": 2,
  "file": "movements.qo"
}

J *req = NoteNewRequest("card.motion.track");
JAddBoolToObject(req, "start", true);
JAddNumberToObject(req, "minutes", 5);
JAddNumberToObject(req, "count", 10);
JAddNumberToObject(req, "threshold", 2);
JAddStringToObject(req, "file", "movements.qo");

NoteRequest(req);

req = {"req": "card.motion.track"}
req["start"] = True
req["minutes"] = 5
req["count"] = 10
req["threshold"] = 2
req["file"] = "movements.qo"

card.Transaction(req)

With the now argument set to true, the Notecard will immediately create a _motion.qo event if the orientation of the Notecard changes (overriding the minutes setting).

{
  "req": "card.motion.track",
  "start": true,
  "minutes": 5,
  "count": 10,
  "threshold": 2,
  "file": "movements.qo",
  "now": true
}

J *req = NoteNewRequest("card.motion.track");
JAddBoolToObject(req, "start", true);
JAddNumberToObject(req, "minutes", 5);
JAddNumberToObject(req, "count", 10);
JAddNumberToObject(req, "threshold", 2);
JAddStringToObject(req, "file", "movements.qo");
JAddBoolToObject(req, "now", true);

NoteRequest(req);

req = {"req": "card.motion.track"}
req["start"] = True
req["minutes"] = 5
req["count"] = 10
req["threshold"] = 2
req["file"] = "movements.qo"
req["now"] = True

card.Transaction(req)

To stop automatic motion capture, use the stop argument.

{
  "req": "card.motion.track",
  "stop": true
}

J *req = NoteNewRequest("card.motion.track");
JAddBoolToObject(req, "stop", true);

NoteRequest(req);

req = {"req": "card.motion.track"}
req["stop"] = True

card.Transaction(req)

note

For location-aware applications, Notecard's accelerometer is also used to gate GPS sampling. With the "mode":"periodic" argument of card.location.mode, GPS only activates after motion is detected. See Sampling GPS Readings with Periodic Mode for how the motion threshold and seconds/vseconds arguments work to keep a stationary tracker from consuming power.

Configuring Sync on Notecard Motion

Finally, use the card.motion.sync to configure automatic syncs to Notehub based on Notecard movement. Use the start argument to turn this feature on:

{
  "req": "card.motion.sync",
  "start": true
}

J *req = NoteNewRequest("card.motion.sync");
JAddBoolToObject(req, "start", true);

NoteRequest(req);

req = {"req": "card.motion.sync"}
req["start"] = True

card.Transaction(req)

And stop to turn it off:

{
  "req": "card.motion.sync",
  "stop": true
}

J *req = NoteNewRequest("card.motion.sync");
JAddBoolToObject(req, "stop", true);

NoteRequest(req);

req = {"req": "card.motion.sync"}
req["stop"] = True

card.Transaction(req)

For finer-grained control, use the minutes argument to specify the maximum frequency at which a sync will be initiated, count for the number of most recent buckets to examine, and threshold to specify the number of buckets that must indicate motion in order for sync to be triggered.

{
  "req": "card.motion.sync",
  "start": true,
  "minutes": 20,
  "count": 20,
  "threshold": 5
}

J *req = NoteNewRequest("card.motion.sync");
JAddBoolToObject(req, "start", true);
JAddNumberToObject(req, "minutes", 20);
JAddNumberToObject(req, "count", 20);
JAddNumberToObject(req, "threshold", 5);

NoteRequest(req);

req = {"req": "card.motion.sync"}
req["start"] = True
req["minutes"] = 20
req["count"] = 20
req["threshold"] = 5

card.Transaction(req)

Customizing Voltage-Variable Behaviors

A number of requests in the Notecard API, like hub.set and card.location, can be configured to use voltage-variable behaviors to perform battery- intensive actions like a sync or tracking location with GPS. If your product battery (a LiPo, for instance) allows you to use voltage as a proxy for the available energy left in the battery, use the card.voltage API's mode argument to specify voltage values that correspond to the following battery states:

• usb
• high
• normal
• low
• dead

tip

When battery voltage drops into the low state, the right response in most deployments is to stretch the device's remaining runtime by throttling sync intervals and sensor sampling, not to give up and let it die silently. A fleet of devices that each report once per day at a low voltage is far more useful than the same fleet going dark a week earlier. Use voltage-variable arguments throughout your design, then surface the devices currently operating in degraded modes via Notehub Smart Fleet Rules so the fleet administrator can see them.

For instance, if powering a project with a LiPo battery, you'd use the following for the mode argument:

{
  "req": "card.voltage",
  "mode": "lipo"
}

J *req = NoteNewRequest("card.voltage");
JAddStringToObject(req, "mode", "lipo");

NoteRequest(req);

req = {"req": "card.voltage"}
req["mode"] = "lipo"

rsp = card.Transaction(req)

Consult the card.voltage API docs for a complete listing of the mode options.

If you need to customize the battery state voltage levels, you can use the mode field as well.

{
  "req": "card.voltage",
  "mode": "usb:4.6;high:4.2;normal:3.6;low:0"
}

J *req = NoteNewRequest("card.voltage");
JAddStringToObject(req, "mode", "usb:4.6;high:4.2;normal:3.6;low:0");

NoteRequest(req);

req = {"req": "card.voltage"}
req["mode"] = "usb:4.6;high:4.2;normal:3.6;low:0"

rsp = card.Transaction(req)

If your application needs to use a similar approach for timing intervals against a connected sensor or peripheral, you can use the name argument to specify an environment variable. This variable can then be set in Notehub to override application default timing values.

{
  "req": "card.voltage",
  "mode": "lipo",
  "name": "sensor-timings"
}

J *req = NoteNewRequest("card.voltage");
JAddStringToObject(req, "mode", "lipo");
JAddStringToObject(req, "name", "sensor-timings");

NoteRequest(req);

req = {"req": "card.voltage"}
req["mode"] = "lipo"
req["mode"] = "sensor-timings"

rsp = card.Transaction(req)

Sampling at Voltage-variable Intervals

If the Notecard is sampling in periodic mode and you want to minimize the impact of GPS on the battery powering your project, use the vseconds argument to instruct the device to take the charge of your battery into consideration when obtaining GPS readings.

The vseconds argument should be a semicolon-delimited string that defines a period for each state of your battery. The pre-defined Notecard battery states are:

• usb
• high
• normal
• low
• dead

When the Notecard's battery is in a given state, it will adjust the period based on the values defined in the vseconds string.

For instance, if you wanted to sample GPS once per hour when the battery is full, but scale back the sample rate as the power decreases, you'd provide a vseconds string like this:

{
  "req": "card.location.mode",
  "mode": "periodic",
  "vseconds": "usb:3600;high:14400;normal:43200;low:86400;dead:0"
}

J *req = NoteNewRequest("card.location.mode");
JAddStringToObject(req, "mode", "periodic");
JAddStringToObject(req, "vseconds", "usb:3600;high:14400;normal:43200;low:86400;dead:0");

NoteRequest(req);

req = {"req": "card.location.mode"}
req["mode"] = "periodic"
req["vseconds"] = "usb:3600;high:14400;normal:43200;low:86400;dead:0"

rsp = card.Transaction(req)

This will return an object confirming that the Notecard is in periodic mode and that GPS should be sampled at a voltage-variable rate:

{
 "mode": "periodic",
 "vseconds": "usb:3600;high:14400;normal:43200;low:86400;dead:0"
}

To set the sample rate from a voltage variable rate back to a set rate, set vseconds to - and provide a new value for the seconds argument:

{
  "req": "card.location.mode",
  "mode": "periodic",
  "vseconds": "-",
  "seconds": 60
}

J *req = NoteNewRequest("card.location.mode");
JAddStringToObject(req, "mode", "periodic");
JAddStringToObject(req, "vseconds", "-");
JAddNumberToObject(req, "seconds", 60);

NoteRequest(req);

req = {"req": "card.location.mode"}
req["mode"] = "periodic"
req["vseconds"] = "-"
req["seconds"] = 60

rsp = card.Transaction(req)

This will return an object confirming that the Notecard is in periodic mode and sample GPS at a set rate:

{
 "mode": "periodic",
 "seconds": 60
}

Achieving the Lowest Possible Power State

The Notecard's hardware components and factory firmware settings provide a default experience with minimal power usage. There are additional Notecard API requests and hardware settings that can be altered to achieve the right balance of power savings and functionality for your specific requirements.

warning

Do not repeatedly power-cycle or reset Notecard to save power. Notecard is designed to be continuously powered. Its idle draw is already very low, and power-cycling it at runtime incurs a startup cost (i.e. re-registering with the network, reacquiring time, etc.) that dwarfs any savings. Leave VIO powered at all times.

For example, the following Notecard API commands will place the Notecard in its lowest possible power state (e.g. ~8µA@5V on a Notecard Cellular):

// perform a "factory reset" on the Notecard and restart
{"req":"card.restore","delete":true}

// disables all syncing between Notecard and Notehub
{"req":"hub.set","mode":"off"}

// disable the Notecard accelerometer and stop motion tracking
{"req":"card.motion.mode","stop":true}

// disables ATTN processing and sets the pin OFF
{"req":"card.attn","off":true}

// disable GPS
{"req":"card.location.mode","mode":"off"}

// disable AUX mode
{"req":"card.aux","mode":"off"}

// enable ESP32 deep sleep (only for NOTE-ESP)
{"req":"card.sleep","on":true}

Likewise, the Notecarrier in use can impact overall power consumption. For instance, the Notecarrier A provides the best out-of-the-box power performance of ~8-9µA@5V with a Notecard Cellular.

The Notecarrier F, however, requires changing a DIP switch to achieve the lowest possible power state. For example, on a Notecarrier F v1.3, setting the FEATHER_EN DIP switch to N_ATTN (which disables the Feather) will lead to the lowest possible power usage (approximately ~9-11µA@5V with a Notecard Cellular).

note

There is a lot of capacitance aboard the Notecarrier F, so you may see the current start high and drift downward toward ~9-11µA@5V.

Debug Tip: Visually Confirm Idle Behavior with a Monitor-Mode LED

While bringing up a low-power design, it can be hard to tell from a multimeter alone whether the Notecard is actually idling as expected. A helpful trick is to wire an LED or NeoPixel to the AUX pins and configure them to light under different scenarios. See the Using LEDs and NeoPixels to Monitor Notecard Status example app for more information.

Power Usage Estimates

All Notecards idle at approximately ~8-18µA@5V, but actual power consumption metrics depend on how the Notecard is used in practice.

This section outlines several common use cases and provides the estimated power consumption for each, based on measurements taken with a Blues Mojo under standardized test conditions and representative cellular signal strengths.

• Test: Initial Power-Up to First Network Connection
• Test: "Cold" Network Connection After Restart
• Test: "Warm" Network Connection
• Test: Create and Sync One Note in Minimum Mode
• Test: Continuous Mode for 12 Hours with 5-Minute Syncs
• Test: Minimum/Periodic Mode for 12 Hours with 30-Minute Syncs
• Test: Perform Notecard DFU

Additional tests were performed on Starnote for Skylo (paired with a Notecard Cell+WiFi MBGLW using WiFi transport for the initial required connections). Please note that all Starnote test results also include power consumption of its paired Notecard, which is generally just the Notecard's idle draw.

• Starnote Test: Create and Sync One Note
• Starnote Test: Minimum Mode for 12 Hours with 60-Minute Syncs

warning

The following data points are best used as a relative comparison between Notecards. Any product design alterations or Notecard models incorporated should be based on your own real-world usage of Notecard, unique to the physical enclosure, antennas, and geographic location.

Testing Parameters

• Tests were performed using firmware v9.1.1, with each device in the same physical location.
• Tests were run using the following independently-powered hardware:
  • Blues Swan 3.0
  • Notecarrier A (Notecarrier XS when testing Starnote for Skylo)
  • Blues Mojo
• A bench power supply was used to power all hardware at 5.5V.
• The body of the "generic Note" used when needed was {"temp":12.3,"alert":true}.
• The Arduino sketches used for the test runs are available on GitHub for Notecards and for Starnote for Skylo.

note

All test results are reported in milliamp hours (mAh); lower values indicate lower power consumption.

Cellular Signal Considerations

Since the strength of a cellular signal and the network technology in use can directly impact power usage (e.g. a weaker signal may require a Notecard to be active for longer to transmit all data), the following table provides a listing of the representational signal strength indicators for each Notecard Cellular or Notecard Cell+WiFi used for testing.

For more information on decoding the following indicators of cellular signal quality, please consult our guide on Diagnosing Cellular Connectivity Issues.

Test: Initial Power-Up to First Network Connection

This test measures power usage from when a Notecard is first powered on, through to a successful connection to Notehub.

Test: "Cold" Network Connection After Restart

This test measures power usage after a Notecard is restarted (using the card.restart API), through to a successful connection to Notehub, averaged across ten independent runs.

Test: "Warm" Network Connection

This test measures power usage of a fresh connection to Notehub, after closing the previous connection to Notehub, averaged across ten independent runs.

Test: Create and Sync One Note in Minimum Mode

This test measures power usage of creating and immediately syncing one Note: from establishing a new network connection, through to successfully syncing the Note with Notehub, averaged across ten independent runs.

Test: Continuous Mode for 12 Hours with 5-Minute Syncs

This test measures power usage of a Notecard in continuous mode for twelve hours, while creating and immediately syncing a new Note every five minutes.

Test: Minimum/Periodic Mode for 12 Hours with 30-Minute Syncs

This test measures power usage of a Notecard in minimum mode for twelve hours, while creating and immediately syncing a new Note every thirty minutes.

Test: Perform Notecard DFU

This test measures power usage while performing an update of the Notecard's firmware via Notehub.

Starnote Test: Create and Sync One Note

This test measures power usage of creating and immediately syncing one Note using Starnote for Skylo, averaged across five independent runs.

Starnote Test: Minimum Mode for 12 Hours with 60-Minute Syncs

This test measures power usage of Starnote for Skylo in minimum mode for twelve hours, while creating and immediately syncing a new Note every sixty minutes.

Deep Sleep Mode on Notecard WiFi v2

Unlike other STM32-based Notecards, Notecard WiFi v2 does not (by default) fall back to a ~10uA current draw when it is idle. This is because the ESP32 on Notecard WiFi v2 doesn't have a STOP mode equivalent where the UART and I2C can operate. The ESP32 does have a deep sleep mode that draws ~10µA@5V, but in this state:

• The RTC is retained
• GPIOs are retained
• It can wake based on RTC or GPIO
• UART and I2C are not functional

Enabling Deep Sleep Mode

To enable Notecard WiFi v2 to enter a deep sleep state during periods of inactivity, the host must configure it with the card.sleep API:

{
  "req": "card.sleep",
  "on": true
}

J *req = NoteNewRequest("card.sleep");
JAddBoolToObject(req, "on", true);

NoteRequest(req);

req = {"req": "card.sleep"}
req["on"] = True
rsp = card.Transaction(req)

In addition, the CTX and RTX pins on Notecard must be wired to GPIOs on your host. These pins are exposed on Notecarrier F and the Notecarrier X series.

When the Notecard is in this state, you must drive RTX high to wake the Notecard from deep sleep when it wants to communicate via UART or I2C. The Notecard WiFi v2 sets CTX high whenever it is ready to receive commands via I2C or UART. Note that there is significant latency on wake (~10 seconds).

The Notecard firmware libraries provide helper functions to handle this automatically:

notecard.setTransactionPins(_ctx_pin, _rtx_pin);

card.SetTransactionPins(_ctx_pin, _rtx_pin)

note

Notecard WiFi v2 will never enter deep sleep mode if any of the following are true (this behavior is analogous to the STM32-based Notecards):

• RTX is high
• USB is connected
• AUX-EN is high
• If the Notecard is in continuous mode