Connecting a LoRaWAN Device to The Things Network in Australia

Detailed Explanation

For LoRa modulation fundamentals, LoRaWAN network architecture, spreading factors, and why AU915 uses 915 MHz, see What Is LoRa and LoRaWAN?. This guide focuses on the practical implementation: selecting the correct AU915 sub-band, registering a device with OTAA on The Things Network, configuring the firmware, and verifying the first uplink.

Why Sub-band Selection Is the Primary TTN Join Failure

AU915 defines 72 uplink channels spread across eight sub-bands, but a LoRaWAN gateway typically monitors only one sub-band at a time. TTN gateways in Australia are configured for sub-band 2 (channels 8–15 and channel 65). If your end device transmits across all 72 channels — which is the default in many LoRaWAN firmware stacks when no sub-band is explicitly selected — the gateway will miss 7 out of every 8 transmission attempts. Join requests distributed across all channels will almost never land on the channels the gateway is monitoring.

The failure mode is silent: the device is transmitting valid LoRa frames, the join request is correctly formatted, but the gateway is simply not listening on those frequencies. The TTN console shows no activity. Adding LMIC_selectSubBand(1) is the single most common fix for a TTN AU915 device that refuses to join.

AU915 Sub-band 2: Channel Frequencies

TTN Australia uses the following uplink channels, as defined in the LoRa Alliance Regional Parameters document RP002-1.0.3 (§2.8):

Downlink channels (shared across all AU915 sub-bands) are 8 × 500 kHz channels from 923.3 to 927.5 MHz in 600 kHz steps, used for RX1 and RX2 receive windows after each uplink.

Registering a Device on The Things Network

1. Create a TTN Account and Application

Sign up at console.thethingsnetwork.org and select the Australia 1 cluster (au1.cloud.thethings.network) when prompted. This is physically the closest cluster for Australian gateways and end devices.

Create an application with a unique Application ID. The application is the container for your devices and handles payload decoding. Give it a descriptive name — you cannot change the Application ID after creation.

2. Register Your Device with OTAA

In the application, navigate to End devices → Add end device and choose Over The Air Activation (OTAA). Key configuration fields:

• LoRaWAN version: LoRaWAN Specification 1.0.3 for most currently deployed modules (RAK3172, Murata CMWX1ZZABZ, Dragino LA66). Select 1.1 only if your module's datasheet explicitly states LoRaWAN 1.1 support.
• Regional parameters version: RP001 Regional Parameters 1.0.3 revision A.
• Frequency plan: Australia 915–928 MHz, sub-band 2 (used by TTN). This is the critical selection — it tells the TTN network server which channels to expect from this device.
• JoinEUI (AppEUI): A 64-bit identifier for the join server. For community TTN deployments using MCCI LMIC, the conventional value is all zeros (0000000000000000). If your module has a manufacturer-programmed JoinEUI (check the AT command AT+DEVEUI / AT+APPEUI), use that instead.
• DevEUI: An 8-byte globally unique device identifier. Most LoRaWAN modules have a factory-programmed DevEUI readable via AT command (AT+DEVEUI on RAK modules; AT$I=10 on Murata). If no hardware EUI is available, TTN can generate one for prototyping.
• AppKey: A 16-byte root key used to derive NwkSKey and AppSKey during the OTAA join. TTN will generate this — click Generate and store the result securely. Anyone with the AppKey can impersonate or eavesdrop on the device.

After registering, note the three credentials (JoinEUI, DevEUI, AppKey). TTN displays these in both MSB and LSB byte order — the order required depends on your firmware library (see firmware section below).

Configuring Firmware for AU915 Sub-band 2

MCCI LMIC (Arduino / ESP-IDF)

MCCI LMIC is the most widely deployed LoRaWAN stack for Arduino-compatible hardware. To configure it for TTN AU915:

1. Set the region in lmic_project_config.h:

#define CFG_au915 1

2. Select sub-band 2 in setup(), after LMIC_init():

