RAK3172T in Arduino

Updated on 2024-12-01 with latest fixes of STM32LoRaWAN v0.3.0

As the RAK11300 did not really match my requirements (it uses way too much energy), I looked further and found the RAK3172 which is based on an STM32WLE5CCU6 - an STM32 chip which usually include good powersaving modes. As with the RAK11300, I did not want to go down the Wisblock way and designed my own breakout board:

This was actually not complicated as the RAK3172 has all needed components on board. I just added an H7333 LDO for powering it from 18650 cells and two additional features: First, the i2c port was aligned with the pinout the the usual BME280 breakouts from your typical websources - so that I could directly plug those in. Secondly, I made a solderbridge that allowed this i2c port to be 3v3 powered either directly by the LDO or by an port of the STM32. The later option I actually now use in normal operations, as this allows the system to really cut the BME280 from power so that it does not drain energy while the setup is in sleep mode / not actively measuring.

As core I wanted to go with the stm32duino Core as it already had the STM32WLE5CC supported. The only thing missing was the fact that I actually bought the TCXO enabled 3172T variant and this was not yet supported - and so I got my first PR on the stm32duino repo.

For the radio library I was thinking about chosing the RadioLib again and made a lot of research already on how to get it implemented, but at that time, RadioLib was working around their LoRaWAN implementation quite a lot - and shooting for a moving target was getting me nowhere, so I tried out STMs own implementation.

Update 2024-12-01
The following two paragraphs detail workarounds for issues with STM32LoRaWAN v0.2.0 which have been resolved for good three days ago with release of v0.3.0 and are thus only interesting in the historical context of me setting up those sensors initially in ~June 2024.

