In our applications we use exclusively P2P and having to deal with a extremely slow baud is a HUGE bottle neck for us. 9600 baud is 12X slower than the standard of 115200 baud. RAK811 is 115200 and modules from other manufacturers are also 115200 baud. To boot, it is fixed, you can’t even change it. It should power-up at 115200 baud. For example transferring 64 bytes payload (128 characters) plus command is about 160 characters. would take close to 200ms. vs. 14ms with 115200. For battery applications this is a killer. The slow baud rate also limits how many packets the module can handle especially with bigger payloads. Indeed using the fastest possible bit rate 62,500 bps this is 6.5X slower the UART baud rate.
Hi @frank_r ，We are very sorry for the inconvenience caused by the baud rate.Setting the baud rate 9600 because we used the LPUART, which used the LSE, the upper limit of the baud rate 9600, and LPUART could wake up the MCU from the sleep mode.
Thank you very much for your suggestion, we ignore the rate problem, I will add 115200 in the next version of the firmware, and can switch the baud rate through the AT instruction, between 9600 and 115200.
Thanks for the reply.
Its important that the part boot up at 115200.
The RAK811 boots up at 115200, you can change it to 9600.
RAK811 wakes-up from sleep at 115200.
Daniel, has baud rate been changed to 115200 yet? Else we can’t use this part.
In practice the real limiting factor would be the bitrate of LoRa radio, which (accounting for framing, and unless you are unusually using 500 KHz channel bandwidth) tends to be lower, even before considering regulatory limits on radio channel duty cycle.
Daniel’s earlier point about wakeup behavior is an important one, especially in the sort of usage pattern these types of devices are designed to be used for. At a low baud rate, there’s time for the UART to detect line activity and wake up the chip sufficiently to read the first byte transferred. At a higher baud rate, there’d need to be some other wakeup paradigm, like an explicit “attention” line or perhaps having a wakeup interrupt on the UART RX line, but having a rule where the sender has to blip that line low as a GPIO then wait a define period of wakeup allowance time before sending any UART data.
If you want to maximize performance for an unusual application case, you may want to look at running your firmware and the LoRaWAN stack together on the same MCU, either by starting with the ST cube example that targets this hardware, or by doing something for different hardware.
Well, if we use the RAK811 way.
The module goes to sleep and wakes-up up by detecting activity on RX line.
The MCU sends any character.
We don’t use LoRaWAN, P2P exclusively.
The slow baud is a huge bottleneck.
Getting the data out of the module at 9600 baud 128 bytes is 133ms with no gaps.
More like 200ms with the gaps between the characters.
For a battery powered application this is 200ms wasted.
NO we don’t want to lock ourselves into a module.
Using that MCU.
The Lora module should default to 115200, and changeable.
9600 baud is totally not usable for us . PERIOD.
Maybe for you, but not for most users.
This is primarily a LoRaWAN device, intended to infrequently send and even less frequently receive quite short messages, with an emphasis on low standby power consumption since it’s the kind of thing that sleeps for 20 minutes and wakes up for a few fractions of a second over a period of 5-6 seconds.
If you want something odd, you may just have to implement suitable firmware yourself.
This is how the RAK811 works.
Intended for the exact same market,
Indeed ALL other manufacturers use 115200 baud as a default.
Having a 9600 baud rate uses more power, not less.
The module needs to be on 12X longer to get data in or out on the UART.
We don’t don’t be burdened with maintaining firmware in the radio module.
This defeats the point of the module.
Abusively yelling about things is unproductive, and will be removed.
In terms of actual technical tradeoffs,
You are only looking at one part of the issue, and ignoring the other part.
For most users using the module as intended, a small fraction of a second occurring only once every few minutes and accompanied by the much more power costly actual usage of the radio, is really no cost at all.
In contrast, lower power consumption while asleep is very key, but comes at the cost of a slower wakeup process, which needs either a distinct wakeup trigger with a gap before the actual serial data, or a slower baud rate.
This module’s firmware is really designed and optimized for a different usage than you are looking for - it can do custom LoRa schemes, but it’s really designed for LoRaWAN usage where it would primarily transmit short messages infrequently with very long sleep periods in between.
You’ll always have more flexibility for unique usage when you run your own firmware directly against the radio, either on the CPU in this module, or on that in your own. For your rather unique use case, I’d agree that 9600 baud is on the slow side, which is why your needs are the textbook example of a situation where you really want your own firmware, rather than a serial command one that’s optimized for the quite different sleep/wake pattern of a LoRaWAN node.
Aesthetically, I also dislike the idea of 9600 baud even for LoRaWAN, but after looking at the tradeoff in detail, it’s actually the better choice - I’d call your attention to section 3.6.9 of the STM32WLE5xx data sheet which documents the exact baud rate limit for the LSE-clocked wakeup mode of the LPUART as already explained, and section 5.3.8 which gives wakeup times from stop mode which would be hard pressed to capture the first bits of 115200 baud traffic without a framing error, unless a faster oscillator were left on (costing power) or some other pre-wake scheme were used. Each chip which could be used in a product such as this offers its own unique sets of tradeoffs - an improvement in one area has a cost in another, and one doesn’t always agree with the designer’s choices.
The LPUART wakeup is a clever enough solution to a problem I recently faced on an other project that I’m going to keep it in mind for a future strategy, since it allows getting a very low power sleep without needing to impose any particular behavioral rules on the interacting code.
I totally disagree with you.
Sleeping has got nothing to do with baud rate sir.
It’s more of waking up issue.
Hi @frank_r ,
There is a new FW going to be released and I am updating now the documentation. You can upload this latest FW using RAK DFU Tool (for the .bin file) or STM32CubeProgrammer if you want to upload the .hex file with bootloader.
Currently, you can switch to 4800, 9600 or 115200.
Btw guys, I hope we can all be civil in this public forum and avoid using capital letters. It might cause misinterpretations on the ideas you want to share
What is the default power-up baud rate?
Sounds like 9600??
In my application it needs to boot up at 115200 baud.
Yes. The default is still 9600.
Is the new baud rate stored in FLASH?
If the module is power cycled, does it start at 9600?
Yes. It will start on the newly configured baud rate.
So if you set it in production as 115200, that will be the new baudrate and not the default 9600.
Does the OK message appear at 9600 or 115200 baud?
All behaviors are the same. But if you are changing the baud rate, the settings won’t take effect unless you restart the device via
ATZ or power recycle.