How can I use it on boards other than raspberry pi?

Issue:
we have a SBC running yocto.
the SBC has a mini pci slot on its back;

Setup:
rak2287goes into the SBC slot;

Server:
a SBC (digi cc6ul) running yocto.

Details:
How do we turn this into a functional Lorawan gateway?

Hi

Most miniPCI slots don’t support the SPI pins the RAK2287 needs.

It might be better to use the RAK2247 in the USB variant. This tends to be more compatible since the USB pins are also used by LTE cards (but always check)

Then you can then try for example chirpstack-gateway-os-base under Yocto https://github.com/brocaar/chirpstack-gateway-os

Since this isn’t a configuration officially supported by RAK or indeed running on RAK hardware you’ll probably have to spend some time getting it right.

[quote=“rcai, post:1, topic:2656”]
yocto.
[/quote]Good advice, I believe, @jmarcelino.
Having read further elsewhere about the timing issues the RAK2247-USB , I still think it is a good choice for people not in busy locations.
But ongoing we users should be encouraging RAKwireless to develop a USB version of RAK2287 maybe with smarter onboard MCU with RTOS. Probably needs a different part number.
So the title says it" How can I use it on boards other than raspberry pi? I want to be able to use other hardware.

I believe, plus or minus a version of the Semtech chipset, that would be a RAK7258.

An MCU with RTOS - not sure the RTOS is totally required, but if you really really want a rocket surgery gateway that you can’t hack away at command line because there isn’t one, then there is the P-NUCLEO-LRWAN2

If you don’t want a hard-RTOS, then there is the RAK7256.

Or, if you feel the market exists for such a device, you could roll your own …

Not something I want. In conversations else where it’s been brought to my attention that because LoRa specs require precise timing and in busy environments USB adds time delay, USB based boards problematic over SPI based boards.
Only RAKwireless knows how much demand there is for USB vs SPI. I’m not asking them to tell me either.
And then there is the added support costs of the user that has to get the software built and configured correctly versus send out SIM card with complete OS and software for Pi and SPI.

True, for varying values of precise, but not requiring an RTOS - if the MCU isn’t otherwise occupied, a simple delay will suffice - it should be no hardship to suspend sensor readings for 4 seconds or less.

USB = 0.1% and only if you are totally mad, SPI = 99.9% so you don’t have problems with USB delays.

SIM card being SD card I presume - not that Raspberry Pi Foundation need to send out cards, an image to download to flash to a card will suffice. As it happens, for some products, RAK do provide SD Cards with known good configurations - bulk flashing a branded card is a good move for a $150+ piece of kit.

[quote=“nmcc, post:6, topic:2656”]
USB = 0.1% and only if you are totally mad, SPI = 99.9% so you don’t have problems with USB delays.
[/quote]We are talking about gateway concentrator here, not an end node. No sensors involved but, I remember it being called, a ‘just in time’ queue.

Right, not a SIM card but SD card.

Huh? I was aware you were talking about a gateway board, I never mentioned sensors. What’s with the JIT queue?

As USB has been shown to have it’s drawbacks and the cost of the interface boards & chip sets have fallen, it doesn’t really make any sense to use anything other than SPI. If you want to reliably collect data, making something too cheap is a false economy.

Semtech, who makes all of the LoRa silicon are ahead of you here, and published a few years ago the “Pico GW” reference design to replace the deprecated FT2232 USB solutions. By keeping all of the time critical operations in between an MCU and the baseband chip, they make the USB latency a non-issue.

There are a couple manufacturers who have Pico GW products on the market.

Using an SX1302 instead of the SX1301/SX1308 would likely require slight adjustments to the MCU firmware (source is published) and then some effort to cherry pick the right parts of the distinct SX1302 and pico GW packet forwarder code bases (yes, Semtech has three separate packet forwarder codebases all doing substantially the same thing and containing substantially the same code, with slight critical differences - apparently they never heard of #ifdef)

If you really need to turn an existing router chassis only supporting USB into a gateway, it’s probably best to use a pico GW card.

If you really want an SX1302 based gateway, pick a host platform which has SPI - eg, while the offered firmware won’t do it so it is officially unsupported, the RAK7258 hardware should be able to host an SX1302 if the appropriate version of the packet forwarder were ported to its painful build process.