(Fixed with PR #47):
This did work out quite well, however, there is to this day a bug with the timers which prevents the chip from ever waking up again - a workaround for it is given in the issue in case you want to try it too ( calling rtc.begin(true) after modem.begin() makes it work! ).

(Fixed with PR #44 / #39):
I also had an additional issue, I left the RAK3172T sleep usually for 10 minutes, wake up, do a measurement and transmitting it back - then go to sleep again. This worked in my testing until 28 "wake-ups" - then on the next sleep, the chip would never wake up again. I am not sure what is causing this, but I went down the road of just counting the wake-ups and restarting the chip after the 24 or so, just to have a safe margin.

Again, this was not a project I spend too much time with, I just wanted something to replace my breadboard wired mess of two CubeCell HTCC-AB01 - which absolutly did not stay unchanged in place since a short test back in 2021 and were working like this ever since (and suffering from disconnect whenever looked at from a wrong direction ;))

So - yeah, if I were to have time I would probably look and test RadioLib support.

GeeekPi RPi 4G Hat for RAKwireless RAK5146 USB

In 2021 I started playing around with the SX1303 based RAKwirless RAK5146 USB LoRaWAN concentrator in mini-PCIe form factor ( 1, 2 ). Back at the time I used the RAK2287 Pi Hat which - even though the website states otherwise ("Note: RAK2287/RAK5146 Pi HAT is compatible only with the SPI version of the RAK2287 and RAK5146 LPWAN concentrators.") is actually compatible with the USB version of RAK5146. In the second post I even want so far to hack the RAK2287 and bridge the PPS (Pulse Per Second) output of the included GPS onto the RPi GPIOs so that I could turn the RPi into a precise GPS NTP server - and I even added an I2C/"poor-mans-QWIIC connector" to it.

While all these hacks were successful and the balenaOS backed RPi 3 LoRaWAN concentrator was still working (with regular updates) in 2024, I finally wanted to streamline my overall IT setup: I had an WD My Cloud Mirror Gen2 NAS I updated to Debian 11 in 2022, the LoRaWAN concentrator/NTP server/Room sensor RPi 3 and an very old Medion Laptop was I was abusing as the main "server" - it was time to unify those systems and move on.

Luckily, I had gotten a TuringPi 2 and Turing RK1 SBCs which were a powerful combination: My plan was to use one RK1 in Node 3 position on the TuringPi 2 which did give the SBC one NVMe slot, a PCIe attached Dual Port SATA bridge and the additional USB 2.0 port which could be switched to any Node on the board. With the RK1 as a way more powerful CPU (in contrast to the old AMD 1 GHz Dual Core on the Medion Laptop...) and the Dual Port SATA bridge I already got Server and NAS functionality solved. But what about LoRaWAN and the other functionalities?

Well, as I bought the RAK5146 USB (with LBT and GPS), I could just use the RAK2287 to plug a cable from the Micro USB cable into the additional USB 2.0 port of the TuringPi 2 - and this was done. However, what about the GPS and PPS input to allow for an NTP server? And did I really wanted to install the RAK2287 into an ugly box - or leave it open for further projects?

Thats when I realized I still had the GeeekPi RPi 4G Hat at hand, an RPi "Hat" I bought back then when I thought that might be the cheaper alternative, but went out of my way to also buy the RAK2287 and never really tested it.

The GeeekPi is just an ordinary hat, well - lets say it does not even has any connection to the RPi, just an USB C port - not even some GPIO connection - its basically just an "USB LTE Modem in mini-PCIe to USB breakout" in the shape of an RPi Hat.

Looking at the SIM Card Slot I had some mixed feelings and hoped that it would not interfere with the RAK5146 - so I rechecked the pinout:

Luckily it turned out that the RAK engineers thought about this and marked the SIM Card Slot connectors as NC/not connect. With this, this card could be inserted into any Laptops WWAN slot or an SBC like the balenaFin. Neat!

After the pinout situation was clear, there was just one thing left: Soldering the needed connections directly to the mini-PCIe connector:

The needed pins were GND, PPS, PI_UART_TX and PI_UART_RX which I broke out onto a 2.54mm female header and fixed them into place with a bit of hotglue as strain relief:

Then I just needed to add an FTDI USB UART to the mix and connect these pins:

  • GND to GND
  • PPS to DCD
  • PI_UART_TX to TX
  • PI_UART_RX to RX

Afterwards I just needed to install the RAK5146 and the LoRaWAN and GPS antennas before powering up the unit via the USB C port of the Hat and connect the FTDI UART USB as well.

And the end I also broke out the RESET_GPS and STANDBY_GPS pins just for good measure, but as they are active low I did not need to pull them to any potential. But then again, it could come in handy in the future.

With those changes I can now use the RAK5146 directly over an USB connection and still get the GPS data and PPS signal for use in gpsd. I ended up printing an enclosure for the overall construction, added an 4 port USB hub and connected one of my RAK11300 breakouts as a Meshtastic node and another Waveshare RP2040 Zero as an environmental sensor which terminates a BME280 and an Amphenol Telair T6713 CO2 sensor to measure the room climate. I also rewired the USB 2.0 Hub to an USB C connector and now everything has its place - and I still have my empty RAK2287 board lying around in case I where to get another RAK5146 for other jobs ;).

RAK11300 - Getting it to work with Arduino-Pico and RadioLib!

Intro

About a year ago I got some RAK11300 modules - which are a nice combination of an RP2040 alongside a SX1262 radio on one module - designed a breakout board - tested it - and quickly shelved it. Reason was that this module was somewhat Arduino compliant - as stated - however only with RAKwireless Arduino mbedOS Repo. Alongside of it being a bit... hacked together, it had the issue of not supporting any low power modes for the RP2040 - making it run on both cores at full tilt and consuming batteries in no time. Not the best thing for a portable/battery powered sensor system, I guess?

Some people tried already to get this RP2040 working with other software - e.g. Micropython or Arduino, but I never heard someone getting it working, so I tried my luck - this is the whole journey from start to finish. Spoiler, it is now working and you can find the example code at the end with Arduino-Pico and RadioLib now fully supporting this module :).

Pinout

