NORA-W36 u-connectXpress

Stand-alone multiradio modules

User guide

This document provides an overview of the u-connectXpress software for u-blox short range modules

and describes how the products can be configured for Wi-Fi and Bluetooth Low Energy use cases.

⚡ Quick Navigation Guide for First-Time Users:

• Getting Started Fast → Quick Start Guide (quick setup)
• Wi-Fi Connection → Wi-Fi station WPA2/WPA3 (most common)
• Bluetooth Setup → Bluetooth GATT client (simple pairing)
• Data Transfer → Send and receive data (modes explained)
• Troubleshooting → Error codes (when things go wrong)
• AT Commands Index → Appendix A (command lookup)

Document information

This document applies to the following products

Disclaimer

u-blox or third parties may hold intellectual property rights in the products, names, logos, and designs included in this document. Copying, reproduction, or modification of this document or any part thereof is only permitted with the express written permission of u-blox. Disclosure to third parties is permitted for clearly public documents only.

The information contained herein is provided "as is" and u-blox assumes no liability for its use. No warranty, either express or implied, is given, including but not limited to, with respect to the accuracy, correctness, reliability, and fitness for a particular purpose of the information. This document may be revised by u-blox at any time without notice. For the most recent documents, visit www.u-blox.com.

Copyright © u-blox AG

1. Overview

This document describes how to set up and use u-blox short range stand-alone modules with u-connectXpress software for NORA-W36. It explains the functionality of different u-blox short range stand-alone modules and includes examples that describe how to use the software in different environments with AT commands. The document is applicable for Bluetooth® Low Energy (LE), multiradio, and Wi-Fi modules.

Several u-blox short range stand-alone modules support open software variants. For more information about the available options, see the corresponding system integration manuals for u-blox short range stand-alone modules.

For older generation modules like ODIN-W2, NINA-W15 and ANNA-B1, u-connectXpress user guide describe the functionality of these modules.

1.1. Getting started with s-center 2

Downloading and installing

1. Download the latest version of s-center 2
2. Double click the downloaded file and follow the installation instructions
3. Launch s-center 2 when the installation is completed

1.2. Product description

u-blox modules are developed for integration into a vast range of devices that demand a high level of reliability, such as those that are typically used in industrial and medical applications.

These professional grade modules operate over an extended temperature range and are approved for radio type application products in many countries. By choosing to use u-blox short range stand-alone modules, the cost and work involved in developing wireless communication solutions is significantly reduced.

1.3. Multiradio and Wi-Fi modules

u-blox compact and powerful stand-alone, multiradio modules are designed for the development of Internet-of-Things (IoT) applications. NORA-W36 modules include an embedded Bluetooth stack, Wi-Fi driver, IP stack, and an application for wireless data transfer. The wireless support includes Bluetooth v5.3 (Low Energy) and dual-band Wi-Fi (2.4 and 5 GHz bands).

The modules support point-to-point and point-to-multipoint configurations and can accommodate concurrent Bluetooth and Wi-Fi connections. The software provides support for micro Access Point.

They are delivered with u-connectXpress software that provides support for u-blox Bluetooth LE Serial Port Service, Generic Attribute Profile (GATT) client and server, Bluetooth beacons, simultaneous Peripheral and Central roles - all configurable from a host by means of AT commands.

2. Quick Start Guide

2.1. Initial setup checklist

Before starting with NORA-W36 configuration, ensure the following setup is complete:

2.1.1. Hardware setup

Essential Hardware Connections:

• ☐ Power Supply (3.3V) - Connect regulated 3.3V power to VCC pin
• ☐ Ground Connection - Connect GND pin to your system's ground reference
• ☐ UART Interface - Connect TX/RX pins between NORA-W36 and host system

Recommended:

• ☐ Reset Circuit - Wire reset pin for hardware reset capability
• ☐ Bootloader Recovery Switches - Install SW1 and SW2 for easy factory reset and bootloader access (see NORA-W36 SIM for details)

2.1.2. Software setup

• ☐ s-center 2 Installation: Download and install s-center 2
• ☐ Serial Connection: Configure correct COM port and baud rate (115200 default)
• ☐ AT Command Testing: Verify communication with basic AT command

UART configuration defaults

Current NORA-W36 UART Settings:

• Baud Rate: 115200 bps
• Data Bits: 8
• Start Bits: 1
• Stop Bits: 1
• Parity: None (8N1 format)
• Hardware Flow Control: Disabled by default (only TX/RX/GND required)

📌 Connection Requirements:

• Minimum: TX, RX, and GND pins only
• Recommended for higher baud rates: CTS/RTS pins for hardware flow control

2.1.3. Initial verification commands

2.2. First connection examples

2.2.1. Quick Wi-Fi connection

📶 Wi-Fi Connection Flow:

    ┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
    │ 📋 Configure    │───▶│ 🔒 Authenticate │───▶│ ✅ Connected    │
    │    Network      │    │    & Secure     │    │    & Online     │
    └─────────────────┘    └─────────────────┘    └─────────────────┘
             │                       │                       │
         SSID/PWD                UWSC=0                  Link Up
    🔧 AT Commands:            🔒 Security:            ✅ Status Events:
    • AT+UWSCP (SSID)         • WPA2/WPA3             • +UEWLU (Link)
    • AT+UWSSW (Password)     • Auto-negotiate        • +UEWSNU (Network)
    • AT+UWSC=0 (Connect)     • 2048-bit keys         • Ready for data!

Basic WPA2/WPA3 Station Connection:

Full Network Configuration Response:

AT+UWSNST?
+UWSNST:0,192.168.1.59             // IPv4 address
+UWSNST:1,255.255.255.0            // Subnet mask
+UWSNST:2,192.168.1.1              // Gateway
+UWSNST:3,192.168.1.1              // Primary DNS
+UWSNST:4,0.0.0.0        // Secondary DNS
+UWSNST:5,[fe80::56f8:2aff:fe10:aad4]        // IPv6 address
OK

💡 Quick Check: For basic connectivity verification, you can query just the IP address:

AT+UWSNST=0
+UWSNST:0,192.168.1.59             // IPv4 address sufficient for most use cases
OK

2.2.2. Quick Bluetooth advertising

📱 Bluetooth LE Advertisement Flow:

    ┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
    │ 🔧 Configure    │───▶│ 📡 Advertise    │───▶│ 📲 Discoverable │
    │   Parameters    │    │   & Beacon      │    │   by Devices    │
    └─────────────────┘    └─────────────────┘    └─────────────────┘
             │                       │                       │
        Set Interval           Start Broadcast          Device Scan
    ⚙️ Configuration:          📡 Broadcasting:         📱 Detection:
    • Interval: 100ms         • Device name            • "NORA-W36"
    • Legacy mode             • BLE 5.3 compliant     • RSSI signal
    • Auto-connectable        • Low power mode        • Available services

Basic BLE Advertising Setup:

Expected Result: Module appears as "NORA-W36" in Bluetooth device scans

2.2.3. Quick TCP connection test

TCP Socket Communication Flow:

    ┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
    │ 🔌 Create       │───▶│ 🔗 Connect      │───▶│ 📤 Send/Receive │
    │    Socket       │    │   to Server     │    │      Data       │
    └─────────────────┘    └─────────────────┘    └─────────────────┘
             │                       │                       │
        USOCR=6              httpbin.org:80              HTTP GET
    🔧 Socket Setup:          🔗 TCP Connection:         📊 Data Exchange:
    • IPv4 TCP socket         • Remote server            • HTTP protocol
    • System allocated        • Port 80 (HTTP)          • Request/Response
    • Ready for connection    • Bidirectional           • Text-based data

After Wi-Fi connection, test TCP socket:

Expected Result: HTTP response from httpbin.org server

2.3. Common quick start issues

2.3.1. Communication problems

🔧 Hardware & Communication Troubleshooting:

2.3.2. Wi-Fi connection issues

📶 Wi-Fi Network Troubleshooting:

Quick Debug Commands:

2.4. Next steps

After successful quick start:

1. Explore specific use cases → Wi-Fi use cases or Bluetooth use cases
2. Learn about security → WPA2/WPA3 configuration
3. Understand data modes → Send and receive data
4. Advanced features → TLS configuration, MQTT

3. Key features

The possibility of replacing serial cables with simple wireless connections is a key feature of u-blox modules. It allows system hosts to transfer data to one another over wireless Bluetooth connections that are established between u-blox modules in Central/Peripheral configuration.

Depending on the module capabilities, data from each host is transferred to local u-blox modules over a serial UART interface.

u-blox modules can be configured to automatically establish new connections and/or accept incoming connections using AT commands. For connected hosts, this means that physical serial cables can be replaced with more convenient wireless solutions.

3.1. Bluetooth GATT connection

NORA-W36 can function as either a Central or Peripheral unit, connecting to devices such as laptops, cellular phones, and tablets using the Generic Attribute Profile (GATT).

3.2. Bluetooth SPS connection

NORA-W36 can function as either a Central or Peripheral unit, connecting to devices such as laptops, cellular phones, and tablets via the u-blox Serial Port Service (SPS).

3.3. Wi-Fi station connection

NORA-W36 can operate as a Station connecting to an Access Point.

3.4. Wi-Fi access point connection

NORA-W36 can operate as an Access Point connecting to other devices that operate as Stations.

4. u-connectXpress software

4.1. Operating modes

NORA-W36 operates in the following modes:

• AT mode (default): AT commands and data can be sent at the same time. Data is sent and received in AT commands and events - in string or binary mode
• Transparent Mode (TM): All data sent and received on the UART is connected to the remote device
• Transparent Mode Persistent (TMP): Same as TM, but the connection is established at startup or when the connection is dropped

Additionally, the module supports various low-power modes, which optimize power consumption regardless of the operating mode. See also Low power modes and Power consumption optimization.

Deep sleep is supported with the command AT+UPMDS, see AT command manual and Data sheet for more information.

4.2. Changing operating modes

u-blox modules can be configured to start in any operating mode. Once up and running, the modules can be switched between most modes. The modes are changed with a command or escape sequence sent to the module:

• Switch from Command mode to Transparent mode using an AT command
• Switch from Transparent mode to command mode with an escape sequence.

The module is controlled using AT commands in (default) Command mode. In this mode, the host sends control and configuration commands and indicates when data is to be sent over the UART interface.

4.3 NORA-W36 capabilities

More information about the AT commands used in this use cases can be found in the NORA-W36 AT command manual.

5. AT Command Programming

This chapter covers the fundamental concepts of AT command programming with NORA-W36, including command response handling, event management, and timing considerations that are essential before diving into specific protocol implementations.

This chapter covers the fundamental concepts of event-driven programming with NORA-W36, including AT command response handling, Unsolicited Result Code (URC) event management, and data flow fundamentals that are essential before diving into specific protocol implementations.

5.1. Event-driven programming fundamentals

5.1.1. Understanding the event model