void setup() {
    os_init();
    LMIC_reset();
    // Restrict to AU915 sub-band 2 (channels 8–15 + channel 65)
    // Argument is 0-indexed: sub-band 2 = index 1
    LMIC_selectSubBand(1);
    LMIC_startJoining();
}

LMIC_selectSubBand(1) disables all channels outside sub-band 2 and leaves only channels 8–15 (125 kHz) and channel 65 (500 kHz) enabled. Without this call, LMIC will spread join requests across all 72 AU915 channels, and the TTN gateway will hear at most 1 in 8.

3. Copy credentials in the correct byte order:

MCCI LMIC expects APPEUI and DEVEUI in LSB order (least significant byte first — reversed from the hex string TTN shows by default). APPKEY is MSB order. The TTN console device overview provides separate copy buttons for LSB and MSB formats — use LSB for the first two arrays and MSB for APPKEY:

// APPEUI — LSB first (use the LSB copy button in TTN console)
static const u1_t PROGMEM APPEUI[8]  = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

// DEVEUI — LSB first (use the LSB copy button in TTN console)
static const u1_t PROGMEM DEVEUI[8]  = { 0xXX, 0xXX, 0xXX, 0xXX, 0xXX, 0xXX, 0xXX, 0xXX };

// APPKEY — MSB first (use the MSB copy button in TTN console)
static const u1_t PROGMEM APPKEY[16] = { 0xXX, 0xXX, /* ... */ };

Passing MSB-order bytes where LSB order is expected produces a device that joins successfully but appears to use incorrect session keys — data uplinks will fail to decrypt correctly at the application layer.

RadioLib

RadioLib (v5.x and later) includes AU915 as a built-in regional plan. The sub-band is specified as a 1-indexed value (sub-band 2 = 2):

#include <RadioLib.h>

// Replace with your SX1262 pin mapping
SX1262 radio = new Module(NSS_PIN, DIO1_PIN, RESET_PIN, BUSY_PIN);
LoRaWANNode node(&radio, &AU915);

void setup() {
    radio.begin();
    // subBand argument: 2 for TTN Australia (1-indexed in RadioLib)
    int16_t state = node.beginOTAA(joinEUI, devEUI, nwkKey, appKey, true, 2);
}

The RadioLib API has evolved across minor versions — verify the beginOTAA signature and sub-band parameter position against the changelog for your installed version. The examples/LoRaWAN/ directory in the RadioLib repository includes AU915 examples.

Testing the OTAA Join

After flashing, open the TTN console at your application → End devices → [your device] → Live data. Within 30–60 seconds of power-on, a correctly configured device should produce this sequence in the live data stream:

1. JoinRequest (uplink) — device transmitted the join request; at least one TTN gateway received it on sub-band 2. If you see this event, the radio, antenna, and channel selection are working.
2. JoinAccept (downlink) — the network server accepted the join and the device received the accept frame in its RX1 or RX2 window. This confirms the AppKey matched.
3. First data uplink — the device is joined and sending application data.

If the live data tab is empty after 2–3 minutes, work through these checks in order:

For field validation beyond the lab, TTN Mapper logs uplinks with GPS coordinates to produce a radio coverage map — useful for verifying gateway coverage at the intended deployment site before committing to a production design.

Chirpstack: Private AU915 Network Server

For industrial or enterprise deployments that require a private network server — dedicated capacity, no fair-use limits, local data retention — Chirpstack is the most widely deployed open-source LoRaWAN network server and supports AU915 natively.

Key Chirpstack AU915 configuration:

• In chirpstack.toml, define the region: [[regions]] name = "au915" ... using the AU915 regional parameter set.
• Configure each gateway's packet forwarder for the sub-band you have selected. For a private network you can use any of the 8 AU915 sub-bands — but end devices, gateways, and the network server must all agree on the same sub-band.
• Chirpstack supports the same OTAA/ABP flow as TTN; device registration follows the same key model (JoinEUI, DevEUI, AppKey).

