Skip to main content

NX40 BLE Application Guide

This page explains common BLE application patterns for NX40 Series devices.

It focuses on application behavior such as advertising, connection-based communication, GATT services, and gateway-based data flow.

note

This page does not cover hardware bring-up, antenna layout, or low-power tuning. Use the related pages at the end for those topics.


BLE Application Models

NX40 BLE applications usually follow one of these models.

ModelDescriptionExample
Advertising onlyDevice broadcasts small data without a full connectionBeacon, simple sensor broadcast
Connection-basedDevice connects to a phone, gateway, or controllerWearable, smart sensor, configuration device
GATT serviceDevice exposes structured data as services and characteristicsBattery, sensor value, device status
Gateway-basedBLE device sends data locally to a gateway, and the gateway forwards it onwardIndustrial monitoring, smart building, asset tracking

Advertising Application

Advertising is useful when the device only needs to broadcast small data or be discovered by another device.

Typical advertising use cases:

Use CaseDescription
BeaconBroadcasts ID, presence, or location-related data
Sensor broadcastSends compact sensor data periodically
Device discoveryAllows a phone or gateway to find the device
Status broadcastSends simple state without connection
Event notificationBroadcasts an event when something changes

Advertising design questions:

QuestionWhy It Matters
What data should be broadcast?Advertising payload is limited
How often should the device advertise?Affects discovery speed and power
Should the device be connectable?Some devices advertise only, others accept connections
Is privacy required?Address type and payload design may matter
Is data encrypted elsewhere?Advertising data may be visible to nearby scanners
tip

Start with simple advertising first. After the device is visible in a BLE scanner, add application data step by step.


Connection-Based Application

A connection-based application is useful when a central device needs to read, write, configure, or control the NX40 device.

Common central devices:

Central DeviceExample
SmartphoneMobile app configuration or monitoring
GatewayData collection and local network bridge
PC toolDevelopment, test, or production setup
ControllerLocal control system

Typical connected actions:

ActionExample
Read dataSensor value, battery level, device status
Write configurationMeasurement interval, device mode, threshold
Receive notificationSensor event, alarm, state change
Control deviceStart/stop, output control, mode change
Firmware-related workflowProject-specific update or maintenance behavior

GATT Service Design

GATT organizes BLE data into services and characteristics.

GATT ItemMeaning
ServiceA group of related functions
CharacteristicA data point or control item
ReadCentral device reads a value
WriteCentral device updates a value
NotifyPeripheral sends value changes to central device
IndicatePeripheral sends value changes with confirmation

Example structure:

ServiceCharacteristicOperation
Device Information ServiceFirmware versionRead
Battery ServiceBattery levelRead / Notify
Sensor ServiceSensor valueRead / Notify
Configuration ServiceMeasurement intervalRead / Write
Control ServiceDevice modeRead / Write
tip

Keep the first GATT design simple. Start with only the characteristics required for the first working application.


Sensor Data Flow

A common NX40 BLE application sends sensor data to a phone or gateway.

StepDescription
1Wake up by timer or event
2Read sensor data
3Format the value for advertising or GATT
4Advertise, notify, or wait for read request
5Return to low-power state

Design questions:

QuestionWhy It Matters
How often does data change?Affects advertising or notification interval
Does the central need real-time updates?Determines connection behavior
Is historical data required?May require storage
Does the data need calibration?Affects firmware processing
Is power critical?May require longer intervals and sensor sleep

Gateway-Based BLE Flow

In many IoT systems, the BLE device does not connect directly to the cloud. Instead, it sends data to a local gateway.

StepDescription
1NX40 reads sensor or device data
2NX40 advertises or connects to a gateway
3Gateway receives BLE data
4Gateway forwards data to a local server or cloud
5Application displays or processes the data

This approach is useful for building monitoring, industrial monitoring, asset tracking, and systems with many local BLE devices.


Application Bring-up Checklist

StepCheck
1Confirm basic firmware runs
2Verify BLE advertising is visible
3Define advertising payload or GATT structure
4Test connection from phone, PC, or gateway
5Test read/write/notify behavior
6Add sensor or application data
7Validate behavior over time
8Optimize power using the Low Power Guide

Common BLE Application Issues

SymptomPossible CauseCheck
Device not visibleAdvertising not enabled or RF issueCheck firmware and antenna design
Cannot connectDevice not connectable or connection settings mismatchCheck advertising mode and BLE settings
Data not updatingNotification not enabled or application state not refreshedCheck characteristic behavior
Phone sees old dataAdvertising payload not updatedCheck application update logic
Gateway misses dataAdvertising interval too long or scan window too shortCheck both device and gateway settings
Battery drains quicklyBLE timing too aggressiveReview Low Power Guide
Connection dropsRF, interval, or central-side issueCheck antenna, RSSI, and connection parameters

What Not to Include Here

TopicGo To
First board bring-upNX40 Quick Start
Power and debug hardwareNX40 Hardware Design
Antenna layoutNX40 Antenna Design
Sleep and current optimizationNX40 Low Power Guide
802.15.4 / Thread applicationNX40 802.15.4 / Thread Guide