---
title: Low-Power Firmware Design
description: Firmware and API techniques for minimizing Notecard power consumption in battery-operated applications.
source_url: https://dev.blues.io/notecard/notecard-walkthrough/low-power-firmware-design/
canonical_url: https://dev.blues.io/notecard/notecard-walkthrough/low-power-firmware-design/
markdown_url: https://dev.blues.io/notecard/notecard-walkthrough/low-power-firmware-design.md
---

# 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](https://dev.blues.io/notecard/notecard-walkthrough/advanced-notecard-configuration.md#functions-that-require-setting-time) require the current time, which is established upon the Notecard successfully connecting to Notehub upon startup.
>
> Consult the [Low-Power Hardware Design Application Note](https://dev.blues.io/datasheets/application-notes/low-power-hardware-design.md) 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_P` (pin 56) is pulled up to `VIO`.

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.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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.

> **Note:**
>
> When using `periodic` or `continuous` mode, both `outbound` and `inbound` are required. If either is omitted, the Notecard behaves as if it is in `minimum` mode for that sync direction (syncing only when explicitly triggered with `hub.sync`).

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.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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 until instructed otherwise. To do this, use the `off` mode.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

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

card.Transaction(req)
```

### Voltage-Variable Sync Behavior

Each of the examples above requires 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:

**JSON**

```json
{
  "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"
}
```

**C/C++**

```cpp
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);
```

**Python**

```python
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"`.

To clear a voltage-variable value and revert to the standard `outbound`/`inbound` behavior, pass `"-"` as the value for `voutbound` or `vinbound`.

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

```json
{
 "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](https://dev.blues.io/notecard/notecard-firmware-releases.md#lts-v4-1-1-december-7-2022).

#### 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 both outbound and inbound data every hour.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

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

card.Transaction(req)
```

#### Fallback to Minimum or Off Modes

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

To fall back to `minimum` mode:

**JSON**

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

**C/C++**

```cpp
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);
```

**Python**

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

