--- title: Troubleshooting Notecard description: A systematic guide to diagnosing and resolving Notecard and Notehub issues, whether you have local access to the device or are troubleshooting remotely. source_url: https://dev.blues.io/support/troubleshooting-notecard/ canonical_url: https://dev.blues.io/support/troubleshooting-notecard/ markdown_url: https://dev.blues.io/support/troubleshooting-notecard.md --- # Troubleshooting Notecard This guide provides a systematic approach to troubleshooting Blues Notecard devices and their connectivity to [Notehub](https://notehub.io). It's divided into two parts based on the level of access you have to the device: - **[Local Device Troubleshooting](#local-device-troubleshooting):** You have a physical serial or USB connection to Notecard (via the [In-Browser Terminal](https://dev.blues.io/terminal/), [Notecard CLI](https://dev.blues.io/tools-and-sdks/notecard-cli.md), or your host MCU) and you can issue any Notecard API request directly. - **[Remote Device Troubleshooting](#remote-device-troubleshooting):** The device is deployed in the field and you have no physical access. You must rely on Notehub's dashboard, environment variables, and system Notefiles like `_health.qo` and `_log.qo` to diagnose issues. ## Local Device Troubleshooting When you have direct serial or USB access to Notecard, you can issue API requests and receive responses. This gives you the most complete view of device state and is the fastest way to diagnose issues. ### Local: Initial Diagnostics Start every local troubleshooting session by collecting basic device information, and potentially updating Notecard firmware if yours is out of date. - [Verify Notecard Firmware Version](#verify-notecard-firmware-version) - [Check Device Status](#check-device-status) - [Validate Notecard's Time](#validate-notecards-time) #### Verify Notecard Firmware Version Use [`card.version`](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-version) to identify the Notecard firmware version, capabilities, and SKU: ```json {"req":"card.version"} ``` ```json { "version": "notecard-11.1.1.17494", "device": "dev:861059067916902", "name": "Blues Wireless Notecard", "sku": "NOTE-NBGLN", "ordering_code": "EB0WT1N0AXBA", "board": "5.13", "cell": true, "gps": true, "body": { "org": "Blues Wireless", "product": "Notecard", "target": "u5", "version": "notecard-u5-11.1.1", "ver_major": 11, "ver_minor": 1, "ver_patch": 1, "ver_build": 17494, "built": "Dec 8 2025 10:13:37" } } ``` > **Action:** > > Confirm the device is running the latest Developer release (or a recent LTS release) of [Notecard firmware](https://dev.blues.io/notecard/notecard-firmware-releases.md). #### Check Device Status Use [`card.status`](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-status) to get a summary of the device's current state: ```json {"req":"card.status"} ``` For example, check the `connected` field to determine if the device has an active Notehub session. This also reports USB power status, storage usage, and current time. ```json { "status": "{normal}", "usb": true, "storage": 8, "time": 1599684765, "connected": true, "cell": true, "sync": true, "inbound": 60, "outbound": 360 } ``` #### Validate Notecard's Time Use [`card.time`](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-time) to verify the device has a valid time reference: ```json {"req":"card.time"} ``` A valid time is [essential for proper operation](https://dev.blues.io/notecard/notecard-walkthrough/advanced-notecard-configuration.md#functions-that-require-setting-time). If time is unavailable, the tells us the device has not yet completed its first successful Notehub connection. ```json { "time": 1599769214, "area": "Beverly, MA", "zone": "CDT,America/New York", "minutes": -300, "lat": 42.5776, "lon": -70.87134, "country": "US" } ``` > **Action:** > > If the device is returning an unknown or invalid time, issue a `hub.sync` request to force a network connection and update the time on the device. ### Local: Connectivity Diagnostics Use these commands to diagnose potential cellular signal issues, verify radio transport and Notehub configuration, and confirm your Notecard's connection status. - [Check Cellular Signal Strength](#check-cellular-signal-strength) - [Verify Transport Configuration](#verify-transport-configuration) - [Look at Notehub Connection Status](#look-at-notehub-connection-status) - [Validate Notehub Configuration](#validate-notehub-configuration) #### Check Cellular Signal Strength If using a cellular-enabled Notecard, use [`card.wireless`](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-wireless) to check the cellular radio status and signal quality: ```json {"req":"card.wireless"} ``` When reviewing the response, there are some key signal quality metrics to keep in mind: | Metric | Description | Minimum Viable Values | | ------ | --------------------------------------- | --------------------- | | RSSI | Received Signal Strength Indicator | Greater than -85 dBm | | RSRP | Reference Signal Received Power | Greater than -111 dBm | | RSRQ | Reference Signal Received Quality | Greater than -12 dB | | SINR | Signal-to-Interference-plus-Noise Ratio | Greater than 5 dB | ```json { "status": "{modem-off}", "count": 1, "net": { "iccid": "00000000000000000000", "imsi": "000000000000000", "imei": "000000000000000", "modem": "EG91NAXGAR07A03M1G_BETA0415_01.001.01.001", "band": "LTE BAND 2", "rat": "lte", "rssir": -69, "rssi": -70, "rsrp": -105, "sinr": -3, "rsrq": -17, "bars": 1, "mcc": 310, "mnc": 410, "lac": 28681, "cid": 211150856, "updated": 1599225076 } } ``` > **Action:** > > If RSSI is below -85 dBm, the Notecard may struggle to maintain a connection. Consider improving antenna placement or using a different antenna. Poor SINR (i.e. below 0 dB) indicates potential radio interference. See [Diagnosing Cellular Connectivity Issues](https://dev.blues.io/support/diagnosing-cellular-connectivity-issues.md) for detailed signal troubleshooting tips. #### Verify Transport Configuration Use [`card.transport`](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-transport) to view the active communication method and its configuration (on Notecards that support more than one radio): ```json {"req":"card.transport"} ``` This shows the current transport method (e.g. cellular, WiFi, NTN, or fallback combinations) and is useful for confirming which radio interface is primary/secondary on Notecard Cell+WiFi devices. ```json { "method": "wifi-cell" } ``` > **Action:** > > Read the guide on [Connection Retry and Fallback Behaviors](https://dev.blues.io/support/connection-retry-and-fallback-behaviors.md) for more information. #### Look at Notehub Connection Status Use [`hub.status`](https://dev.blues.io/api-reference/notecard-api/hub-requests.md#hub-status) to check whether Notecard is actively connected to Notehub: ```json {"req":"hub.status"} ``` Check the `status` and `connected` fields. ```json { "status": "connected (session open) {connected}", "connected": true } ``` If the device shows `disconnected` or `idle`, it may be between sync intervals while in `periodic` or `minimum` modes. ```json { "status": "disconnected", "connected": false } ``` #### Validate Notehub Configuration Verify Notecard's connection configuration with Notehub using [`hub.get`](https://dev.blues.io/api-reference/notecard-api/hub-requests.md#hub-get): ```json {"req":"hub.get"} ``` The response will show which Notehub project the device is attached to (`product`) and the sync cadence (`mode` with `outbound` and `inbound` arguments). ```json { "device": "dev:000000000000000", "product": "com.your-company.your-name:your_product", "mode": "periodic", "outbound": 60, "inbound": 240, "host": "a.notefile.net", "sn": "your-serial-number" } ``` > **Action:** > > Confirm the `product` field matches your Notehub project's ProductUID and that `mode` is correct. For example: > > - **`periodic`**: Connects at regular intervals (set by `outbound`/`inbound` minutes). > - **`continuous`**: Maintains a persistent connection. Outbound data still syncs periodically unless a request specifies otherwise. > - **`minimum`**: Only syncs when explicitly triggered by a `hub.sync` request. OTA DFU updates are not available in this mode. ### Local: Data Flow and Environment Use these commands to verify sync behavior, test the full Notecard-to-Notehub data path, check Note templates, and inspect local environment variables. - [Sync Status and Forcing a Sync](#sync-status-and-forcing-a-sync) - [Test the Full Pipeline](#test-the-full-pipeline) - [Verify Note Templates](#verify-note-templates) - [Utilize Health Logging](#utilize-health-logging) - [Examine Local Environment Variables](#examine-local-environment-variables) #### Sync Status and Forcing a Sync Use [`hub.sync.status`](https://dev.blues.io/api-reference/notecard-api/hub-requests.md#hub-sync-status) to see any pending outbound and/or inbound Notes: ```json {"req":"hub.sync.status"} ``` To force an immediate sync: ```json {"req":"hub.sync"} ``` After issuing `hub.sync`, you can repeately issue `hub.sync.status` requests to observe the sync progressing. > **Action:** > > If the `status` field contains an error message (e.g., `not connected to network` or `modem not active`), this indicates a connectivity issue. Cross-reference with [`card.wireless`](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-wireless) to check signal quality. #### Test the Full Pipeline Add a test outbound Note and force a sync to verify the complete data path: ```json {"req":"note.add","file":"data.qo","body":{"test":true}} ``` > At this point it can be useful to start generating a [trace log](https://dev.blues.io/support/using-notecard-trace-mode.md) locally prior to and during the sync to help identify potential issues. ```json {"req":"hub.sync"} ``` > **Action:** > > After syncing, verify the test event appears in Notehub under your project's **Events** tab. If it does not appear, the issue is between the Notecard and Notehub (connectivity). If it does appear, the Notecard-to-Notehub path is working and the issue is likely on the host MCU side. #### Verify Note Templates If your application uses [Note templates](https://dev.blues.io/notecard/notecard-walkthrough/low-bandwidth-design.md#working-with-note-templates), verify the template configuration with [`note.template`](https://dev.blues.io/api-reference/notecard-api/note-requests.md#note-template): ```json {"req":"note.template","file":"readings.qo","verify":true} ``` Check the [data type values](https://dev.blues.io/notecard/notecard-walkthrough/low-bandwidth-design.md#understanding-template-data-types) in use. A mismatched template can prevent Notes from being processed correctly. > **Note:** > > You can also use the [Notefile explorer](https://dev.blues.io/notehub/notehub-walkthrough.md#managing-notefiles) in Notehub to verify that your templates have been applied correctly. > **Action:** > > If you suspect a data type mismatch, create a new Notefile Template, then retry your `note.add` operation. #### Utilize Health Logging While not an active troubleshooting step, using custom logging information generated on your device can be useful to create an audit trail in Notehub. Use [`hub.log`](https://dev.blues.io/api-reference/notecard-api/hub-requests.md#hub-log) to add device health log messages that will be transmitted to Notehub during the next sync via the `_health_host.qo` system Notefile: ```json {"req":"hub.log","text":"System status: normal"} ``` For urgent issues, use the `alert` flag to mark the message and `sync:true` to trigger an immediate sync (which also removes the Notecard from certain [penalty box](https://dev.blues.io/support/understanding-notecard-penalty-boxes.md) states): ```json {"req":"hub.log","text":"something is wrong!","alert":true,"sync":true} ``` The response is an empty JSON object `{}` on success. > **Action:** > > Use `hub.log` in your host firmware to surface critical events to Notehub. This creates a remotely visible audit trail in the `_health_host.qo` Notefile that you can monitor from the Notehub Events tab. This is especially useful for deployed devices where you cannot view local serial output. #### Examine Local Environment Variables If you suspect an issue with an invalid or missing environment variable on the device, you can always read environment variable values with [`env.get`](https://dev.blues.io/api-reference/notecard-api/env-requests.md#env-get): ```json {"req":"env.get","names":["monitoring"]} ``` You can set a default value for a variable locally with [`env.default`](https://dev.blues.io/api-reference/notecard-api/env-requests.md#env-default). This value applies until overridden by a device, project, or fleet-level setting in Notehub: ```json {"req":"env.default","name":"monitoring","text":"on"} ``` Check if variables have been updated since the last check with [`env.modified`](https://dev.blues.io/api-reference/notecard-api/env-requests.md#env-modified): ```json {"req":"env.modified"} ``` > **Note:** > > Locally-set environment variables will be overwritten by Notehub values on the next sync if the same variable is defined in Notehub! ### Local: Location, Power, and Hardware Use these commands to troubleshoot GPS and location tracking, check voltage and temperature readings, review attention/wake configuration, and verify host firmware update status. - [Check Location Tracking Mode](#check-location-tracking-mode) - [Retrieve Current Location](#retrieve-current-location) - [Monitor Voltage](#monitor-voltage) - [Check Firmware Update Status](#check-firmware-update-status) - [Perform a Factory Reset](#perform-a-factory-reset) #### Check Location Tracking Mode If your Notecard is not reporting location data as expected, start by confirming the GPS mode is configured correctly. Check the current GPS configuration with [`card.location.mode`](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-location-mode): ```json {"req":"card.location.mode"} ``` ```json { "mode": "continuous", "max": 100, "lat": 42.5776, "lon": -70.87134, "minutes": 2, "threshold": 4 } ``` Common modes: `periodic` (GPS at intervals), `continuous` (always-on), and `off` (disabled). Verify the mode is not set to `off` if location data is expected. > **Note:** > > The Notecard cannot use the internal GPS at the same time it has a data connection to Notehub. If both GPS and cellular are configured for high-frequency usage, they may interfere with each other. See [Diagnosing GPS Issues](https://dev.blues.io/support/diagnosing-gps-issues.md#avoid-simultaneous-usage-of-cellular-and-gps) for details. > **Action:** > > If location data is expected but not appearing, confirm the mode is not `off`. If the mode is `periodic`, check that the `seconds` interval is not conflicting with your `hub.set` sync intervals (e.g. `outbound` and `inbound`) and that [motion sensitivity](https://dev.blues.io/notecard/notecard-walkthrough/low-power-firmware-design.md#motion-monitoring) is appropriate for your use case. #### Retrieve Current Location If the tracking mode looks correct but location data is still missing or stale, check whether the Notecard has an active GPS fix. Retrieve the most recent GPS fix with [`card.location`](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-location): ```json {"req":"card.location"} ``` ```json { "status": "GPS updated (58 sec, 41dB SNR, 9 sats) {gps-active} {gps-signal} {gps-sats} {gps}", "mode": "periodic", "lat": 42.5776, "lon": -70.87134, "time": 1598554399, "max": 25 } ``` > **Action:** > > If no fix is available, try moving the device outdoors with a clear sky view and retry. Also confirm a GPS antenna is connected if using an external antenna. > > Consider falling back on [Cell Tower & WiFi Triangulation](https://dev.blues.io/notecard/notecard-walkthrough/time-and-location-requests.md#using-cell-tower-and-wifi-triangulation) as an alternative (if fine-grained location is not required) and consult [Diagnosing GPS Issues](https://dev.blues.io/support/diagnosing-gps-issues.md) for additional suggestions. #### Monitor Voltage Insufficient power is one of the most common causes of connectivity failures and unexpected behavior. Check the power supply with [`card.voltage`](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-voltage): ```json {"req":"card.voltage"} ``` *For example, when using a LiPo battery:* | LiPo Voltage Level | Status | Action | | ------------------ | ---------------- | --------------------------- | | Above 3.5V | Normal operation | No action needed | | 3.2V - 3.5V | Low battery | Plan battery replacement | | Below 3.2V | Critical | Replace battery immediately | > **Action:** > > If voltage is below 3.2V, the Notecard may not have enough power to start the modem. Replace or recharge the battery before continuing troubleshooting. Use a [Blues Mojo](https://dev.blues.io/datasheets/mojo-datasheet.md) in your hardware design to continually monitor power draw. #### Check Firmware Update Status If a [host firmware update (DFU)](https://dev.blues.io/notehub/host-firmware-updates/host-dfu-overview.md) was initiated and the device is not behaving as expected, verify whether the update completed successfully. Check current DFU status with [`dfu.status`](https://dev.blues.io/api-reference/notecard-api/dfu-requests.md#dfu-status): ```json {"req":"dfu.status","name":"user"} ``` > **Action:** > > If a DFU has failed, check power stability, connection quality, and that the firmware image is correct for the hardware SKU. Retry the update after resolving any underlying issues. #### Perform a Factory Reset If other troubleshooting steps have not resolved the issue, a factory reset clears most configuration values and returns the Notecard to its default state. As a last resort, restore the Notecard to factory defaults with [`card.restore`](https://dev.blues.io/api-reference/notecard-api/card-requests.md#card-restore): ```json {"req":"card.restore","delete":true} ``` > **Warning:** > > This erases all configuration, pending Notes, and stored data. The device will need to be completely reconfigured afterwards. Only use this as a last resort! ## Remote Device Troubleshooting When a device is deployed in the field and you cannot physically connect to it, you must use Notehub and Notecard's built-in remote management capabilities. This section covers the tools available for diagnosing issues without direct device access. ### Remote: Notehub Diagnostics The Notehub dashboard is your primary tool for remote troubleshooting. Navigate to your project, locate the device by its DeviceUID, and use the following views. - [Device Summary](#device-summary) - [Session History](#session-history) - [Events View](#events-view) - [Route Logs](#route-logs) - [Health Monitoring with \_health.qo](#health-monitoring-with-health-qo) - [Connectivity Analysis with \_session.qo](#connectivity-analysis-with-session-qo) #### Device Summary The device overview page shows the last known location, last connection time, and last transport used. This is your starting point for understanding a device's current state. ![notehub device summary view](https://dev.blues.io/images/support/trouble-devices.png?v=24337a9a) > **Action:** > > If the device's last connection time is older than expected based on your configured sync interval, the device may be offline. Check voltage and signal trends in `_health.qo` events to understand why. #### Session History Each time Notecard establishes a new connection with Notehub, it creates a session. The session history shows connection patterns, durations, and errors. ![notehub session list](https://dev.blues.io/images/support/trouble-sessions.png?v=056d68bd) Key things to look for: - **Regular session intervals** matching the configured sync mode. - **Unexpected gaps** in session history (may indicate power loss or connectivity failure). - **Session duration anomalies** (very short sessions may indicate connection instability). - **Session metadata** including RAT (Radio Access Technology), Notes received, and bytes used. > **Action:** > > Compare the actual session frequency against your expected `outbound`/`inbound` configuration. If sessions are less frequent than expected, the device is likely struggling to connect. If sessions are more frequent, check for unexpected triggers like host-initiated syncs separate from the sync cadence set in your `hub.set` request. #### Events View The **Events** tab shows all events in reverse chronological order. ![notehub events view](https://dev.blues.io/images/support/trouble-events.png?v=c9013938) Check this view for: - Recent events with expected timestamps and data fields. - Repeated error events or unusual patterns. - Errors with routing attempts. - [\_health.qo](#health-monitoring-with-health-qo) events with health telemetry. - [\_session.qo](#connectivity-analysis-with-session-qo) events showing connection/disconnection cycles. #### Route Logs If events reach Notehub but do not appear in your downstream service, check your Route configuration. Notehub provides route logs showing delivery attempts, HTTP status codes, and error messages. Verify the route is enabled, the endpoint URL is correct, and any JSONata transformation expressions are valid. ![A route log showing a routing error](https://dev.blues.io/images/blog/posts/whats-new-in-notehub/route-log.png?v=e3dc966e) > **Action:** > > If route logs show HTTP errors (4xx or 5xx), the issue is between Notehub and your downstream service, not the device. Check your endpoint availability and authentication credentials. #### Health Monitoring with \_health.qo The Notecard automatically sends health telemetry to Notehub via the `_health.qo` system Notefile. This is one of your most valuable remote troubleshooting tools because it requires no device-side configuration. *Example \_health.qo body:* ```json { "method": "boot", "text": "boot (brown-out & hard reset [17494])", "voltage": 4.6992188, "voltage_mode": "usb" } ``` To view `_health.qo` events in Notehub, navigate to your device and filter events by the `_health.qo` Notefile. Look for trends over time rather than single data points to identify developing issues. > **Action:** > > Configure a Notehub Route to forward relevant health data to your monitoring system. This can enable automated alerts when voltage drops below a threshold or signal strength degrades. #### Connectivity Analysis with \_session.qo Every time the Notecard establishes or closes a connection with Notehub, it creates a `_session.qo` event with [detailed connection metadata](https://dev.blues.io/api-reference/system-notefiles.md#session-qo). Key fields to examine: | Field | What It Tells You | | ------------------------------ | ------------------------------------------------------------------------------------------------ | | `voltage` | Current battery/power voltage. Declining voltage suggests a power issue. | | `rssi`, `rsrp`, `sinr`, `rsrq` | Cellular signal quality indicators. Consistently poor values indicate a signal or antenna issue. | | `bars` | A simplified 1-4 signal strength indicator. | | `rat` | The radio access technology in use (e.g., `lte`, `nbiot`, `gsm`). | | `tower_id` | The cell tower identifier (`mcc,mnc,lac,cid`). Changes may explain connectivity shifts. | > **Action:** > > Consult the [Diagnosing Cellular Connectivity Issues](https://dev.blues.io/support/diagnosing-cellular-connectivity-issues.md) guide for antenna and signal troubleshooting steps. ### Remote: Logging and Configuration The `_log.qo` system Notefile captures diagnostic log messages from Notecard and sends them to Notehub. Unlike `_health.qo`, logging must be explicitly enabled using the [`_log` reserved environment variable](https://dev.blues.io/guides-and-tutorials/notecard-guides/understanding-environment-variables.md#reserved-environment-variables). - [Enabling Remote Logging](#enabling-remote-logging) - [Using a Diagnostic Logging Window](#using-a-diagnostic-logging-window) - [Viewing \_log.qo Events](#viewing-log-qo-events) - [Setting Environment Variables in Notehub](#setting-environment-variables-in-notehub) - [Reserved Environment Variables for Troubleshooting](#reserved-environment-variables-for-troubleshooting) #### Enabling Remote Logging Set the `_log` environment variable in Notehub (at the device, fleet, or project level) to one of the following values: | Value | Description | | -------- | ------------------------------------------------- | | `gps` | GPS/GNSS-related diagnostic messages | | `gpsmax` | Verbose GPS diagnostics including NMEA data | | `modem` | Cellular modem connection and registration events | | `power` | Power management events | | `all` | All diagnostic categories combined | To enable logging, go to your device (or fleet) in Notehub, open the **Environment** tab, and add the `_log` variable with your desired value. The change takes effect after the next sync. > **Warning:** > > Remote logging increases cellular data usage. Enable it only when actively troubleshooting, and **delete the `_log` environment variable when done** to revert to normal operation. #### Using a Diagnostic Logging Window For intensive remote debugging sessions, combine `_log` with other [reserved environment variables](https://dev.blues.io/guides-and-tutorials/notecard-guides/understanding-environment-variables.md#reserved-environment-variables) to create a temporary high-frequency logging window: | Environment Variable | Example Value | Purpose | | -------------------- | ------------- | ----------------------------------- | | `_log` | `all` | Comprehensive diagnostic data | | `_sync_continuous` | `1` | Switch to continuous sync mode | | `_session_mins` | `5` | Create new sessions every 5 minutes | > **Warning:** > > This combination provides comprehensive logging data in 5-minute chunks with continuous connectivity. **When done, delete all three variables** to revert the device to its normal configuration. #### Viewing \_log.qo Events In Notehub, filter events by the `_log.qo` Notefile. Each event body contains a `text` field with the diagnostic message. > **Note:** > > Events from `_log.qo` are [Platform Events](https://dev.blues.io/api-reference/system-notefiles.md#log-qo) and do not consume your Notehub event credits. Also note that `_log.qo` Notes are only generated when a new Notehub session begins. If your device is in `continuous` mode, you may need to set `_session_mins` to define a session length and generate periodic log uploads. #### Setting Environment Variables in Notehub [Environment variables](https://dev.blues.io/guides-and-tutorials/notecard-guides/understanding-environment-variables.md) are your primary mechanism for remotely changing device behavior through Notehub without deploying new firmware. You can set environment variables at three levels in Notehub: - **Project level:** Applies to all devices in the project. - **Fleet level:** Applies to all devices in a specific fleet. - **Device level:** Applies only to a single device (overrides project and fleet values). Changes propagate to the device on its next sync with Notehub. > **Action:** > > Review this blog post on [Remotely Manage Notecards with Reserved Environment Variables](https://dev.blues.io/blog/remotely-manage-notecards-reserved-environment-variables.md) for more information on which environment variables to use. #### Reserved Environment Variables for Troubleshooting The Notecard recognizes several [reserved environment variables](https://dev.blues.io/guides-and-tutorials/notecard-guides/understanding-environment-variables.md#reserved-environment-variables) that directly control its behavior. These are powerful remote troubleshooting tools: | Variable | Purpose | | ---------------------------- | ----------------------------------------------------------------------------------------- | | `_log` | Enable diagnostic logging to `_log.qo` (values: `gps`, `gpsmax`, `modem`, `power`, `all`) | | `_sync_continuous` | Set to `1` to switch device to continuous sync mode | | `_session_mins` | Override session duration in minutes | | `_restart` | Trigger a controlled Notecard restart (set to current UNIX epoch time) | | `_restart_host` | Trigger a controlled restart of the connected host MCU | | `_restart_no_activity_hours` | Auto-restart if no sync occurs within the specified hours | > **Warning:** > > Reserved environment variables directly modify device behavior. Always delete temporary troubleshooting variables (like `_log`, `_sync_continuous`, `_session_mins`) when done to avoid unnecessary data usage and battery drain. ## Getting Additional Help If you are unable to resolve an issue using this guide, Blues can always help! To expedite the troubleshooting process, gather the following information before reaching out. 1. **DeviceUID and Notecard firmware version:** Available from `card.version` or from the device page in Notehub. 2. **Notecard SKU:** The hardware model (e.g., NOTE-NBGL, NOTE-WBNA). 3. **Country where the device is located:** Cellular coverage varies by region and Notecard SKU. 4. **Whether the device uses an external SIM:** If so, include the carrier name and APN. 5. **Recent session data:** Export or screenshot the last several `_session.qo` events showing signal quality, voltage, and modem data cycles. 6. **Health events:** Any `_health.qo` events from the period when the issue started. 7. **Remote diagnostic logs:** If you enabled `_log`, include the relevant `_log.qo` events. 8. **Description of the issue:** When it started, whether it is intermittent or persistent, and whether a device reset affects it. 9. **Host MCU details:** The host MCU platform, communication interface (UART, I2C, USB), and a description of the host application behavior. ### Support Channels - **[Notehub Status](https://status.notehub.io)** Check the current operational status of Notehub services. If multiple devices across different projects are experiencing connectivity issues simultaneously, check here first. - **[Blues Community Forum](https://discuss.blues.com)** Community Q\&A for the entire Blues ecosystem of products and services. The Blues team and community members actively monitor the forum. - **[Blues Paid Support](https://blues.com/pricing/)** Personalized support from Blues offered via phone, email, a dedicated Slack channel, and portal.