Don’t get a 433MHz unit, TTN does not support it.
For a concentrator SPI is the way to connect it to a computer. If you really need to go the USB route, make sure to get a concentrator using the pico gateway protocol. Solutions using a ftdi adapter are not supported by recent versions of the reference software with good reason.
The easiest solution is buy the 8 channel Dragino gateway LG308.
@cslorabox Thank you.
Pi is cheap, I prefer the computer since I have immediate access with keyboard and screen. It’s open all day, no reason to have extra device + maintenance.
I will remember your advice. Worst case, I buy the concentrator and if I fail I will buy the pi.
What are the reliability problems? Although I want to test for now, I like to contribute with the gateway to the TTN in the future. I like the idea of community IoT.
@kersing thank you, I forgot the draginos. Nice proposal, it has also a server like I wanted.
I am searching 12-16 hours now, i never encounter about pico gateway protocol device. Do you have an example device to purpose?
And how I connect my computer to SPI interface / device? Via usb-to-spi? (I know silly question: sorry)
This is ok for pc to concentrator?
They also have a usb to mini PCIe adapter.
No point idea really.
Directional antennas implies gain, and to use them legally (in most places in the world) you would need to reduce the transmit power of the gateway and nodes, thus negating the point of the gain antenna.
However if you have significant cable or connector losses then you can use a gain antenna to compensate for those losses,
The n-fuse one uses the pico gateway protocol and can safely be used with USB.
For other devices, don’t attempt to use USB. LoRaWAN is timing critical and timing for USB connected concentrators is less precise.
I know you don’t want to have an additional device but for SPI the easiest way to go is a Raspberry Pi. It does not have to have a keyboard and monitor attached, network access is all that is required. I have serveral RPis deployed in metal casings, outside with just a network connection. I rarely need to log on. (There is one I haven’t logged on to for > 2 years that is still running fine)
@LoRaTracker thank you for the heads up.
Again thank you @kersing .
I have the wish 10 years to build an arm server. But my x86 chips are not dead yet. Maybe now is the time 
By the way, it seems that it’s doable with pc. The last comment from Paul Beard says he made it.
I also remembered that my laptops have mPCIe, so maybe I don’t need the adapter but sometimes the bios does not like unknown cards.
Screwdriver time. 
Thank you all! I didn’t decided yet but I understood better the situation 
One last advice please! (ok, I have some more questions in the end)
The software was easier than I thought. No problem to compile it. I tried both 32bit and 64bit systems. Seems fine. Now the hardware is missing. (I will not try to build loraserver for now)
So now the question is:
To my understanding I have two options.
German people. (they also have the usb to mPCIe + extension antenna cable + antenna.)
https://www.n-fuse.co/devices/LoRaWAN-Concentrator-Card-mini-PCIe.html
China people
https://uk.pi-supply.com/products/rak833-spi-lora-gateway-concentrator-mpcie-module-sx1301
extension with antenna.
https://uk.pi-supply.com/products/small-plastic-antenna-850-1850mhz?_pos=34&_sid=62ff032f3&_ss=r
I also found embit with gps (but no price) [No one answered: “Why a gateway needs a gps? You can have a mobile gateway?”]
Do I have other choice? There is a preference between the two?
Those options are inferior to IMST iC808a? They have only one Antenna, I thought it’s better with two antennas.
Bonus: One laptop has this card. I can substitute it with those lora cards? I don’t care about wifi.
https://www.thinkwiki.org/wiki/Intel_PRO/Wireless_4965AGN_Mini-PCI_Express_Adapter
Thank you, I hope those are my last questions. 
(for this matter)
You were already advised to use an SPI solution on an embedded board that supports that. If you are going to ignore that advice and try to push forward with a PC, you’ll likely have to do a lot more work on your own without support.
Your choice.
I know USB solutions with a Linux server can work. I’m running one myself on and off for development of packet forwarder software (a lot faster in a big machine), however due to strict timing of LoRaWAN and conflict with other workloads this gateway is less suitable to be part of a stable and reliable LoRaWAN network. A Raspberry Pi with running just a packet forwarder provides a 100% more reliable gateway.
Feel free to ignore our advice, don’t expect us to help solve issues later on if you ignore the advice you asked for which people with years of experience took time to provide.
@kersing Thank you for your detailed answers, I will contact n-fuse.
I am surprised that a pc can’t handle the communication (probably usb’s fault?). I had the impression that the card handles autonomously the communication and just handles the bytes to medium (SPI or usb). Since the bytes are tiny I am surprised that usb or other communication (rs232) can’t handle that.
So if I use a pi, I have to used it only for that service otherwise there will be reliability problems. (Again surprised). So it seems the best solution is a dedicated standalone machine like mentioned in first post. Now I understood the message about testing from @cslorabox
N-fuse have a hat with gps for pi 60-70€. So if a fail I with pc I will use the hat to a pi.
I found a similar thread here.
Example with similar card mPCIe to pi (aka: hat for convenience)
I hope I will have good news.
USB to SPI overhead results in overhead that has too much impact on timing. The reference design used by n-fuse uses a USB capable processor to drive the SPI bus. Older designs use an FTDI device in more or less bit bang mode to drive the SPI bus. The SX devices on the PCI bus have limited buffer capacity requiring fast communication to avoid loss of data which with the old design is not guaranteed. (And from experience I know will fail on a PC running other jobs as well)
LoRaWAN when operating under load (multiple packets arriving in a short amount of time) requires millisecond accuracy communications or data is lost. With a system loaded with other applications that can not be guaranteed.
Regarding all the references you are posting, keep in mind there are a lot of tutorials on the web that are based on wrong assumptions or seem to run well for a couple of days and might fail later. On this forum you’ll find people working with LoRaWAN for multiple years and having learned by experience.
I have not imagined that we discuss about real-time requirement. You reminded me when I had audio glitches and I managed to fight that with various methods, but the ultimate solution was the upgrade.
So if I see too much traffic I have to fight it 
, if if I loose have to upgrade to pi 3 (not 2), if I loose again, I have to buy something dedicated and expensive 
(I will move the ‘unreliable’ gateway to a place with less traffic: job done.)
Sorry for the “wrong” references I read them in the TTN so I thought they were valuable / accurate.
Thank you for your detailed answers, you where helpful again!
It’s not a “real time” requirement but one of general responsiveness, for which a computer trying to do lots of distinct things tends to be ill-suited, almost irrespective of how theoretically fast it is.
It’s not that you need a faster embedded board, but that you want something like an embedded board that is not trying to do anything but be a gateway. And which has a good native SPI interface, something PCs lack.
One of the most counterintuitive lessons of engineering is that a slower processor tends to be able to be more tightly coupled to external events, and a slower processor that can be dedicated to a task will usually be more responsive than a fast one trying to juggle many tasks. There end up being situations where an Arduino is faster than a pi which in turn is faster the a PC. (Granted, a classic Arduino isn’t up to being a gateway, but something like an ESP chip is, though getting all the software working is a challenge)
I am not saying all your references are bad. Or even most of them are. I am just trying to warn you not everything you read is 100% correct.
That applies to messages on the forum as well. Sometimes people write messages based on (wrong) observations, not based on knowledge.
I have experienced Ubuntu with ionice and nice process to make an old computer useless. But I never experienced this phenomenon with my custom installations (example: i use my own custom kernel). Exception is the starvation of memory. Maybe two times in a year.
I have “manual” OS (Slackware, aka: no “automations”) but I just read that usb adds latency.
Anyway, I placed the order. I hope the journey continues. The worst case scenario is to move the card to low traffic place, or to buy some dedicated computer with SPI.
My mPCIe slot on my laptop is not SPI capable*? So they use (n-fuse / rak) the mPCIe interface as connector for convenience?
Great answers, thank you!
Unless you really want to play with a concentrator, for the price of a concentrator you can also buy a TTIG.
No. SPI is not part of mPCIe. LoRa cards just re-use the connector in a proprietary, non-standard way. The power pins and maybe a reset are the only things that match mPCIe (or at least they hopefully do).
x86-type PC’s all but never offer a user SPI interface, there’s no reason for them to.
Thank for the clarification. I thought (SPI) it was a bus inside of PCIe or mPCIe.
I don’t know if it’s right. But one person told me that mPCIe in a laptop maybe supports USB bus, so I was expecting also a SPI interface / bus via mPCIe.
So a PC is out of specifications. Interesting. So the best option is a host with SPI but the only host I found till now is Rapsberry Pi and maybe mikrotik in the future with routerboard.
Hmmm… still confused about the ideal situation (we are off-topic now). To my understanding the best solution is a non-customized dedicated device.
Anyway I am waiting the device, the shipped it
As @kersing noted. I made wrong assumption here. The n-fuse card is only USB / UART capable, not SPI. I was confused with RAK833 which has version SPI/USB (now obsolete. The new one is: RAK2247)
So if you lose with n-fuse you have to buy an SPI capable card with a SPI host.