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.
I faced same problem. Did you get any reply?
I don’t have the complete answer for how to properly configure the LoRa8 as WiFi client (aka Station), but the first steps are to disable the firewall (to make the configuration menu accessible via wired LAN), then connect it to wired LAN via the RJ45 connector and from there continue with steps to configure it as WiFi client (when wired your connection won’t be dropped during WiFi configuration).
Also see the following:
Now in stock in the UK, yell if you need any help with them
Regards
Nick
I’m looking for the Mikrotik LORA8 gateway with the 6.5 dbi antenna kit.
Does anyone have experience with this?
2 Likes
I can give positive feedback on this combination.
It is really a priceworth out of the box solution.
For those unfamiliar with router configuration mikrotiks routeros may have some pitfalls.
But compared to other Gateways we have really reliable router as base with a LoRa concentrator on top.
As antenna connector i would prefer a N-Connector especially on the antenna side.