Hello. I Finally got my gateway in and attempted to get it connected to the TTN, but it doesn’t seem to be seen by the cloud. I setup the Gateway, rebooted it, and let it sit for about 45 mins, but nothing. The Gateway is on my network and is running.
This is the info from the Gateway
$ gateway-version
Raspberry Pi Zero W Rev 1.1, OS “10 (buster)”, 4.19.75+.
RAKWireless gateway RAK7246 version 4.2.0R install from firmware.
Gateway ID: B827EBFFFEC9E57A.
Looking at my account, it shows
Gateway ID eui-b827ebfffec9e57a
Is there any way for me to look into the where the issue might be? I’ve tried searching around, but haven’t found anything that works yet.
@garengllc, the 7246 is as simple as it seems following the instructions on the RAK website so it’s reasonable to assume you’ve done all the right things.
If you have a gateway, do you also have a device setup for TTN??
The best test is to watch the logs on the 7246 for incoming uplinks from your device that then appear on the application or device page on the TTN console.
I am starting from scratch (hardware and knowledge wise), so I am sure I could be doing a few things better.
The 7246 is on my network and I can ssh onto it.
I have a board with the Microchop RN2903 module on it. It fires up and makes transmissions (uncnf) and I can see it on my scpecAn, so I know it is transmitting. I attempted to register the device, but I am not 100% confident that I did that right. The C code the micro is using only had three variables that seemed to pertain to this (he said to copy it from the TTN console):
const char *devAddr = “”;
const char *nwkSKey = “”;
const char *appSKey = “”;
I setup the first
*devAddr = “05060709”;
I am not really sure where I can grab the nwkSKey.
The appSKey confuses me also. I see where I can grab the appkey, but I think that is different from the app session key
OK, TTN seems to be seeing my gateway now, so that is one problem solved. I didn’t do anything, so I am guessing that they fixed something on their end. My end nodes still aren’t being seen, so that is the next problem. I still feel like they aren’t setup properly somehow.
And just like that, I think data is flowing through. I am probably getting lucky as you can see this is with the wrong device ID (another one I previously setup), so I am not sure if I re-compile and load if I made other changes that will screw this up, but it at least shows that some level of things are working.
It absolutely won’t work without the keys - which will be on the page you setup the device. There’s a whole learn section that explains all the different setups:
Thank you to everyone, I think I have things kind of working. What is odd to me is that I seem to lose A LOT of packets, is this normal? I have the end node and the gateway in my basement, and both have proper 910MHz antenna on them. I am obviously sending data a lot faster than I plan down the road, but even with sending stuff once every ~45s, I am missing a lot of transmissions.
What would cause that? I tried to switch to confirmed (instead of uncomfirmed) mode, and that didn’t really seem to change much.
They may be too close and you are overloading the input stages of the gateway. Put one of them behind a good solid brick wall or put the gateway upstairs.
There’s really no need to spam the heck out the TTN infrastructure and the frequency of transmission is wholly unrepresentative of normal use - try doing normal and see what happens.
Confirmed mode will make things worse as there will be even more transmissions - it certainly won’t fill in the gaps, if the gateway doesn’t hear the uplink, it won’t confirm it.
Setup some debug output from your device, your gateway, the TTN console page for the gateway and another one for the device. And then trigger a send and see what happens. But please, turn off the fire hose of spam.
Make sure the node and gw isn’t too close…look to be >3m pref >5m apart and with some kind of absorber in between to avoid overloading front end and data spillage to adjacent channels which can confuse the baseband decoder and rf front end. Also if in a basement be aware that reflections and multi paths are something that LoRa can be quite resilient to where they will often kill legacy modulations and may make signal strength worse (too strong) close up.
Many LoRaWAN software stacks have built in duty cycle regulation implementations limiting txs if you breach duty cycle limits or dwell times… I believe the microchip modules do this though unsure of specifics for us version vs eu. Be aware of the TTN FUP even if not yet imposed (search forum).
I have the gateway separated a decent amount with a wall in between, but I will separate them more.
Good point on spamming the TTN, I didn’t think about it that way. I am sure the infrastructure wasn’t expecting that much information coming from a single gateway. I’ll dial that back this morning!!!
