Firmware Best Practices Guide

The firmware running on your host MCU is the virtual brains of your smart connected product. It acts as the bridge between your sensors and actuators and the cloud services that give your connected product business value to you and your customers. How you architect this firmware affects everything from battery life and data costs, to how easily you can update devices in the field and how gracefully your product handles real-world connectivity challenges.

This guide covers firmware development patterns for connected products using Blues Notecard, synthesizing best practices from Blues documentation, and customer deployments. Whether you're building a battery-powered asset tracker or a mains-powered industrial monitor, these patterns will help you create firmware that's production-ready from day one.

note

Key Takeaways

• Treat Notecard as a durable on-device queue—your firmware doesn't need to manage connectivity.
• Design for intermittent connectivity from day one; buffer data locally and sync when possible.
• Use environment variables for remote configuration instead of hardcoding behavior.
• Plan for over-the-air firmware updates before your first deployment.

In This Guide

This guide covers firmware patterns for building production-ready connected products with Blues Notecard:

• Working with Notecard's Queue-Based Model: How Notecard handles connectivity so your firmware doesn't have to.
• Power Management Patterns: Sync cycles, voltage-variable behavior, host MCU power strategies, and power budgeting.
• Remote Configuration with Environment Variables: Changing device behavior remotely without firmware updates.
• Over-the-Air Firmware Updates: Planning and implementing OTA DFU with Notecard.
• Satellite-Specific Considerations: Payload limits, compact templates, and firmware patterns for Starnote and Skylo.
• Error Handling and Resilience: Sync failures, sensor validation, and recovery strategies.
• Firmware Development Checklist: A checklist to verify before deploying firmware.

Working with Notecard's Queue-Based Model

The most important concept to understand when developing firmware for Notecard-based products is that Notecard acts as a durable on-device queue. Your host firmware doesn't need to manage connectivity, handle retries, or worry about network availability. Instead, you add data (i.e. events or Notes) to Notefiles (queues), and Notecard handles everything else, like data storage when offline, syncing when connectivity is available, and retrying failed transmissions automatically.

The Notecard Communication Pattern

Your firmware's interaction with Notecard follows a simple pattern:

1. Add Notes to Notefiles by sending JSON data to Notecard via I2C, UART, or Serial. This is a local operation that succeeds even when there's no network connectivity.
2. Notecard handles sync timing based on your configured sync mode and intervals, managing when to connect to the appropriate network (e.g. cellular, satellite, LoRa, WiFi).
3. Notecard manages retries automatically if a sync fails, ensuring your data eventually reaches Notehub without data loss and without your firmware needing to track delivery status.

This model means your host firmware can focus on what it does best: reading sensors, controlling actuators, and implementing your product's core logic while Notecard handles the networking complexity.

Power Management Patterns

For battery-powered devices, power management is often the most critical firmware concern. Notecard provides several mechanisms for optimizing power consumption, but using them effectively requires understanding how Notecard draws power and coordinating between Notecard and your host MCU.

When idle (not actively transmitting), the Notecard typically draws only ~8–18 µA@5V!

Understanding Notecard Sync Cycles

The impact of sync frequency on battery life can be dramatic. A device syncing hourly might last years on a battery that would drain in days with continuous connectivity and repeated syncs. Understanding your application's true latency requirements is essential for optimizing power.

The Notecard API supports placing a device in minimum mode (meaning only sync when instructed to in firmware), periodic mode (meaning connect and sync on a specified cadence), and continuous mode (meaning establish and maintain a network connection).

While they each have their pros and cons, most battery-powered smart connected products will benefit from using periodic mode. This is especially true since Notecard will not even attempt to establish a network connection if there is nothing to sync!

Voltage-Variable Sync Behavior

Notecard supports voltage-variable sync behavior that automatically adapts sync frequency based on battery voltage. As voltage drops, Notecard can reduce sync frequency to extend remaining battery life, providing graceful degradation rather than sudden failure.

Configure voltage thresholds using the card.voltage API to define how Notecard should behave at different battery levels. Consider implementing multiple degradation stages: perhaps syncing hourly at full charge, every four hours at 50% battery, and once daily when critically low.

This approach requires thinking through your product priorities. What's more important, frequent updates or maximum battery life? The answer often varies by battery level, which is exactly what this voltage-variable behavior enables!

Host MCU Power Strategies

