The Things Network (TTN) is a community, that aims to build a large network of long-range LoRaWAN and for short range Bluetooth 4.2 gateways to enable communication of IoT devices without 3G or Wifi. It looks very cool, and a lot of gateways seem to exist already.
Looks like some of those gateways, that let LoRa and Bluetooth devices to connect to the Internet, is deployed over resin.io. Here are some project we’ve seen recently to do that:
Would love to hear if anyone has experience with these or with LoRa or with TTN!
Sure! I do. As one of the early builders of the things networks in Amsterdam, I also ported some software over to Resin.
Resin is great for cross compiling the packet forwarder. It is a pity that most professional grade gateways have such tiny embedded computers in them, Resin isn’t possible. Just only running busybox with some 100ish MB’s left for the packet forwarder. I might just hang a raspberry pi beside the gateways to manage these darn things.
Pro tip for the guys linked above. The packed forwarder seems to crash a lot. There should be some mechanism that detects and restart this. Otherwise, you cannot login your resin device anymore
Btw. I am writing new software for de Lorank8 based on Resin. It actually has a beaglebone inside.
I am busy putting a pilot project together using Raspberry Pi 3 and RisingHF radio module. It’s proving to be quite the challenge BUT resin.io has made it MUCH simpler! Thanks to the ttn-resin-gateway-rpi project on github! Thank you!!!
I cannot seem get a node up and running for some reason. I have followed every possible guide and forum post I can find my hands on and I seem to still be missng something. The latest guide I found had the most promise, but even though I follow it to the letter I have not yet come right. It doesn’t get past ‘Joining’ … It sits on that for a whle and then repeatedly returns ‘joining failed’ messages.
I followed the following guide once I managed to get my gateway registered on TTN:
I am using the standard Adafruit Feather 32u4 LoRa radio … NOT the M0 version. I went through all the comments and did all the suggestions, and cannot get it work. It receives a radio packet, but I get an CRC_Fail 100% message.
How would I view the Packet Forwarder’s logs? Does it run in the Docker container because I cannot find any logs when I log into terminal using resin.io website terminal. Since I installed resin.io I don’t know how to log into device using ssh because I dnt know credentials I’m supposed to use Any ideas?
The packet forwarded should be running in your application container, so if there are logs to debug, that would be the right place, IMHO. You can check whether the program is running, or try to start it manually in that web terminal, etc… Since the initsystem is enabled, you can use systemd’s journalctl to look at all the logs inside the container for more info…
You can also check out resin-cli that lets you remotely log into the user container just like in the web terminal, or and a bunch of other things if you are using a .dev version of the OS to debug (such as Local Mode)
Personally I think the solution will be in the user application, not in the host OS, but the best is to test…
Thank you for the responses. I have made a small amount of progress but I have to admit that I am a little lost. I cannot find the place to check for the logs of the packet_forwarder. I know that it’s not your project, but the logs are displayed online so I can only guess you must know where the logs are stored for you to read and transmit online.
I need to add more details to the logs. I keep getting CRC_Fail errors and need to see what the actual packets are being received so firstly, where would I find the logs? Secondly, would anyone have any idea how I can increase the verbosity of the log data of the packet forwarder? I am running the following application:
Do you see this in the logs? Does the run.sh script run without errors?
What happens if you SSH into the container and run ./ttn-gateway? Does it throw an error? You could try passing the --verbose flag and see if that gives more detailed messages. Any logs the program outputs should be printed in the terminal.
Maybe try uncommenting these hardware debugging lines.