When considering RAK2247 with Linux PC, keep in mind that uses code discontinued by Semtech in 2015. Semtech discontinued the code with good reason (timing inaccuracies due to the USB to SPI translation which cause scalability issues)
Then it’s important to note that the RAK2247 comes in both SPI and USB versions, and the concern mentioned there is specific to the USB version which someone would probably pick if they had a Linux “PC” vs. a Linux “embedded board” likely to have an SPI channel.
If you can use SPI, be sure you order the SPI version of the RAK2247. Unlike the RAK833 where the USB model also supported SPI, for the 2247 you have to specifically chose the SPI version at order time. You do have to slow the clock speed to account for a poorly chosen and unnecessary level translator in the 2247, but that doesn’t really cause problems the way the latency of an FT2232 USB interface does.
If you need to use a USB interface because your host system is constrained, pick a “pico GW” design which uses an MCU to accomplish the tighter timing tasks. nFuse makes them, one of the Heltec offerings might also have this capability but you’d have to check carefully. The picoGW code from Semtech code forces slightly longer timings than the native SPI code, but not by much. Also note that it is unfortunately a different packet forwarder codebase (though if you do a full diff, not terribly different), so if you want to use a packet forwarder that has been modified from the Semtech original, you may need to spend some time patching before it will work with the pico GW interface code.
That’s precisely what is not recommended, as the USB latency really limits agility on a busier network
For picoGW solutions which are sensible I should also mention that the nFuse seems to have compatibility issues with some internal mPCIe slots. You might consider it, but in an external holder connected to a USB port.
It’s unlikely your embedded PC supports SPI. Certainly not on the mPCIe connector - there isn’t even a standard pinout for that, because SPI is not part of the mPCIe spec the way that USB is.
I thought you were asking about the embedded PC chassis.
The FT2232 USB based LoRa Concentrators are obsolete configurations sustained by demand of customers uninformed enough to buy something better like the SPI configuration, or if they must use USB, the pico GW design that Semtech engineered precisely to solve that problem.
Hardly a good choice - you’re still at the mercy of an unknown flash translation layer. The pi is a consumer toy, it was never engineered to be an embedded system. The SoC could be used in one, but the pi foundation can’t be bothered to bring out the necessary strapping pins to use alternate storage technology, because they see their mission as building a consumer toy, not an embedded board for serious usage.
Hi @Ivan992@Borroz is no longer active on the forum so to avoid you getting frustrated waiting I guess we need to open up your question to others with experience and willing to coment…Anyone?