Low Power 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.
noteAs a low-power device (consuming only ~8uA 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 a cellular network upon startup.
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. The Notecard
is extremely low 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.
When designing a system that utilizes the Notecard, its 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.
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.
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.
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.
Both arguments expect semicolon-delimited string values with intervals that correspond to a battery state. The pre-defined Notecard battery states are:
usbhighnormallowdead
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. Note: 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:
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.
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.
Host Power Management
If needed in your design, the Notecard can also manage the power state of its
host using the card.attn request.
warningAdditional 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.
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
}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.
When the host reawakens, the payload is retrieved by setting start to true
in a card.attn request.
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":"?".
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 Wi-Fi 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.
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.
Finally, you can use the vmax and vmin arguments to tell the Notecard to
ignore voltage measurements above or below a certain level, respectively.
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.
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
}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.
{ "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.
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-upface-downportrait-upportrait-downlandscape-rightlandscape-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.
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 ({}).
Use the start argument to turn motion monitoring back on:
warningThe 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:
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.
{ "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 sensitivity2: 25Hz, +/- 8G range, 3.9 milli-G sensitivity3: 25Hz, +/- 4G range, 1.95 milli-G sensitivity4: 25Hz, +/- 2G range, 1 milli-G sensitivity5: 25Hz, +/- 2G range, 0.25 milli-G sensitivity
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 ({}).
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.
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).
To stop automatic motion capture, use the stop argument.
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:
And stop to turn it off:
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.
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:
usbhighnormallowdead
For instance, if powering a project with a LiPo battery, you'd use the
following for the mode argument:
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.
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.
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:
usbhighnormallowdead
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:
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:
This will return an object confirming that the Notecard is in periodic mode and sample GPS at a set rate:
{
"mode": "periodic",
"seconds": 60
}