NORA-W36 operates on an event-driven architecture where the module continuously monitors for various conditions and notifies the host application through events. This approach enables efficient, asynchronous programming patterns.

Key Concepts:

• Events are asynchronous - They can occur at any time regardless of when commands are sent
• Events require handling - Your application must be prepared to process events when they arrive
• Events provide real-time status - They inform about connection status, data availability, errors, and more

5.1.2. Event types overview

NORA-W36 generates several categories of events:

5.2. AT command response handling

5.2.1. Command response types

Every AT command generates predictable response patterns that your application must handle:

5.2.1.1. Synchronous responses (immediate)

// Command sent:
AT+UWSNST?
// Immediate response:
+UWSNST:0,192.168.1.59             // IPv4 address
+UWSNST:1,255.255.255.0            // Subnet mask
+UWSNST:2,192.168.1.1              // Gateway
+UWSNST:3,192.168.1.1              // Primary DNS
+UWSNST:4,0.0.0.0        // Secondary DNS
+UWSNST:5,[fe80:0000:0000:0000:56f8:2aff:fe10:aad4]    // IPv6 address
OK

5.2.1.2. Asynchronous responses (delayed)

// Command sent:
AT+UWSC=0
// Immediate acknowledgment:
OK
// Later event (when connection completes):
+UEWLU:0
+UEWSNU

5.3. Response parsing best practices

5.3.1. Command response validation

5.3.1.1. Always check for ok/error

AT+UBTM=1
OK               // Success - command accepted
// vs
AT+UBTM=1
ERROR            // Failure - command rejected

5.3.1.2. Parse multi-line responses

AT+UBTBDL
+UBTBDL:AAAAAAAAAAAAp              // Bonded device 1 (BD address)
+UBTBDL:BBBBBBBBBBBBp              // Bonded device 2 (BD address)
+UBTBDL:CCCCCCCCCCCCp              // Bonded device 3 (BD address)
OK               // Final confirmation

5.3.1.3. Handle parameter responses

AT+UWSNST?
+UWSNST:0,192.168.1.59             // IPv4 address
+UWSNST:1,255.255.255.0            // Subnet mask
+UWSNST:2,192.168.1.1              // Gateway
+UWSNST:3,192.168.1.1              // Primary DNS
+UWSNST:4,0.0.0.0        // Secondary DNS
+UWSNST:5,[fe80:0000:0000:0000:56f8:2aff:fe10:aad4]    // IPv6 address
OK

5.4. Command timing considerations

Response Timeouts by Command Type:

5.5. Unsolicited result code (URC) event management

5.5.1. Understanding urcs

Unsolicited Result Codes (URCs) are events generated by NORA-W36 without being prompted by a command. They provide real-time information about module status, incoming data, and connectivity changes.

URC Characteristics:

• Unprompted - Arrive without commands being sent
• Time-critical - Often require immediate handling
• Context-dependent - May require maintaining state information
• Protocol-specific - Different protocols generate different URCs

5.5.2. Critical URC categories

5.5.2.1. Connectivity urcs

+UEBTC:0,AAAAAAAAAAAAp             // Bluetooth connected
+UEBTDC:0        // Bluetooth disconnected
+UESOC:0         // Socket connected
+UESOCL:0        // Socket closed
+UEWLU:0         // Wi-Fi link up
+UEWLD:0,4       // Wi-Fi link down (reason code)

5.5.2.2. Data availability urcs

+UESODA:0,128            // 128 bytes available on socket 0
+UESODS:0,"Hello World"            // Direct string data on socket 0
+UESPSDS:0,"SPS Data"              // SPS string data received
+UEMQDA:0        // MQTT data available

5.5.2.3. Status change urcs

+STARTUP         // Module started/restarted
+UEWSNU          // Wi-Fi station network up
+UEWSND          // Wi-Fi station network down
+UEMQC:0         // MQTT connected
+UEMQDC:0        // MQTT disconnected

5.5.3. URC handling strategies

5.5.3.1. Strategy 1: event-driven state machine

// Maintain connection state
connection_state = "DISCONNECTED"
// Handle connection events
if URC == "+UEBTC:0,*":
- connection_state = "BT_CONNECTED"
- start_data_monitoring()
if URC == "+UEBTDC:0":
- connection_state = "DISCONNECTED"
- stop_data_monitoring()

5.5.3.2. Strategy 2: data-driven processing

// Handle data events immediately
if URC == "+UESODS:0,*":
- data = extract_data_from_urc()
- process_incoming_data(data)
if URC == "+UESODA:0,*":
- bytes_available = extract_count_from_urc()
- read_buffered_data(bytes_available)

5.5.3.3. Strategy 3: error recovery

// Handle error conditions
if URC == "+UESOCL:0":
- log_error("Socket closed unexpectedly")
- attempt_reconnection()
if URC == "+UEWLD:0,4":
- log_error("Wi-Fi disconnected - reason 4")
- retry_wifi_connection()

6. Data Handling and Processing

This chapter covers advanced data handling concepts, event processing patterns, and practical implementation strategies for building robust NORA-W36 applications.

6.1. Data flow fundamentals

6.1.1. Data mode overview

NORA-W36 supports multiple data handling modes, each optimized for different use cases:

6.1.2. Event-data relationship

Understanding Data Event Flow:

1. Data Arrives at module
2. Module Processes according to current mode
3. Event Generated to notify host
4. Host Application handles event appropriately

6.1.2.1. Buffered mode flow

// Data arrives → stored in buffer
// Event generated:
+UESODA:0,256            // 256 bytes available on socket 0
// Host reads data:
AT+USORS=0,256
+USORS:0,256,"actual data content here..."
OK

6.1.2.2. Direct mode flow

// Data arrives → immediately delivered
+UESODS:0,"immediate data"         // String data delivered directly
// No additional read command needed

6.2. Protocol-specific event patterns

6.2.1. Event categories

6.2.1.1. Wi-Fi socket events

// Connection sequence:
+UESOC:0         // Socket connected
+UESODA:0,128            // Data available (buffered mode)
+UESODS:0,"data"         // Data delivered (direct mode)
+UESOCL:0        // Socket closed

6.2.1.2. Bluetooth SPS events

// SPS connection sequence:
+UESPSC:0        // SPS connected
+UESPSDS:0,"Hello"       // String data received
+UESPSDA:0,64            // Binary data available
+UESPSDC:0       // SPS disconnected

6.2.1.3. MQTT events

// MQTT lifecycle:
+UEMQC:0         // MQTT connected
+UEMQDA:0        // Data available
+UEMQPC:0,123,45         // Publish completed
+UEMQDC:0        // MQTT disconnected

6.3. Event processing best practices

6.3.1. Event handler design patterns

6.3.1.1. Pattern 1: central event dispatcher

function handle_event(event_string):
- if event_string.startswith("+UEBTC"):
- handle_bluetooth_connected(event_string)
- elif event_string.startswith("+UESODS"):
- handle_socket_data(event_string)
- elif event_string.startswith("+STARTUP"):
- handle_module_startup()

6.3.1.2. Pattern 2: state-based processing

function process_event(event, current_state):
- switch current_state:
- case CONNECTING:
- if event == "+UESOC:0":
- transition_to_state(CONNECTED)
- case CONNECTED:
- if event.startswith("+UESODA"):
- handle_data_available(event)

6.3.2. Error handling strategies

6.3.2.1. Robust event processing

function safe_event_handler(event):
- try:
- process_event(event)
- except ParseError:
- log_error("Failed to parse event: " + event)
// Continue processing other events
    except ConnectionError:
- log_error("Connection lost during event processing")
- initiate_reconnection()

6.3.2.2. Event queue management

// Buffer events during critical operations
event_queue = []
critical_operation_active = False
function queue_or_process_event(event):
- if critical_operation_active:
- event_queue.append(event)
- else:
- process_event_immediately(event)

6.4. Performance considerations

Event Processing Guidelines:

• Keep handlers fast - Long processing can cause event loss
• Use buffering for high-frequency events
• Prioritize critical events (connection status over data)
• Batch process multiple data events when possible

Memory Management:

• Limit event queue size to prevent memory exhaustion
• Clean up resources when connections close
• Monitor buffer usage in high-throughput scenarios

6.5. Practical implementation examples

6.5.1. Basic event loop

// Simple event monitoring loop
while True:
    line = read_from_uart()
    if line.startswith("+"):
// This is an event (URC)
        handle_event(line)
    elif line in ["OK", "ERROR"]:
// This is a command response
        handle_command_response(line)
    elif line.startswith("+STARTUP"):
// Module restarted
        reinitialize_module()

6.6. Connection state management

// Track multiple connection types
connection_states = {
    "wifi": "DISCONNECTED",
    "bluetooth": "DISCONNECTED",
    "mqtt": "DISCONNECTED"
}
// Update states based on events
function update_connection_state(event):
- if "+UEWLU" in event:
- connection_states["wifi"] = "CONNECTED"
- elif "+UEWLD" in event:
- connection_states["wifi"] = "DISCONNECTED"
- elif "+UEBTC" in event:
- connection_states["bluetooth"] = "CONNECTED"
-                // ... etc

6.7. Data collection pattern

// Collect data from multiple sources
data_sources = {
    "socket_0": [],
    "sps_0": [],
    "mqtt": []
}
function handle_data_event(event):
- if "+UESODS:0" in event:
- data = extract_data(event)
- data_sources["socket_0"].append(data)
- elif "+UESPSDS:0" in event:
- data = extract_data(event)
- data_sources["sps_0"].append(data)

6.8. Troubleshooting event handling

6.8.1. Common issues

6.8.2. Debugging event flow

Enable Debug Logging:

// Log all events for analysis
function debug_log_event(event):
- timestamp = get_current_time()
- log_file.write(f"{timestamp}: {event}")

Verify Event Sources:

// Check which events are actually being generated
AT+UBTM?         // Check Bluetooth mode
AT+UWSNST?       // Check Wi-Fi status
AT+USOST=0       // Check socket status

This foundation in event-driven programming and data handling prepares you for implementing specific protocol use cases covered in subsequent chapters. Understanding these fundamentals is crucial for building robust IoT applications with NORA-W36.

7. Bluetooth use cases

The following Bluetooth Low Energy use case, show some functionality to get started with GATT client, GATT server and SPS.

The following examples use the MAC address below, this must be replaced by the real MAC address of the devices that are used.

• Peripheral MAC address: AAAAAAAAAAAA
• Central MAC address: BBBBBBBBBBB

7.1. Bluetooth GATT client

This use case configures NORA-W36 as a Central device that operates as a GATT client and receives data.

This use case configuration is used in combination with Bluetooth GATT server.

7.2. Bluetooth GATT server

This use case configures NORA-W36 as a Peripheral device that operates as GATT server and sends notifications.

This configuration works in combination with Bluetooth GATT client.

7.3. Bluetooth SPS central

