I am trying to know if it is possible to make a LoRa Wan repeater out of the Heltec Wireless Tracker that uses the SX 1262 pin. So far, I have gone through some threads saying you cannot make a repeater from LoRa wan but from LoRa p2p only.
I have found a thread of something similar but I am not sure if this is compatible with the SX 1262 chip and the device that I want to implement it on.
For my project, I just want the repeater to forward packets from the node, to the gateway.
The thread you quoted describes that a repeater for simple LoRa P2P is possible.
There is no suggestion in the thread that such a simple ‘repeater’ would work with LoRaWAN.
Given how many years LoRaWAN has been with us, if a simple LoRaWAN repeater was possible and sensible you would expect to find plenty of working examples …
Yes if you have the most amazing level of skills with the LoRaWAN specification & writing large complex stacks.
Or if you want some lesser pain, you could port the new stack that supports a relay option to the ESP32.
Otherwise generally no. The simplest solution is to run LoRa P2P from the sensor to a ‘repeater’ that switches between P2P and LW - this is not trivial but RadioLib can do it.
The thread you quoted describes that a repeater for simple LoRa P2P is possible.
There is no suggestion in the thread that such a simple ‘repeater’ would work with LoRaWAN.
Noted. I will try to get it to work with LoRa p2p.
I cannot seem to find the GPIO pin number for the DIO2 pin/tone pin. I have tried looking at the datasheet for the board I am using but I can’t seem to figure out or interpret what GPIO number it is.
The schematic you’ve linked to doesn’t look like the one from the product page.
P2P isn’t a topic we support or discuss on this forum - it’s all LoRaWAN for TTI/TTN as they fund the forum. DIO2 isn’t needed for LW, the Heltec or Arduino forums may be able to assist.
I think it is not rocket science to make a repeater for LoRaWAN but I cannot see a practical benefit. The originating node could encapsulate a LoRaWAN frame within an outer LoRa frame to be propagated by LoRa nodes until it reaches an exit node where the outer LoRa frame is unencapsulated and the LoRaWAN passed to the LoRaWAN network. This type of tunneling mechanism is commonly used by multiple networking protocols.
If you have a LoRaWAN stack on a device and rather than transmit the final payload, you stick a ring on it header on it and send via point 2 point or a mesh and at the node near a gateway it unwraps the message and then pretends to be the originating device?
This will break ADR which is rather useful for maintaining bandwidth in a busy spectrum, so we’ll have to turn that off at the server. How about user downlinks? I guess if the exit device ‘looks’ like the original one, then it will pick up the downlink but by that time the originating device won’t get it in time.
But as you need to make radical alterations to the original devices firmware, probably easier to use the official relay spec which covers all the nice-to-haves of LW for us.
The real ambition is to have something that can take an off the shelf device with current firmware and provide a relay or repeater. The relay or repeater can be all-new-rocket-surgery firmware, but the challenge is to use devices straight off the shelf so you can pick & choose from all the devices currently available.
I built a similar solution on a STM32 Bluepill a few years back but not for a repeater application.
I entered a competition that required a solution for environmental monitoring (Wildland fire / Bushfire detection) using geographically dispersed sensor nodes deployed in remote areas. I picked LoRaWAN as the technology of choice however for the evaluation process, where the sensor nodes were tested in test chambers and where I had no control over where the sesnor nodes would be deployed for the field testing, I implemented both a meshed LoRa and a LoRaWAN model. In my case, the sensor nodes ran a dual network stack, LoRa and LoRaWAN with the node data sending the same data to both. The Bluepill handled both network stacks and all other functions of the senor nodes. For the mesh part of the LoRa solution I implemented proprietry solution where each node functioned as a cross between an Ethernet switch, a Token Ring hub and a router.
Back to the question about the ESP32, yes it can do that but if that is all you wanted to do then the ESP32 would be an overkill.
I can see its possible to have something like an ESP32 listen on a single P2P LoRa frequency for P2P node data and then forward that received sensor data via LoRaWAN.
But that is not really a LoRaWAN repeater, it would not be able to pick up LoRaWAN traffic on each of the normally 8 possible channels and repeat or forward it.
Maybe the way forward is to have a small box with gubbins in it that, upon disassembly, turns out to be a full gateway with LTE modem. Or full gateway with microwave link to civilisation.
If you were coming from peer to peer or even a bridged LoRa network then you would most likely be using a single channel on the LoRa network. However the reason that I think the concept does not make sense is because the edge node is receiving data directly or indirectly from multiple LoRa nodes and therefore the edge node has to forward the sum of all unique frames from the LoRa nodes and therefore you have a single Edge node injecting to much traffic leading to fair usage, LoRaWAN throttling and regulatory issues
There are techniques for mitigating this - white listing, reasonable uplink intervals and if you are in to this level of tech, you’ll be on TTI so FUP isn’t a thing.
Plus there is the official spec which seems to cope just fine.
A bit of a generalisation, but the use case is to get a handful of devices in to range. If you’ve lots of devices out of range, put in a gateway (on solar with LTE if necessary).
And if you keep banging in to this as a problem, most devices are easily replicated or even off the shelf ones reprogrammed to do LoRa P2P which goes to a dual radio repeater/relay. I’ve built a BLE temp sensor (coin cell power) to BLE Listener to LoRa and then a LoRa to LTE or Swarm (satellite) relay. For urban deployments, BLE to LoRaWAN. Each part does it’s thing so there’s no co-ordination needed. All these things are solvable.