MikroTik LoRaWAN gateways and concentrator boards

Another supplier listing

EuroDK has a Mikrotik section entry for it, but, no products listed as yet.


LinITX also have the wAP loRa8 on backorder for around December.

Mikrotik have officially listed Lora (though the package was already in the testing branch) support in latest Beta OS release.

Mikrotik does not currently have the wAP LoRa8 kit in stock. The estimated time for availability is December 21st.

hi, thanks for this information

We have an office where we currently use a 4g mifi type router as it’s difficult to get a phone line in. I’m also running a TTIG there.

I’m wondering how this would fare as a 4g to Ethernet and WiFi router with Lora as a bonus on the side. Any thoughts?

What is the 3rd party card that you are using?

I’m using the N-Fuse card (https://www.n-fuse.co/devices/LoRaWAN-Concentrator-Card-mini-PCIe.html) but the latest version no longer supports the 3rd party card. I had to downgrade back to the 1st beta version that included LoRa support. I’m waiting on the official cards to come out so I can swap that in.

1 Like

What’s new in 6.46 (2019-Dec-02 11:16):


!) lora - added support for LoRaWAN low-power wide-area network technology for MIPSBE, MMIPS and ARM;

The R11e-LoRa8EU card is shipping now.

Yes, the card has been available this week. The two units ordered from helpful Sonictest in Estonia arrived quickly.

It is possible to assemble the kit from wAP R11e, LoRa8 card, U.fl/SMA female pigtail (and external LoRa antenna).

Yep you can build your own kit so you dont have to wait until Mikrotik ship all components together in the Kit :slight_smile:

My Mikrotik GW just arrived. It is a LtAP Router with the RN11e Lora Card. The GW was easy to setup for TTN and is running fine with LAN connection.

But I am not able to config WiFi to use the GW as a WiFi client, because I want to put the GW on a place without LAN.
As soon as I try to add the WiFi, I cant‘t reach the router any more. I must admit, I have no idea about Mikrotik Routers.
Can anybody help me with this?

1 Like

So I’m now using an LTAP-LTE providing LTE to WiFi and Ethernet routing and also a LoRa gateway for the office. Fantastic LoRa performance.

I’m getting dropouts on the LTE side - apparently Three prefer dual in demand rather than persistent connections so I’ve switched on the Watchdog functionality to reboot when LTE drops. Also worth upgrading the LTE card firmware (although turn off the watchdog for this).

Note the Lora8 gateway can’t do any cellular even though it has sim slots - the mini PCI-e is filled with the LoRa card

I have several mikrotik lora8 cards up and running.

8 pcs in combination with an lte card on a RBM33G board in outdoor cases,
2 pcs in wap R with a wifi or cable backhaul.

and will get my first ltap with lte and lora next week.

all are running stable.


I’m trying to experiment with the MikroTik LoRa card to connect to the router.eu.thethings.network but I couldn’t connect at all. I registered the gateway under console with the respective details (Europe868MHz, ttn-router-eu), but even if I collect RF data, it seems that the gateway remains offline (see pic).


I attached the lora settings as well if someone has any idea.

[admin@LoRa] /lora> print 
Flags: X - disabled 
 0   name="gateway-2" status="Enabled" hardware-id="32353132xxxxxxxx" 
     gateway-id="323531323xxxxxxxx" servers="" channel-plan=eu-868 antenna-gain=0dB 
     forward=crc-valid,crc-error network=public lbt-enabled=no listen-time=5000us 

Thank you

First of all, all packets list CRC status error and packets with crc errors should ‘rightly’ not be forwarded to TTN.

Next, the servers=“” looks suspicious to me, I would expect that value to be non empty.

1 Like

Did you (try to) configure it for only TTN? What does the “Servers” page in your screenshot show?

Though maybe the verbose logging in your screenshot might be incorrect when it’s trying to interpret packets for which the CRC clearly failed (or for LoRa traffic that is not LoRaWAN traffic), a Join Request followed by a Join Accept after 5 seconds nicely fits the expected RX1-timing, so seems to indicate it’s communicating to some server?

But the DevAddr in that Join Accept, and the ones in the downlinks, are not TTN addresses (which should start with 0x26 or 0x27). And assuming this is running as a gateway (right?) then it should not hear downlinks transmitted by other gateways. So, seeing logging of downlinks with non-TTN addresses doesn’t feel right to me.

Unless you know what you’re doing, you should only connect your gateway to a single network.

It seems that the empty server field was the main problem. I set the field servers=ttn while the ttn points to router.eu.thethings.network. All of the packets under traffic appear with CRC Status “Error”, however my Console says that it has received a packet as you can see in the following pics.



Do you think that this is a normal behavior ? I expect a couple of LoRa sensors by the end of next week, so for now I’m experimenting with sensors that may listen on the air.


I missed that both screenshots show Type being Rx for all entries. So, I’d say that the Join Accept and the other downlink are not things that have been transmitted by your very gateway, but have been received by your gateway, just like the uplinks.

Like I wrote above, usually LoRaWAN gateways won’t hear each other’s downlinks. So, either I’m wrong and this gateway receives downlinks too (and there’s some other LoRaWAN network in your neighbourhood). Or it’s weird that the screenshot shows Join Accepts and other downlinks.

I’d guess that the CRC errors are indeed true errors. If true, then the decoded details (such as message type and DevAddr) are just bogus, and that Join Request seemingly being followed by a Join Accept after 5 seconds is just a coincidence.

Assuming that the CRC errors are indeed true errors, then the packet that you got forwarded to TTN (due to using forward=crc-valid,crc-error) is not valid either. TTN cannot know that, as the DevAddr (as far as one can extract that from an invalid packet) is not known to TTN, so it cannot validate the Message Integrity Code (MIC) and will just discard the message, thinking it’s from some other LoRaWAN network (or not even LoRaWAN).

In other words: using forward=crc-valid,crc-error surely will make TTN Console show things, but it’s probably all invalid (or not even LoRa?). But at least you now know that the gateway is connected to TTN. Next, I’d change the setting to use forward=crc-valid.

You’ll have to wait for your LoRaWAN nodes to arrive, to be able to tell if you still get CRC errors then.

Especially that Join Request followed by the Join Accept after about 5 seconds is suspect. Other entries might simply not be LoRaWAN at all, even though the logging on the screenshot assumes they are: the gateway does not know the secrets to be able to validate the MIC, so all it can do is assume it’s a valid LoRaWAN packet where some unencrypted bytes have some specific meaning. And that’s what it shows, even if it’s not LoRaWAN. However, for that Join Request and Join Accept the 5 seconds difference happens to match the OTAA RX1 timing, like I wrote above, and I figured that’s not very likely to happen by coincidence. But maybe it did.