Hello,
We are considering the RAK3172 for our new product. However it seems to be missing some very important AT Commands.
For example, the AT Command to put the device to sleep and to wake the device up.
Also AT Commands that can configure the UART to be faster and have parity bits.
Could you clarify why those commands aren’t in the AT Command Set?
Thanks!
Jacky
Welcom to RAK forum @jackyruth 
RAK3172 has no sleep command. After transmitting or receiving LoRa/LoRaWAN packets, it will automatically sleep on its own.
UART change of configuration is not supported (yet). Are these configuration critical on your application. Can you share me the rationale and so I can forward it to the R&D.
We use the LoRaWAN radio to schedule events. Its important that the device receives the right event time and event actions. With the default 8/N/1 UART configuration, the data could be corrupted and they host MCU wouldn’t know about it correct?
Thats why we want some parity bits, we want to make sure what the host MCU receives is the correct data
Hi @jackyruth , I understand now where you are coming from. I already forward the concern to R&D.
For now as alternative since we do not support parity bit (yet), probably you can implement your own checksum (even just a simple XORing) to ensure the integrity of the data that you need.
That requires custom firmware correct?
Do we use the RUI and the DFU tool to accomplish this? That leads to another question I have, is it possible to upgrade the firmware via the terminal so we can automate RAK Module Flashing?
Thanks!
@jackyruth , you are right. A custom FW is needed for the checksum. RAK3172 is not based on RUI V2. It is a new FW that supports LoRaWAN v1.0.3. RUI V2 is compatible for LoRaWAN v1.0.2.
Btw, I got a reply from our R&D and said that different UART settings will be supported by RUI V3. But it is still under development and not schedule release yet.
If you do not want a custom FW, you can probably include the checksum on the payload. Then check the checksum on the javascript decoder on the LoRaWAN Server. However, this only ensures payload and not the whole AT commands. Might still be a good solution.
Thanks for the info.
Since LoRaWAN application payload is a “premium space” we’ll look into implementing CRC into UART via RUI v2 on the RAK4270 instead.
Cheers!
How long does it take to go into sleep mode? How long does it take to wake-up?
I presume it wakes upon receiving a command.
There no command to change baud rate.
We like to use 115,200 baud.
9600 baud is way too slow.
I have no specific timing (in msec) when sleep is activated. I can have a look.
Sadly 115200 is not supported and 9600 seems to be a speed of the past. But with the RUI V3 being developed for RAK3172, UART settings will be configurable.
But very very very reliable - particularly if you are using Software Serial - no problems syncing at that speed and, particularly important, time for the module to wake when you start talking to it - no multiple AT commands required.
And as none of the strings being sent are much more than a few dozen characters, it’s not exactly holding back a device - particularly if your TX & Rx buffers are ~64 bytes each and leave the MCU to do the transfer.
Just my 2c
The LoRaWAN data for most regions is not coming in much faster than the UART baudrate. 
Unless you run LoRa P2P and go to 500kHz.
Regarding how long does the unit before its sleeps and wake up.
Here’s a screenshot of current consumption using Power Profiler Kit 2.
You’ll see that every after each command, the unit goes to sleep immediately.
This is one of the advantages of RAK3172 compared to other WisDuo modules.
Hi Carl,
Yes it seems very fast.
Your time scale is too short to say just how fast.
You need better resolution, is it 10ms or 1ms or 50ms?
Wake-up time seems fast also.
Of course with a sleep command it typically only takes a few ms anyway.
If the sleep time in the ms range than it would very advantages to save energy,
while waiting for commands from the eternal MCU.
Thank you
Frank
Um, the whole graph is showing 1 minute and the lines look pretty vertical to me - I haven’t seen any recent reference code that doesn’t know what’s coming next - transmit join request, sleep for 4.994s, wake for preamble, receive, sleep, wake for send, sleep for 4.994s, wake for preamble, open Rx1, it even shows it sleeping between between the Rx1 window & Rx2 window.
I’m using 4.994s for the 5.1ms for SF7 detection, the module will know when to wake for reception as it’s all built in to the Semtech LoRaMAC-node.
Given that RAK is pretty much dedicated to LoRaWAN so know about these things, what else have you seen that performs better or worse on STM32WL55? Have you tried the NUCLEO-WL55JC board from ST? The Nucleo and TTI GNSE both show similar results to the above, the first obviously uses the ST reference code, the second is an implementation of the reference code.
The only real way you are going to know if it fits your needs is to invest the full $6 in a module to try it out!
And as @carlrowan has provided the core source with implementation guide, you can take the hardware and tweak the firmware sleep to what ever suits:
Hi Nick,
We use the module in P2P mode exclusively.
Why can’t you just change the parameters and get better time resolution?
Having used the RAK811 and integrating it into our firmware take a considerable effort.
Timing for for our application is important.
We discovered several major bugs with RAK811, some of these caused the module to hang.
For example if TX and RX UART coincided the module would hang.
Occasionally the module just stopped responding with certain commands
The only way out a hard reset.
Fortunately these are rare.
No timing information is published at all by RAK.
This we had to determine experimentally.
Yes buying the $6 module is easy enough.
It will take days or weeks figuring out how the the module responds etc.
I guess if you use existing libraries in LoRaWan mode it might be easier.
But we don’t use that mode.
We have to rewrite our module interface firmware to use that module
The craziest thing RAK decided use to 9600 baud default (!@#$%^&*())
What were they smoking?
And you can’t change it.
I would be MUCH MUCH simpler if they used 115,200 baud default
thank you
Well this changes the context somewhat, as @beegee noted, the numbers are radically different now.
Well mostly because I’m not @carlrowan or a staff member, just a groupie. And I prefer the Microchip Power Debugger on my desk over the PPK2 which is in a box somewhere but is definitely better than the STM Power Shield, oh the irony.
Same for everyone, the STM32WL55 in relative terms is brand spanking new - no one has more than a couple of months experience with any commercial variation of the chip, from ST or anyone. That is assuming they have managed to get their hands on any, I started out with 433MHz ones as I could get two and nothing else at the time.
If you’ve got the RAK811 under control, you don’t have to rewrite anything.
But you can follow the link above to download the difference files and use the official ST STM32Cube MCU, you’ve got access to the ST point to point code that you can put on the modules.
It’s early days for the module, they have to start somewhere. Taking the Cube code base and getting up & running with an AT interface that suits your need wouldn’t be a big job for you - couple of days tops.
