Hi All,
I am trying to connect my RAK3172 module with TTN by OTAA. But the device is not joining TTN.
This is the error I am getting:
I am using RAK2245 as the gateway. The frequency is set to IN865.
Hi @d.prasannaakumar ,
I already replied to you on Zendesk.
But regarding the MIC mismatch, you need to use a different APPKEY. Just regenerate it under settings.
Update your RAK3172’s APPKEY then rejoin.
You can also try to re-register a totally new device with different DEVEUI, APPEUI and APPKEY. It wont hurt for troubleshooting purpose.
Hi @carlrowan ,
I tried as you suggested. But it didn’t work. The same error continues;
These are the device registration settings;
I tried again with ABP. It worked a couple of times. I was not able to send data frequently as shown below:
The data is collected by the gateway, but its not displayed in the Application;
Please give me your suggestions. Thanks in advance!
Hi @d.prasannaakumar
In TTN application, did you try to set LoRaWAN version of the device to MAC V1.0.3 and Regional Parameters version to PHY V1.0.3 REV A?
RAK3172 firmware is based on MAC V1.0.3 not V1.0.2 that I saw in your screenshot
Hi @beegee
Thanks for sharing the information. I changed the LoRaWAN version of the device to MAC V1.0.3 and Regional parameters to PHY V1.03. REV A . But OTAA is not working and has the same error MIC Mismatch.
I tried with ABP with the following settings:
But I am facing the same trouble. For the first 2 times, I am able to send data. From next time, it’s not working.
The Firmware in RAK3172 is V.1.0.2;
This is the firmware version, not the LoRaMAC version.Firmware version and LoRaMAC version are different things.
Hi @beegee ,
I just posted in case if there are any updates on firmware versions.
This time I used the LoRa MAC version suggested by you. But it’s the same still.
Also, in the RAK3172 Quick Start Guide, they have mentioned the LoRaMAC version as V.1.0.2
HI @d.prasannaakumar ,
I already asked help from the R&D team regarding this issue.
I setup a gateway on IN865 Band and connected it to TTS.
I found erratic behavior on the uplink as well both on OTAA and ABP (both LoRaWAN 1.0.2 and 1.0.3).
I will let you know whatever we can find.
In the mean time, let’s solved your OTAA joining issue. MIC mismatch is highly likely caused by the APPKEY. I know you already re-register your device as you told above.
But by looking at the screenshot here RAK3172 OTAA not Joining - #3 by d.prasannaakumar
The APPEUI and JOINEUI are different. You could have overlooked it?
I have few RAK3172 devices here and I switch on different regions, network server, etc. to support different international customers so I commonly encounter the MIC mismatc once I move a device here and there. It is always solved by either generating a new APPKEY or re-registering the device.
Also, your RAK3172 is trying to join at Spreading Factor 12. The device and the gateway can’t be to close to each other at that setting. You can try to set the SF to 7 or 8 via AT+DR=5 or AT+DR=4 then try to rejoin.
Btw, I validated IN865 band of RAK3172 in ChirpStack network server and it is working ok 100%. All confirmed uplinks are received.
So the problems seems to be related to TheThingsStack.
Two other observations - the time between uplinks is a bit tight - the LoRaMAC-node code may be rejecting uplinks as being out of duty cycle.
Additionally, you will be killing local reception by using confirmed uplinks which on TTN are completely highly not recommended or wanted or desired or acceptable on a normal basis. A confirmed uplink requires the gateway to transmit which means it can’t hear any uplinks whilst it is doing that.
Hi @carlrowan ,
The same happened to me.
We are working on a project of installing around 200 - 300 nodes around the city. So please do find a solution for this.
It’s different in the screenshot. But I have used the correct ones in the device matching to TTN. As you said, I was using SF12. I’ll try with SF7 or SF today.
Thank you for sharing this Carl. I’ll try on Chirpstack. BTW, I am new to Chirpstack ecosystem. Can I use the chirpstack running in the Gateway (RAK2245) to connect with a Raspbery Pi standalone server that runs Chirpstack?
Hi @nmcc,
What do you suggest me to do? Please give me an Idea.
Hi @d.prasannaakumar ,
Yes. We’ll figure out.
You can use the built-in chirpstack in RAK2245. That’s the one I used as well on my Chirpstack testing.
Don’t use confirmed uplinks. If the data is of a critical nature LoRaWAN may not be the best solution. If the data can’t cope with gaps due to missing uplinks (TTI say to expect 10% loss), then keep the data on the device and purge it out after a day or so. Then you can ask for the data to be resent if necessary (bearing in mind that’s a downlink).
And noting above, SF11 & 12 shouldn’t by used as standard - the device may use that to join but ideally with ADR turned on it will allow the best power & transmission time to be setup by the network server. The transmission time at those levels is measured in seconds which means there is more time for another transmission interference and signal path issues to prevent reception.
Hi @nmcc
The concept is Simple I just need to send 5 parameters to Tago (Temp, Humidity, UV Index, AQI & Atmospheric Pressure) once every 5 minutes. Also, there is an internal data logger.
What if I use Chirpstack instead of TTN? I haven’t used Chirpstack previously. So please do tell your suggestions.
I understood it lately and now I have changed it to SF7/SF8.
Thank you for the Support!
It’s a function of radio waves, not the back end servers - so you’ll probably get similar results even if you run your own server.
Thank you for letting me know Nick.
I just have one more doubt regarding RAK2245+Chirpstack. Just now I installed Chirpstack in RAK2245+Raspi 4. Can the web UI be accessed remotely when I install this gateway somewhere far from me? (The pi will be connected to Local WiFi)
The built-in chirpstack of RPI4 is local. You can create scripts probably via MQTT that can run to it and send the data to some server. I am not sure if you are capable on doing that. But you can run chirpstack as well on cloud like AWS, Digital Ocean, etc. You just need to update the packetforward to point on the server location.
Some updates about this @d.prasannaakumar @nmcc , I am confused too why IN865 is working smoothly on chirpstack. If I move to TTS, the erratic uplink behavior persists. I validated it not just on RAK3172 but on WisBlock and RAK4270 as well. On chirpstack, all is ok. But if it is in TTS, it seems that RX windows of the devices are not getting anything RF packets from the gateway.
My colleague tested RAK3172 in IN865 band on TTS using RAK7268C gateway. It works smoothly. I am leaning towards it is related to the gateway-LNS connection.
@d.prasannaakumar is using RAK2245. I am using RAK2287. Both are Rpi based gateways.
Hi @carlrowan ,
Hope you’re doing good.
I have installed the gateway successfully. Soon I’ll continue by testing it’s range. Thought of sharing the pictures with you.
Nice. It looks great!
What gateway is that? I don’t see any lighting arrester. I am not sure about the weather there or if there is tower with arrester nearby. But some good to consider too 
It is RAK2245 running Chirpstack.
There is a lighting arrester nearby (around 100 meters). So I didn’t consider installing one. Should I install one?