I’m running the @xoseperez basicstation repo with the RAK5146 USB concentrator with the RAK2287 Pi Hat and it works great. Having said that i didn’t test the GPS/PPS.
The only thing you will need to do is to connect the micro-USB connector from the Pi Hat to the Raspberry Pi USB ports plus change the Device Variables to USB and the MODEL.
Check the notes here for more detailed information.
The RAK5146 distributes GPS and PPS internally and makes it available to the module, so the LoRa concentrator gets GPS and PPS signals. However, your basicstation / RPi will not if you connect it only by the means of the USB connector.
The GPS module connects via the UART Pins of the RPi as you can see on the hats description: RAK2287/RAK5146 Pi HAT Datasheet | RAKwireless Documentation Center
So if you plug in the Hat to the RPi, it will receive GPS data and coarse timing via the messages.
PPS signal is sadly kept internally to the RAK5146 and is not broken out to the GPIO pins.
If you’re good with a soldering iron you can grab it from pin 19 of the RAK5146: RAK5146 WisLink LPWAN Concentrator Datasheet | RAKwireless Documentation Center or - if you want a more easy way, you can grab it from the unpopulated module pad directly next to the GPIO pins on the Hat: https://docs.rakwireless.com/assets/images/wishat/rak2287-pi-hat/overview/RAK2287_buy.png
That pads were in the past for a Ublox (I think it was a M8Q) GPS module (in an older HAT model) and with that, the PPS pin is actually hot wired to the Pin 19 of the RAK5146 ;). So you can just measure out the right pin (I documented this in this thread above) and just jump it to a free GPIO pin. From that point on, your RPi will have coarse GPS signal and PPS signaling, so you can use it to have precise timing on your RPi for running an NTP server just next to the concentrator (so your RAK5146 will run double duty and not only give you awesome good access to LoRaWAN, but also to highly precise timing :))
The LBT functionality is implemented in the STM32 microcontroller on the USB versions of the RAK5146. That’s why it is not supported in the SPI versions since there is no STM32 in these, the SPI interface is wired directly to the SX1303.
Awesome info, does the LBT functionality need any software support/coordination from the host system to work or is this also completely taken care of by the STM32? (so basically is it “always on” or is something needed to be able to use it beside the USB version of the RAK5146?)
I don’t have a deep knowledge on how LBT works. But if you check the basicstation repo you can see that there is code in the HAL related to LBT, so I guess it’s kind of a join venture between the firmware on the module and the host 
Very cool thank you
Took me a while, but now they are there:
Designed myself the RAK11300 (RP2040 + SX126x) breakouts I wanted.
Their pinouts directly match the order of the normal BME680 and BME280 breakout boards, so its just a “slide and and replace” if needed. USB breakout can also be used to directly power the unit from 18650s. I could have done the boards much smaller, but I wanted to breakout all pins and have it in a handy but painless format. Auto programming from Arduino does not yet work, could be that I need to rework this - but at the moment I don’t mind. The workaround is to just to grab the .u2f file and drop it on the RP2040 manually. Works like a charm :). Now just need to write the appropriate code for the BME680s I want to deploy and finally get rid of the CubeCells “temporary” (… now serving a year or so :'D) setup on the breadboards 
Nice work @nmaas87! Any thoughts on the RP2040 power consumption? I love that RAK has a RP2040 based block, but for some reason I had assumed they were very power hungry.
Very good point. Yes, sadly RAK put all their work on top of the Arduino MbedOS Core instead of some actual good implementation of the RP2040, like Mr. Philhowevers excellent SDK. With that, the RP2040 wisblocks are useless for any kind of battery powered IoT application, as they do NOT support any kind of deepsleep, at least it looks like the MbedOS is missing this completly and RAK did not rework this fact.
I actually figured this out some weeks ago, tried to work around it and then threw the modules into the corner… I thought it was self-explanatory that an IoT module needs to have such features, but… well.
My idea was to just use the normal RP2040 SDK. However, there comes the SX1262 radio into play: Libs for this are quite rare. And if you find one, there is no current implementation for LoRaWAN functionality added.
The fun thing is that my actually plan (and I even got the components for that) was to build my own RP2040 and RFMxx (need to see what I got, I forgot :'D) LoRa “OnAModule” - even had the parts here, but bought the RAK11300 because I thought it to be a good product and loved the formfactor. If they just had added an SX1272 radio or similar, this would have been working right now with deepsleep… I should have learned that cutting corners will come in expensive in so many ways…
So, … no this product is currently a bad idea if you’re not planing on using a wallplug - but then again, you can use an ESP8266 or even ESP32 because this might still be cheaper and might have more power.
Hm… thats a bummer. I almost picked up a few with my latest order, because I was tempted by doing some rapid micropython tests (I know zero c++), but perhaps the RP2040 just isn’t ready for the LoRa space yet.
Meantime, did you see this? WisBlock Core Module | RAK3372 – RAKwireless Store
The marketing says “1.69 μA in sleep mode”
Also, I did just order a RAK7391 so I’ll share some experiments here.
I struggled for so long getting LTE working on CM4 base boards with Waveshare and the Oratek Tofu I shared above, so I’m excited to see if I have better luck with the 7391 as it has 3 mcpie ports
Yeah there was actually someone on RAKs Forums who tinkered around with the 11300 and Micropython - even writing some drivers for the radio, however, this seemed to was a one-off and the person than vanished. So it did not test it myself.
I don’t know if it was the RAK3372 - however, I saw some WisBlock with an STM32 (which this one has) and that should have better compability. It uses their own RUI3 framework - which is a RAK specific SDK. I must admit I am not sure how I feel about it. On the one hand, a unified framework for fitting different sensors into the same system / streamlining it makes absolute sense. On the other hand, I know not enough to understand how open and easy it would be to add non-RAK sensors to this overfall system. I was burnt quite often by going all vendor-lock so I try to avoid it as much as possible.
The RAK7391 looks really sick, I would love to play around with one of those puppies - and after the early kinks got ironed out of the RAK5146 I really learned to love that little guy. Maybe had one or two “please restart me” issues - which do not necessarily have to come from the module itself - but never the less, good stuff :).
I really need see, maybe at some point in time I might get an 7391 or so, would be an awesome base platform for my current satellite/LoRa developments and testing. But then again, I have no sponsor for this and getting all these Taxes again (including the high prices for the shipping, which will then also be taxed, because Germany…) - well… this might take a while ;).
But when you get the 7391, please post your experiences, I would be really interested in that beast
So, the RAK11300 journey continues. I finally got the first life out of it, using Arduino Pico and RadioLib - so completly without the RAK Arduino mbedOS environment. Took me quite some time behind the screen and even destroying one of the RAK11300s for working it under a microscope (and testing some stuff directly) - but we are slowly getting there
My trusty RPi 3 with RAK5146 and running on balenaOS is still my gateway and works like a charm
Blog Post on: RAK11300 Teardown / Getting to work with Arduino-Pico and RadioLib! | Nico Maas
Glad to read this! Thanks for sharing!
