Summary of the Issue:
I have developed a custom LoRaWAN Network Server from scratch using Java. This server correctly processes OTAA Join-Request messages from two different devices (a Wisol-based module and a Heltec LoRaWAN node), but the devices never successfully join the network.
After an extensive debugging process, I have confirmed that the issue lies in the HT-M02 gateway’s failure to transmit the Join-Accept downlink packet that my server sends to it.
Key Facts & Evidence:
-
Both devices and the HT-M02 gateway work perfectly with The Things Stack (TTS). This confirms that all hardware (gateway, devices,
antennas), device keys (AppKey, NwkKey), and the physical RF environment are functioning correctly.
-
My server successfully validates Join-Request uplinks. Server logs consistently show that the MIC (Message Integrity Code) of the Join-
Request is validated successfully, and a new session (DevAddr, session keys) is stored in the database.
-
My server sends a standards-compliant txpk JSON object to the gateway. By analyzing gateway logs from a successful join on TTS, I have
reverse-engineered the txpk JSON object for the Join-Accept message. My server now generates a txpk object that is virtually identical to the
one sent by TTS, targeting the RX1 window.
Here is an example of the txpk JSON object my server sends to the gateway:
Generated json
{
“txpk”: {
"imme": true,
"freq": 922.300000,
"rfch": 0,
"powe": 14,
"modu": "LORA",
"datr": "SF12BW125",
"codr": "4/5",
"ipol": true,
"ncrc": true,
"size": 33,
"data": "..."
}
}
Analysis of the Problem:
Despite my server sending this well-formed txpk command, the gateway does not appear to transmit the RF signal. The devices never receive the Join-Accept, time out, and send a new Join-Request, creating an endless loop.
Since the gateway hardware is proven to work with TTS, this strongly suggests a subtle incompatibility or a requirement for a non-standard parameter in how the HT-M02’s specific Packet Forwarder firmware interprets the txpk JSON from a non-TTS server.
My Questions for Heltec Support:
To resolve this issue, I kindly request your assistance with the following:
-
Is there any known incompatibility or specific txpk JSON parameter requirement for the HT-M02 gateway (firmware version [if you know
the version, insert it here]) when receiving downlink commands, especially for OTAA Join-Accept messages?
-
Does the HT-M02 Packet Forwarder require any specific fields in the txpk object beyond the standard ones (e.g., preamble, a specific
powe value, or other vendor-specific fields)?
-
Are there any known issues with the TX/RX switching mechanism when an uplink on SF12 is immediately followed by a downlink command
on SF12 for the Join-Accept?
-
Could you provide a definitive, complete example of a txpk JSON object that is guaranteed to trigger a Join-Accept transmission on the
HT-M02 for the KR920-923 region plan?
This issue has been a significant roadblock, and any technical clarification you can provide would be immensely helpful. We have successfully developed a fully functional LoRaWAN server, and this final gateway compatibility issue is the only thing preventing us from moving forward.
Thank you for your time and assistance.