Rak811 Tracker Board

Tried, and tried and re-tried - there is a pin mapping incorrect in the core setup which i need to pass on, but i just cant get past it freezing - tried those interrupt fixes, I will post some finding I found here over the next few days

I have not checked myself but is ARDUINO_ARCH_STM32 defined when using Arduino_Core_STM32?

The RAK811 Tracker Board is a board with RAK811 module with additional sensors and GPS.
The RAK811 module internally contains a STM32 MCU and SX1276.
The RAK811 tracker board definition in the Arduino_Core_STM32 core contains pin definitions for both the SX1276 inside the module and for the sensors and GPS on the board (external to the module).

Do you know of any documentation (other than Arduino_Core_STM32) where the internals of the RAK811 module and its STM32/SX1276 pin mappings are described?

I would like to be able to use the Arduino core with a RAK5205 tracker board.
Do you know if the RAK5205 Tracker Board is identical to the RAK811 Tracker Board (just a name change), or would a new board definition need to be created for the RAK5205?

I believe the RAK5205 is still build around the RAK811 module - but the tracker boards are not identical at all, the core RAK811 module is the same in terms cpu/lora bits so I think it will have the same issues I am having with the older tracker board

55%20PM

2 Likes

It’s strange that multimeter’s display indicates uA while the the selection switch appears to be in the temperature measurement position. :thinking:

switch%20versus%20display

that’s a great achievement ! :+1:

@ bluejedi
could be the knob out of position on this Chinese multimeter :sunglasses:

Sure, but the “out of position” issue makes one validly question the reliability of the measurement.

I have already seen big annoucement from RAK saying that they provide low power nodes (eg annoucing their new RAK5205 tracker going down to 14uA).

The measurements I have done and documented to RAK show a power consumption of 1.5mA and they did not provide any feedback or answer.

So for me, I will pass.

with their latest firmware ?? I doubt it because it’s a beta

with their latest firmware ?? I doubt it because it’s a beta

All the information are in the link to the post I have done in their forum.
But the answer is no, not with their latest beta firmware.

They have announced that their RAK5205 tracker node can go down to 14uA.
It is written in their datasheet and clearly mentionned in their aliexpress shop

https://www.aliexpress.com/item/WisTrio-LoRa-Tracker-RAK5205-is-built-on-SX1276-LoRaWAN-modem-with-low-power-micro-controller-STM32L1/32957226407.html?spm=a2g0w.10010108.1000001.12.4f482061ZH0N8d

So far, the product is not inline with the spec and no explanation or feedback from RAK has been provided since end of March.

So when RAK is announcing a new beta firmware being able to reach low power, I have a trust issue with that.

But I really hope that I am wrong

just try it… that wouldn’t hurt ?
If I have a product and the manufacturer comes with a firmware update, that improves the product, I install it… :sunglasses:

I have completed your sentence :smiley::smiley:

If I have a product and the manufacturer who demonstrates interest into answering their customer feedback comes with a beta firmware update, that supposedly improves the product , and plenty of time, I install it…

I spent too much time and effort on their products. I will eventually start again once it is really confirmed that they can achieved low power operations.

just released the V3.0.0.1 version firmware for RAK811:
https://downloads.rakwireless.com/en/LoRa/RAK811/Firmware/
and the new document:
https://downloads.rakwireless.com/en/LoRa/RAK811/Application_Notes/

In this version, we add the LoRaP2P mode.
You can see what’s the difference in the ChangeLog file:
https://downloads.rakwireless.com/en/LoRa/RAK811/Firmware/RAK811_ChangeLog.txt

2 Likes

Hello,
i have old WisNode board with STM32L151CB (not STM32L151CB-A)
Flash size 128K but RAM only 16K (from 20000000 to 20004000)
So RUI_RAK811_V3.0.0.3.H.bin can’t start because stack pointer set to 20008000.
Also SysTick timer not disabled on jump from bootloader to application.
Can RAK developer publish source codes so i can change for my strange RAK811 ?

P.S. If i change 20008000 to 20004000 firmware works.

You’ve asked that

Yes but no answer

This is a monster thread.
I have had limited success with the 811 breakout, the wisnode and now the 5205. I am trying to move to the Arduino core in PlatformIO. I have been using ESP32s with no issues, but the RAK stuff is putting up a fight. Are any of you using OSX and able to push code to the RAK devices from PIO? I have a micro usb using SLAB_UART as well as an ST-Link. If you have a working platformio.ini I would love to check it out.

Thanks!

Great to see RAK did finally release working set of code with Arduino support - works perfectly.

I did have to add LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100); //Relax RX timing window to sort receive and join issue.

I know its an old board but it did annoy me that we could never get past the old os_init() crashes.

Obviously a lot of code has changed since its launch so I’m unsure if its the Arduino board support, lmic updates or minor main.ino code changes from RAK that has fixed the old issue.

My setup is VS Code, PlatformIO 5.0, all latest libraries out of the box - all working with OTAA :slight_smile:

Finally I can put my boards to use :+1:

1 Like

Did that 1% work without also setting LMIC_ENABLE_arbitrary_clock_error in the library’s Arduino/libraries/MCCI_LoRaWAN_LMIC_library/project_config/lmic_project_config.h file? (MCCI LMIC may have set that correction to 0.4% instead.)

1 Like

Not tested much more at the moment, I wanted to backtrack on my code and find what they had changed (I suspect its the board support) but in the end I jumped to their sample code and needed to add LMIC_setClockError as the join was hanging, I’ve not had time to do any more as I was not expecting any working code.

Yes it did work basic tests, join, uplinks and a few ack downlinks too - all fine, did not use LMIC_ENABLE_arbitrary_clock_error