@nmaas87 I just got myself the RAK adapter HAT. Have it up with the 5146 on a pi4.
Maybe I’m confused but did you get it to work with the rak hat?
1 Like
Hey @barryjump when I started working with the RAK5146-USB, no infos were available that you can use with a RAK2287 HAT, so I got myself a non RAK WWAN hat (see above) and started working with that. I got some reliability issues (a lot of dropped LoRa packets with my cubecells as testing platform) and @jmarcelino and @xoseperez offered support and to send me a hat to test with that. But I am still waiting on that shipment.
@mpous I was using your basicstation repo. Although I only ever got the RAK2245 working.
I just discovered the Seeed WM1302 which offers a US915 USB version. Which seems promising… But before I make another module purchase I want to be more confident it would work in the Fin mpcie slot.
Have you seen this? Any thoughts? They have a USB (EU868) version as well…
1 Like
Hi there, some new updates 
- I hope you’re all fine and had some downtime in form of christmas and new years: Belated happy everything 
After finally executing a huge project at work - I freed up some nerves to get back to the drawing board… um… SX1303 front - and got some results.
Own shield vs RAK2287 Pi Hat
Rakwireless / Jose has been silent since the offering of the RAK2287 Pi Hat, which never arrived at my place, I found a single offer for that board in my neighborhood and bought it to finally get over with it. It is still curious that the websites still state that it is only for RAK2287 SPI and RAK5146 SPI - and no other board revisions. But you can easily insert a RAK5146 USB - you additionally will need to connect the Micro USB connector on the Hat with your RPi / Fin to get it working. This does work in the same way as my own WWAN hat, but will also connect the GPS to your RPi. Funnily there seems to be some kind of error in the RAK5146 packet forwarder / firmware because the GPS coordinates are not sent up to TTNv3. I have not tried to use this GPS connection for a NTP sync - but I guess this would be no joy anyway: RAKwireless did not connect the PPS pin of the M8Q GPS module to the hat. I know this pin is internally used by the concentrator card - and also broken out on the mPCIe connector on pin 19 ( RAK5146 WisLink LPWAN Concentrator Datasheet | RAKwireless Documentation Center ) - so I am really wondering why they did not break if out via the hat - as it would have been extremely useful.
Also, I am a bit sad that the documentation for RAK products is still not on par with industry leading companies like Seeed Studio, but I hope that will be fixed in some time? A big reason why I am wondering is that e.g. on the Pi Hat, both buttons and USB interface are not described on the wiki - and the usability of the RAK5146 USB is stated to be a no-go. This just confuses customers (like myself and other guys and gals in this thread) - so… please fix that?
Maybe I will modify my WWAN hat, add a breakout for the GPS UART and PPS pin as well as the other needed pins to get a version of the hat that I could use to make my LoRaWAN concentrator also an NTP server without an additional GPS module. Another idea would be to add a second USB uart to add the GPS TX/RX and maybe PPS (via DTR?) to a PC via USB. With that I could make the board totally USB connected and useable with GPS and PPS to any computer or SBC - regardless of GPIO pins. That would be great for debugging purposes or using it as a ground station for LoRaWAN long-distance experiments on flying platforms (read: rockets).
RAK5146 quality
In regards of quality, after the RAK5146 got it’s own firmware package, usability went up as well as the quality of connections. Does not matter whether I use the USB WWAN or official hat, it does work great. I would still love to see it getting the same kind of polish and regular updates like the RAK2287.
First client
I finally finished my first ESP32 powered client. Nope, ESP32 is probably the worst idea for a small, battery powered LoRaWAN client - but for a first PoC it is awesome. You do not have to think about resources (be it CPU, RAM, flash or pins) and you can power and program it easily via USB.
I used it with an RFM95W LoRa module, which are easily available via… all your online shops.
Arduino and the Arduino-LMIC Lib for LoRaWaN: GitHub - mcci-catena/arduino-lmic: LoraWAN-MAC-in-C library, adapted to run under the Arduino environment
However, there is a problem with ESP32: Making arduino-lmic competible with arduino-esp32-2.0 - gitmetadata
Error about multiple definition of hal_init
I suggest you add #define hal_init LMICHAL_init in your LMIC project config or on the PlatformIO command line where you define other LMIC options.
That option resides in libraries\MCCI_LoRaWAN_LMIC_library\project_config\lmic_project_config.h
Also you need to change some other stuff there, here is mine for use in EU868 and with RFM95W on an ESP32:
// project-specific definitions
#define CFG_eu868 1
//#define CFG_us915 1
//#define CFG_au915 1
//#define CFG_as923 1
// #define LMIC_COUNTRY_CODE LMIC_COUNTRY_CODE_JP /* for as923-JP */
//#define CFG_kr920 1
//#define CFG_in866 1
#define CFG_sx1276_radio 1
//#define LMIC_USE_INTERRUPTS
#define hal_init LMICHAL_init
You wire if up like so / main idea:
But here are my used connections:
GND: GND
3.3V: 3.3V
DIO0: 2
DIO1: 13
DIO2: 4
Reset: 14
NSS: 5
SCK: 18
MOSI: 23
MISO: 19
And the resulting pin-mapping for the LMIC lib:
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 5,
.rxtx = LMIC_UNUSED_PIN,
.rst = 14,
.dio = {2, 13, 4},
};
I used the ttn-oota example - and that worked great, together with an BME280 sensor.
Actually - BME280 sensors are gotten damn expensive. Like sometimes 20 bucks, if you even get them anymore in china or similar. Even te BME680 are cheaper right now… weird!
Next steps would be to shrink down the design with some power efficient chip. I like the ATTNode idea ( ATTNode v2 | ATTNode ) very much and ordered some BME680s as sensor for my rooms. I also already gotten some HT7333 ( https://www.angeladvance.com/HT73xx.pdf ) with which I hope to be able to directly power some small LoRaWAN nodes via 18650 cells, due to the extreme low drop out voltage and quiescent current of these LDOs
Ht7333:
Range voltage: 12 v
Max current out: 250 mA
Quiescent current: 4 uA
Drop out voltage: 170 mV
vs, e.g. the “normal” 1117
AMS1117:
Range voltage: 12 v Max
Max current out: 1 A
Quiescent current: 5 mA (!)
Drop out voltage: 1.3 V (!)
(awesome list by lucasromeiro here: Ultra Low Power Consumption (ideal regulator) - Everything ESP8266 )
So, still a lot of work to do, but finally on the right track. And even with my indoor antenna in a “non-LoRaWAN area” of cologne (meaning no LoRaWAN gateways at all, even though in a industrial area) - I am having a single client connecting to my TTNv3 gateway multiple times a day:
Hi there - whoever you are :D!
I think this is it from my side for the moment, cheers!
Nico
1 Like
I got SOME time, Marc, not THAT MUCH time 
- but serious question - I think I read somewhere you got it already working with the RAK5146 USB? Is that true - and if so - can I test it ?
1 Like
Another update, this time regarding the HelTec HTCC-AB01 - I was trying to use two of these with my Gateway since I started working with it. However, there were lots of problems and only the fairly old version (0.0.7) seemed sometimes to work. It would authenticate with TTN and then basically “die”. The reason was now found out by 1rabbit - the EU868 and US915 versions of the HelTec LoRaWAN libs had the wrong preamble size all along: 0.0.7 last working version with LoraWAN and HTCC-AB01 · Issue #195 · HelTecAutomation/CubeCell-Arduino · GitHub
His patch got my problems solved and now they are working like they should [ 0.0.7 last working version with LoraWAN and HTCC-AB01 · Issue #195 · HelTecAutomation/CubeCell-Arduino · GitHub ] - so if you’re in the 915 Mhz or 868 Mhz business and yours are broken - thats probably the reason. HelTec has not yet reacted to this and not incorporated the changes - so you need to patch your libs youselves.
hey @nmaas87 the amazing @xoseperez made this packet forwarder from the RAK common for gateway and i think you might try it with your SX1303 
1 Like
Hey thanks for the heads-up. I had the RAK5146 running for the last 9+ days and it worked out so far.
Sounds like a fun weekend project, I wanted to modify the RPi Hat anyway and add PPS functionality to the RPi to re-use the GPS for a precise NTP server. So I might do this at the same time. But I don’t know if I’ll manage this weekend. (I will however put this info into my “Snooze this Tab” addon, so it will pop-up on saturday evening :D)
As for LoRaWAN: I am currently testing how long the battery lifetime of my HTCC-AB01 / BME280 nodes with the Ht7333 LDO and a single 18650 cell are - but thinking about creating my own nodes on base of the naked RP2040 chip - because the chips are available and cheap (actually ordered them on monday and they arrived this morning from the USA :D). But I will need to create a new PCB design and let it manufacture and want to learn some new tools on the way, so this will take probably this year 
1 Like
I put the changes as PR into @xoseperez main repo to allow any building at all @ balena.
( I guess his Docker Image is still private, as it gives me some authentication errors on trying to pull - so I added the option of manually building it and decreased the docker-compose version to ‘2’ (not docker-compose-v2, but the 2.0 format) so that balena build servers will be happy - along with some very small changes.
I now added a deploy with button and balena.yml file on: GitHub - nmaas87/udp-packet-forwarder: UDP Packet Forwarder for Docker
I am currently trying to deploy my RAK5146 with Hat with those variables set over the deploy mechanism
- CONCENTRATOR: “SX1303”
- INTERFACE: “USB”
- HAS_GPS: “1”
- HAS_LTE: “0”
- RESET_GPIO: 0
- RADIO_DEV: “/dev/ttyACM0”
- GPS_DEV: “/dev/ttyAMA0”
- GATEWAY_EUI: “MyEUIObviously”
- TTN_REGION: “eu1”
- BAND: “eu_863_870”
… and it worked 
Feel free to clone and improve upon it
PS:
One should remove these variables before deploying the service if one does not want to use a FakeGPS
- GPS_LATITUDE: 0
- GPS_LONGITUDE: 0
- GPS_ALTITUDE: 0
1 Like
@mpous FYI, GitHub - lorabasics/basicstation: LoRa Basics™ Station - The LoRaWAN Gateway Software just released v. 2.0.6 with support for USB concentrators (sadly LBT not yet included) but I think that should be of use for your fleet?
1 Like
@xoseperez repo has now run for one week on my RPi 3 without any issues. I now updated my repo to reflect his latest changes and improvements while retaining the belana Deploy functionality.
2 Likes
Great.
I just updated my basicstation docker repository compiled against latest basicstation code v2.0.6. It adds:
- Support for USB concentrators based on SX1302/SX1303 (RAK2287 or RAK5146)
- Support for amd64/x86_64 hosts
- Support for multiple radios per device (16-channel gateways? several sectorial antennas?)
You can check the repo here:
4 Likes
Very nice, I really have to read into the difference between Basicstation and the udp-packet-forwarder, but as far as I understood, Basicstation is much more sophisticated as the “dumb” forwarder.
Never the less, I will update my forwarder fork later on
1 Like
This is terrific! Nice work @xoseperez and @nmaas87.
I might have missed the answer, but @mpous does this mean I’d be able to use my USB RAK5146 in the Fin’s mpcie slot with Xose’s updates? 
2 Likes
Thank you, since yesterday evening @xoseperez commited my PR for the udp-packet-forwarder, so you directly could use that via balena Deploy: https://github.com/RAKWireless/udp-packet-forwarder
You can use it with the USB RAK5146 in the Fin’s mpcie - however, no GPS will be available (only timing information as they are sent on the concentrator card, but not the coordinates - this will only be able via the RAK2287 Pi Hat).
Also @xoseperez has the Basic Station up which should also work, but I think no balena deploy available yet. Both support the RAK5146 USB now.
1 Like