I have, sitting on my desk, an Arduino LoRaWAN Pro Gateway, that is basically a RasPi with an Embit lr1301 LoRaWAN module attached to it.
Obviously, this device is pre-programmed to talk to Arduino, but I am wondering if it is possible to reconfigure the packet forwarder to talk to TTN? The LR1301 is an OEM gateway, by the way. I’ve searched around a fair bit, but I found nothing.
The reason for my request is that, with Arduino, adding third-party LoRaWAN devices requires a monthly subscription payment…
This is probably a fairly vanilla SX1301-on-a-pi type of gateway. The main connection would presumably be to the pi’s SPI bus, along with another GPIO for the SX1301’s active high reset (high to reset low to run) which typically gets handled via a script using the /sys/class/gpio/… interface.
Try searching the filesystem of their image for a script referencing that, files like global_conf.json and so on. Also do a sudo logread -f and see if you have messaged from a “packet forwarder” which is the main gateway software component.
If you can figure out that it’s an ordinary SPI interface, and identify the GPIO used for reset (either from their install or by tracing the interface board) then you can probably put their SD card on the shelf, get an ordinary Raspbian or whatever image and follow setup instructions for an iC880, RAK831, RAK833 or whatever and get things going in short order - there are also some “out of the box” pi images floating around that might just work or only need the reset GPIO changed.
Found there are the facts that this appears to be the later generation concentrator design with an FPGA, though that should probably be handled for you by the Semtech packet forwarder. It would appear that on this card the reset is the traditional PCIe active low, so a standard script written to talk to a bare SX1301 may need the sense with which it is driving the reset inverted.
I’ve not worked with a concentrator of the generation having the FPGA, so it would probably be worth spending some time to understand how the host interaction usually works there. Most of it should probably be taken care of by the Semtech code. It’s also possible that (if your area does not require listen-before-talk) the extra capability could simply be ignored.
Also the pins used for SPI are different than on something like a RAK833, though that probably won’t matter as long as you use the supplied interface board.
Morning, and thanks for the quick and detailed reply!
I spent the day yesterday, experimenting with the Pro Gateway (it’s quite surprising that it is permanently bonded to Arduino’s ecosystem, given that Arduinio is quite open-source minded). Anyway, from peeking into the official Arduinio image, I found the reset pin designation, and this matched with what I found by physically tracing the connection on the boards.
So, with that information, I set about setting up the software, using the guide from TTN for the iC880A board (also SX1301 based). After much experimentation, learning and poking around, I had, unfortunately, no luck. The packet forwarder reports ‘failed to start the concentrator’ and stops. I also stopped at midnight I know the board works, as it communicates nicely with Arduino - shame it can’t be persuaded to talk to anyone else! I might give one final try, but ultimately, I might have to put this board to one side, and invest in a gateway that is a little more configurable (a RAK product, for example).
You may need to check out more recent repos directly from Semtech with support for concentrators with FPGAs on them.
That said I would have thought that the concentrator would have at least minimally worked.
Try inverting the reset as it seems to be electrically opposite on the module compared to the bare chip.
Also run the spi tests in the lora hal repo rather than the packet forwarder.
And make sure that Arduino’s image doesn’t have a copy of all of this sitting on it - it’s not a given that you need to do anything more than just change the global_conf.json / local_conf.json to point to TTN instead of their system.
I found the reset pin from the EMBIT documentation (linked in cslorabox’s post above). I’d already found it by tracing it electrically. Digging into the Arduino image also reveals which pin it is.
However, despite my best and lengthy efforts, I failed to get it to work. Clearly my best efforts were just not good enough
Anyway, I haven’t touched this topic for a month now; it is a work-related project, so I don’t have so much time to play around (i.e. none at the moment).
I’m sorry I may be late, I was having the same issue for months now.
My issue was that i installed and used the semtech pkt forwarder and on his start up the concentrator receive RF packets only in the first iteration of his loop and after that just forward stats messages although the devices are sending data.
But, I think i’ve found a way to override the Arduino code by doing these steps :
And then try starting the lora_pkt_fwd script given by the semtech packet forwarder.
It worked for me I know it’s not optimal but i’m still trying to figure out a better way. PS: I tried disabling this service but if you do it the arduino board won’t start so you need this service to start first and then stop so it won’t overlap with the semtech pkt forwarder(for now i’m trying to alter the code of the arduino forwarder and keep the part responsible for the concentrator start up).
I know the board works, as it communicates nicely with Arduino - shame it can’t be persuaded to talk to anyone else! I might give one final try, but ultimately, I might have to put this board to one side, and invest in a gateway that is a little more configurable (a RAK product, for example).