For teams building LoRaWAN IoT products that require AU915 firmware integration, private Chirpstack deployment, or cloud data pipeline development, Zeus Design's software development team delivers the full stack from hardware bring-up through cloud connectivity — discuss your LoRaWAN project.

Design Considerations

• OTAA for all production deployments: OTAA derives fresh session keys per join, provides per-session replay protection, and lets the network server manage frame counters. ABP hardcodes session keys and resets the frame counter on reboot — which TTN's default frame counter check will silently reject, making the device appear to stop transmitting after a power cycle. Reserve ABP only for deployments where the two-message OTAA exchange genuinely cannot be supported.
• TTN fair-use policy: The Things Network Community is shared infrastructure. The fair-use policy recommends no more than approximately 30 seconds of total uplink air time per device per day. At SF9/125 kHz with a 20-byte payload, each uplink takes roughly 370 ms — giving about 80 uplinks per day before approaching the limit. Design reporting intervals with this constraint in mind; applications requiring higher uplink frequency should run on a private Chirpstack server rather than the shared TTN community network.
• Adaptive Data Rate (ADR): Enable ADR for fixed or slow-moving deployments. The TTN network server measures each device's SNR history and progressively reduces the spreading factor as the link quality allows, reducing time-on-air and extending battery life. Disable ADR for mobile devices (vehicles, assets in motion) where link quality changes faster than the ADR convergence time.
• Crystal tolerance: SX1262 and SX1276 LoRa ICs require a 32 MHz crystal or TCXO with ≤10 ppm initial frequency accuracy (per Semtech reference design). AU915 channel spacing is 200 kHz — a 10 ppm error at 917 MHz corresponds to approximately 9 kHz of frequency offset, well within the 125 kHz channel bandwidth. However, crystals with wider tolerance or significant temperature drift (untrimmed NX3225 crystals in the ±50 ppm range) can shift the transmitted frequency into the adjacent channel, particularly at temperature extremes. For crystal selection, load capacitor calculation, and the full SX1262 hardware design, see how do you design the hardware around an SX1262 or SX1276?.

Common Mistakes

• No sub-band selection in firmware: Leaving the default (all 72 AU915 channels enabled) distributes join requests across eight sub-bands. TTN gateways monitor only sub-band 2, so 7 out of 8 join requests land on channels the gateway isn't listening to. LMIC_selectSubBand(1) must be present in every firmware build targeting TTN Australia. If you upgrade the MCCI LMIC library, verify the call is still present and still uses index 1 — the sub-band numbering convention is 0-indexed in LMIC.
• LSB/MSB byte order confusion: The TTN console shows DevEUI and JoinEUI as a hex string in MSB order by default. MCCI LMIC requires these two arrays in LSB order (reversed). Copying the MSB hex string directly into APPEUI/DEVEUI produces credentials that look correct on screen but cause the join to fail with incorrect session key derivation. Always use the TTN console's explicit LSB copy button for APPEUI and DEVEUI; use MSB for APPKEY.
• Wrong TTN cluster: Creating an application on the EU1 (eu1.cloud.thethings.network) or Nam1 cluster and deploying AU915 hardware results in devices that transmit on 915 MHz but whose packets route to a cluster that has no AU915 gateways — the packets are dropped. Verify the application URL contains au1.
• ABP frame counter resets after reboot: ABP devices reset their frame counter to zero on every power cycle. TTN's replay protection rejects frames whose counter is lower than the last stored value. The symptom is a device that transmitted successfully on first boot but "stops working" after a reset or battery change. Switching to OTAA eliminates the problem; if ABP is unavoidable, enable the "Resets frame counters" option in the device's TTN console settings.
• Flashing EU868 firmware onto AU915 hardware: EU868 LoRaWAN firmware sets channels in the 863–870 MHz range. AU915 hardware (SX1262 in its standard configuration for the Australian market) can typically receive at 868 MHz but is not optimised for that band, and the transmissions violate the ACMA class licence for 915 MHz operation. Always verify the regional configuration (CFG_au915 for MCCI LMIC) before flashing hardware intended for Australian deployment.