The most important thing was trying to figure out the internal wiring of the RP2040 to the SX1262 - while RAK did not offer complete schematics, they at least revealed parts of it after asking in the forums :).

The antenna switch direction is controlled by the SX1262 itself through DIO2.
The antenna switch power is controlled with GPIO25
It uses an TCXO
uint32_t lora_rak11300_init(void)
{
    _hwConfig.CHIP_TYPE = SX1262;          // Chip type, SX1261 or SX1262
    _hwConfig.PIN_LORA_SCLK = 10;          // LORA SPI CLK
    _hwConfig.PIN_LORA_MOSI = 11;          // LORA SPI MOSI
    _hwConfig.PIN_LORA_MISO = 12;          // LORA SPI MISO
    _hwConfig.PIN_LORA_NSS = 13;           // LORA SPI CS
    _hwConfig.PIN_LORA_RESET = 14;         // LORA RESET
    _hwConfig.PIN_LORA_BUSY = 15;          // LORA SPI BUSY
    _hwConfig.RADIO_TXEN = -1;             // LORA ANTENNA TX ENABLE (e.g. eByte E22 module)
    _hwConfig.RADIO_RXEN = 25;             // LORA ANTENNA RX ENABLE (e.g. eByte E22 module)
    _hwConfig.USE_DIO2_ANT_SWITCH = true;  // LORA DIO2 controls antenna
    _hwConfig.USE_DIO3_TCXO = true;        // LORA DIO3 controls oscillator voltage (e.g. eByte E22 module)
    _hwConfig.USE_DIO3_ANT_SWITCH = false; // LORA DIO3 controls antenna (e.g. Insight SIP ISP4520 module)
    _hwConfig.PIN_LORA_DIO_1 = 29;         // LORA DIO_1
    _hwConfig.USE_RXEN_ANT_PWR = true;     // RXEN is used as power for antenna switch
#ifdef RAK11310_PROTO
    _hwConfig.USE_LDO = true; // True on RAK11300 prototypes because of DCDC regulator problem
#else
    _hwConfig.USE_LDO = false;
#endif

To sum up:

  • RP2040 connects to the SX1262 using SPI1
  • RP2040 has the same pinout/GPIO output as a generic Raspberry Pi Pico board
  • SPI1 however has its connections twisted a bit
  • SPI1 Pinout:
    • SCLK/CLK/Clock: GPIO 10
    • MOSI: GPIO 11
    • MISO: GPIO 12
    • CS/ChipSelect: GPIO 13
  • Additional lines needed for SX1262:
    • NRESET: GPIO 14
    • Busy: GPIO 15
    • DIO1: GPIO 29
    • RXEN: GPIO 25
  • LoRaWAN compliance is mentioned to be 1.0.2 specification compliant with Rev B, however I also saw mentions of 1.0.3 with Rev B

RP2040

To get this to work, you can take the legendary Earle F. Philhower's Arduino Pico repo, use the normal RPi Pico board and overwrite the SPI1 positions like so:

SPI1.setCS(13);
SPI1.setSCK(10);
SPI1.setTX(11);
SPI1.setRX(12);
SPI1.begin(false);

however, to make it easier I put up a PR to directly change those pinouts and integrate the RAKwireless RAK11300 proper into the arduino-pico framework.

SX1262

Lets get to the SX1262 library and the implementation of the LoRaWAN communication schema:
Luckily, Jan Gromeš, maintainer of the awesome RadioLib decided to implement LoRaWAN support - and the SX1262 modules. I tried to get everything working, however, there seem to be some minor issues. His library does detect the SX1262, however, I am not able to join TTN with it. The issue ticket is currently open here.

The most weird thing is still the GPIO 25 for me, the mentioned Antenna switch power. It might be all thats needed to put this port as output and put it on high to supply power whenever someone wants to receive/transmit - but I am not really sure yet. I have not found any evidence and I feel something with the join event in the RadioLib is still off as other people also saw issues - so there are probably two different problems right now.

Getting further

To understand the whole idea better, I opened up one RAK11300 and put it under the microscope. Sadly my microscope camera ain't really good, so the picture quality is a bit hit and miss, but as there are no pictures at all on the internet, I thought it might be useful for someone.

Some details:

  • Flash Chip is a Winbond 25Q16JVIQ (16 Mbit, should be 2 MB then?)
  • RP2040 is the usual RP2-B2
  • Semtech SX1262
  • Antenna Switch is a small 6 pin part with label 259 128, I not really found anything on the net, pinout looks a bit like that:
    GPIO25  | Antenna   |   DIO2(?)
                    259
                    128
*   VR_PA/RFO | GND     |   RFI_N/RFI_P

So it looks like the RP2040 PIN 25 could be really the "power supply" for that switch, while the DIO2 of the SX1262 would be changing the switch to either supply the RX or TX chains to the antenna output, however I am not that sure.

Photos

So, without anymore addition, here are the pictures, sorry for the bad quality.

If you have any infos to help on the quest, please let me know :).

