Newbie - Gateway with Linux-box? (EU-Greece)

First time in embedded, so please excuse me. I have many silly questions.

I am willing to build a bike tracker with LoRa+GPS(+Accell+RFID) but I realized that I need also a gateway at least for testing. (only 4-5 gateways in my city all DIY, only one is serious: kerlink)

I am totally confused for software and hardware options.

a) It seems, that there is no cheap gateway (concentrator) since the cheap ones are single channel aka: SCG and they are not officialy supported by TTN, since they monopolize / waste the frequency (and I agree). Those gateways with many channels are too expensive. So I need to build one my-self, but if I loose too much time trying it to work / debug, I prefer to buy one.

After some reviewing, something like this seems ideal to my case. (anyone knows the price?)

But this is ok? 120€ (No lan, but I will live with that)

Also found those at 200€

(150€ - this is not so expensive.)

My requirements are

I) To control the db gain.
II) Optionally to send the packets to my server for MY devices. For other devices, the data will be go to TTN. Also mine can copied to TTN, I don’t care. I can’t control the flow with MAC address?

To my understanding I have three bare options.

IC880A concentrator


There was a USB edition for connection with PC (?), but where is the software to control / configure the device? (I am using Linux). To my understanding, I need special drivers for the SPI edition. And how I connect the SPI to my linux-box?
2. RAK2247 concentrator (see p. 8)

So many options, I am confused!

(like 1, just smaller)

I have a computer active all day so I don’t want to use Raspberry / Arduino e.t.c. Can I use those boards (1,2,3) with my Linux-box? It’s more difficult? (I can compile) What do I need for the connection? A usb to serial convertor like this?

I think a usb-to-ftdi, is the appropriate.

b) It’s easy to by-pass the TTN server and store the communication directly to my computer for my devices? In that case I see only one choice of loraserver. Do I have another (simpler) options? Since this is a suite of software to my understanding, I think I will suffer to compile it :slight_smile:

c) In Europe we also have the choice of 433Mhz. It’s better for area coverage? Right? Any cons?

d) To my understanding the better interface is I2C but most devices / shields are UART / SPI?

e) Why some concentrators have GPS ability? You can have mobile gateways?

Summary: Is it possible or pain in the ass to operate a proper gateway with Linux-box? Should I go for Raspberry + concentrator like this?

This solution (PC > ftdi > concentrator) is ok, or there is a better solution?

For the above example in installation we have two problems:

  1. page: 5 “This project supports only LoRa P2P, does not support LoRaWAN” THE HORROR! :stuck_out_tongue_winking_eye:
  2. in the same page the github link is dead! THE HORROR #2 :scream:

The new one is here, but it supports LoRaWan? And I don’t see instruction for PC but for Rasbperry.

I also found image specific to Ubuntu. Kind of pain to grub the stuff for my distro, anyone done this?

Bonus: I didn’t find info about directional antennas. Silly idea? If I have a mountain in one side, I can use directional antenna to cover other populated areas.

Thank you for reading!

You really don’t want to run a gateway on a desktop PC - in some configurations it might be possible but it is not advisable. For a test setup even the cheapest Raspberry Pi is fine, for something field deployed you have reliability challenges that neither a desktop PC nor a pi really meet, but fortunately that is not your goal.

1 Like

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.

1 Like

@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)

1 Like

@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 :grin:

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. :hammer_and_wrench:

Thank you all! I didn’t decided yet but I understood better the situation :slight_smile:

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.

  1. German people. (they also have the usb to mPCIe + extension antenna cable + antenna.)

  2. China people

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.

Thank you, I hope those are my last questions. :face_with_hand_over_mouth:

(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.

  1. For a TTN community gateway GPS for position information is not useful. Community gateways are useful when at the same location all the time so people can rely on connectivity for their devices. A second use case for GPS would be Time Difference of Arrival (TDoA) time stamping for location information, however that required multiple gateways (at least 4) with that feature receiving the same packet which is very unlikely in the community network. Only a small fraction of existing gateways have GPS.
  2. If you want to go the USB route you need to go n-fuse. That is the only of the bunch I where software support for the foreseeable future is guaranteed. The USB version of the RAK solution relies on software that was retired by Semtech a couple of years ago, not something you want to invest in at this point in time. A quick look at the embit solution does not provide information on the software used, so I would not risk it.

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 :face_with_raised_eyebrow:, if if I loose have to upgrade to pi 3 (not 2), if I loose again, I have to buy something dedicated and expensive :moneybag: (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.

1 Like

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.