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 
1 Like
Hi,
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?
Martin
2 Likes
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.
Hi,
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
rssi-threshold=-150dBm
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.
Thanks
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.
I changed the parameter to forward=crc-valid and after about two days my console says that it received (only) 57 packets - even if I can not see the details of the packets received under Traffic tab. As you said, I will wait to get the LoRaWASN sensors to make the tests, however I would expect more traffic to appear from random users/sensors while the gateway is installed very close to a highway.
F.
There are 2 other gateways within 3 km around yours though those have been offline since December. And quite a bit more when extending the distance. So yeah, maybe other LoRa(WAN) transmissions are to be expected. Of course, antenna placement will be crucial; see Best position for a gateway.
You might want to join the Athens community; maybe someone can tell you if your area should indeed see a lot of traffic, or not.
Note that the gateway’s Traffic page in TTN Console does not show historical data; it will only show packets that are received while you have your browser open. But indeed the total counter will show you how many LoRa packets have been received (even if not LoRaWAN, or if not TTN).
1 Like
I just received the sensor and it seems that something is working here 
Attached MikroTik & Console screenshots.
It’s not very clear to me, but I feel that this is a good point to start working with the sensor (i.e. interpret data and so on).
F.
1 Like
We finally got the stock in, we now have cards, gateways and antennas:
Regards
Nick
I just installed the LoRa8 kit and am also seeing lots and lots of “error” packets.
I wonder if it may be traffic from nodes belonging to another provider which is using a different CRC encoding?
I only forward packets which are considered valid, so it will not give load on the TTN routers.
But this is not the default setting, so might be good to make a note of that in manuals like this one
I have several hundred Mikrotik routers on my network and Joshaven is a friend of mine. You can trust his Winbox for Mac package.
Getting ready to do a fairly large geographical area and am considering the LoRa8/9 cards. I’d like to have 16 channels but I don’t know yet if I can add two LoRa8/9 cards to a RB33 or not. I’ll know as soon as I have a minute to test it I guess. Has anyone tried this? I’m in the US so we have lots of available spectrum and higher output power but a few other archain rules not imposed in the EU/UK.
1 Like
If you are looking to use TTN you shouldn’t bother as it only supports an 8 channel channelplan (at the moment).
1 Like
Thank you, Jac, for the heads up. I did know that (being in America has made LoRaWAN rather confusing as there isn’t nearly as much information) My project doesn’t just have to be just TTN. (thus my thread over in the Intracommunity Knowledge Exchange channel, in fact, it doesn’t have to be TTN at all so I’m looking for people to pitch me on why I should. )
1 Like
I noticed that wAP LoRa8 does not report time, latitude, longitude and altitude with uplinks.
Is that normal behavior?
1 Like
Most of the messages with CRC error have a low spreading factor (SF7), poor SNR (-14 to -11) and RSSI of -100 and less, which probably explains the CRC errors.
You won’t see these messages on the TTN console so when using other gateways without local traffic logging, messages with CRC error are normally not noticed.