After much trial and error, I couldn’t get a RAK2305 WisBlock Wifi Interface Module running the .NET nanoFramework plugged into the IO Slot of RAK5005 Base Board to send RUIV3 AT Commands to a RAK4631 Module.
When I requested the version information with “AT+VER=?” the RAK4630 Module did not respond with version information.
I reviewed the schematics of the RAK2305 WisBlock Wifi Interface Module, RAK5005 Base Board and RAK4630 Module
The RAK2305 WisBlock Wifi Interface Module has the TX0 pin is connected to pin 11, RX0 is connected to pin 12, TX1 pin (Gpio.IO21) is connected to pin 34, and the RX1 pin (Gpio.IO21) is connected to pin 33 of the IO Slot connector (crossover TX & RX).
On the RAK5005 Base Board the RAK2305 WisBlock Wifi Interface Module is plugged into the IO Extension Slot (BTB40_F) with TX pin 33 and RX pin 34.
The RAK4630 Module is plugged into the CPU slot (BTB40_F) of the RAK5005 Base Board with TX pin 33 and RX pin 34. The RAK4630 Module UART2_TX pin is connected to 33, and the UART2_RX is connected to 34 on the CPU slot.
I then read the RAK4630 AT Command documentation to see if I could enable AT Commands on the second serial port

I tried AT+ATM which didn’t work, and I had to reflash the device to get the UART0(USB port) to work. The TXD0 & RXD0 on the RAK4630 Module & RAK2305 WisBlock Wifi Interface Modules are connected by the RAK5005 Base Board. The .NET nanoFramework uses TXDO & RXD0 for debugging so I couldn’t connect to the first serial port on the RAK4630 Module
I had a look at the RAK4360 RAK Unified Interface (RUI) code to see if I could modify it so UART1 responded to AT Commands but I’m not certain this would work.
This is a longish post about failure, it took many hours to explore all the different approaches which was way longer than I should have spent. For why see “sunk cost fallacy”