Notecard can manage the power state of a connected host MCU using the ATTN pin. For example, Notecard can cut power to the host and restore it only when specific conditions are met—such as a scheduled time interval, accelerometer activity, or the arrival of inbound data. See Host Power Management to learn more.

Power Budget Planning

Before deployment, you need a realistic power budget. Estimate battery life based on your sync frequency, sensor reading frequency, and host MCU duty cycle. The Power Usage Estimates documentation provides a rough structure for what you can expect. Then measure actual consumption using tools like the Blues Mojo power-analysis board.

Common power pitfalls include underestimating cellular transmission power (which can spike as high as 2A), forgetting to account for GPS acquisition time if using location features, and assuming ideal cellular conditions when real-world signal strength is often marginal.

Remote Configuration with Environment Variables

Hardcoding behavior in firmware creates problems at scale. When you need to change sync intervals, adjust thresholds, or enable features across your fleet, you don't want to push firmware updates to every device. Environment variables provide a mechanism for remote configuration without firmware changes.

The Environment Variable Hierarchy

Environment variables in Notehub exist at three levels. When the same variables are used at lower levels they override higher level variables, enabling powerful customization of function and behavior.

1. Project-level variables apply to all devices in a project and are useful for global settings.
2. Fleet-level variables apply to devices in a specific fleet, enabling different configurations for different deployment stages or customer segments.
3. Device-level variables apply to individual devices, useful for per-device customization or troubleshooting.

This hierarchy enables powerful patterns. Set a default sync interval at the project level, override it for your beta fleet to get more frequent data during testing, and further override it for specific devices that need special handling.

DB Notefiles for Stateful Configuration

Environment variables are excellent for simple key-value configuration, but some use cases require more complex state synchronization. DB Notefiles provide bidirectional state replication between Notehub and devices, which is useful when you need the cloud to know the current state of device configuration, not just what it should be.

Use DB Notefiles when configuration is complex (nested structures, arrays), when you need acknowledgment that configuration was received, or when device-side state needs to sync back to the cloud.

Over-the-Air Firmware Updates

The ability to update firmware remotely transforms how you operate connected products. Bug fixes, security patches, and new features can reach devices in the field without truck rolls. But OTA updates require planning—both in how you design your firmware and how you manage the update process.

Notecard Outboard Firmware Update

Blues recommends using Notecard Outboard Firmware Update (a.k.a. ODFU) for host MCU firmware updates. ODFU works by storing firmware images on Notecard's flash, then streaming the image to your MCU over the existing I2C or serial connection. This approach works regardless of your MCU's architecture, RTOS, or programming language.

ODFU requires some hardware consideration as your MCU needs enough flash to store both the running firmware and a bootloader that can receive and apply updates. The integration pattern involves implementing a bootloader that checks for available updates and applies them, plus application code that triggers the update process when appropriate.

Preparing Your Firmware for OTA DFU

Version numbering conventions matter more than you might think. Establish a clear versioning scheme (semantic versioning is common) and ensure your firmware reports its version to Notehub so you can track what's running where.

Binary preparation using the binpack tool packages your firmware for OTA distribution. Integrate this into your build process so every release is OTA-ready.

Testing update flows before production deployment is critical. Verify that updates work reliably in your test environment, including edge cases like updates during low battery, updates interrupted by power loss, and updates to devices that have been offline for extended periods.

Satellite-Specific Considerations (Starnotes and Notecard for Skylo)

If your product uses Blues Starnote for satellite connectivity when cellular isn't available, additional firmware considerations apply. Satellite connectivity has different constraints than cellular, and firmware that works well on cellular may perform poorly or incur excessive costs on satellite.

Understanding Satellite Constraints

Payload size limits are much more restrictive on satellite than cellular. Starnote for Iridium payloads range from 10-340 bytes, while Skylo payloads range from 50-256 bytes. Firmware designed to send large JSON payloads over cellular will need adaptation for satellite.

Higher latency expectations are inherent to satellite communication. Data may take minutes rather than seconds to reach Notehub, and round-trip communication for acknowledgments takes longer still. Design your firmware to not depend on immediate responses.

Cost per byte is significantly higher on satellite than cellular. Every byte of unnecessary data like verbose field names, redundant metadata, or debug information, costs real money at scale.

Compact Templates for Satellite

Reducing metadata overhead through the use of compact Note templates is required for satellite efficiency. Standard Notes include metadata like device IDs and timestamps in every transmission.

Designing minimal payloads requires thinking carefully about what data is truly necessary. Can you send deltas instead of absolute values? Can you batch multiple readings into single transmissions? Can you reduce numeric precision without losing meaningful information?

