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

Gateways
7

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,

3 Likes
8

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
9

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

10

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.)
    https://www.n-fuse.co/devices/LoRaWAN-Concentrator-Card-mini-PCIe.html

  2. China people
    https://uk.pi-supply.com/products/rak833-spi-lora-gateway-concentrator-mpcie-module-sx1301

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

(for this matter)

11

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.

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

3 Likes
13

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

14

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.

2 Likes
15

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!

16

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)

2 Likes
17

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.

18

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!

19

Unless you really want to play with a concentrator, for the price of a concentrator you can also buy a TTIG.

1 Like
20

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.

21

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 :slight_smile:

22

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.

23

Success! Thank you all for the help and advices!

The concentrator was delayed, in the meantime I made a node (feather lora 32u4). It was helpfull, because without the node the gateway seemed offline. After the first message from the node, it appears online!

Observations:

  1. I was confused with the server settings. I had to use router.eu.thethings.network instead of eu.thethings.network as stated in the website (console).
  2. The mini pci-e adapter to USB is USB1 (12Mbit instead of 480Mbit). I suppose no trivial since the data rate is minimal. My testing connection now is: n-fuse (mpci-e) > usb adapter (V1) > usb hub (4 ports) > pentium-m (era 2004). Seems fine. But the only traffic is my node.
  3. The concentrator is HOT after five minutes! Even if your laptop has mini pci-e with USB host capabilities, don’t try it. IT’S HOT!
  4. Indoor seems only useful for testing. I don’t know if the antenna is crap. Very limited range my current setup. Arount 200-300 meters, but I impressed that I could send message from my basement (only concrete on walls, no bricks on any wall)

Can I make more questions here?

  1. What is the auto-update in gateway settings (console settings)? I have to update the global_conf.json sometimes? Or I have to do submit my local_conf.json? https://github.com/ttn-zh/gateway-remote-config
  2. Although my concentrator is new, the software is old / abandonware. I am forced to use ‘legacy’ packet forwarder. This is the reason I am not trusted?
  3. ttnmapper says unknown distance. How can I inform about the distance? TTN says correct location with the remark: “location_source”:“registry”. I have to enable fake_gps on json?
  4. This is noise or low signal? (I have not tried to send message)

# RF packets received by concentrator: 3,
# CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%

  1. Is important my date (clock) settings on my computer? I should regurarly run ntpdate?

  2. Those messages normal?
    INFO: host/sx1301 time offset=(1566397011s:959717µs) - drift=964272037µs
    INFO: [down] PULL_ACK received in 89 ms
    INFO: [down] PULL_ACK received in 89 ms
    INFO: [down] PULL_ACK received in 89 ms
    INFO: host/sx1301 time offset=(1566397011s:959457µs) - drift=-260µs

  3. Can I test the antenna without special equipment? The antenna is also for RX an TX? Can I remove for testing? I don’t even understand if the antenna makes a proper connection to the module. I know that for TX is catastrophic to the module. But my node is using TinyLoRa without ACK’s.

  4. The more important question. I can’t log the activity of lora_pkt_fwd. lora_pkt_fwd >> lora.log logs only after exit! I suppose I need to modify the code to support syslog?

  5. The console data are temp and only live? I have integration with my server, so I don’t lose data. TTN ROCKS!

Now I have the idea to buy a large USB cable and to place the gateway outdoors. But I need time for that.

1 Like
24

That setting applies to first generation TTN gateways only.

  1. Although my concentrator is new, the software is old / abandonware. I am forced to use ‘legacy’ packet forwarder. This is the reason I am not trusted?

It is not abandoned, however newer TCP based software is available. Search the forum and you will find it.

  1. ttnmapper says unknown distance. How can I inform about the distance? TTN says correct location with the remark: “location_source”:“registry”. I have to enable fake_gps on json?

No, you should not need to do so.

  1. This is noise or low signal? (I have not tried to send message)

# RF packets received by concentrator: 3,
# CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%

Multiple possible causes. Node too close to the hardware is one of the most occurring, keep at least 3 meters between the node and the gateway. If no node is active it might be Lora traffic or noise.

  1. Is important my date (clock) settings on my computer? I should regurarly run ntpdate?

No, you should run ntpd to keep the clock in sync. Ntpdate causes jumps in the time which isn’t good for timekeeping.

  1. Those messages normal?
    INFO: host/sx1301 time offset=(1566397011s:959717µs) - drift=964272037µs
    INFO: [down] PULL_ACK received in 89 ms
    INFO: [down] PULL_ACK received in 89 ms
    INFO: [down] PULL_ACK received in 89 ms
    INFO: host/sx1301 time offset=(1566397011s:959457µs) - drift=-260µs

You could google some or check the forum in stead of asking every single thing… Yes, perfectly normal.

  1. Can I test the antenna without special equipment? The antenna is also for RX an TX? Can I remove for testing? I don’t even understand if the antenna makes a proper connection to the module. I know that for TX is catastrophic to the module. But my node is using TinyLoRa without ACK’s.

However another node could happen to be close by and force your gateway to transmit. Never run your gateway without an antenna attached. To test the antenna you could exchange it with another one to see it that performs better.

  1. The more important question . I can’t log the activity of lora_pkt_fwd. lora_pkt_fwd >> lora.log logs only after exit! I suppose I need to modify the code to support syslog?

Anything started by systemd should log to the journal, not to syslog. You would need to change the software for that. However why would you want to? Keep in mind the software writes to a buffered output file which shows data only after 1k has been written to the buffer, which is standard on *nix since 1970…

  1. The console data are temp and only live?

This has been answered on the forum over and over. Yes, not buffered, so only shows data arriving when open and everything is lost when the window is closed.

25

@kersing

I did not get that about the software. I will search. I thought for n-fuse only picoGW packet forwarder was my option.

ntpd vs ntpdate: Thanks, I didn’t knew that!

Yes the log is populated after some data. I think other programs (ex. apache) are not behaving like that, but maybe it’s my bad. (no systemd here).

I am semi-ok with that (lost log data with ctrl+c):
lora_pkt_fwd | grep --line-buffered -E ERROR\|WARNING\|sent\|mote\|rxpk >> /var/log/lora.log

26

One more observation.

I upgraded the firmware and the gateway stopped to receive messages connected to hub - although no errors reported. Connected directly to the computer was ok (receiving messages). Also stress test where failing via hub, but before the update it was ok.

The magic line to make sure the gateway is working is:
INFO: host/sx1301 time offset=(1566772299s:304389µs) - drift=-1705505339µs
INFO: [down] PULL_ACK received in 92 ms

After a restart of host computer is working again through the hub. The hub has some weird cache? I forgot to power-off the hub, or change ports. Maybe the problem was with the hub.