Nasty OTAA connect
After getting basic connectivity for my RAK811 LPWAN Evaluation Board(EVB) and Fezduino test rig working. I wanted to see if I could get the device connected to The Things Network(TTN) via the RAK7246G LPWAN Developer Gateway on my desk. I had got the EVB configuration sorted with a nanoFramework device so I was confident it should work.

My Over the Air Activation (OTAA) implementation is very “nasty” I assumed that there would be no timeouts or failures and I only send one BCD message “48656c6c6f204c6f526157414e” which is “hello LoRaWAN”
I configured the RAK811 module for LoRaWAN
// Set the Working mode to LoRaWAN txByteCount = serialDevice.Write(UTF8Encoding.UTF8.GetBytes("at+set_config=lora:work_mode:0\r\n")); Debug.WriteLine($"TX: work mode {txByteCount} bytes"); Thread.Sleep(500); // Read the response rxByteCount = serialDevice.BytesToRead; if (rxByteCount > 0) { byte[] rxBuffer = new byte[rxByteCount]; serialDevice.Read(rxBuffer); Debug.WriteLine($"RX :{UTF8Encoding.UTF8.GetString(rxBuffer)}"); } ...
Then just sequentially step through the necessary configuration to join the TTN network with a suitable delay after each command is sent.
// Set the Region to AS923 txByteCount = serialDevice.Write(UTF8Encoding.UTF8.GetBytes("at+set_config=lora:region:AS923\r\n")); Debug.WriteLine($"TX: region {txByteCount} bytes"); Thread.Sleep(500); // Read the response rxByteCount = serialDevice.BytesToRead; if (rxByteCount > 0) { byte[] rxBuffer = new byte[rxByteCount]; serialDevice.Read(rxBuffer); Debug.WriteLine($"RX :{UTF8Encoding.UTF8.GetString(rxBuffer)}"); } // Set the JoinMode txByteCount = serialDevice.Write(UTF8Encoding.UTF8.GetBytes("at+set_config=lora:join_mode:0\r\n")); Debug.WriteLine($"TX: join_mode {txByteCount} bytes"); Thread.Sleep(500); // Read the response rxByteCount = serialDevice.BytesToRead; if (rxByteCount > 0) { byte[] rxBuffer = new byte[rxByteCount]; serialDevice.Read(rxBuffer); Debug.WriteLine($"RX :{UTF8Encoding.UTF8.GetString(rxBuffer)}"); } // OTAA set the devEUI txByteCount = serialDevice.Write(UTF8Encoding.UTF8.GetBytes($"at+set_config=lora:dev_eui:{DevEui}\r\n")); Debug.WriteLine($"TX: dev_eui: {txByteCount} bytes"); Thread.Sleep(500); // Read the response rxByteCount = serialDevice.BytesToRead; if (rxByteCount > 0) { byte[] rxBuffer = new byte[rxByteCount]; serialDevice.Read(rxBuffer); Debug.WriteLine($"RX :{UTF8Encoding.UTF8.GetString(rxBuffer)}"); } ...
The code is not suitable for production but it confirmed my software and hardware configuration worked.
The thread '<No Name>' (0x2) has exited with code 0 (0x0). devMobile.IoT.Rak811.NetworkJoinOTAA starting TX: work mode 32 bytes RX :UART1 work mode: RUI_UART_NORAMAL Current work_mode:LoRaWAN, join_mode:OTAA, Class: A Initialization OK TX: region 33 bytes RX :OK TX: join_mode 32 bytes RX :OK TX: dev_eui: 45 bytes RX :OK TX: app_eui 45 bytes RX :OK TX: app_key 61 bytes RX :OK TX: confirm 30 bytes RX :OK TX: join 9 bytes RX :OK Join Success TX: send 43 bytes RX :OK TX: send 43 bytes RX :OK
In the Visual Studio 2019 debug output I could see messages getting sent and then after a short delay they were visible in the TTN console.

I had some issues with TimeSpan.ToString(…) throwing a CLR_E_UNSUPPORTED_INSTRUCTION exception which has been mentioned on the GHI Forums.
I had to modify my code to fix this issue
Debug.WriteLine($"{DateTime.UtcNow:hh:mm:ss} Join start Timeout:{JoinTimeOut:hh:mm:ss}"); // Became Debug.WriteLine($" {DateTime.UtcNow:hh:mm:ss} Join Start Timeout {timeout.TotalSeconds} seconds");
I won’t bother with confirming any other functionality as I’m reasonably confident the nanoFramework library (which this code is based on) is working as expected.