Implementing cellular AND satellite redundancies requires the use of NTN vs non-NTN template patterns to handle the common case where devices have both cellular and satellite connectivity. Define two templates for the same data type: a full-featured template for cellular (non-NTN) and a compact template for satellite (NTN). Notecard intelligently switches between them based on current connectivity.

Starnote-Specific Firmware Patterns

Be sure to sync with Notehub once over cellular or WiFi (and when any templates change) before attempting satellite operations! Starnote needs the current time and location data to communicate with satellites efficiently. Skipping this sync prevents Starnote from transmitting data to Notehub.

Use a fixed GPS location for stationary deployments to save power. If your device isn’t expected to move, configure a fixed location manually, or configure the Notecard to use GPS to capture location one time to determine location before disabling it.

Minimizing unnecessary syncs is even more important on satellite than cellular. Every sync consumes power and costs money. Queue data aggressively and sync only when you have meaningful data to send or when you need to check for inbound commands from Notehub.

Error Handling and Resilience

Production firmware encounters conditions that never appear in testing. Sensors fail, connectivity drops at inconvenient times, and edge cases that seemed impossible turn out to be possible after all. Resilient firmware handles these gracefully rather than failing mysteriously.

Handling Sync Failures

Notecard automatically retries failed syncs, so your firmware generally doesn't need to manage retry logic. What your firmware should do is monitor sync status if your application depends on timely delivery. The hub.sync.status API tells you whether recent syncs succeeded and what's still pending.

What your firmware shouldn't do is implement its own retry logic on top of Notecard's. This leads to duplicate data, wasted power, and complexity without benefit.

Sensor and Data Validation

Validate readings before queuing to avoid sending garbage data to your cloud backend. Sensors occasionally return impossible values like negative temperatures from a thermistor, pressure readings outside physical bounds, or status codes indicating failure.

Handling sensor failures gracefully means detecting when a sensor stops responding or returns consistently invalid data. Your firmware might log the failure, retry initialization, or switch to a backup sensor, but it shouldn't silently send bad data!

Data quality patterns include sanity checks ("is this value physically possible?"), trend validation ("did the value change by more than expected since last reading?"), and sensor health monitoring ("is the sensor responding at all?").

Recovery Strategies

Watchdog patterns ensure your firmware recovers from unexpected hangs. Implement both hardware watchdogs (if your MCU supports them) and software watchdogs that detect stuck states and trigger recovery.

"Self-healing" firmware attempts to recover from error conditions automatically. If a sensor fails, try reinitializing it. If communication with Notecard fails, reset the connection. If configuration seems corrupt, restore defaults.

Remote diagnostics via environment variables enable support engineers to investigate issues without physical access. Environment variables can enable verbose logging, trigger diagnostic routines, or adjust timing parameters to work around issues while a proper fix is developed.

Firmware Development Checklist

Before deploying firmware to your device, verify you've at least noted, if not fully addressed, these areas:

Architecture

• Using Notecard's queue-based model and a proper sync schedule (e.g. not trying to manage connectivity manually)
• JSON data schema defined and versioned for Notes
• Error handling for sensor failures and connectivity gaps

Power

• Power budget calculated and validated with actual measurements
• Voltage-variable behavior configured appropriately with Notecard, if using battery power
• Host MCU sleep patterns implemented, if necessary
• Peak current requirements verified against power supply capability

Remote Configuration

• Key parameters configurable via Notehub environment variables
• Appropriate hierarchy level selected for all env vars (e.g. device/fleet/project)
• Default values defined for when environment variables not set
• Configuration changes tested across device restarts

OTA DFU

• ODFU integration implemented and tested
• Firmware failure/rollback strategy defined and tested
• Binary (binpack) preparation integrated into build workflow

Satellite (if applicable for your product)

• Compact templates defined for NTN transmission
• Template switching logic implemented and tested
• Payload sizes validated against satellite limits

Resources and Next Steps

With your firmware architecture planned, you're ready to move forward! The following resources provide deeper guidance on some of the topics we looked at in this guide.

Blues Resources

• Best Practices for Production-Ready Projects
• Low Power Design
• Understanding Environment Variables
• Notecard Outboard Firmware Update
• Starnote Best Practices

Getting Help

If you have additional questions about firmware development for your Blues-based product:

• Post questions on the Blues Community Forum
• Contact Blues sales for enterprise-level support