RAK3172 RUI3 baudrate change

LPWAN Modules / EVBs RAK3172
1

Hello,
I noticed today in the documentation for the RAK3172 that the default module baud has changed FROM 9600, TO 115200. I am wondering why that happened? Was there a specific reason? I am very concerned about it due to 115200 being too fast for some software serial communications. One of the nice parts of the RAK3172 over the RAK4200 was that I could simply add it to a board.
I may have to change the pin mappings for a board now and loose my valuable serial port (used for an LTE module) :frowning:
Will new modules being shipped contain the v3 RUI? or will they continue to use the previous version and only be updated by users if they choose???

Thank you,
-Kevin

2

Hi @Kevin192291 ,

Thank you for giving your feedback. We value and appreciate that.

Regarding your concerns, let me share some insights.

  1. 9600 baud rate is fine and the de facto standard for a long time. But microprocessors and microcontrollers can now handle 115200 easily and the time difference is important to some users that is running on tiny batteries. In the beginning, we prefer to use 115200 even on the old firmware (not RUI3 yet) but we got some power consumption related issues unless we set to 9600. But this was solved now in RUI3. However, please note that even 115200 is default, you can still set it to 9600 if you need.
  2. Regarding losing serial port, are you losing serial port of the host MCU or serial port of RAK3172? There are two useable UART in RAK3172.
  3. All modules will have RUI3. We will stop developing on the legacy firmware. But we try are best to make it backward compatible. We have a bigger team now under RUI3 and also it is compatible to our new WisDuo modules.

Btw, have you tried using RAK3172 with RUI3 API via Arduino IDE?

3

Hello carlrowan,
I looked at the RUI3 API really quick, though, I believe if I re-flash the RAK3172, it will void the TELEC certification and I will not be able to sell the product that contains the module. Also, I am sure my program is too large :frowning:

I can cut the board traces, and re-wire to a serial port.
I did this with a few boards, I am now worried that something bigger is wrong as I keep getting timeouts, and it seems as if the RAK3172 forgets the DevEUI, AppEUI, and AppKey. I don’t think I am resetting them in code, Before on the previous fw I thought I had a guarantee that these settings were set and forget. (perhaps it has to do with the cut traces???)

I am wondering if the RAK3172 is intended for production products? or is this just a dev board?

Thanks!
-Kevin

4

Hi @Kevin192291 ,

The RAK3172 is designed to work for production. Saying that, we are serious in fixing any bugs our customer find.

I am not sure about TELEC certification though. There are certifications that as long as the Radio parameters are not changed, there will be no need for re-certifications.

With the timeouts, did you update your RAK3172 FW from v1.0.4 to RUI3? If yes, the parameters you set will be lost.

5

I see, I am very happy to hear the chip is for production!!! :smiley:
The 3172 seemed to loose the settings between power up/down(specifically when I connected/disconnected a battery). I think someone else had mentioned this as well. My work around was to re-init the app/dev eui and app key at powerup.
I have since updated to the latest fw, and I am waiting to see if I see this again.

6

Are you using AT commands with external host MCU or the RUI3 APIs?

7

External MCU and I am using simple serial AT commands

8

What is the output of AT+VER=?

If I understand it correctly, you designed your host to just send AT+JOIN command since you already configured the DEVEUI, APPKEY and APPEUI right? Or you are not sending AT+JOIN at all and depend on auto join? But suddenly joining fails?

9

I am manually sending the AT-JOIN when the app is ready, I am not using auto join.

Really, I only send 2 commands AT+JOIN AND AT+SEND I MANUALLY SET THE AppEUI and AppKEY once using a simple serial forwarder flash when I get the new boards, but then flash my primary app afterwards and never again mess with the “set” settings

10

Sorry, I just realized you asked me the version: AT+VER=? gives me: AT+VER=3.2.0-p2_22q1_final.87

11

I suggest you update to the latest firmware and see if the issue will still persist :+1:

1 Like
12

Hello @carlrowan !
I seem to have run into the problem again. The issue seems to not only clear out the Devices EUIs but the the class, band, and work mode as well!
Nothing happned to the device, it simply sat on my desk for a few days. The current FW version I am running is:

AT+VER=?
AT+VER=3.4.2-rui3_22q1_update.112
OK

Any idea why this may still be occurring???

My current workaround is on every boot, set the values:

awaitResponse("AT+DEVEUI=XXXXXXXXXXXXX", "OK");
awaitResponse("AT+APPEUI=XXXXXXXXXXXXX", "OK");
awaitResponse("AT+APPKEY=XXXXXXXXXXXXX", "OK");
awaitResponse("AT+NWM=1", "OK");
awaitResponse("AT+NJM=1", "OK");
awaitResponse("AT+CLASS=A", "OK");
awaitResponse("AT+BAND=8", "OK");

I am scared I will quickly hit the write limit of the chip though.
I could check to see if these values are alerady set… but battery live is a imprtant.
I don’t see why these values are now being replaced with all zeros.