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.
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)
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)
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.
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.
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)
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?
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.
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.
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:
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).
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.
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!
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?
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
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?
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?
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%
Is important my date (clock) settings on my computer? I should regurarly run ntpdate?
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
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.
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?
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.