Hi, which mpcie formfactor concentrator would you recommend then?
If you are referring to this:
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.
Yes, I was referring to that statement. I want to use it in an alix apu2 ( https://www.pcengines.ch/apu2.htm ) no mention in the docs ( https://github.com/pcengines/apu2-documentation/blob/master/docs/APU_mPCIe_capabilities.md ) about SPI support though.
Was planning on using https://github.com/RAKWireless/rak_common_for_gateway
Was planning on using GitHub - RAKWireless/rak_common_for_gateway
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.
Even if I use the SPI version? I understand the USB version has timing issues.
https://github.com/RAKWireless/rak_common_for_gateway states:
“Added support for rak2247/rak833 spi version.”
Am considering: https://store.rakwireless.com/products/rak2247-lorawan-gateway-concentrator-module?variant=29444341923885 (SPI, not USB)
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.
Presumably the sell that embedded computer for purposes other than LoRa/LoRaWAN
What do-it-yourself (mpcie) concentrator would you reccomend?
waiting for a sx1302 based mpcie board? like: https://www.cnx-software.com/2019/10/16/semtech-sx1302-lora-transceiver-to-deliver-cheaper-more-efficient-gateways/
Your issue isn’t the concentrator, but the host.
Either get a host with SPI, or get a pico GW concentrator
Ok, but it’s confusing when they sell it for exactly that purpose, it’s even called: " LoRaWAN™ Gateway Concentrator Module"
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.
Do you know a SBC host which does support this non standard spi use in mpcie formfactor?
I wasn’t clear
SPI yes, my question on picking one was ruled off topic but pretty much any ARM embedded Linux board would, as would the MIPS based router chips.
in that form factor, no, because there is no standard That’s why people make adapter boards
I’ll stay away from mpcie 
with a raspberry pi (with some in memory filesystems to spare the sd card)
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.
They made that in the form of the compute module which is targeted at exactly that market. Available with eMMC.
1 Like
Hi there, I can see that you are using 2245 with rasp pi 3 model b+, is it work nice? are you satisfied with this product? Thank you in advance