Added support for RAK3401 + RAK13302 (RAK WisMesh 1W)

[Carl-McCoy]

Support for RAK3401 MCU with RAK13302 PA

Not ready to merge

https://store.rakwireless.com/products/wismesh-1w-booster-starter-kit

This is the first thing I've done involving platformio or RNode firmwares and I don't know what I'm doing.
Hopefully someone can spot any obvious issues here.

Firmware builds and is stable so far with atterman's latest filesystem commits.

    -DURTN_PATH_TABLE_MAX_RECS=25
    -DRNS_DEFAULT_ALLOCATOR=RNS_HEAP_ALLOCATOR
    -DRNS_CONTAINER_ALLOCATOR=RNS_HEAP_ALLOCATOR

Note to self: Clean/Update PlatformIO lib imports of microReticulum and microStore when merging changes.

Issues

• Provisioning after the firmware upload fails; Restarting board and provisioning manually works with the below commands.

  rnodeconf --product 10 --model 14 --hwrev 1 --rom /dev/ttyACM0
  rnodeconf --firmware-hash `rnodeconf -L /dev/ttyACM0 | grep "actual firmware hash" | awk '{print $7}'` /dev/ttyACM0`
  

• Currently matching the MeshCore setup, only using one SPI bus
  This should be fixed to allow use of GPS etc. on the second
• NFC pins left undefined

Uncertainties

1 ) Boards.h / platformio.ini - Not sure what the best method is to define the IDs, but this looked okay reusing 0x10 and incrementing. I'm still unsure where the BOARD_RAK3401 ID is used.

 #define PRODUCT_RAK4631     0x10
 #define BOARD_RAK4631       0x51
 #define MODEL_11            0x11 // RAK4631, 433 Mhz
 #define MODEL_12            0x12 // RAK4631, 868 Mhz
 #define BOARD_RAK3401       0x52 // RAK3401 + RAK13302 (nRF52840 + SX1262 + SKY66122 1W FEM)
 #define MODEL_13            0x13 // RAK3401 + RAK13302, 433 MHz
 #define MODEL_14            0x14 // RAK3401 + RAK13302, 868 MHz

2 ) boards/rak3401.json isn't/shouldn't be required and using 4631.json works. I had issues making it work again, left as 3401 board and variant for now.
I'm not sure what the right way to add the variant is, but tried a few, settling on this setup when it packaged with the rnode_firmware_rak4631.zip filename needed for rnodeconf.

3 ) Provisioning when uploading worked once that I saw. Unsure if it's a timing issue on startup (occasionally requires a reset and provisioning within the next ~5 seconds) or the platformio.ini board / variant settings

[attermann]

Great work on this @Carl-McCoy . I actually received a couple of these kits recently and looking into adding support. Where are you at with this PR? It says it's a WIP. Anything else you'd like to add before I merge it?

[Carl-McCoy]

Great work on this @Carl-McCoy . I actually received a couple of these kits recently and looking into adding support. Where are you at with this PR? It says it's a WIP. Anything else you'd like to add before I merge it?

Thanks! Everything I've tested works between two of these and two heltec v4s.
There was a small change for bluetooth needed to build successfully for the recent update.

I'd appreciate some opinionated input, if there's a way to improve the auto-provisioning (you need to reset the board after flashing and set the firmware hash/model).
(It has only just clicked, that I should probably test with 0x51 as the board model and still use 13 and 14 for the model if I want to try using rak4631 as the board model in platformio.ini)

Some 15001s just arrived and are connected on SPI A, but I haven't increased the path storage to test yet. I wanted to check whether any changes are needed for these and to see if auto-detection is possible but haven't had time yet.

[attermann]

Thanks! Everything I've tested works between two of these and two heltec v4s. Want me to submit it as a patch or flatten it? There was a small change for bluetooth needed to build successfully for the recent update.

If you have an updated PR that would be fine. A lot has changed recently and there's a merge conflict anyway so I may have to cherry pick parts.

I'd appreciate some opinionated input, if there's a way to improve the auto-provisioning (you need to reset the board after flashing and set the firmware hash/model). (It has only just clicked, that I should probably test with 0x51 as the board model and still use 13 and 14 for the model if I want to try using rak4631 as the board model in platformio.ini)

I tried just loading the rak4361 build onto mine knowing full well the radio wouldn't work, and it seemed to provision fine. I'll be able to give better advice once I've had a chance to make a legit build, but I suspect we're going to be fighting with rnodeconf which tends to only like to work the boards it knows about. It may be balking at the new unknown board ids.

Some 15001s just arrived and are connected on SPI A, but I haven't increased the path storage to test yet. I wanted to check whether any changes are needed for these and to see if auto-detection is possible but haven't had time yet.

I'll be testing that as well. Auto-detection logic is in and works with rak4631 but could need to be tweaked for rak3401. I've heard about potential conflicts too between the rak13302 and other external SPI modules because they have to share the same SPI bus, so we'll see.