My plan is to put two gateways into operation. One in Krefeld, one in Tönisvorst.
I’m not sure yet whether I should build the gateway myself or buy a ready-made device. To make it faster, it will probably be a commercial device. I’m looking at a Mikrotik 8 channel gateway.
I would like to mount an antenna on the roof. That would be about 40 meters above sea level in our region. Which outdoor antenna is the best to use and what would you recommend as a beginner?
MiktoTik has excellent gateway and also corresponding antenna’s (including antenna cable). I would highly recommend getting both as MikroTik uses antenna connector and cable holes on the gateway that are not ‘standard’ for use with most third party antennas.
Thanks for the tip about the antenna connections. I probably would have fallen into that trap.
The Miktrotik gateway has a slot for a SIM card. Am I correct in assuming that this is only optional and that the router can communicate with the Lorawan server via my DSL line?
Yes, either by wireline E’Net or WiFi to your WiFi/DSL Router, WIFi AP or what ever to your DSL modem/router…I have one here connected just fine over WiFi to one of my DSL Routers…
Is it possible to send data from a LoraWAN sensor to a local server, e.g. via mqtt. I would like to send data from my sensors directly from the gateway to my local mqtt server.
Some, but not the Mikrotik gateways, can act as the LoRaWAN network server, but that’s off topic for a forum funded by TTI which runs the community TTN LNS and generally not recommended as you have no redundancy - if you lose the encryption settings you have to re-setup the devices.
And you won’t be contributing to your TTN community as your gateway won’t be on TTN.
Once the TTN servers have done the heavy work for you, you can use MQTT to receive the data as a client.
So you get the same result with the backup of the TTN LNS and your community benefits. The delivery time (via Dublin) is of the order of about 1 or 2 seconds. And you can setup the Data Storage to act as a backup if your MQTT system or internet connection has an issue.
PS, as the discussion was less about joining the TTN Niederrhein community and more about technical details, I’ve moved the topic.
Thanks for moving the thread. I think that’s a misunderstanding. I want to install the gateways to support TTN. That’s the first goal. I just want to be able to send my sensor data locally to a lokal device, such like a smart home box or similar. In this way, i am able to use the data from my nearby sensors, although the Internet access is disrupted. I realize that’s not the primary use case.
Es gibt da ja verschiedene Gateways von MikroTik.
Ich selbst habe mir das MikroTik wAP LoRa8 kit ohne LTE Option. Das kann Ethernet und WiFi.
Das betreibe ich mit einem POE Adapter über Ethernetkabel. Zur Zeit im EG des Hauses. Das möchte ich noch auf den Dachboden eventuell Dach bringen daher POE, also nur ein Kabel durch den Kabelschacht und ich brauche keinen zusätzlichen Stromanschluss.
Das ganze läßt sich gleichzeitig als WiFi AP einrichten und dadurch habe ich zusätzlich eine höhere WiFi Reichweite.
MikroTik hat ein Router OS in dem vieles einstellbar und konfigurierbar ist.
Eine Videobeschreibung https://youtu.be/xCBlGao5wBs am Beispiel eines MikroTik KNOT hat mir da einen guten Einstieg gegeben.
There are different gateways from MikroTik.
I myself have the MikroTik wAP LoRa8 kit without LTE option. This can Ethernet and WiFi.
I operate it with a POE adapter via Ethernet cable. Currently on the ground floor of the house. That I still want to bring to the attic possibly roof therefore POE, so only one cable through the cable shaft and I do not need an additional power connection.
The whole thing can be set up at the same time as a WiFi AP and thus I also have a higher WiFi range.
MikroTik has a router OS in which many things are adjustable and configurable.
A video description https://youtu.be/xCBlGao5wBs on the example of a MikroTik KNOT has given me a good start.
Why not using the best of all? In my opinion it is better to transport data locally first instead of send it hundreds or thousands of kilometer forth and back. Sure it´s a matter of the use case.
Internet access is lost more often than my local LAN. Besides, that was just an example. Data delivered locally also has low latency, although conceptually that is not the goal of LoraWAN.
But i found a solution. The Mikrotik Gateway seems to be the best Solution to me. Then i additionaly use Chirpstack, Miktrotik can also handle that instances. For this, there is a multiplexer available:
So i can use both. LoraWAN sensor data locally and sent it to TTN.
Alternatively i can configure a sensor device to send first to Chirpstack an then to TTN.
This makes my entry-level project a little more complex than I thought. But I’ll stick to the motto: one after the other.
I’m initially happy when my first sensor sends data to TTN.
Danke für den Hinweis. Ich wusst nicht, dass es die Mikrotik Geräte auch ohne LTE gibt.
Aber vermutlich werden ich doch einen mit LTE kaufen, da der Preisunterschied nicht so hoch ist.
Ich überlege noch, ob ich das Gerät direkt auf dem Dach befestige, oder ob ich mit einer externen Antenne arbeite. So muss ich nicht auf Dach klettern, wenn man mal was am Gerät machen muss. Vielleicht gewinne ich auch Reichweite.
Thanks for the hint. I didn’t know that Mikrotik devices also exist without LTE.
But I’ll probably buy one with LTE after all, since the price difference isn’t that big.
I’m still considering whether to attach the device directly to the roof or whether to work with an external antenna. So I don’t have to climb onto the roof if i have to do something on the device. Maybe I’ll gain the reach of the device too.
Because that’s not how LoRaWAN works - packets have to be decrypted on a LNS - so you will need to run one locally. It’s not about the distance the packets travel, it’s all about the convenience of having a non-trivial server setup looked after for you for free, so you don’t have to.
If latency of more than a second is an issue, probably best not be using any form of radio system as they are prone to dropped packets due to interference of the shared spectrum.
The multiplexer sends copies of the packet to two or more LNS’s - so you will need to have a local one.
I don’t think this will work - Chirpstack will turn the uplink in to a payload, doing all the decryption, it would then have to repackage & encrypt to relay to TTS. And you’d be proposing to do this for all TTN uplinks that your gateway heard.
Once you’ve got this done, then you will be able to see how you may be able to have a local relay of the data.
Keep in mind every meter of antenna cable will weaken the RF signal. So keep the gateway and the antenna close with just a short cable for best performance. (10 meters of typical coax cable can reduce the signal strength by well over half)
Wenn der Dachboden gut isoliert ist macht es auf jeden Fall Sinn die Antenne auf das Dach zu setzen. Manche Isolierungen dämpen das Signal mehr als eine Mauer.
Aber wie @kersing schon schrieb, das Kabel macht den Antennengewinn schnell zunichte wenn die Leitung zu lang ist.
So ein Kabel wie RG58 hat ca 0,46 dB Dämpung/m bei 800 MHz. Es gibt da auch einige mit über 1 dB/m und nur wenige bessere. Leider scheuen sich viele Verkäufer die Dämpfung anzugeben, denn die ist dann ja auch noch Frequenzabhängig. ,da weiß man erst hinterher wie hoch die ist. Deshalb die Kabellänge vorher berechnen Beim RG58 würden dann 6,5m schon die Leistung halbieren. 2m ca 20% rauben.
If the attic is well insulated, it makes sense to put the antenna on the roof. Some insulations attenuate the signal more than a wall.
But as @kersing wrote, the cable will quickly destroy the antenna gain if the cable is too long.
A cable like RG58 has about 0.46 dB attenuation/m at 800 MHz. There are also some with more than 1 dB/m and only a few better ones. Unfortunately, many sellers shy away from specifying the attenuation, because it is then also dependent on the frequency. You only know afterwards how high it is. Therefore, calculate the cable length before At RG58 would then 6.5m already halve the power. 2m rob about 20%.
Well, that’s a matter of opinion. If I can get the data locally immediately, it’s worth the effort.
Setting up a chirpstack instance is not that difficult. And it is lightweight because it requires just a view resources. But admittedly additional effort is required.
I think that’s an exaggerated view.
Sure, that would be the chirpstack instance.
The Mikrotik Gateway can do that. He can send payload from all heard sensors to all registered servers in his configuration. Sure, the gateway send all data two times.
At least that’s what the guys in the Mikrotik forum say, and one guy showed so on youtube.
Be aware that the metric that TTI work to for radio link packet loss is 10%. Typical real life figures in community installs which are normally less radio-active (!) are ~2-5%.
So if you need to get the data quickly, you presumably need to get the data reliably as well. Hence my comment.
That’s not the same thing - you appeared to be saying you would configure the device to send to Chirpstack and then have that relay over to TTN which has immense technical challenges. I took this to mean have the gateway send to CS and then relay it on to TTN.
Gateways that can send to two different LNS’s are available off the shelf - I’ve probably got a couple in the pile somewhere - but you then run in to issues with duty cycles on downlinks - forum search will help here.
Experimentation & exploration is what TTN is all about, but please be aware that as the forum is funded by TTI we focus almost exclusively on TTS. And as TTN is a community network that comes with some responsibilities for those deploying gateways, the community expects a deployed gateway to be routing as expected with minimal downtime.
