I have been looking at TTN as a way to simplify the process since using LoRaWAN should take care of the implementation of the communication layers 2 and 3, and use the raspberry as a gateway to ttn that gets it’s internet from a phone.
However, It’s very important for the project to also work in situations where there is no 3g/4g coverage, using the raspberry itself to show the sensor data to the user on the field, and I don’t know if this is possible using LoRaWAN or if my only choice is to use a direct LoRa connection between the two devices.
Tracking with LoRaWAN\TTN would require that your drone is in range of a Gateway. If the areas where you want tracking do not have 3g\4g coverage there is a good probability there is no TTN Gateway coverage either.
TTN is not a good fit for a lot of GPS tracking applications. In best case circumstances, close to a Gateway the fair access policy limits you to 555 transmitted packets a day, and if a long distance from a Gateway the limit is 24 packets a day. Its reasonable to plan for the worse case scenario.
The plan was to bring my own TTN gateway for that purpose (either one I bought or one I made with a RPi) but that bit about fair access policy is extremely helpful.
That was my question, whether it would be possible to use the LoraWAN protocol for MAC and use a localhost server to host the web application in situations where there is no internet.
The gist I got was that it wouldn’t be possible since the gateway itself cannot understand LoRaWAN packets but I wanted to ask just to make sure I wasn’t missing anything.
Your college supervisors appear to have set you up to fail on so many levels - GPS over LoRa, gateway / mobile coverage
Doesn’t seem any point sending data to some remote server that’s going to be tricky to connect to and then have it come back again for the display. Just use point to point LoRa - there are plenty of libraries that will do that for you out the box.
First, there are gateways that have a LoRaWAN network/application server running in the box itself, for example RAK’s MT7628 based offerings (they are also a bit more robust against unexpected power loss compared to a pi). Of course, if you are using one of those with its on-board server, then you are not using TTN, and so the discussion becomes off topic here.
Another is that if you use LoRaWAN and TTN in an “uplink mostly” way - which is to say ABP and no ADR, then if you know your node’s secrets, it’s possible to decrypt and validate the raw messages yourself, without relying on them passing through the network. Nodes that move around a lot can’t really use ADR well anyway, so mostly you’re left with the operator hassle of doing ABP correctly.
The one thing you’ll need is software to run on the gateway to “split” the feed and give the packet forwarder enough acks that it doesn’t give up and error out in total loss of connectivity. I think there are version of the packet forwarder which will report to two servers (hopefully they handle the loss of one). Another solution is to whip up your own program in python or whatever that you run locally on the gateway which acts as a proxy server for the Semtech UDP protocol - you point the packet forwarder at that instead of the real server, it answers the acks, and it also tries to pass the traffic on to TTN (just ignoring failures) and also your own own on-board decoder scheme. (It also must pass transmit commands from TTN back to the gateway with little delay - even if you are not using any downlink’s other people’s nodes could be picked up, and if the TTN servers elect your gateway to send a response, it would be misleading and detrimental to the network to fail to do so)
Most of the problem in sharing a device between networks comes if you use OTAA, ADR, and if more than one of the networks would ever command a downlink. It’s easier to make your own custom decoder listen-only than to try to make it transmit, so you can chose a path that makes all of this work.
Along the way you’ll gain understanding of a lot of LoRaWAN’s underlying mechanism.
Or you can just do point-to-point, if you think there will never be enough tie-in to TTN for that to be beneficial. Point to point would make using a cheap node-class radio in the base station more viable, but would also mean you couldn’t benefit from other gateways out there which might be in range when yours is not.
Also consider that flying a drone beyond visual range is in many places illegal without additional operator licensing.
Point to point LoRa is far more configurable and with the newer LoRa devices (SX126x series) you would be able to operate reliably at much lower bandwidths than used by TTN, lower bandwidths gives more range\distance.
Choose the right band and there are no duty cycle limits and no fair access TTN limit to keep too.
The obvious one would be being able to leverage a theoretically wider assortment of gateways - if the node gets “lost” there’s more chance of one being in range.
Only if there’s something in range to receive it.
But you can do both - alternate a TTN compatible packet and a TTN incompatible one.
The inexperienced probably want to start with an SX127x solution for which there’s a lot more software support rather than the newer chips though.
Why do you want to attach a GPS tracker to a drone in the first place ?
If the drone is being flown by normal RC means, there should be back telemetry avaliable, especailly on 2.4Ghz RC control, that already tells you where the drone is. There are a number of systems in the radio control world that do this, even some very long range LoRa ones.
The OP says that it is a college project. I imagine that the purpose of the project is to demonstrate the ability to investigate options, evaluate each one, compare/contrast the characteristics and develop a working prototype. Telling your teacher that the drone already has a tracker isn’t a great way to get good marks