This use case configures NORA-W36 as a Central device that sends and receives data from another NORA-W36 module operating as a Peripheral device. The communication between the two modules is facilitated using the proprietary u-blox Serial Port Service. It is also possible to connect to other devices that supports the SPS protocol.

This use case operates in combination with Bluetooth SPS peripheral.

7.4. Bluetooth SPS peripheral

This use case configures NORA-W36 module as a Peripheral device that sends and receives data from another NORA-W36 module operating as a Central device. The communication between the two modules is facilitated using the proprietary u-blox Serial Port Service. It is also possible to connect to other devices that support the SPS protocol.

This use case configuration is used in combination with Bluetooth SPS central.

7.5. Bluetooth advertise

This use case configures NORA-W36 as a peripheral device that operates as a GATT client and receives data.

This use case configuration is used in combination with Apple iPhone using the Apple Notification Center Service (ANCS).

7.6. Bluetooth security

Pairing

• Pairing is the initial process where two Bluetooth devices exchange information necessary to establish an encrypted connection
• During pairing, devices negotiate security parameters, such as encryption keys and authentication methods
• It ensures that communication between devices remains confidential and secure

Think of pairing as the handshake that sets the foundation for a secure link

Bonding

• Bonding occurs after successful pairing
• It involves storing the information from the pairing process on both devices
• Once bonded, devices remember each other's security credentials (keys) for future reconnections
• Bonding eliminates the need to repeat the pairing process every time the devices reconnect
• Essentially, bonding creates a permanent security relationship between the devices

In summary

• Pairing: Establishes the initial secure connection
• Bonding: Ensures that the devices remember each other's security details for subsequent interactions
• Remember, these processes are essential for maintaining the confidentiality and integrity of data exchanged over Bluetooth connections

7.7. Bluetooth security initiator

Bluetooth Security is disabled by default and must be configured and enabled before use.

7.8. Bluetooth security responder

Bluetooth Security is disabled by default and must be configured and enabled before use.

8. Wi-Fi Connection Use Cases

The following Wi-Fi use cases show basic connectivity functionality to get started with Wi-Fi Station and Access Point connections.

The following examples use the MAC address below, this must be replaced by the real MAC address of the devices that are used.

• Station MAC address: AAAAAAAAAAAA
• Access Point MAC address: BBBBBBBBBBB

8.1. Wi-Fi station WPA2 and WPA3

Connect as a Wi-Fi station to an Access Point to get access to network.

This use case connects NORA-W36 as a Wi-Fi station to an Access Point for access to the network. The connection is set to DHCP client by default.

To use static IP the AT+UWSIPS set the IP address, gateway, subnet mask and DNS.

8.1.1. WPA2/WPA3 security overview

The NORA-W36 module supports both WPA2 Personal and WPA3 Personal security protocols when operating as a Wi-Fi station, providing enhanced wireless network protection:

WPA3 Security Enhancements (Station Mode Only):

• SAE (Simultaneous Authentication of Equals): Stronger password-based authentication
• Forward Secrecy: Previous session keys remain secure even if password is compromised
• Enhanced Protection: Resistant to offline dictionary attacks
• Improved Handshake: More robust authentication process

Note: WPA3 support is available for station mode only. When operating as an Access Point, NORA-W36 supports WPA2 Personal only.

8.1.2. Station connection configuration

8.1.3. Wpa security parameter details

AT+UWSSW Command Format:

AT+UWSSW=<interface_id>,<password>,<wpa_threshold>

Parameters:

• interface_id: Wi-Fi interface (0 = station)
• password: WPA/WPA2/WPA3 password (8-63 characters)
• wpa_threshold: Security level selection
• 0: Accept WPA2 or higher (WPA2/WPA3 compatible)
• 1: Require WPA3 only (enhanced security)

Security Recommendations:

• Use wpa_threshold=1 for WPA3-only networks requiring maximum security
• Use wpa_threshold=0 for broader compatibility with WPA2/WPA3 networks
• Ensure password meets complexity requirements (minimum 8 characters)

Important Note: If NORA-W36 should connect to Wi-Fi at startup, the Connect, Store and Reset commands should be sent: AT+UWSC=0, AT&W and AT+CPWROFF. The current Wi-Fi Station state is stored in flash and NORA-W36 will try to connect using the Service Set Identifier (SSID) and password stored at startup.

8.1.4. Wi-Fi station command reference

The following section provides detailed documentation for key Wi-Fi station commands using the standardized format:

AT+uwscp - Wi-Fi station connection parameters

Purpose: Configure SSID for Wi-Fi station connection

Syntax:

AT+UWSCP=<interface_id>,<ssid>

Parameters:

• interface_id: Wi-Fi interface ID (0 = station)
• ssid: Network SSID name (1-32 characters, quoted string)

Examples:

AT+UWSCP=0,"MyNetwork"             // Set SSID to "MyNetwork"
AT+UWSCP=0,"Office_WiFi_5G"        // Set SSID with special characters

Response: OK on success, ERROR on failure

Notes:

• Channel selection is automatic during connection
• Settings can be stored with AT&W followed by AT+CPWROFF to ensure safe flash storage

AT+uwssw - Wi-Fi station security/password

Purpose: Set WPA/WPA2/WPA3 password and security threshold

Syntax:

AT+UWSSW=<interface_id>,<password>,<wpa_threshold>

Parameters:

• interface_id: Wi-Fi interface ID (0 = station)
• password: WPA password (8-63 characters, quoted string)
• wpa_threshold: Security level
• 0: Accept WPA2 or higher (recommended for compatibility)
• 1: Require WPA3 only (enhanced security)

Examples:

AT+UWSSW=0,"MyPassword",0          // WPA2/WPA3 compatible
AT+UWSSW=0,"SecurePass123",1       // WPA3 only

Response: OK on success, ERROR on invalid parameters

AT+uwsc - Wi-Fi station connect

Purpose: Initiate connection to configured Wi-Fi network

Syntax:

AT+UWSC=<interface_id>

Parameters:

• interface_id: Wi-Fi interface ID (0 = station)

Example:

AT+UWSC=0

Response:

• OK - Connection process started
• +UEWLU:0,<mac_address>,<channel> - Wi-Fi link established
• +UEWSNU - Network interface ready

Common Errors:

• ERROR:1 - Invalid parameters
• ERROR:8 - Connection timeout
• ERROR:16 - Authentication failed

AT+uwsdc - Wi-Fi station disconnect

Purpose: Disconnect from current Wi-Fi network

Syntax:

AT+UWSDC[=<interface_id>]

Parameters:

• interface_id: Optional Wi-Fi interface ID (default: 0)

Example:

AT+UWSDC

Response: OK on success

8.1.5. Wi-Fi station troubleshooting

8.1.5.1. Common connection issues

8.1.5.2. Debug commands

8.1.5.3. Step-by-step troubleshooting

1. Test Basic Communication

   AT
   OK

1. Enable Extended Errors

   AT+USYEE=1
   OK

1. Check Current Configuration

   AT+UWSCP=0
   +UWSCP:0,"MyNetwork"

1. Verify Signal Strength

   AT+UWSST=4
   +UWSST:4,-45          // Good signal (-30 to -50 dBm)

1. Test Connection

   AT+UWSC=0
   OK
   // Wait for events...

1. If Connection Fails, Check Error

   AT+USYEC?
   +USYEC:16     // Error code 16 = Authentication failed

8.2. Wi-Fi PEAP enterprise security

Connect as a Wi-Fi station to an Access Point using PEAP (Protected Extensible Authentication Protocol) and a RADIUS server to get access to network.

This use case connects NORA-W36 as a Wi-Fi station to an Access Point for access to the network. The connection is set to DHCP client by default.

<!---

--->

Important Note: If NORA-W36 should connect to Wi-Fi at startup the Connect, Store and Reset should be sent, AT+UWSC=0, AT&W and AT+CPWROFF, the current Wi-Fi Station state is stored in flash and NORA-W36 will try to connect using Service Set Identifier (SSID) and password stored at startup.

8.3. Wi-Fi EAP-TLS enterprise security

Connect as a Wi-Fi station to an Access Point using Extensible Authentication Protocol (EAP) and EAP Transport Layer Security (EAP-TLS) to get access to network.

This use case connects NORA-W36 as a Wi-Fi station to an Access Point for access to the network. The connection is set to DHCP client by default.

To use static IP the AT+UWSIPS set the IP address, gateway, subnet mask and DNS.

<!---

--->

Important Note: If NORA-W36 should connect to Wi-Fi at startup the Connect, Store and Reset should be sent, AT+UWSC=0, AT&W and AT+CPWROFF, the current Wi-Fi Station state is stored in flash and NORA-W36 will try to connect using Service Set Identifier (SSID) and password stored at startup.

TLS Version Options for EAP-TLS:

The second parameter in AT+UWSSE specifies the TLS version:

• 0: Disable TLS (not recommended for EAP-TLS)
• 1: TLS 1.2 only
• 2: TLS 1.3 only (recommended for enhanced security)
• 3: TLS 1.2 or 1.3 (negotiate highest available)

Security Recommendation: Use TLS 1.3 (parameter 2) for the strongest security posture, as it provides improved encryption algorithms, forward secrecy, and reduced handshake latency.

8.4. Wi-Fi access point WPA2

This use case configures NORA-W36 to act as a Wi-Fi Access Point that allows Wi-Fi Stations to connect, send, and receive data to the module.

The Wi-Fi connection has WPA2 encryption and a DHCP server that automatically assigns IP addresses to devices when they connect to the network.

The server assigns connected devices with IP addresses from 192.168.1.100 + x, where 'x' represents the additional IP addresses that can be assigned to other devices connected to the network.

Note: If NORA-W36 activates Wi-Fi Access Point at startup, Activate (AT+UWAPA), Store (AT&W) and Reset (AT+CPWROFF) commands should be sent. The current Wi-Fi Access Point state is stored in flash and NORA-W36 then activates the Access Point using the stored SSID and password at startup.

IP address range is 192.168.1.100 + x to connected stations.

8.4.1. Access point security details

Security Limitation: Access Point mode supports WPA2 Personal only. WPA3 is not supported when operating as an Access Point.

AT+UWAPSW Command Format:

AT+UWAPSW=<password>

Parameters:

• password: WPA2 password (8-63 characters)

Security Features:

• WPA2 Personal: Industry-standard security with AES-CCMP encryption
• Password Protection: 8-63 character password requirement
• DHCP Server: Automatic IP address assignment for connected devices

9. Wi-Fi Security Configuration

This chapter provides comprehensive security guidance for NORA-W36 implementation in production environments, covering wireless security, encryption protocols, certificate management, and operational security considerations.

9.1. Wireless security configuration

9.1.1. Wi-Fi security protocol selection

Recommended Security Hierarchy (Best to Acceptable):

9.1.2. Password security standards

WPA/WPA2/WPA3 Password Requirements:

✅ Strong Password Criteria:

• Minimum 12 characters (8 is technical minimum, 12+ recommended)
• Mixed case letters (A-Z, a-z)
• Numbers (0-9)
• Special characters (!@#$%^&*)
• Avoid dictionary words and predictable patterns

Examples:

// Weak passwords (avoid)
AT+UWSSW=0,"password",0            // Dictionary word
AT+UWSSW=0,"12345678",0            // Sequential numbers
AT+UWSSW=0,"CompanyName",0         // Predictable
// Strong passwords (recommended)
AT+UWSSW=0,"Mx7$kL2@Rt9!uP",0      // Random strong password
AT+UWSSW=0,"BlueTree#2024$IoT",0             // Memorable but complex

9.2. Network architecture security

Station Mode Security:

• ✅ Use WPA3 when available (wpa_threshold=1)
• ✅ Verify network authenticity before connecting
• ✅ Monitor signal strength to detect rogue APs
• ✅ Implement connection timeouts to prevent hanging

Access Point Mode Security:

• ✅ Change default SSID from "NORA-W36"
• ✅ Use complex passwords (12+ characters)
• ✅ Limit connected devices (max 5 stations)
• ✅ Monitor connected devices with +UEWAPSA events
• ✅ Regular password rotation in production

9.3. TLS/SSL security implementation

9.3.1. TLS version configuration

TLS Security Layer Architecture:

    ┌─────────────    ┌─────────────    ┌─────────────
    │🛡 TLS 1.3   │ ── │🔒 TLS 1.2   │ ── │⚠ No TLS    │
    │   (Best)    │    │ (Legacy)    │    │  (Never!)   │
    └─────────────┘    └─────────────┘    └─────────────┘
           │                     │                     │
      Max Security         Good Security         No Security
    🔧 TLS 1.3 Benefits:    🔧 TLS 1.2 Support:    ⚠ Security Risk:
- • Forward secrecy      • Legacy compatibility  • Plain text data
- • 0-RTT handshake      • Proven stability      • No encryption
- • Modern encryption    • Wide support          • Vulnerable to attacks

TLS Security Hierarchy:

Implementation Examples:

// Best: TLS 1.3 only (recommended for new projects)
AT+USOTLS=0,2            // Socket TLS 1.3
AT+UMQTLS=0,2            // MQTT TLS 1.3
AT+UHTCTLS=0,2           // HTTP TLS 1.3
// Good: TLS 1.2/1.3 compatible (legacy support)
AT+USOTLS=0,3            // Negotiate highest available

9.4. Certificate management security

Certificate Security Best Practices:

✅ Certificate Validation:

• Always validate server certificates in production
• Use complete certificate chains (CA + intermediate + server)
• Verify certificate expiration dates before deployment
• Test certificate chain validity with openssl

✅ Certificate Storage:

• Limit certificate lifetime (1-2 years maximum)
• Use secure certificate sources (trusted CAs only)
• Monitor certificate expiration (automated renewal)
• Remove unused certificates to free storage

Certificate Upload Security:

// Upload complete certificate chain
AT+USECUB=0,"ca.pem"{binary_ca_cert}         // Root CA
AT+USECUB=1,"intermediate.pem"{binary_int_cert}    // Intermediate CA
AT+USECUB=2,"client.pem"{binary_client_cert}    // Client certificate
AT+USECUB=3,"client.key"{binary_private_key}    // Private key (secure!)

Certificate Validation Commands:

// List all certificates
AT+USECL?
// Verify specific certificate details
AT+USECD="ca.pem"
// Remove expired certificates
AT+USECR=1,"expired_cert.pem"

9.5. TLS extensions security

Recommended TLS Extension Configuration:

// Enable Server Name Indication (SNI) - Required for modern TLS
AT+USETE0=1      // Enable SNI (default: enabled)
// Enable Handshake Fragmentation - Prevents MTU issues
AT+USETE1=1      // Enable fragmentation (default: enabled)
// Store TLS extension settings
AT&W             // Persist configuration
AT+CPWROFF       // Reset to apply stored settings safely

9.6. Application protocol security

9.6.1. MQTT security configuration

Comprehensive MQTT Security Setup:

// Secure connection with TLS 1.3
AT+UMQCP=0,"secure-mqtt-broker.com",8883
AT+UMQTLS=0,2,"ca.pem","client.pem","client.key"
// Strong authentication (set connection parameters with credentials)
AT+UMQCP=0,"mqtt.broker.com",8883,"device_id_12345","device_id_12345","complex_password_67890"
// Connect securely
AT+UMQC=0

MQTT Security Checklist:

• ✅ Always use port 8883 (TLS) instead of 1883 (plain)
• ✅ Implement client certificates for mutual authentication
• ✅ Use unique client IDs to prevent conflicts
• ✅ Avoid predictable topics (use device-specific prefixes)
• ✅ Implement message encryption for sensitive data
• ✅ Monitor connection events for security anomalies

9.7. HTTP/HTTPS security configuration

Secure HTTP Implementation:

// Always use HTTPS (port 443)
AT+UHTCCP=0,"api.secure-service.com",443
AT+UHTCTLS=0,2,"ca.pem"
// Add security headers
AT+UHTCRHAF=0,"Authorization","Bearer secure_token_here"
AT+UHTCRHAF=0,"User-Agent","NORA-W36/3.1.0"
AT+UHTCRHAF=0,"Content-Type","application/json"
// Make secure request
AT+UHTCRG=0,"/api/v1/secure-endpoint"

HTTP Security Checklist:

• ✅ Always use HTTPS (never HTTP for sensitive data)
• ✅ Validate SSL certificates
• ✅ Use proper authentication (tokens, API keys)
• ✅ Implement request timeouts
• ✅ Validate response status codes
• ✅ Sanitize response data

9.8. Operational security practices

9.8.1. Device configuration security

Secure Configuration Management:

// Change default settings
AT+UWAPCP="SecureIoTGateway_001",6           // Unique SSID
AT+UWAPSW="ComplexPassword#2024$"            // Strong password
// Enable extended error reporting (development only)
AT+USYEE=1       // Enable during development
AT+USYEE=0       // Disable in production (security through obscurity)
// Store secure configuration
AT&W             // Save to flash
AT+CPWROFF       // Reset to apply stored settings safely
// Test configuration
AT+UWSNST=0      // Verify network status
AT+UWSSC         // List available networks

9.9. Power management security

Secure Power Save Configuration:

// Balance security and power efficiency
AT+UPMPSL=1      // Enable moderate power save
AT+UPMPSTO=5000          // 5-second timeout (balance responsiveness/power)
AT&W             // Store settings
AT+CPWROFF       // Reset to apply stored settings safely
// Security consideration: Ensure power save doesn't impact security monitoring

9.10. Monitoring and diagnostics

Security Monitoring Commands:

// Regular security health checks
AT+UWSST=4       // Monitor signal strength (detect rogue APs)
AT+UWSNST=0      // Verify network connection status, only IPv4 Address
AT+USECL?        // Check certificate validity
AT+USYEC?        // Check for error conditions
AT+UWSNST?       // Verify network connection status, all parameters

9.11. Security incident response

9.11.1. Connection security issues

Rapid Response Commands:

9.11.2. Security audit checklist

Regular Security Review (Monthly):

• [ ] Password strength audit - verify all passwords meet current standards
• [ ] Certificate expiration check - ensure all certificates valid for next 30 days
• [ ] TLS version compliance - confirm TLS 1.3 usage where possible
• [ ] Access point security - verify WPA3 usage and strong passwords
• [ ] Connection monitoring - review unusual connection patterns
• [ ] Firmware currency - ensure latest security patches applied
• [ ] Configuration backup - secure backup of device configurations

Security Configuration Validation:

// Complete security status check
AT+UWSCP=0       // Verify SSID configuration
AT+UWSS=0        // Check security configuration
AT+USECL?        // List all certificates and expiration
AT+USYEC?        // Check for any error conditions

This comprehensive security framework ensures NORA-W36 deployments maintain the highest security standards while remaining operationally efficient.

10. Wi-Fi Performance Optimization

This chapter provides comprehensive performance optimization guidance for NORA-W36 deployments, covering connection optimization, power efficiency, memory management, and throughput enhancement techniques for maximum system performance.

10.1. Connection performance optimization

10.1.1. Wi-Fi connection speed enhancement

Fast Connection Techniques:

Optimal Connection Sequence:

// Disable power save during connection (faster scanning)
AT+UPMPSL=0
// Scan for target network (get channel info)
AT+UWSSC
// Connect with specific parameters
AT+UWSCP=0,"TargetNetwork"         // Set SSID (channel determined by AP)
// Verify connection quickly
AT+UWSNST=0
// Re-enable power save after connection
AT+UPMPSL=1

10.2. Socket performance tuning

TCP Socket Optimization:

// Enable TCP fast recovery
AT+USORS=0,1000          // Read available data (1kB chunks)
// Use larger receive operations for bulk data
AT+USORS=0,1000          // 1kB chunks for file transfers
// Monitor socket status for optimal timing
AT+USYEE=1       // Enable extended error reporting

UDP Performance Configuration:

// UDP is inherently faster - optimize for your use case
AT+USORS=0,1000          // Standard read operations

10.3. TLS performance enhancement

TLS Handshake Optimization:

TLS Performance Commands:

// Fastest: TLS 1.3 with session resumption
AT+USOTLS=0,2            // TLS 1.3 for new connections
AT+USETE1=1      // Enable handshake fragmentation (faster on slow networks)
AT+USETE0=1      // Enable SNI (required for many servers)
// Pre-load certificates for faster handshake
AT+USECL?        // Verify certificates are already loaded

10.4. Power vs performance trade-offs

10.5. Power save mode optimization

⚡ Power Management Decision Matrix:

    ┌─────────────    ┌─────────────    ┌─────────────
    │🚀 High Perf │ ── │⚖ Balanced  │ ── │🔋 Low Power │
    │ Mode 0      │    │  Mode 1     │    │  Mode 2     │
    └─────────────┘    └─────────────┘    └─────────────┘
           │                     │                     │
      Max Speed            Good Balance          Max Battery
    ⚡ Performance:         ⚖ Balanced:          🔋 Power Saving:
- • No delays            • Smart trade-offs    • Extended battery
- • Instant response     • Good responsiveness • Ideal for IoT
- • High throughput      • Moderate power      • Periodic updates

Power Save Performance Matrix:

Adaptive Power Management:

💡 Timeout Logic: High-performance mode uses longer timeouts to maintain sustained operation without frequent power state changes. IoT sensors use shorter timeouts for quick wake-up and responsiveness to events.

// High performance mode (data streaming)
AT+UPMPSL=0      // Disable power save
AT+UPMPSTO=30000         // Long timeout (30 seconds) for sustained performance
// Balanced mode (regular operations)
AT+UPMPSL=1      // Light power save
AT+UPMPSTO=5000          // 5-second timeout
// Power efficient mode (IoT sensors)
AT+UPMPSL=2      // Moderate power save
AT+UPMPSTO=1000          // Short timeout (1 second) for quick responsiveness
// Save configuration
AT&W
AT+CPWROFF       // Reset to apply stored settings safely

10.6. Dynamic power scaling

Context-Aware Power Management:

// During active data transfer - maximum performance
AT+UPMPSL=0      // Disable power save
// After transfer complete - enable power save
AT+UPMPSL=1      // Light power save for quick response
// During idle periods - deep power save
AT+UPMPSL=2      // Moderate power save
// Example: Automatic switching based on socket activity
// (implement in host application logic)

10.7. Memory management optimization

10.7.1. Efficient memory usage

Memory Allocation Best Practices:

Memory Monitoring Commands:

// Check certificate usage
AT+USECL?        // List certificates and sizes
// Remove unused certificates
AT+USECL?        // List certificates
AT+USECR=0,"old_cert.pem"          // Remove unused certificates
// Remove unused certificates to free storage
AT+USECR=0,"unused.pem"            // Remove unused certificates

10.8. Data handling efficiency

Optimal Data Transfer Guidelines:

// For socket operations, use appropriate read/write sizes
// Socket commands will be covered in Wi-Fi Sockets section
// Focus on connection optimization and certificate management

10.9. Network performance optimization

10.9.1. Wi-Fi signal quality management

Signal Strength Optimization:

Signal Monitoring Commands:

// Check current signal strength
AT+UWSST=4       // Signal strength in dBm
// Monitor connection quality
AT+UWSNST=0      // Network status and quality
// Scan for alternative networks
AT+UWSSC         // Scan and compare signal levels

10.10. Network congestion management

Channel Optimization Strategy:

// Scan all channels to find optimal one
AT+UWSSC
// Example: Choose less congested channel
// If scan shows:
-                // Channel 1: Many APs (congested)
-                // Channel 6: Few APs (better choice)
-                // Channel 11: Few APs (best choice)
// Configure network (channel determined by AP)
AT+UWSCP=0,"MyNetwork"             // Set SSID

10.11. Application-level performance

10.11.1. Protocol selection guidelines

Performance Comparison by Protocol:

10.11.2. Data format optimization

Efficient Data Formats:

// JSON (human readable, moderate efficiency)
{"temp":23.5,"hum":65,"time":1640995200}
// Compact JSON (remove spaces, shorter keys)
{"t":23.5,"h":65,"ts":1640995200}
// Binary format (highest efficiency)
// Custom binary protocol for maximum performance
// bytes: temperature (float)
// bytes: humidity (float)
// bytes: timestamp (uint32)
// Total: 12 bytes vs 45+ bytes JSON

10.12. Real-time performance monitoring

10.12.1. Performance metrics collection

Key Performance Indicators:

// Connection establishment time
// Measure time between AT+UWSC and +UEWLU event
// Data transfer throughput
// Measure bytes/second during AT+USOWS/AT+USORS operations
// Power consumption monitoring
// Use external current meter with different AT+UPMPSL settings
// Certificate usage tracking
AT+USECL?        // Check certificate storage regularly

10.13. Performance benchmarking

Standardized Performance Tests:

Performance Test Sequence:

// Baseline connection test
AT+UWSC=0        // Time this command
// Target: <10 seconds to +UEWLU
// Throughput test
AT+USOCR=6       // Create TCP socket
AT+USOC=0,server,port              // Connect
AT+USOWS=0,"data"        // Write data (up to 1000 bytes per command)
// Measure: bytes/second throughput
// Power consumption test
AT+UPMPSL=1      // Enable power save
// Measure current draw over time
// Certificate storage test
AT+USECL?        // Check certificates before/after operations

10.14. Performance troubleshooting

10.14.1. Common performance issues

10.14.2. Performance optimization checklist

Regular Performance Maintenance:

Optimal Configuration Summary:

// High-performance configuration
AT+UPMPSL=0      // Disable power save during operation
AT+USOTLS=0,2            // Use TLS 1.3 for fastest secure connections
AT+USORS=0,1000          // Optimize for 1000-byte MTU limit
AT+USYEE=1       // Enable extended error reporting
// Power-efficient configuration
AT+UPMPSL=1      // Light power save
AT+UPMPSTO=10000         // 10-second timeout
AT+USORS=0,512           // Smaller read operations for efficiency
AT&W             // Save configuration
AT+CPWROFF       // Reset to apply stored settings safely

This comprehensive performance framework ensures NORA-W36 implementations achieve optimal speed, efficiency, and reliability across all operating conditions.

11. Wi-Fi Sockets use cases

11.1. Wi-Fi TCP client

This use case configures NORA-W36 as a Wi-Fi TCP client device that initiates a TCP connection to a specified server (listener) over a Wi-Fi network. It actively seeks to establish communication by sending a connection request to the server's IP address and port number, which the server is listening on.

The Transmission Control Protocol (TCP) is bidirectional and one socket can both send and receive data:

• ATE0 turns off the AT command echo to speed up the data transmission in AT mode. The written data is not echoed back to the host, which helps to make the parsing easier.
• It is possible to connect using a host name like AT+USOC=0,"www.u-blox.com",80 or an IP address AT+USOC=0,"75.2.60.5",80
• TCP can both send and receive data between the TCP client and server

11.2. Wi-Fi TCP server (listener)

This use case configures NORA-W36 as a Wi-Fi TCP server (listener) that is configured to accept incoming TCP connections over a Wi-Fi network. It "listens" on a specific IP address and port number for connection requests.

11.3. Wi-Fi UDP client

Unlike TCP, the User Datagram Protocol (UDP) is not bi-directional. Both an outgoing and incoming socket, AT+USOCR, are needed to send and receive data over UDP.

It is possible to connect using the host name, like AT+USOC=0,"www.u-blox.com",80, or the IP address AT+USOC=0,"75.2.60.5",80

11.4. Wi-Fi UDP server (listener)

11.5. Wi-Fi TCP using TLS without certificates

TLS Extensions are enabled by default but in some (mostly older) TLS servers they are not supported. See https://www.rfc-editor.org/rfc/rfc6066.html.

The extensions, Server Name, Indication and Maximum Fragment Length Negotiation, are disabled with:

• AT+USETE0=0 Server Name Indication, 0: Disable - 1: Enable (default)
• AT+USETE1=0 Maximum Fragment Length Negotiation, 0: Disable - 1: Enable (default)
• All other Extension are disabled and not supported.
• It is possible to use host name like AT+USOC=0,"www.u-blox.com",80 or using ip address AT+USOC=0,"75.2.60.5",80 for the connections.

TCP is bidirectional and one socket can both send and receive data.

11.6. Wi-Fi TCP using TLS with certificates

TCP is bidirectional and one socket can both send and receive data.

11.7. Create own certificates using OpenSSL

This section provides examples for creating your own certificates using OpenSSL (https://www.openssl.org/).

The examples demonstrate how to use 2048-bit or 4096-bit key lengths for different security requirements.

Prerequisites:

• Use Git Bash (https://git-scm.com/download/win) on Windows
• Or a Linux environment like Ubuntu (https://ubuntu.com/download)
• OpenSSL must be installed and available in PATH

11.7.1. Certificate authority (CA) creation

Step 1: Create the root CA private key

Generate 2048-bit key size (faster, suitable for most applications):

openssl genrsa -out ca.key 2048

Or generate 4096-bit key size (higher security, recommended for production):

openssl genrsa -out ca.key 4096

Step 2: Create the root CA certificate (valid for 1 year)

openssl req -x509 -sha256 -new -nodes -key ca.key -days 365 -out ca.pem

11.7.2. Server certificate creation

Step 3: Create server certificate signing request (CSR)

For 2048-bit key:

openssl req -newkey rsa:2048 -keyout server.key -out server.csr -nodes

Or for 4096-bit key:

openssl req -newkey rsa:4096 -keyout server.key -out server.csr -nodes

Step 4: Sign server certificate with CA (valid for 1 year)

openssl x509 -req -CA ca.pem -CAkey ca.key -in server.csr -out server.pem -days 365 -CAcreateserial

11.7.3. Client certificate creation

Step 5: Create client certificate signing request (CSR)

For 2048-bit key:

openssl req -newkey rsa:2048 -keyout client.key -out client.csr -nodes

Or for 4096-bit key:

openssl req -newkey rsa:4096 -keyout client.key -out client.csr -nodes

Step 6: Sign client certificate with CA (valid for 1 years)

openssl x509 -req -CA ca.pem -CAkey ca.key -in client.csr -out client.pem -days 365 -CAcreateserial

11.7.4. Testing certificates

Windows Git Bash Environment:

Note: winpty is required for interactive OpenSSL commands in Git Bash on Windows.

TLS 1.2 Testing:

Set up a local TLS 1.2 server:

winpty openssl s_server -CAfile ca.pem -key server.key -cert server.pem -accept 44330 -tls1_2 -state -Verify 1

Connect to the local TLS 1.2 server:

winpty openssl s_client -connect localhost:44330 -CAfile ca.pem -key client.key -cert client.pem -tls1_2

TLS 1.3 Testing:

Set up a local TLS 1.3 server:

winpty openssl s_server -CAfile ca.pem -key server.key -cert server.pem -accept 44331 -tls1_3 -state -Verify 1

Connect to the local TLS 1.3 server:

winpty openssl s_client -connect localhost:44331 -CAfile ca.pem -key client.key -cert client.pem -tls1_3

Linux Environment:

TLS 1.2 Testing:

Set up a local TLS 1.2 server:

openssl s_server -CAfile ca.pem -key server.key -cert server.pem -accept 44330 -tls1_2 -state -Verify 1

Connect to the local TLS 1.2 server:

openssl s_client -connect localhost:44330 -CAfile ca.pem -key client.key -cert client.pem -tls1_2

TLS 1.3 Testing:

Set up a local TLS 1.3 server:

openssl s_server -CAfile ca.pem -key server.key -cert server.pem -accept 44331 -tls1_3 -state -Verify 1

Connect to the local TLS 1.3 server:

openssl s_client -connect localhost:44331 -CAfile ca.pem -key client.key -cert client.pem -tls1_3

Testing Both TLS Versions (Flexible):

For testing compatibility with both TLS 1.2 and 1.3:

// Server that accepts both TLS 1.2 and 1.3 (Windows)
winpty openssl s_server -CAfile ca.pem -key server.key -cert server.pem -accept 44332 -state -Verify 1
// Server that accepts both TLS 1.2 and 1.3 (Linux)
openssl s_server -CAfile ca.pem -key server.key -cert server.pem -accept 44332 -state -Verify 1
// Client connecting with version negotiation (will use highest available)
winpty openssl s_client -connect localhost:44332 -CAfile ca.pem -key client.key -cert client.pem    // Windows
openssl s_client -connect localhost:44332 -CAfile ca.pem -key client.key -cert client.pem    // Linux

11.7.5. Certificate verification

Verify CA certificate key size:

openssl x509 -in ca.pem -text -noout | grep "Public-Key"

Expected output: RSA Public-Key: (4096 bit) or RSA Public-Key: (2048 bit)

Verify client certificate key size:

openssl x509 -in client.pem -text -noout | grep "Public-Key"

Expected output: RSA Public-Key: (4096 bit) or RSA Public-Key: (2048 bit)

Verify client private key size:

openssl rsa -in client.key -text -noout | grep "Private-Key"

Expected output: RSA Private-Key: (4096 bit, 2 primes) or RSA Private-Key: (2048 bit, 2 primes)

11.7.6. Security recommendations

Key Size Selection:

• 2048-bit: Minimum recommended, faster processing, suitable for most IoT applications
• 4096-bit: Higher security, recommended for production environments with sensitive data

Certificate Validity:

• Production certificates should have shorter validity periods (1-2 years)
• Test certificates can use longer periods for convenience

File Security:

• Protect private key files (*.key) with appropriate file permissions
• Store CA private key securely and offline in production environments
• Consider using hardware security modules (HSM) for critical applications

11.7.7. Certificate management commands

NORA-W36 provides comprehensive certificate management capabilities for secure storage and administration of X.509 certificates and private keys.

Certificate Storage Capacity:

• Maximum 8 certificates (or certificate chains) can be stored simultaneously
• Maximum certificate size: 15,360 bytes per certificate
• Support for PEM format certificates (DER format not supported)

Certificate Management Commands:

Certificate Types:

• 0: Root/CA certificate
• 1: Client certificate
• 2: Client private key

Certificate Operations Examples:

// List all stored certificates
AT+USECL?
+USECL:0,"ca-root"
+USECL:1,"device-cert"
+USECL:2,"device-key"
// View certificate details (fingerprint, size, validity dates)
AT+USECD="device-cert"
+USECD:0,A1B2C3D4E5F6...           // Certificate fingerprint (hex)
+USECD:1,2048            // Certificate size in bytes (decimal)
+USECD:2,5F5E1000        // Not valid before: Unix epoch in hex (Jan 1, 2023)
+USECD:3,6586A400        // Not valid after: Unix epoch in hex (Dec 31, 2025)
// Remove specific certificate
AT+USECR=1,"old-client-cert"
// Remove all certificates (factory reset certificates)
AT+USECR

Understanding Certificate Fingerprint:

The fingerprint (+USECD:0) is a SHA-256 hash of the certificate, useful for verification and identification.

Calculate and Verify Fingerprint with OpenSSL:

# Calculate SHA-256 fingerprint using OpenSSL
openssl x509 -noout -fingerprint -sha256 -in ca.pem

Real Example:

# NORA-W36 output:
AT+USECD="ca.pem"
+USECD:0,025EF9A024DEF7FCBFD6E3717557C016BCB9C34E6BAA288111D53F9490E06CC2
# OpenSSL verification:
$ openssl x509 -noout -fingerprint -sha256 -in ca.pem
sha256 Fingerprint=02:5E:F9:A0:24:DE:F7:FC:BF:D6:E3:71:75:57:C0:16:BC:B9:C3:4E:6B:AA:28:81:11:D5:3F:94:90:E0:6C:C2

Note: NORA-W36 returns fingerprint as continuous hex string, while OpenSSL formats with colons.

Understanding Certificate Date Format:

• Dates are returned as hexadecimal Unix epoch timestamps
• Example: 6586A400 (hex) = 1,703,462,400 (decimal) = Dec 25, 2023 00:00:00 UTC
• Conversion: Use online epoch converters or: date -d @$((0x6586A400)) (Linux/macOS)
• PowerShell: [DateTimeOffset]::FromUnixTimeSeconds(0x6586A400).DateTime

Security Best Practices:

1. Regular Certificate Audits: Use AT+USECL? to monitor stored certificates
2. Certificate Rotation: Remove expired certificates with AT+USECR
3. Storage Optimization: Remove unused certificates to free storage space
4. Validity Monitoring: Check certificate expiration dates with AT+USECD
5. Backup Strategy: Keep secure backups of certificates before removal operations

Certificate Date Format Reference:

When using AT+USECD to check certificate validity dates, the NORA-W36 returns timestamps in hexadecimal Unix epoch format:

AT+USECD="my-certificate"
+USECD:2,61F2D000        // Not valid before: Jan 27, 2022 12:00:00 UTC
+USECD:3,6586A400        // Not valid after:  Dec 25, 2023 00:00:00 UTC

Converting Hex Epoch Timestamps:

Common Epoch Hex Values:

• 0x61F2D000 = 1,643,289,600 = Jan 27, 2022 12:00:00 UTC
• 0x6586A400 = 1,703,462,400 = Dec 25, 2023 00:00:00 UTC
• 0x677B8000 = 1,736,207,360 = Jan 7, 2025 00:16:00 UTC

Password-Protected Private Keys:

NORA-W36 supports AES-encrypted PKCS8 private keys with password protection:

// Upload encrypted private key with password
AT+USECUB=2,"secure-key","mypassword123"{binary_data}

11.8. TLS version configuration

NORA-W36 v3.1.0 introduces comprehensive TLS 1.3 support across all protocols including EAP-TLS, TCP sockets, HTTP clients, and MQTT. This enhanced security capability provides improved encryption algorithms, forward secrecy, and reduced handshake latency.

TLS Version Parameters:

All TLS-enabled AT commands support the following version parameters:

• 0: Disable TLS (not recommended for secure connections)
• 1: TLS 1.2 only (legacy compatibility)
• 2: TLS 1.3 only (recommended for new implementations)
• 3: TLS 1.2 or 1.3 (negotiate highest available - flexible option)

Protocol-Specific TLS Support:

TLS 1.3 Security Enhancements:

• Forward Secrecy: Each session uses unique encryption keys
• Reduced Handshake: Faster connection establishment (1-RTT vs 2-RTT)
• Improved Cipher Suites: Only secure AEAD algorithms supported
• Certificate Privacy: Server certificate encrypted during handshake
• Anti-Downgrade Protection: Prevents fallback to weaker TLS versions

Migration Recommendations:

1. New Projects: Use TLS 1.3 (parameter 2) for maximum security
2. Legacy Compatibility: Use flexible mode (parameter 3) during transition
3. Testing: Verify server/broker TLS 1.3 support before deployment
4. Performance: Monitor connection times - TLS 1.3 typically reduces latency

11.9. TLS extensions configuration

NORA-W36 supports advanced TLS extensions that enhance security and compatibility with modern TLS implementations.

Available TLS Extensions:

Server Name Indication (SNI):

• Enables TLS client to specify hostname during handshake
• Essential for servers hosting multiple domains on same IP
• Required for proper certificate validation in many deployments

// Enable SNI (recommended for most applications)
AT+USETE0=1
// Disable SNI (only for legacy servers)
AT+USETE0=0
// Check current SNI setting
AT+USETE0?

Handshake Fragmentation:

• Splits large TLS handshake messages into smaller fragments
• Prevents issues with MTU limitations and network constraints
• Improves reliability in constrained network environments

// Enable handshake fragmentation (recommended)
AT+USETE1=1
// Disable handshake fragmentation
AT+USETE1=0
// Check current fragmentation setting
AT+USETE1?

Configuration Best Practices:

1. Keep SNI Enabled: Required for most modern TLS servers
2. Enable Fragmentation: Prevents handshake failures in constrained networks
3. Store Settings: Use AT&W followed by AT+CPWROFF to persist extension settings across reboots
4. Test Configuration: Verify TLS handshake success with target servers

12. MQTT use cases

📡 MQTT Communication Overview:

    ┌─────────────     ┌─────────────     ┌─────────────
    │📱 Publisher │────▶│ MQTT      │◄────│📱 Subscriber│
    │  (NORA-W36) │     │   Broker    │     │  (Device)   │
    │             │     │             │     │             │
    │ Sends data  │     │ Routes      │     │ Receives    │
    │ to topics   │     │ messages    │     │ from topics │
    └─────────────┘     └─────────────┘     └─────────────┘
           │                     │                     │
      Publish Msgs          Topic Routing         Subscribe
    🔧 Features:             Broker:             📊 Benefits:
- • Low bandwidth        • Topic management     • Decoupled comm.
- • Reliable delivery    • Message routing      • Scalable design
- • QoS levels (0,1,2)   • Client sessions      • IoT optimized

• The MQTT client in NORA-W36 uses version MQTT v3.1.1
• For more about the Message Queuing Telemetry Transport (MQTT), see the MQTT beginner's guide
• TLS 1.3 Security: NORA-W36 v3.1.0 supports TLS 1.2 and TLS 1.3 for secure MQTT communications with enhanced encryption algorithms, forward secrecy, and reduced handshake latency

12.1. MQTT overview

MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe messaging protocol designed for IoT applications with constrained networks and devices. It enables efficient communication between devices and cloud services with minimal bandwidth and power consumption.

Key MQTT characteristics:

• Publish-Subscribe Model: Decoupled communication through topics
• Lightweight Protocol: Minimal overhead for constrained devices
• Reliable Delivery: Multiple Quality of Service levels
• Persistent Sessions: Maintain connection state across disconnections
• Last Will Testament: Automatic notification of unexpected disconnections

NORA-W36 MQTT Implementation:

• Uses MQTT v3.1.1 protocol (MQTT v5.0 is not supported)
• TLS 1.2 support for secure connections
• Optimized for IoT device constraints

12.2. MQTT key concepts

12.2.1. Quality of service (qos) levels

MQTT provides three QoS levels to guarantee message delivery:

QoS 0 - At Most Once

• Fire-and-forget delivery
• No acknowledgment required
• Fastest but least reliable
• Use case: Sensor readings where occasional data loss is acceptable

AT+UMQPS=0,0,0,"temperature","25.5"          // QoS 0 publish

QoS 1 - At Least Once

• Guaranteed delivery with possible duplicates
• Requires PUBACK acknowledgment
• Balanced reliability and performance
• Use case: Important notifications that must be delivered

AT+UMQPS=0,1,0,"alert","Low battery warning"    // QoS 1 publish

QoS 2 - Exactly Once

• Guaranteed single delivery
• Requires PUBREC/PUBREL/PUBCOMP handshake
• Highest reliability but slowest
• Use case: Critical commands or financial transactions

AT+UMQPS=0,2,0,"command","device_reset"      // QoS 2 publish

12.2.2. Retained messages

Retained messages are stored by the broker and delivered to new subscribers immediately upon subscription:

Publishing a retained message:

AT+UMQPS=0,0,1,"device/status","online"      // Retain flag = 1

Use cases for retained messages:

• Device status (online/offline)
• Last known sensor values
• Configuration settings
• System announcements

12.2.3. Last will and testament (LWT)

LWT allows devices to specify a message that the broker publishes automatically if the device disconnects unexpectedly:

Configuration example:

// Configure LWT during connection setup
AT+UMQCP=0,"broker.example.com",1883,"device123","user","pass"

LWT use cases:

• Device health monitoring
• Automatic offline notifications
• System fault detection
• Connection status tracking

12.2.4. Connection management

Clean Session Flag:

• Clean Session = 1: Fresh start, no stored state
• Clean Session = 0: Resume previous session with stored subscriptions

Keep-Alive Timer:

• Maintains connection during idle periods
• Broker disconnects if no communication within keep-alive interval
• Recommended: 30-300 seconds depending on application

12.3. Error handling and troubleshooting

Common MQTT Error Scenarios:

MQTT Connection Status:

• Successful connection: +UEMQC:0
• Message received: +UEMQD:<handle>,<length>
• Connection lost: Monitor connection events

Troubleshooting Steps:

12.4. Performance optimization

Connection Parameters:

Best Practices:

• Use QoS 0 for frequent sensor data
• Use QoS 1 for important events
• Keep topic names short and hierarchical
• Implement exponential backoff for reconnections
• Monitor connection stability with keep-alive
• Use retained messages sparingly

Network Considerations:

• Choose appropriate keep-alive based on network reliability
• Consider cellular vs Wi-Fi network characteristics
• Implement proper error handling and retry logic
• Monitor battery usage for power-constrained applications

12.5. MQTT client without TLS - Mosquitto

This use case connects NORA-W36 as a Wi-Fi Station and a MQTT Broker on port 1883. In this scenario, the module connects to Mosquitto without a certificate.

Parameters and values

• Host: test.mosquitto.org
• Port: 1883 (no TLS connection)
• Client ID: -
• Username: -
• Password: -
• CA Root certificate: -
• Client certificate: -
• Client private key: -

Before connecting to MQTT, set up Wi-Fi Connection, as described in Wi-Fi station, steps 1-5.

Note: Use the wildcard "*" to receive messages for all topics. Note that this option may not be supported by all brokers, like Azure.

12.6. MQTT TLS client - Mosquitto

This use case connects NORA-W36 as a Wi-Fi Station and a MQTT Broker. In this scenario, the module connects to Mosquitto using certificates.

To generate client certificate and client key, follow the procedures described on the Mosquitto web page: https://test.mosquitto.org/ssl/

• CA certificate can be downloaded here: mosquitto.org.crt

Parameters and values

• Host: test.mosquitto.org
• Port: 8884 (TLS)
• Client ID: -
• Username: -
• Password: -
• CA Root certificate: mosquitto.org.crt
• Client certificate: client.crt
• Client private key: client.key

Note: The parameters given in this scenario use the port 8884 for connections and encryption for security.

To authenticate the client and ensure the following:

• Only authorized devices can establish a connection with the MQTT broker
• Clients provide a valid certificate when making a connection
• 1883 : MQTT, unencrypted, unauthenticated
• 1884 : MQTT, unencrypted, authenticated
• 8883 : MQTT, encrypted, unauthenticated
• 8884 : MQTT, encrypted, client certificate required (used in this example)
• 8885 : MQTT, encrypted, authenticated
• 8886 : MQTT, encrypted, unauthenticated

Before connecting to MQTT, set up a Wi-Fi Connection like that described in Wi-Fi station, steps 1-5.

12.7. MQTT TLS client - thingstream

Thingstream is the u-blox service delivery platform for:

• IoT Communication-as-a-Service
• IoT Location-as-a-Service

This use case connects NORA-W36 as a Wi-Fi Station and a MQTT Broker. In this scenario NORA-W36 connects to Thingstream using a CA Root certificate, Client-ID, Username and Password.

Thingstream uses the AWS Root Certificate found here: https://www.amazontrust.com/repository/AmazonRootCA1.pem

Before connecting to MQTT, set up Wi-Fi Connection, like that described Wi-Fi station, steps 1-5.

The parameters and values necessary for the use case include:

Parameters and values

• Host: mqtt.thingstream.io
• Port: 8883 (TLS)
• Client ID: device:78e3d356-876f-483b-872f-3485853fAAAA
• Username: HMVK8C09FQP245O2BBBB
• Password: ofYyBB/L3GkPvo060J6Dv+t+mfrh0XpGMcf7CCCC
• CA Root certificate: AmazonRootCA1.pem
• Client certificate: -
• Client private key: -

Before connecting to MQTT, set up Wi-Fi Connection like in steps 1-5 in Wi-Fi station

12.8. MQTT TLS client - AWS IoT core

Connect as a Wi-Fi Station and a MQTT Broker. In this scenario, NORA-W36 connects to Amazon AWS IoT Core using certificates.

Parameters and values

• Host: a3loryode2aaaa-ats.iot.us-east-2.amazonaws.com
• Port: 8883 (TLS)
• Client ID: -
• Username: -
• Password: -
• CA Root certificate: AmazonRootCA1.pem
• Client certificate: aws_client.crt
• Client private key: aws_priv_key.key

Before connecting to MQTT, set up Wi-Fi Connection like in steps 1-5 in Wi-Fi station

12.9. MQTT TLS client - Azure IoT hub

Connect as a Wi-Fi Station and an Access Point and a MQTT Broker. In this scenario, NORA-W36 connects to Microsoft Azure using certificates.

Important Note: Azure IoT Hub isn't a full-featured MQTT broker and doesn't support all the behaviors specified in the MQTT v3.1.1 standard.

Parameters and values

• Host: iothub-test-sw.azure-devices
• Port: 8883 (TLS)
• Client ID: device1
• Username: iothub-test-sw.azure-devices.net/device1/
• Password: -
• CA Root certificate: AzureCa.pem
• Client certificate: azure_client.crt
• Client private key: azure_priv_key.key

Before connecting to MQTT, set up Wi-Fi Connection like in steps 1-5 in Wi-Fi station

13. HTTP and HTTPS use cases

NORA-W36 includes a comprehensive HTTP client supporting HTTP/1.1 protocol with features including GET, POST, PUT, DELETE operations. When combined with TLS, it provides secure HTTPS communication. The HTTP client simplifies web communication without requiring deep protocol knowledge.

Important Note: HTTP requests have a Maximum Transmission Unit (MTU) of 1000 bytes. This applies to both request data and response data. For larger data transfers, consider splitting the data into multiple requests or using chunked transfer encoding.

13.1. HTTP client features

• HTTP Methods: GET, POST, PUT, DELETE, HEAD
• TLS/SSL Support: HTTPS with server certificate validation
• Authentication: Basic authentication, custom headers
• Content Types: JSON, XML, binary data, form data
• Connection Management: Keep-alive and connection reuse
• Error Handling: HTTP status codes and error reporting

13.2. Available HTTP commands

13.3. Simple HTTP get request

This example demonstrates a basic HTTP GET request to retrieve data from a web server.

Target: http://httpbin.org/get (HTTP test service)

Before connecting, ensure Wi-Fi is connected as shown in Wi-Fi station.

13.4. HTTPS get with certificate validation

This example shows secure HTTPS communication with server certificate validation.

Target: https://api.github.com/repos/octocat/Hello-World (GitHub API)

13.5. HTTP post with JSON data

This example demonstrates sending JSON data via HTTP POST request.

Target: https://httpbin.org/post (HTTP test service)

Payload: {"temperature": 25.6, "humidity": 60.2, "device": "NORA-W36"}

13.6. HTTP post with binary file upload

This example shows how to upload binary files using HTTP POST with multipart/form-data.

Target: https://httpbin.org/post

File: sensor_data.bin (256 bytes)

13.7. HTTP post request for data updates

This example demonstrates updating data on a server using HTTP POST method.

Target: https://httpbin.org/post

Data: Configuration update JSON

13.8. HTTP delete request

This example shows how to delete resources using HTTP DELETE method.

Target: https://httpbin.org/delete

13.9. Advanced TLS configuration

This example demonstrates advanced TLS settings including client certificates for mutual authentication.

Target: Secure API with mutual TLS authentication

Certificates: CA certificate, client certificate, and private key

13.10. HTTP response status codes

The HTTP client returns standard HTTP status codes to indicate request results:

13.11. Troubleshooting HTTP requests

13.11.1. Common issues and solutions

13.11.2. Debugging steps

1. Check connection status: AT+UWSNST? (connection info)
2. Verify DNS resolution: Check if domain name resolves correctly
3. Test without TLS: Try HTTP instead of HTTPS to isolate TLS issues
4. Check certificate chain: Ensure complete certificate chain is uploaded
5. Validate headers: Confirm Content-Type, Content-Length, and Authorization headers

13.12. HTTP client best practices

13.12.1. Performance optimization

• Connection Reuse: Keep HTTP client connected for multiple requests to same server
• Compression: Use Accept-Encoding: gzip header when supported
• Chunked Transfer: For large uploads, consider chunked transfer encoding
• Timeout Settings: Configure appropriate timeout values for your use case

13.12.2. Security recommendations

• Always use HTTPS for sensitive data transmission
• Validate server certificates using proper CA certificates
• Use strong authentication (API keys, OAuth tokens) instead of basic auth
• Implement rate limiting to avoid overwhelming servers
• Sanitize response data before processing in your application

13.12.3. Memory management

• Read response data incrementally using appropriate buffer sizes
• Disconnect unused clients to free resources: AT+UHTCDC=0
• Monitor memory usage with large file transfers
• Use binary mode for non-text data to avoid encoding overhead

13.12.4. Example: complete IoT sensor data upload

// Connect to secure IoT platform
AT+UHTCCP=0,"iot.example.com",443
AT+UHTCTLS=0,1,"iot-ca.pem","device.crt","device.key"
AT+UHTCRP=0,"POST","/api/v1/sensors/data"
AT+UHTCRHAF=0,"Content-Type","application/json"
AT+UHTCRHAF=0,"Authorization","Bearer eyJhbGciOiJIUzI1..."
AT+UHTCRHAF=0,"X-Device-ID","NORA-W36-001"
// Send sensor reading
AT+UHTCRPOS=0,85
{"timestamp":"2025-09-25T10:30:00Z","temperature":23.5,"humidity":65,"pressure":1013}
// Expected response: HTTP 201 Created
+UEHTCRS:0,201,"Created"
AT+UHTCGBS=0,200
+UHTCGBS:0,0,45,"{"status":"success","id":"sensor_12345"}"
AT+UHTCDC=0

14. Network Time Protocol (NTP) use cases

NORA-W36 supports Network Time Protocol (NTP) client functionality to synchronize the system clock with time servers on the internet. This ensures accurate timekeeping for applications that require time-stamped data, secure communications, or scheduled operations.

14.1. Basic NTP configuration

Connect as a Wi-Fi station and configure NTP to synchronize system time automatically.

This use case demonstrates how to set up NTP with multiple time servers for redundancy and verify time synchronization.

Prerequisites:

• Module must be connected to a Wi-Fi network with internet access
• Network must allow UDP traffic on port 123 (NTP)

Note: The unix time 66E7B2A4 (hex) equals 1726468772 (decimal), which corresponds to a human-readable time like "Mon, 16 Sep 2024 10:12:52 GMT".

14.2. NTP with DHCP fallback

Configure NTP to use DHCP-provided time servers with manual fallback.

This configuration first attempts to use NTP servers provided by the network's DHCP server, falling back to manually configured servers if DHCP servers are unavailable.

14.3. NTP server management

Manage and troubleshoot NTP server configuration.

Popular NTP Servers:

• pool.ntp.org - Global NTP pool project
• time.google.com - Google Public NTP
• time.nist.gov - US National Institute of Standards
• time.cloudflare.com - Cloudflare Public NTP
• Regional pools: 0.europe.pool.ntp.org, 0.asia.pool.ntp.org, etc.

Troubleshooting Tips:

• If servers show reachable=0, check network connectivity and firewall settings
• NTP synchronization may take 30-60 seconds on first connection
• Use multiple servers from different sources for redundancy
• Regional NTP servers typically provide better performance than global ones

15. Roaming use cases

15.1. Wi-Fi roaming overview

Wi-Fi roaming allows devices to maintain seamless connectivity while moving between access points (APs) in the same network. This is essential for mobile applications, large coverage areas, and enterprise environments where multiple APs provide overlapping coverage using the same Service Set Identifier (SSID).

15.1.1. IEEE 802.11 roaming standards

Modern Wi-Fi networks implement several roaming standards to optimize the handoff process:

IEEE 802.11r (Fast BSS Transition - FT)

• Reduces roaming time from ~1000ms to ~50ms
• Pre-authenticates with target AP before handoff
• Maintains security associations during transition
• Critical for real-time applications like VoIP

IEEE 802.11k (Radio Resource Management - RRM)

• Provides neighbor AP reports to clients
• Enables intelligent roaming decisions
• Reduces scanning time by providing AP candidate lists
• Includes signal strength and load information

IEEE 802.11v (Wireless Network Management - WNM)

• Allows network-assisted roaming decisions
• APs can suggest better connection targets
• Enables Band Steering (2.4GHz ↔ 5GHz)
• Supports load balancing across APs

IEEE 802.11w (Protected Management Frames - PMF)

• Secures management frames during roaming
• Prevents deauthentication attacks
• Required for WPA3 networks

15.2. NORA-W36 roaming implementation

NORA-W36 supports client-initiated roaming based on RSSI thresholds and scanning algorithms. Roaming is disabled by default and must be enabled before connecting to Wi-Fi.

15.2.1. Roaming process

1. Monitoring Phase: Continuously monitors current AP's RSSI
2. Trigger Phase: When RSSI drops below threshold, initiates background scanning
3. Discovery Phase: Scans for APs with same SSID and better signal strength
4. Decision Phase: Evaluates candidate APs based on configured criteria
5. Handoff Phase: Disconnects from current AP and connects to target AP

15.2.2. Roaming configuration

NORA-W36 supports roaming, it is disabled by default and needs to be enabled before connecting Wi-Fi with AT+UWSROE=1

The most important settings are the following, see AT manual for more settings:

15.2.3. Standard roaming mode (AT+uwsros3=0)

With the default configuration, roaming will start when RSSI drops to -70 dBm or below. A background scan will start to find a better AP with the same SSID. It will perform roaming if an Access Point with -70 + 10 = -60 dBm or better is found.

Example configuration:

AT+UWSROE=1      // Enable roaming
AT+UWSROS0=-70           // Start scanning at -70 dBm
AT+UWSROS1=10            // Require 10 dB improvement
AT+UWSROS3=0     // Use fixed threshold mode

15.2.4. Adaptive roaming mode (AT+uwsros3=1)

In some situations you want to roam based on your current RSSI instead of a fixed value. This "aggressive roaming" mode uses AT+UWSROS3=1 and typically requires lowering the switch limit to 3 dBm AT+UWSROS1=3.

Calculation: If current RSSI is -78 dBm, the target threshold becomes -78 + 3 = -75 dBm. Roaming will occur if an AP with -75 dBm or better signal is found.

Example configuration:

AT+UWSROE=1      // Enable roaming
AT+UWSROS0=-70           // Start scanning at -70 dBm
AT+UWSROS1=3     // Require only 3 dB improvement
AT+UWSROS3=1     // Use current RSSI mode

15.2.5. Roaming optimization guidelines

Roaming Configuration Strategies:

For enterprise environments:

• Consider AP density and coverage overlap
• Test roaming behavior in actual deployment
• Monitor for excessive roaming (ping-ponging)

15.2.6. Current roaming capabilities and roadmap

Current implementation:

• NORA-W36 performs client-initiated roaming only
• Roaming decision based on RSSI only (no load balancing)
• Brief connectivity interruption during AP handoff
• Both APs must use identical security configuration

Future roadmap:

• 802.11r (Fast BSS Transition) support planned for future releases
• 802.11k (Radio Resource Management) support planned for future releases
• 802.11v (Wireless Network Management) support planned for future releases
• These standards will enable faster, more intelligent roaming with minimal service interruption

16. Power save use cases

16.1. Auto sleep

By default no lower power mode is enabled in NORA-W36 to have maximal performance and response time.

In some applications power consumption is important and data throughput and latency is not that important. By enabling the low power mode this will slightly change. More power save means more latency can be expected.

Power level 0 (default, no power save) and power level 1 (moderate power save) is supported, more levels may be added in future releases.

The low power level 1 is set using the command AT+UPMPSL=1 see NORA-W36 SIM and AT command manual for more details. There is a limitation that the first AT command after the timeout (default 1 second) can't be longer than 16 bytes.

Important Note: In power level 1 only 115200 baud rate or lower is allowed.

Power Management Commands:

Power Save Configuration Examples:

// Enable moderate power save with 2-second timeout
AT+UPMPSL=1
AT+UPMPSTO=2000
AT&W             // Store settings
AT+CPWROFF       // Reset to apply stored settings safely
// Check current power save configuration
AT+UPMPSL?
+UPMPSL:1        // Power save level 1 enabled
AT+UPMPSTO?
+UPMPSTO:2000            // 2000ms timeout
// Disable power save (maximum performance)
AT+UPMPSL=0

Power Save Behavior:

• Level 0: No power save, maximum performance and responsiveness
• Level 1: Moderate power save, slight increase in latency after timeout period
• Module enters low-power state after specified timeout of inactivity
• Any AT command or data activity resets the timeout timer

All low power modes save power automatically and will adjust this depending on the level.

When enabled, no further action is required by the host.

16.2. Deep sleep

The most efficient power level is Deep sleep which is almost like a power off, no radio communication is possible in this mode.

• To initiate Deep sleep mode, the host uses the AT command AT+UPMDS
• To wake up the module from Deep sleep mode, the host sets GPIO_J9 to GND
• After wake up, the module assumes the same state as it does after a reset

17. Send and receive data

17.1. Quick mode selection guide

Not sure which mode to use? Answer these questions:

1. What type of data are you sending?

• Text/JSON → String Mode (human readable, easy debugging)
• Images/Files → Binary Mode (preserves exact bytes)
• Real-time streams → Transparent Mode (lowest latency)

1. Do you need to process each message separately?

• Yes → Buffered Mode (message boundaries preserved)
• No → Direct Mode (stream of bytes)

1. How important is speed vs reliability?

• Speed critical → Direct Mode (faster)
• Reliability critical → Buffered Mode (event-driven)

👉 Most Common Choice: String Buffered Mode - Perfect for most IoT applications

---

NORA-W36 provides multiple data transmission modes optimized for different use cases and performance requirements. Understanding when to use each mode is crucial for optimal application performance and reliability.

17.2. Data mode overview

17.2.1. Data format modes

17.2.2. Receive buffer modes

17.3. When to use each data mode

17.3.1. String mode - text and structured data

✅ Use string mode when:

• Sending/receiving JSON, XML, HTML, or plain text
• Working with REST APIs and web services
• Transmitting sensor readings in text format
• Handling configuration data or commands
• Data contains only printable ASCII characters

Avoid string mode when:

• Working with binary files (images, certificates, executables)
• Data contains null bytes (0x00) or control characters
• Maximum performance is critical
• Handling encrypted data or raw binary protocols

Example use cases:

• IoT sensor data: {"temperature":25.6,"humidity":60.2}
• HTTP responses: HTTP/1.1 200 OK\r\nContent-Type: application/json
• MQTT messages with text payloads
• Configuration files in JSON/XML format

17.3.2. Binary mode - all data types

✅ Use binary mode when:

• Transferring files (images, documents, firmware)
• Uploading TLS certificates and private keys
• Working with binary protocols (custom, proprietary)
• Data contains null bytes or control characters
• Need full byte range support (0x00-0xFF)
• Data integrity is critical

Avoid binary mode when:

• Only working with simple text data
• Ease of debugging is more important than functionality
• Working with text-only protocols (HTTP headers, SMTP)

Example use cases:

• Certificate uploads: AT+USECUB=0,"ca.pem"{binary certificate data}
• File transfers: Images, PDFs, firmware updates
• Encrypted data transmission
• Custom binary protocols

17.3.3. Transparent mode - maximum performance

✅ Use transparent mode when:

• Maximum throughput is required
• Implementing legacy applications (similar to old data mode)
• Streaming data continuously
• Want direct UART-to-network bridge functionality
• Minimal protocol overhead needed

Avoid transparent mode when:

• Need multiple concurrent connections
• Require AT command access during data transfer
• Application needs flow control or data validation
• Working with complex protocols requiring parsing

Example use cases:

• Legacy terminal applications
• High-speed data streaming
• Simple bridge applications

---

17.4. Basic data mode configuration

NORA-W36 supports several modes for sending and receiving data:

• String mode
• All readable ASCII characters (0x21-0x7E, 0xA1-0xFF)
• Use when sending data in plain text format. For example, when using JSON, HTML, or NMEA.
• Binary mode
• All types of characters (0x00-0xFF)
• Use when all types of data is needed. For example, in binary content using file upload and download.
• Transparent mode
• All types of characters (0x00-0xFF)

Performance notes:

• Transparent mode has best performance, due to no wait states
• Direct mode is faster than Buffered mode
• Binary mode is faster than String mode

To receive data without an event and read it out, the read mode can be changed to direct mode AT+USORM=1

17.5. String mode

Socket receive mode

Syntax

AT+USORM=<receive_mode>

• 0: Buffered mode
• +UESODA - Socket Data Available Event, default mode
• 1: Direct string mode
• +UESODS - Socket Data Binary Event: Incoming on TCP socket data represented as a string
• +UESODSF - Socket Data Binary From Event: Incoming on UDP socket data represented as a string

SPS Receive data mode

Syntax

AT+USPSRM=<receive_mode>