Woohoo! The RAK5146 in the Fin’s mpcie is a game changer for me.
Only thing is I’ll need to use Basicstation as I’m running on AWS’s LoraWAN LNS which does not support packet-forwarder.
I’ll try to test this weekend and share the results here.
I just saw @xoseperez repo has the deploy button, but it is pointing to @mpous Basicstation repo which - as far as I know - does not yet support the new changes (please correct me Marc if am wrong :)) - but you could just try to use Xoses Repo via balena cli or similar. But yeah, let us know how it goes - I never did really use basicstation and at some point I want to upgrade - but was just happy to finally got the udp-packet-forwarder thanks to Xoses and RAKs work.
Arg! @nmaas87, just fixed the deploy button on the basicstation repo.
@barryjump RAK5146 USB works with basicstation now so you will be able to use it on the Fin. Also, latest version allows to easily configure CUPS mode in case you need it for AWS. Almost all concentrators by RAK should work on both the UDP packet forwarder and Basicstation. Exceptions with basicstation:
- RAK2247-USB will not work since basicstation does not support USB on SX1301
- RAK833-USB/SPI will only work in SPI mode for the same reason (check the troubleshooting section)
- I have not yet tested RAK7246 on basicstation. It works with UDP packet forwarder but it’s very slow… not sure about the performance when using basicstation (nothing to do with the concentrator but that gateway is based on the Pi Zero)
2 Likes
Perfect, thanks 
! Probably @mpous will find that info also useful - so we got up to date udp-packet-forwarder and basicstation now ready for balena
@xoseperez at first test I’m seeing in the logs it looks like even though USB is defined in the variables it’s still trying to connect to SPI.
Variables:
interface: USB
model: SX1303
I’ll dig a little deeper but wanted to share…
basicstation 2022-02-05 14:20:33.469 [S00:INFO] Station device: usb:/dev/spidev0.0 (PPS capture enabled)
basicstation 2022-02-05 14:20:33.469 [S00:INFO] [lgw_com_open:88] Opening USB communication interface
basicstation 2022-02-05 14:20:33.469 [S00:INFO] [lgw_usb_open:162] INFO: Configuring TTY
basicstation 2022-02-05 14:20:33.469 [S00:ERRO] [set_interface_attribs_linux:74] tcgetattr failed with 25 - Inappropriate ioctl for device
basicstation 2022-02-05 14:20:33.469 [S00:ERRO] [lgw_usb_open:165] failed to configure COM port /dev/spidev0.0
basicstation 2022-02-05 14:20:33.469 [S00:ERRO] [lgw_connect:1182] CONNECTING CONCENTRATOR FAILED
basicstation 2022-02-05 14:20:33.469 [S00:ERRO] [lgw_start:866] FAIL TO CONNECT BOARD
basicstation 2022-02-05 14:20:33.469 [S00:ERRO] Concentrator start failed: lgw_start
basicstation 2022-02-05 14:20:33.469 [S00:CRIT] Slave radio start up failed with status 0x08
basicstation 2022-02-05 14:20:33.383 [TCE:VERB] Connected to MUXS.
basicstation 2022-02-05 14:20:33.419 [RAL:INFO] Region plan hwspec 'sx1301/1' mapped to 1 slaves 'sx1301/1'
basicstation 2022-02-05 14:20:33.419 [RAL:INFO] Master sending 645 bytes of JSON sx1301conf to slave (0)
basicstation 2022-02-05 14:20:33.419 [S2E:INFO] Configuring for region: US915 -- 923.0MHz..928.0MHz
You forgot to set the DEVICE variable, its still set to /dev/spidev0.0.
You probably will need to overwrite it with “/dev/ttyACM0” - or whereever the USB interface on the balenaFin of the RAK5146 comes up
Yes, you have to specify the DEVICE variable, actually the INTERFACE is inferred from the DEVICE, not the other way around.
1 Like
Thats the trick! I’m thrilled this is working now.
Thank you both @xoseperez and @nmaas87!
I’ll add some more details about my setup later, since others might be interested in using the Fin with a RAK card in the mpcie.
Meantime, probably unrelated, but I noticed on my other gateways that the time sync error has started getting out of hand, and even causing disconnects. For two years I’ve seen time sync quality warnings, but only in the last week or two has it started causing problems.
Have you guys been seeing the same issue?
basicstation 2022-02-05 16:25:55.084 [SYN:INFO] Mean MCU drift vs SX130X#0: -11.0ppm
basicstation 2022-02-05 16:25:59.291 [SYN:VERB] Time sync rejected: quality=2982 threshold=2953
basicstation 2022-02-05 16:26:12.972 [SYN:INFO] Time sync qualities: min=2046 q90=2922 max=3098 (previous q90=2953)
basicstation 2022-02-05 16:26:21.395 [SYN:VERB] Time sync rejected: quality=2930 threshold=2922
basicstation 2022-02-05 16:26:27.708 [SYN:VERB] Time sync rejected: quality=2983 threshold=2922
basicstation 2022-02-05 16:26:36.125 [SYN:VERB] Time sync rejected: quality=3095 threshold=2922
Great!
Credit to the guys from Semtech. It took them some time but they finally updated the BasicStation code with some really nice features . I just built the binaries and the docker image in a way it can be easily used with as many concentrators as I can test.
1 Like
@xoseperez By the way - any idea on when LBT is going to be implemented for the USB RAK5146 in the udp-packet-forwarder or Basicstation?
@barryjump As I am quite often restarting and working on my one and only RAK5146 USB (got no other gateways at all) - nothing like that accumulated. Does this gateway use GPS for time? If so, I would assume the GPS reception is bad and you could move the Gateway to a window or use an active GPS antenna with longer cable. I had my concentrator picking up GPS without any issues, but in the last weeks it became a bit … unreliable. Put the active GPS antenna to my window yesterday and within a minute - GPS and time were perfect.
You might be right @nmaas87, it never occurred to me that my gateways might not be getting GPS signal. I assumed because elsewhere it was stated that GPS does not work with my setup that it was a hardware issue - so I never bothered to get the gateways into a place where they could get a signal. But you’re saying that although GPS coordinates aren’t supported, GPS timing is?
Maybe I glossed over the details. I just moved the gateway we’re discussing to a better location to see if that fixes the time sync issue.
Any suggestions on how to debug whether or not the concentrator is receiving any GPS connection (for timing or otherwise)?
My understanding was that timing came from network - or more specifically from the mcu which gets time from network when GPS was not available.
I did just see this for the first time ever in my logs - a reference to gpsOffset and SX130X->GPS which maybe means its made a fix?
basicstation 2022-02-05 19:21:19.011 [SYN:INFO] Time sync: NOW ustime=0x000248E0EB1A utc=0x5D74A459CD6D4 gpsOffset=0x4B7EBFCE66DC0 ppsOffset=622951 syncQual=2709
basicstation 2022-02-05 19:21:19.011 [SYN:INFO] Time sync: MCU/SX130X#0 ustime=0x000248C86D1B xtime=0x9400004A6675B2 pps_ustime=0x248C23986 pps_xtime=0x9400004A60421D
basicstation 2022-02-05 19:21:19.011 [SYN:INFO] Time sync: Last PPS ustime=0x000248C86D1B xtime=0x9400004A6675B2 pps_ustime=0x248C23986 pps_xtime=0x9400004A60421D
basicstation 2022-02-05 19:21:19.011 [SYN:INFO] Time ref: Last PPS sys->UTC=19:21:17.000000 SX130X->GPS=19:21:35.000000 leaps=18s diff=0
However, somewhere buried deep in either the Balena, RAK or TTN forums I recall someone saying the time sync doesn’t even really matter which is why I never paid it much attention. Perhaps thats still true…
Anyway thanks for the tip!
Ok I did think the shown logs were from a different gateway, not your Fin/RAK5146-USB - but… I think these logs are from that pair, can you confirm?
In a nutshell: RAK5146 USB needs a RPi HAT to route the GPS module TX/RX to the Fin/RPi serial. Without that, GPS coordinates will not work. However, the pulse per seconds / PPS signal of the GPS module is routed on the RAK5146 module itself, so if you got a solid GPS fix, you will get time with your config (the Last PPS line is looking extremely well and I would also say you fixed the location and are now getting a solid GPS fix, otherwise there would be no GPS time there :))
As of “is it required”… well Xose can probably tell this better. What I think (please confirm or deny @xoseperez ) - LoRaWAN does need precise timing. But if GPS does fail (or you don’t have a GPS module) - Basicstation will get the time information via NTP or the upstream server. I think to recall that this is a part of the more complicated protocol between the “TTN servers” and the gateway. But normally, I prefer a local clock which is precise, so I go for the GPS antenna
It is indeed from the RAK5146 USB & Fin combo.
Thanks for clarifying the RPi HAT requirement for serial real of GPS coords. It doesn’t make sense to me why coordinates would route differently than GPS time, however it does now make sense why I was confused. I assumed GPS data was GPS data and time & coords were handled in the same message between hardware. So that definitely clears why I was getting mixed signals.
RE: the network / local time when GPS is not avail, perhaps there is someway to pipe in the RTC clock capability of the Fin? Thats more advanced than I’m comfortable with at the moment.
Anyway, can’t thank all of you enough for your help. Now the task for me this week is to do some tidying up on the software side and I’ll have a self-contained 8 channel gateway with solar capability, 5 hr battery backup and cellular backhaul ready to place anywhere in the country. Very exciting.
No worries
The answer to the “why does this work with the GPS time” lies in the Diagram: RAK5146 WisLink LPWAN Concentrator Datasheet | RAKwireless Documentation Center
It is a bit misleading, but you can see the 1PPS pin going into the SX1303.
What is missing is the fact that the 1PPS signal comes from the GPS module.
I am actually not sure whether something else than the PPS pin is routed through.
The diagram would make you think that only the PPS part is transferred to the SX, which would mean that the module has no idea of the time itself (like current date, clock. etc) - but only about the Pulse Per Second for the extra-precise timing. The rest of the data would have than needed to come from another source, meaning the onboard RTC, NTP or the TTN/similar server. But I am not sure about this… Just my 2 cents
Cheers!
2 Likes
So I am still working on my setup - now trying to pull it completely into my homenetwork
The first steps are an MQTT server (used as Bridge to TTNv3 to receive my packets ) - a locale Python script which does calibrate the packet data and ingest it into InfluxDBv2 and then Grafana. I am currently at the ingestion part and then it should be easy to move forward.
As a short question @mpous - can I actually setup my Gateway in a way that I can have my locale Chirpstack instance running - but also have the Gateway as part of TTNv3? I would really love to have my own “private” Stack for just my own, internal sensors - and the rest should be done via TTNv3?
Thanks!
1 Like
That is not a recommended setup. A gateway should be connected only to one LNS.
That said, there are ways to do it. The old way was to use a fork of the UDP packet forwarder named “poly packet forwarder”. I guess you can still find the code somewhere on the Internet, but I’d recommend a different aproach.
The second option is using Brocaar’s multiplexer (GitHub - brocaar/chirpstack-packet-multiplexer: Forward Semtech packet-forwarder data to multiple servers.). It lets you define N-to-N relations between gateways and LNSs.
But again, sending to more than one LNS is strongly NOT-recommended.
2 Likes
Thank you @xoseperez for clarifying this to @nmaas87
Nico, do you have a balena Chirpstack LNS working? looking forward to test this!
Thank you @xoseperez - this helps me out - I can understand why this ain’t a good idea, but hacking away on tech means that at some point you will develop specific usecases no one else has, so… sometimes they are stupid but worth a try 
@mpous no, at the moment I am running the GitHub - RAKWireless/udp-packet-forwarder: UDP Packet Forwarder for Docker on an RPi 3 with balenaOS. This has been working great so far - only one hiccup that I could never grasp was the fact that the gateway will pick up up to 5000 packets - and then the counters will just reset. It looks like this falls together with some reconnect of the gateway on balenaCloud. Seems to be very sensitive to internet connectivity loss
So, no I have not yet installed a balena Chirpstack - do you got some around here somewhere? 
I think I saw one balena blog with that specific topic some time ago…