card.Transaction(req)
```

To fall back to `off` mode (modem completely disabled when unplugged):

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
req = {"req": "hub.set"}
req["mode"] = "continuous"
req["sync"] = True
req["voutbound"] = "usb:1;60"
req["uoff"] = 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](https://dev.blues.io/datasheets/application-notes/low-power-hardware-design.md#level-shifting) 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](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-attn).

`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 a `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.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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 pulling the pin `HIGH`.

```json
{
 "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 and when the Notecard wakes the host after a `card.attn` sleep timeout, use the `"stop":true` argument in a [card.dfu](https://dev.blues.io/api-reference/notecard-api/card-requests/latest.md#card-dfu) request. This is particularly useful when you want the host to resume from a known state after a sleep-wake cycle rather than performing a full MCU reset.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

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

card.Transaction(req)
```

If the host needs to preserve a small amount of state across a sleep-wake cycle, the Notecard can hold a Base64-encoded string on behalf of the host. Pass the data as a `payload` argument in the `sleep` mode call to `card.attn`.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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.

```json
{
 "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.

The Notecard exposes its `V+` voltage and a built-in historical voltage analyzer through the [`card.voltage`](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-voltage) request.

### Reading the Current Voltage

A bare `card.voltage` request returns the current voltage on the Notecard's `V+` pin along with the Notecard's computed voltage-variable threshold bucket.

**JSON**

```json
{
  "req": "card.voltage"
}
```

**C/C++**

```cpp
J *req = NoteNewRequest("card.voltage");

NoteRequest(req);
```

**Python**

```python
req = {"req": "card.voltage"}

rsp = card.Transaction(req)
```

The response always includes:

- `value` — the current voltage, in volts.
- `mode` — the current voltage-variable threshold bucket, one of `high`, `normal`, `low`, `dead`, or `usb`. See [Customizing Voltage-Variable Behaviors](#customizing-voltage-variable-behaviors) for what each state represents and how the bucket is computed.

When the Notecard is connected to USB power, the response also includes `"usb": true` and reports `mode` as `"usb"`.

```json
{
 "usb": true,
 "mode": "usb",
 "value": 5.112190219747135
}
```

When the Notecard is on battery, the response instead includes `minutes`, the number of minutes since the Notecard was last on USB power.

```json
{
 "mode": "normal",
 "value": 3.95,
 "minutes": 1440
}
```

### Enabling Historical Voltage Trends

The Notecard can also track up to 720 hours (30 days) of voltage history and include statistical analysis with each `card.voltage` response. Historical analysis is opt-in; enable it once with `"on": true`.

**JSON**

```json
{
  "req": "card.voltage",
  "on": true
}
```

**C/C++**

```cpp
J *req = NoteNewRequest("card.voltage");
JAddBoolToObject(req, "on", true);

NoteRequest(req);
```

**Python**

```python
req = {"req": "card.voltage"}
req["on"] = True

rsp = card.Transaction(req)
```

This setting persists across reboots, so it only needs to be sent once per Notecard. To turn historical analysis off later, send `{"req":"card.voltage","off":true}`.

> **Note:**
>
> Historical analysis requires the Notecard's clock to be set, which typically happens after the first successful sync with Notehub. Until the clock is set, `card.voltage` will return an error of the form `{"err":"time required for history analysis {time-unavailable}"}`.

Once history is enabled, subsequent `card.voltage` responses include these additional fields:

- `hours` — the number of hours of voltage history actually used in the analysis.
- `vmin`, `vmax`, `vavg` — the minimum, maximum, and average voltage during the analyzed window.
- `daily`, `weekly`, `monthly` — the change in moving-average voltage over the past 24 hours, 7 days, and 30 days, when those time periods fall within the analyzed window. A negative value indicates voltage is trending downward.

```json
{
 "mode": "normal",
 "value": 3.85,
 "hours": 720,
 "vmin": 3.2,
 "vmax": 4.1,
 "vavg": 3.75,
 "daily": -0.05,
 "weekly": -0.3,
 "monthly": -0.8,
 "minutes": 43200
}
```

### Customizing the Analysis Window

By default, voltage trend analysis uses all available history (up to 720 hours, or 30 days). The `hours` argument narrows the window to a specific number of hours.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

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

rsp = card.Transaction(req)
```

The `offset` argument tells the Notecard to skip a set number of hours into the past before starting analysis. The example below analyzes the 24-hour window that ended 48 hours ago.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

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

rsp = card.Transaction(req)
```

The `vmax` and `vmin` arguments tell the Notecard to ignore voltage measurements above or below specific levels when computing statistics.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

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

rsp = card.Transaction(req)
```

### Monitoring USB Power State

The Notecard can watch for USB power connect and disconnect events and respond automatically. Enable USB monitoring with `"usb": true`:

**JSON**

```json
{
  "req": "card.voltage",
  "usb": true,
  "alert": true,
  "sync": true
}
```

**C/C++**

```cpp
J *req = NoteNewRequest("card.voltage");
JAddBoolToObject(req, "usb", true);
JAddBoolToObject(req, "alert", true);
JAddBoolToObject(req, "sync", true);

NoteRequest(req);
```

**Python**

```python
req = {"req": "card.voltage"}
req["usb"] = True
req["alert"] = True
req["sync"] = True

rsp = card.Transaction(req)
```

- `usb: true` — activates USB power-state monitoring.
- `alert: true` — adds an entry to `_health.qo` whenever USB power is connected or disconnected.
- `sync: true` — triggers an immediate sync to Notehub on USB connect or disconnect.

All three arguments are independent. You can, for example, enable `sync` without `alert` to silently sync on USB plug/unplug, or enable `alert` without `sync` to log the event without an immediate upload.

> **Note:**
>
> `usb` requires firmware v3.5.1 or later. These settings persist across reboots. To disable USB monitoring, send `{"req":"card.voltage","usb":false}`.

### 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:

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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.

**JSON**

```json
{
  "req": "card.temp"
}
```

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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.

```json
{
 "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](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-motion-mode), `card.temp` will return an error.
>
> ```json
> {
>   "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 for LoRa.

**JSON**

```json
{
  "req": "card.motion"
}
```

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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`
- `angled` (when the board is tilted but not clearly in any of the above orientations)

```json
{
  "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.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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.

```json
{
 "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 (`{}`).

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

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

card.Transaction(req)
```

Use the `start` argument to turn motion monitoring back on:

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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](https://dev.blues.io/notecard/notecard-walkthrough/low-power-firmware-design.md#temperature-monitoring). 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:

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

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

rsp = card.Transaction(req)
```

```json
{
  "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

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
req = {"req": "card.motion.mode"}
req["sensitivity"] = 3

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 (`{}`).

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

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

card.Transaction(req)
```

By default, the Notecard stores motion events in a Notefile called [`_motion.qo`](https://dev.blues.io/api-reference/system-notefiles.md#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.

**JSON**

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

**C/C++**

```cpp
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);
```

**Python**

```python
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).

**JSON**

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

**C/C++**

```cpp
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);
```

**Python**

```python
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.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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](https://dev.blues.io/notecard/notecard-walkthrough/time-and-location-requests.md#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:

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

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

card.Transaction(req)
```

And `stop` to turn it off:

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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 allows you to use voltage as a proxy for available energy, you can use the `card.voltage` request's `mode` argument to map voltage levels to the following battery states:

- `usb`
- `high`
- `normal`
- `low`
- `dead`

The `mode` argument accepts either a **named preset** (like `"lipo"`) or a **custom voltage string**. Both are described below.

> **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](https://dev.blues.io/notehub/notehub-walkthrough.md#using-smart-fleet-rules) so the fleet administrator can see them.

### Using a Named Preset

Named presets set the voltage thresholds for your battery chemistry automatically. For instance, for a LiPo battery:

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

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

rsp = card.Transaction(req)
```

Consult the [card.voltage API](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-voltage) docs for a complete listing of named presets (`lipo`, `l91`, `alkaline`, and others).

### Using a Custom Voltage String

If the built-in presets don't match your battery's characteristics, you can provide a custom semicolon-delimited string of `state:voltage` pairs as the `mode` value directly.

> **Note:**
>
> List the pairs in **descending** voltage order. Working from the highest threshold down, the Notecard returns the first state whose threshold is at or below the current voltage. End the string with `dead:0` as a catch-all for any voltage not matched by an earlier entry.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
req = {"req": "card.voltage"}
req["mode"] = "usb:4.6;high:4.2;normal:3.6;low:3.1;dead: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.

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
req = {"req": "card.voltage"}
req["mode"] = "lipo"
req["name"] = "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:

**JSON**

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

**C/C++**

```cpp
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);
```

**Python**

```python
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:

```json
{
 "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:

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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:

```json
{
 "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):

```json
// 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.

![notecard cellular and notecarrier a](https://dev.blues.io/images/guides/notecard-walkthrough/carr-a-low-power.jpg?v=20521865)

The Notecarrier F, however, requires changing a [DIP switch](https://dev.blues.io/datasheets/notecarrier-datasheet/notecarrier-f-v1-3.md#dip-switches) 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.

![notecard cellular and notecarrier f](https://dev.blues.io/images/guides/notecard-walkthrough/carr-f-low-power.jpg?v=2f29c1ff)

### 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](https://dev.blues.io/example-apps/samples/using-leds-and-neopixels-to-monitor-notecard-status.md) 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](https://shop.blues.com/collections/accessories/products/mojo?utm_source=dev-blues\&utm_medium=web\&utm_campaign=store-link) under [standardized test conditions](#testing-parameters) and representative [cellular signal strengths](#cellular-signal-considerations).

- [Test: Initial Power-Up to First Network Connection](#test-initial-power-up-to-first-network-connection)
- [Test: "Cold" Network Connection After Restart](#test-cold-network-connection-after-restart)
- [Test: "Warm" Network Connection](#test-warm-network-connection)
- [Test: Create and Sync One Note in Minimum Mode](#test-create-and-sync-one-note-in-minimum-mode)
- [Test: Continuous Mode for 12 Hours with 5-Minute Syncs](#test-continuous-mode-for-12-hours-with-5-minute-syncs)
- [Test: Minimum/Periodic Mode for 12 Hours with 30-Minute Syncs](#test-minimum-periodic-mode-for-12-hours-with-30-minute-syncs)
- [Test: Perform Notecard DFU](#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-create-and-sync-one-note)
- [Starnote Test: Minimum Mode for 12 Hours with 60-Minute Syncs](#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](https://shop.blues.com/collections/feather-mcu/products/swan?utm_source=dev-blues\&utm_medium=web\&utm_campaign=store-link)
  - [Notecarrier A](https://shop.blues.com/products/carr-al?utm_source=dev-blues\&utm_medium=web\&utm_campaign=store-link) ([Notecarrier XS](https://shop.blues.com/products/notecarrier-xs?utm_source=dev-blues\&utm_medium=web\&utm_campaign=store-link) when testing Starnote for Skylo)
  - [Blues Mojo](https://shop.blues.com/collections/accessories/products/mojo?utm_source=dev-blues\&utm_medium=web\&utm_campaign=store-link)

- 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](https://gist.github.com/rdlauer/a1bbe3eda1bb4800ab7b5de4921685ca) and [for Starnote for Skylo](https://gist.github.com/rdlauer/763b49a52272f693642de380cb47b433).

> **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](https://dev.blues.io/support/diagnosing-cellular-connectivity-issues.md#measuring-the-quality-of-the-cellular-connection).

| Notecard       | Network Tech  | RSSI | SINR | RSRP | RSRQ | Bars |
| -------------- | ------------- | ---- | ---- | ---- | ---- | ---- |
| **Narrowband** |               |      |      |      |      |      |
| NOTE-NBGL      | LTE-M         | -49  | 19   | -76  | -12  | 3    |
| NOTE-NBGLN     | LTE-M         | -56  | 12   | -83  | -13  | 2    |
| NOTE-NBGLN     | NB-IoT        | -63  | 17   | -74  | -10  | 4    |
| NOTE-NBGLW     | LTE-M         | -62  | 16   | -85  | -9   | 3    |
| NOTE-NBNA      | LTE-M         | -59  | 20   | -87  | -14  | 3    |
| NOTE-NBNAN     | LTE-M         | -62  | 11   | -86  | -10  | 2    |
| NOTE-NBNAW     | LTE-M         | -58  | 17   | -81  | -11  | 3    |
| **Midband**    |               |      |      |      |      |      |
| NOTE-MBGLN     | LTE Cat-1 bis | -63  | 14   | -91  | -10  | 2    |
| NOTE-MBGLW     | LTE Cat-1 bis | -62  | 15   | -90  | -10  | 3    |
| NOTE-MBNAN     | LTE Cat-1 bis | -60  | 15   | -93  | -16  | 2    |
| NOTE-MBNAW     | LTE Cat-1 bis | -71  | 21   | -94  | -9   | 2    |
| **Wideband**   |               |      |      |      |      |      |
| NOTE-WBGLWT    | LTE Cat-1     | -60  | 16   | -91  | -14  | 2    |
| NOTE-WBNA      | LTE Cat-1     | -56  | 19   | -85  | -13  | 3    |
| NOTE-WBNAN     | LTE Cat-1     | -57  | 24   | -88  | -15  | 3    |
| NOTE-WBNAW     | LTE Cat-1     | -63  | 12   | -92  | -13  | 2    |

### 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.

| Notecard       | Network Tech  | mAh   |
| -------------- | ------------- | ----- |
| **Narrowband** |               |       |
| NOTE-NBGL      | LTE-M         | 0.941 |
| NOTE-NBGLN     | LTE-M         | 0.887 |
| NOTE-NBGLN     | NB-IoT        | 0.672 |
| NOTE-NBGLW     | LTE-M         | 0.751 |
| NOTE-NBNA      | LTE-M         | 0.970 |
| NOTE-NBNAN     | LTE-M         | 0.879 |
| NOTE-NBNAW     | LTE-M         | 0.727 |
| **Midband**    |               |       |
| NOTE-MBGLN     | LTE Cat-1 bis | 0.540 |
| NOTE-MBGLW     | LTE Cat-1 bis | 0.477 |
| NOTE-MBNAN     | LTE Cat-1 bis | 0.504 |
| NOTE-MBNAW     | LTE Cat-1 bis | 0.539 |
| **Wideband**   |               |       |
| NOTE-WBGLWT    | LTE Cat-1     | 0.709 |
| NOTE-WBNA      | LTE Cat-1     | 1.372 |
| NOTE-WBNAN     | LTE Cat-1     | 1.200 |
| NOTE-WBNAW     | LTE Cat-1     | 1.120 |

### 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.

| Notecard       | Network Tech  | mAh   |
| -------------- | ------------- | ----- |
| **Narrowband** |               |       |
| NOTE-NBGL      | LTE-M         | 0.908 |
| NOTE-NBGLN     | LTE-M         | 0.794 |
| NOTE-NBGLN     | NB-IoT        | 0.623 |
| NOTE-NBGLW     | LTE-M         | 0.667 |
| NOTE-NBNA      | LTE-M         | 0.848 |
| NOTE-NBNAN     | LTE-M         | 0.801 |
| NOTE-NBNAW     | LTE-M         | 0.668 |
| **Midband**    |               |       |
| NOTE-MBGLN     | LTE Cat-1 bis | 0.498 |
| NOTE-MBGLW     | LTE Cat-1 bis | 0.485 |
| NOTE-MBNAN     | LTE Cat-1 bis | 0.438 |
| NOTE-MBNAW     | LTE Cat-1 bis | 0.519 |
| **Wideband**   |               |       |
| NOTE-WBGLWT    | LTE Cat-1     | 0.750 |
| NOTE-WBNA      | LTE Cat-1     | 1.241 |
| NOTE-WBNAN     | LTE Cat-1     | 1.036 |
| NOTE-WBNAW     | LTE Cat-1     | 1.073 |

### 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.

| Notecard       | Network Tech  | mAh   |
| -------------- | ------------- | ----- |
| **Narrowband** |               |       |
| NOTE-NBGL      | LTE-M         | 0.402 |
| NOTE-NBGLN     | LTE-M         | 0.415 |
| NOTE-NBGLN     | NB-IoT        | 0.464 |
| NOTE-NBGLW     | LTE-M         | 0.517 |
| NOTE-NBNA      | LTE-M         | 0.475 |
| NOTE-NBNAN     | LTE-M         | 0.455 |
| NOTE-NBNAW     | LTE-M         | 0.513 |
| **Midband**    |               |       |
| NOTE-MBGLN     | LTE Cat-1 bis | 0.303 |
| NOTE-MBGLW     | LTE Cat-1 bis | 0.363 |
| NOTE-MBNAN     | LTE Cat-1 bis | 0.300 |
| NOTE-MBNAW     | LTE Cat-1 bis | 0.426 |
| **Wideband**   |               |       |
| NOTE-WBGLWT    | LTE Cat-1     | 0.748 |
| NOTE-WBNA      | LTE Cat-1     | 0.956 |
| NOTE-WBNAN     | LTE Cat-1     | 0.788 |
| NOTE-WBNAW     | LTE Cat-1     | 0.910 |

### 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.

| Notecard       | Network Tech  | mAh   |
| -------------- | ------------- | ----- |
| **Narrowband** |               |       |
| NOTE-NBGL      | LTE-M         | 0.275 |
| NOTE-NBGLN     | LTE-M         | 0.258 |
| NOTE-NBGLN     | NB-IoT        | 0.242 |
| NOTE-NBGLW     | LTE-M         | 0.360 |
| NOTE-NBNA      | LTE-M         | 0.291 |
| NOTE-NBNAN     | LTE-M         | 0.257 |
| NOTE-NBNAW     | LTE-M         | 0.323 |
| **Midband**    |               |       |
| NOTE-MBGLN     | LTE Cat-1 bis | 0.261 |
| NOTE-MBGLW     | LTE Cat-1 bis | 0.284 |
| NOTE-MBNAN     | LTE Cat-1 bis | 0.211 |
| NOTE-MBNAW     | LTE Cat-1 bis | 0.299 |
| **Wideband**   |               |       |
| NOTE-WBGLWT    | LTE Cat-1     | 0.517 |
| NOTE-WBNA      | LTE Cat-1     | 0.747 |
| NOTE-WBNAN     | LTE Cat-1     | 0.701 |
| NOTE-WBNAW     | LTE Cat-1     | 0.776 |

### 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.

| Notecard       | Network Tech  | mAh   |
| -------------- | ------------- | ----- |
| **Narrowband** |               |       |
| NOTE-NBGL      | LTE-M         | 294.8 |
| NOTE-NBGLN     | LTE-M         | 278.1 |
| NOTE-NBGLN     | NB-IoT        | 253.3 |
| NOTE-NBGLW     | LTE-M         | 293.2 |
| NOTE-NBNA      | LTE-M         | 301.8 |
| NOTE-NBNAN     | LTE-M         | 286.8 |
| NOTE-NBNAW     | LTE-M         | 294.9 |
| **Midband**    |               |       |
| NOTE-MBGLN     | LTE Cat-1 bis | 156.9 |
| NOTE-MBGLW     | LTE Cat-1 bis | 158.7 |
| NOTE-MBNAN     | LTE Cat-1 bis | 155.1 |
| NOTE-MBNAW     | LTE Cat-1 bis | 160.6 |
| **Wideband**   |               |       |
| NOTE-WBGLWT    | LTE Cat-1     | 220.4 |
| NOTE-WBNA      | LTE Cat-1     | 255.0 |
| NOTE-WBNAN     | LTE Cat-1     | 257.6 |
| NOTE-WBNAW     | LTE Cat-1     | 263.0 |

### 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.

| Notecard       | Network Tech  | mAh   |
| -------------- | ------------- | ----- |
| **Narrowband** |               |       |
| NOTE-NBGL      | LTE-M         | 9.27  |
| NOTE-NBGLN     | LTE-M         | 10.62 |
| NOTE-NBGLN     | NB-IoT        | 10.19 |
| NOTE-NBGLW     | LTE-M         | 12.28 |
| NOTE-NBNA      | LTE-M         | 9.52  |
| NOTE-NBNAN     | LTE-M         | 10.23 |
| NOTE-NBNAW     | LTE-M         | 11.32 |
| **Midband**    |               |       |
| NOTE-MBGLN     | LTE Cat-1 bis | 8.86  |
| NOTE-MBGLW     | LTE Cat-1 bis | 10.12 |
| NOTE-MBNAN     | LTE Cat-1 bis | 8.92  |
| NOTE-MBNAW     | LTE Cat-1 bis | 10.20 |
| **Wideband**   |               |       |
| NOTE-WBGLWT    | LTE Cat-1     | 14.41 |
| NOTE-WBNA      | LTE Cat-1     | 18.32 |
| NOTE-WBNAN     | LTE Cat-1     | 19.92 |
| NOTE-WBNAW     | LTE Cat-1     | 21.01 |

### Test: Perform Notecard DFU

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

| Notecard       | Network Tech  | mAh   |
| -------------- | ------------- | ----- |
| **Narrowband** |               |       |
| NOTE-NBGL      | LTE-M         | 9.23  |
| NOTE-NBGLN     | LTE-M         | 5.12  |
| NOTE-NBGLN     | NB-IoT        | 9.31  |
| NOTE-NBGLW     | LTE-M         | 7.00  |
| NOTE-NBNA      | LTE-M         | 8.29  |
| NOTE-NBNAN     | LTE-M         | 7.40  |
| NOTE-NBNAW     | LTE-M         | 4.16  |
| **Midband**    |               |       |
| NOTE-MBGLN     | LTE Cat-1 bis | 1.80  |
| NOTE-MBGLW     | LTE Cat-1 bis | 2.20  |
| NOTE-MBNAN     | LTE Cat-1 bis | 2.03  |
| NOTE-MBNAW     | LTE Cat-1 bis | 2.04  |
| **Wideband**   |               |       |
| NOTE-WBGLWT    | LTE Cat-1     | 3.35  |
| NOTE-WBNA      | LTE Cat-1     | 16.53 |
| NOTE-WBNAN     | LTE Cat-1     | 8.11  |
| NOTE-WBNAW     | LTE Cat-1     | 7.76  |

### 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.

| Device             | Network Tech | mAh   |
| ------------------ | ------------ | ----- |
| Starnote for Skylo | NTN          | 0.169 |

### 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.

| Device             | Network Tech | mAh   |
| ------------------ | ------------ | ----- |
| Starnote for Skylo | NTN          | 27.16 |

## Deep Sleep Mode on Notecard WiFi v2

Unlike 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](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-sleep):

**JSON**

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

**C/C++**

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

NoteRequest(req);
```

**Python**

```python
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](https://dev.blues.io/tools-and-sdks/firmware-libraries.md) provide helper functions to handle this automatically:

**C/C++**

```cpp
notecard.setTransactionPins(_ctx_pin, _rtx_pin);
```

**Python**

```python
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

[Web Transactions](https://dev.blues.io/notecard/notecard-walkthrough/web-transactions.md "Web Transactions") [Low Bandwidth Design](https://dev.blues.io/notecard/notecard-walkthrough/low-bandwidth-design.md "Low Bandwidth Design")