Update to the Antenna Switch / GPIO25 (@2023-11-03 17:08)

Looking at the lora_rak11300_init, we can quickly find out that the GPIO 25 is used as power to the antenna switch, e.g. switching on the use of the antenna. Its important to see that TXEN=-1, so RXEN and TXEN are not used to determine the direction (e.g. if sending or receiving, but this is done by DIO2/directly by the SX1262 module. The use of RXEN/GPIO25 is purely for powering the Antenna switch:

    _hwConfig.RADIO_TXEN = -1;             // LORA ANTENNA TX ENABLE (e.g. eByte E22 module)
    _hwConfig.RADIO_RXEN = 25;             // LORA ANTENNA RX ENABLE (e.g. eByte E22 module)
    _hwConfig.USE_RXEN_ANT_PWR = true;     // RXEN is used as power for antenna switch
    _hwConfig.USE_DIO2_ANT_SWITCH = true;  // LORA DIO2 controls antenna

( https://github.com/beegee-tokyo/SX126x-Arduino/blob/fe6178f82d81e6509a5352f1d2aa85e433e19a7a/src/boards/mcu/board.cpp#L239C25-L239C25 )

If we dig a bit deeper, we will find the SX126xIoInit ( https://github.com/beegee-tokyo/SX126x-Arduino/blob/ca879479b25071c568ded9a60f7c060f10c7791a/src/boards/sx126x/sx126x-board.cpp#L49 )

    // Use RADIO_RXEN as power for the antenna switch
    if (_hwConfig.USE_RXEN_ANT_PWR)
    {
        if (_hwConfig.RADIO_TXEN != -1)
            pinMode(_hwConfig.RADIO_TXEN, INPUT);
        pinMode(_hwConfig.RADIO_RXEN, OUTPUT);
        digitalWrite(_hwConfig.RADIO_RXEN, LOW);
    }

This also shows that the GPIO25 is used only as antenna switch power and is configured as output, but still in "low" mode, e.g. the power switch is off.

In all instances of the Antenna used or the TX/RX channels ( SX126xAntSwOn, SX126xAntSwOff, SX126xRXena, SX126xTXena - https://github.com/beegee-tokyo/SX126x-Arduino/blob/ca879479b25071c568ded9a60f7c060f10c7791a/src/boards/sx126x/sx126x-board.cpp#L496-L555 ) we can see that the GPIO25 is pulled high, e.g powers on the Antenna Switch - and powers down after sending. It does not make a difference if TX or RX is needed, its always HIGH/ON when the antenna is used and LOW/OFF when its not. Probably to preserve energy. So basically, we would need to always set GPIO25 as output and pull it high when we need to use the module.

Update to RadioLib (@2023-11-03 20:29)

I got TTN working, however Chirpstack proved to be difficult. Reason was the error "ERROR chirpstack::uplink: Deduplication error error=Unknown data-rate: Lora(LoraDataRate { spreading_factor: 7, bandwidth: 125000, coding_rate: “4/7” })" reason for that was that RadioLib accidently tries to drive EU868 packets with 4/7 instead of 4/5 coding rate - so these packets are thrown away right away ( https://forum.chirpstack.io/t/error-unknown-data-rate-on-eu868-with-coding-rate-4-7/16109 ). I made a PR ( https://github.com/jgromes/RadioLib/pull/865 ) to fix that issue. There is also an error in the LoRaWAN example as handled by this PR ( https://github.com/jgromes/RadioLib/pull/866 ). With that we can finally join TTN and Chirpstack v4 servers! What is still a problem, is re-connecting: Trying to restore a connection ends with an issue -1101 in RadioLib, seems to be what was described beforehand in https://github.com/jgromes/RadioLib/issues/858. Lets see if we find something. Other than that, its looking so much better already :)/

Update to RadioLib (@2023-11-04 16:25)

  • The issue with the restore of the connection is now also solved, it was an issue with the "software" EEPROM on the RP2040 and has now been fixed by a PR ( https://github.com/jgromes/RadioLib/pull/868 ).
  • The switching of the Antenna Switch can be done as such (kudos also to Jan from RadioLib for pointing it out :))
    static const uint32_t rfswitch_pins[] = { 25, RADIOLIB_NC, RADIOLIB_NC };
    static const Module::RfSwitchMode_t rfswitch_table[] = {
    {MODE_IDLE,  { LOW }},
    {MODE_RX,    { HIGH }},
    {MODE_TX,    { HIGH }},
    END_OF_MODE_TABLE,
    };
    (...)
    radio.setRfSwitchTable(rfswitch_pins, rfswitch_table); // must be called before begin!
    radio.begin();
  • There is currently a big PR from StevenCellist ( https://github.com/jgromes/RadioLib/pull/867 ) being put together which will make everything a lot better - I tested it and now the RAK11300 is fully working!
  • Currently still working on getting my PR for the RAK11300 included in the arduino-pico, but we are getting there 🙂

Update to RadioLib (@2023-11-12 14:02)

RadioLib has accepted the PR and the needed commits are now in the main branch.
Both RadioLib and Arduino-Pico have not yet posted a new release version, so if you want to use the tech right now, you need to install the current main git branches.

Update to Arduino-Pico (@2023-11-22)

Earle has now released arduino-pico 3.6.1 which does include my contribution and adds the RAK11300 as its own board to his awesome Arduino Core ( https://github.com/earlephilhower/arduino-pico/releases/tag/3.6.1 ). You can download it right now via the Arduino Board Manager. So we just need for the latest RadioLib to drop :).

Update to RadioLib (@2023-11-29)

Jan has now pushed RadioLib 6.3.0 which includes all changes and fixes to support the module 🙂 ( https://github.com/jgromes/RadioLib/releases/tag/6.3.0 ). I am thinking about putting up a finale example to use it and then this project to support the RAK11300 directly via Arduino will be finished.

Full Example / Closing thoughts (@2023-12-01)

Following full example shows all magic needed to use RAK11300 with the Arduino-Pico 3.6.1 (using either the standard Raspberry Pi Pico or the RAKwireless RAK11300 as board setting) and RadioLib 6.3.0. It was kind of quite a ride and I am very pleased with this working now, finally. Thanks a lot for all that helped make this a reality. All the best 🙂

/*
  RadioLib LoRaWAN End Device Persistent Example

  This example assumes you have tried one of the OTAA or ABP
  examples and are familiar with the required keys and procedures.
  This example restores and saves a session such that you can use
  deepsleep or survive power cycles. Before you start, you will 
  have to register your device at https://www.thethingsnetwork.org/
  and join the network using either OTAA or ABP.
  Please refer to one of the other LoRaWAN examples for more
  information regarding joining a network.

  NOTE: LoRaWAN requires storing some parameters persistently!
        RadioLib does this by using EEPROM, by default
        starting at address 0 and using 384 bytes.
        If you already use EEPROM in your application,
        you will have to either avoid this range, or change it
        by setting a different start address by changing the value of
        RADIOLIB_HAL_PERSISTENT_STORAGE_BASE macro, either
        during build or in src/BuildOpt.h.

  For default module settings, see the wiki page
  https://github.com/jgromes/RadioLib/wiki/Default-configuration

  For full API reference, see the GitHub Pages
  https://jgromes.github.io/RadioLib/
*/

// include the library
#include <RadioLib.h>

// RAK11300
// SX1262 on RAK11300 has the following connections:
// pin name       pin number  pin mnemonic (RAK11300 board in arduino-pico)
// SPI1 NSS/CS:   13          PIN_SPI1_SS
// BUSY/GPIO:     15          PIN_SX1262_BUSY     
// RESET/RST:     14          PIN_SX1262_NRESET
// DIO1/IRQ:      29          PIN_SX1262_DIO1     
// RXEN/swpwr:    25          PIN_SX1262_ANT_PWR  
// SPI1 CLK:      10          PIN_SPI1_SCK   
// SPI1 MOSI:     11          PIN_SPI1_MOSI  
// SPI1 MISO:     12          PIN_SPI1_MISO

// RAK 11300 setup of SX1262 Radio
SPISettings spiSettings(2000000, MSBFIRST, SPI_MODE0);
SX1262 radio = new Module(13, 29, 14, 15, SPI1, spiSettings);

// RAK11300 setup of RF switch configuration
// powers up RF switch when modules wants to send or receive data
static const uint32_t rfswitch_pins[] = {25,  RADIOLIB_NC, RADIOLIB_NC};
static const Module::RfSwitchMode_t rfswitch_table[] = {
  {Module::MODE_IDLE,  {LOW}},
  {Module::MODE_RX,    {HIGH}},
  {Module::MODE_TX,    {HIGH}},
  END_OF_MODE_TABLE,
};

// create the node instance on the EU-868 band
// using the radio module and the encryption key
// make sure you are using the correct band
// based on your geographical location!
LoRaWANNode node(&radio, &EU868);

void setup() {
  Serial.begin(9600);

  // RAK11300 set SPI1 ports correctly
  SPI1.setCS(13);
  SPI1.setSCK(10);
  SPI1.setTX(11);
  SPI1.setRX(12);
  SPI1.begin(13);

  // RAK11300 add RF switch configuration to radio
  radio.setRfSwitchTable(rfswitch_pins, rfswitch_table);

  // initialize SX1262 with default settings
  Serial.print(F("[SX1262] Initializing ... "));
  int state = radio.begin();
  if(state == RADIOLIB_ERR_NONE) {
    Serial.println(F("success!"));
  } else {
    Serial.print(F("failed, code "));
    Serial.println(state);
    while(true);
  }

  // first we need to initialize the device storage
  // this will reset all persistently stored parameters
  // NOTE: This should only be done once prior to first joining a network!
  //       After wiping persistent storage, you will also have to reset
  //       the end device in TTN and perform the join procedure again!
  // Here, a delay is added to make sure that during re-flashing
  // the .wipe() is not triggered and the session is lost
  // delay(5000);
  // node.wipe();

  // now we can start the activation
  // Serial.print(F("[LoRaWAN] Attempting over-the-air activation ... "));
  // uint64_t joinEUI = 0x12AD1011B0C0FFEE;
  // uint64_t devEUI = 0x70B3D57ED005E120;
  // uint8_t nwkKey[] = { 0x74, 0x6F, 0x70, 0x53, 0x65, 0x63, 0x72, 0x65,
  //                      0x74, 0x4B, 0x65, 0x79, 0x31, 0x32, 0x33, 0x34 };
  // uint8_t appKey[] = { 0x61, 0x44, 0x69, 0x66, 0x66, 0x65, 0x72, 0x65,
  //                      0x6E, 0x74, 0x4B, 0x65, 0x79, 0x41, 0x42, 0x43 };
  // state = node.beginOTAA(joinEUI, devEUI, nwkKey, appKey);

  // after the device has been activated,
  // the session can be restored without rejoining after device power cycle
  // on EEPROM-enabled boards by calling "restore"
  Serial.print(F("[LoRaWAN] Resuming previous session ... "));
  state = node.restore();
  if(state == RADIOLIB_ERR_NONE) {
    Serial.println(F("success!"));
  } else {
    Serial.print(F("failed, code "));
    Serial.println(state);
    while(true);
  }

}

// counter to keep track of transmitted packets
int count = 0;

void loop() {
  // send uplink to port 10
  Serial.print(F("[LoRaWAN] Sending uplink packet ... "));
  String strUp = "Hello World! #" + String(count++);
  String strDown;
  int state = node.sendReceive(strUp, 10, strDown);
  if(state == RADIOLIB_ERR_NONE) {
    Serial.println(F("received a downlink!"));

    // print data of the packet (if there are any)
    Serial.print(F("[LoRaWAN] Data:\t\t"));
    if(strDown.length() > 0) {
      Serial.println(strDown);
    } else {
      Serial.println(F("<MAC commands only>"));
    }

    // print RSSI (Received Signal Strength Indicator)
    Serial.print(F("[LoRaWAN] RSSI:\t\t"));
    Serial.print(radio.getRSSI());
    Serial.println(F(" dBm"));

    // print SNR (Signal-to-Noise Ratio)
    Serial.print(F("[LoRaWAN] SNR:\t\t"));
    Serial.print(radio.getSNR());
    Serial.println(F(" dB"));

    // print frequency error
    Serial.print(F("[LoRaWAN] Frequency error:\t"));
    Serial.print(radio.getFrequencyError());
    Serial.println(F(" Hz"));

  } else if(state == RADIOLIB_ERR_RX_TIMEOUT) {
    Serial.println(F("no downlink!"));

  } else {
    Serial.print(F("failed, code "));
    Serial.println(state);
  }

  // on EEPROM enabled boards, you can save the current session
  // by calling "saveSession" which allows retrieving the session after reboot or deepsleep
  node.saveSession();

  // wait before sending another packet
  // alternatively, call a deepsleep function here
  // make sure to send the radio to sleep as well using radio.sleep()
  delay(30000);
}

LoRaWAN with RAKwireless RAK5146: The SX1303 in the field, a rocky start

Setting the scene

Working with the guys over at balena comes with some perks - including the peer pressure of getting into new technologies and trying them out. My go-to person this time was balena Developer Advocate Marc Pous - who is not only no stranger to soldering - but also deeply rooted in the LoRaWAN field (and he is also doing balenaHub projects for LoRaWAN applications 1, 2).

I heared about LoRaWAN a while back, when I was working with Sigfox - but never really gave it a try, other than trying to run a basestation for a certain satellite using LoRa for its communication.

This changed through Marcs constant LoRa presentations and work - I just gave in and wanted to try it. I had already three projects at hand: One was getting some BME280s into a network (because due to 2.4 GHz spectrum hell induced by too many neighbours with too many WiFi APs cranked to 11 using WiFi with ESP8266 did not work anymore...). This project would be the "first hello-world" to maybe be allowed to deploy a network in my company to care for our sensors - and lastly, strapping LoRa technology to a rocket and see whether we can muster the about 250 km+ downrange.

But things start small, so I wanted to get into the field with best-in-class technology - and the latest available products (especially thinking about ultra-long communications like on my last usecase). Luckily, the new Semtech SX1303 came to market 8 months ago and RAKwireless decided to make their first concentrator on its base, the RAKwireless Wislink RAK5146 - and I wanted to be an "early adopter".

Wrong expectations

If I am getting into a new product, I am used to finding a certain amount of good documentation, software and support. I must admit that I was really spoiled with my latest endeavors using Paul Stoffregens excellent Teensy series (loyal customer since Teensy 2.0/2010 ;)), some new STM32s and also NVIDIAs Jetson lineup.

So I went into this whole project with wrong expectations, as RAKwireless had made a ton of useful stuff available already for their older systems like the RAK2287 - and I thought everything would be in place for the new system as well, which was wrong.

I started the project more than a month ago and at that time not even a real firmware was available. The only project I found was this Github Repo - which could not even install for my RAK5146 USB because someone forgot the chmod +x on the install script, which gave a bad first impression regarding how tested this official project would be - and I was not disappointed, as I had to try to figure out how to get it working with TTN - because the important step (after the installation was done) to changing the server address in the configuration file - was not included in the setup instructions, so my gateway never connected.

Also, no RPi Hat was available - which brought me into looking for own solutions, which I found in an USB WWAN adapter card to be stacked onto the RPi.

A last thing which was confusing, especially with trying to figure out how to connect everything were the Pinout and Blockdiagram. I remind you, there are 6 different configurations of the RAK5146:

  • SPI (always without LBT)
    • with GPS
    • without GPS
  • USB
    • with LBT
      • with GPS
      • without GPS
    • without LBT
      • with GPS
      • without GPS

Both the Blockdiagram and Pinout for all these variations were handled in one graphic. While one could handle the block diagram, the pinout is just confusing. Which Pins are actually on the card using the USB version with LBT and GPS? What is going on with the SPI pins? Are they not even routed?

I tried to use my new TTNv3 gateway with Heltec Cubecells - and while I got it working, there was just unreliable data transmission and huge packet loss.

I must admit, I went to this project with wrong expectations - because I saw the RAK5146 now freely available on RAKwireless shop - thinking it should be another product like the RAK2287 - but that was wrong. It seems to be a product which is firstly marketed towards huge OEM customers - and not for the hackers at heart.

Moving forwards

To try to get this issues resolved, I wrote a bunch of PRs and Issues on the Github repo and documented my findings on balenas Forum. Luckily, those comments did not fall onto deaf ears and the situation improved:

RAKwireless worked in enhancing the documentation of the RAK5146 - but sadly the Blockdiagram and Pinout is still in the same state. Also, no quickstart guide was added.

Thanks to Taylor there is now a firmware package made available, which can be downloaded from the RAK5146 page.

Regarding the documentation on using it, this is not available yet. Please stick to the RAK2287 Quickstart guide. You can set it up as "RAK Gateway LoRa Concentrator" for TTN like shown there - but need to edit the packet-forwarder config afterwards (see the main menu of gateway-config) and replace the "server_address": "router.us.thethings.network" with your things network router (e.g. eu1.cloud.thethings.network in Europe TTNv3). You should then restart the Gateway / Forwarded. In adding it to the TTNv3 stack, the Quickstart guide is a bit outdated. You can still find out the EUI of your gateway using gateway-version and use this for adding it to TTNv3, but please be careful not to choose the frequency plan "Europe 863-870 MHz (SF9 for RX2 - recommended)" - but the RX2 SF12 option to improve the signal quality.

I still have problems with bad performance - and the helpful Jose Marcelino decided to send me a RPi Hat for switching out my contraption, which should improve quality. However, after waiting a month I have not yet received this Hat yet and could therefore not test.

Also Xose Pérez did try to help and I am grateful for both of them trying to resolve the situation and getting the RAK5146 also working in the hands of power users.

After all, it looks like an extremely capable platform - and I would really like to see it performing accordingly.

What is next?

Even though the start was a bit rocky, I want to continue working on this project - after all, my room sensors need some LoRa, as well as my other projects - and when these issues are resolved, thr RAK5146 looks like a good offer. I will report back on my blog with updates - and wait for the RPi Hat which hopefully will resolve the issues - or helping me pin down the issue, if it were to be somewhere else.