I have been looking for a way to extend the range for a long time so that, for example, if a mountain is in the way, I can set up a receiving / transmitting station on it to be able to continue transmitting. I then found this code and my problem is the following: a message is only received sporadically and only about 30% of the received messages are then actually sent again. Of course, this is anything but a solution to my problem.
Does anyone of you have an idea or a program that could solve my problem?
I already have a Lora gateway with IC880A board + an external roof antenna (DELOCK) the communication within sight is great, of course, but my sensors are behind a large mountain so I need a solution to implement a small signal repeater. Hardware is not my problem, I will use a Pro Mini 3.3V with SX1276 and solar regulator, everything works perfectly. But how can I receive my signals and send them out again?
I wanted to have 2-4 sensor queries per day that would also work with SF7 / 8 but with the mountain I have no chance even with SF11.
There have been white-paper type proposals for LoRaWAN repeaters, but itās not trivial. The actual nodes have to have knowledge of and support the idea of a repeater, since if the repeater has only a node (vs gateway) type radio, then the channels and spreading factors that nodes connecting through it are restricted, and additional thereās the added time delay before the receive window to allow for the repeating.
Basically, research the work thatās already been done, but recognize itās probably not ready for actual use yet.
What would probably make more practical sense would be to set up and actual gateway on the mountain. The SX1302 chip may be getting power consumption to the point where when paired with a very low power computer, solar power might be more realistic than it was with the SX1301 generation.
Of course, it would be nicer to build a high-performance gateway on the mountain, but you would have to take the risk that it will be stolen and therefore for me or most people who have such a problem, only the variant with the low cost repeater (arduino / Sx1276 ) in question.
I honestly see no problem in receiving my signal that I will send 2-4 times a day via a 1-channel repeater and again e.g. 8 seconds after receipt to send again. I am sure that I do not burden the Lora network any more than when my node is constantly trying to send its data to a gateway that it cannot reach because a mountain is preventing it from being received. and in the end my node would have only sent on one channel under conditions of visibility;)
I think many currently have the problem with the mountain / distances / or sources of interference where such a cheap repeater could quickly help. the program is just running, I donāt understand why it doesnāt receive the signal more often and send it back again maybe I did something wrong ?! Of course it is clear to me that the frequency and the other parameters must match in order to receive a signal. greetings Marc
Just to check the obvious, are you hoping that @LoRaTrackerās relay will relay for LoRaWAN or are you using it to get some data from the device point to point?
The code base works off a fixed channel / DR - whilst a LoRaWAN device will use a variety of channels which may explain the lost packet rate you are seeing.
It shouldnāt be so hard to have a module that listens for incoming LoRa packets and re-broadcasts the data over LoRaWAN. Somewhere on my todo list is to recycle a Dragino OLG02 outdoor gateway, using one LoRa module for receiving from remote nodes and the other to retransmit the incoming messages on LoRaWAN. Note, this is NOT a LoRaWAN repeater and Iām sure Iām about to be told why this is a terrible idea but the scheme works just fine with my NRF24L01 to LoRaWAN repeater which listens for incoming data packets from a collection of devices in the near vicinity, pre-processes / packages / respects duty cycles etc and relays the information via LoRaWAN. This allows metal & concrete outbuildings to have sensors in various places and the repeater/gateway positioned at a convenient point at the boundary.
The fundamental problem with any of these schemes is the single frequency / single spreading factor receive - just like a āsingle channel gatewayā
If you were going to work around those, then the next problems are that an OpenWrt Linux isnāt a great way to do precisely timed things - eg, uplink is fine, getting the downlink receive window timings right will be more trick. For an end device, you could just run the radio longer, but this needs to not only receive, but also re-transmit the downlink with precise delayed timing. Finally you have the issue of power consumption - with an SX1302 rather than SX1301 the computer is now the dominant power consumption in a gateway an OpenWrt gateway, no longer the radio.
In short, a ārepeaterā is more an MCU task than a Linux one (Iām actually thinking of doing some more serious investigation of RTOS-threaded type MCU possibilities for running a gateway)
But a LoRaWAN repeater also requires changes in node behavior - Semtech has thought some of that through, but it doesnāt seem to be deployed much.
The situation for collecting 2.4 GHz uplinks is quite different - even if you do it ārightā in using multiple frequencies, things are so much faster with GFSK semi-reliable on-air meetings are more viable, eg, BLE advertising uses the same modulation and three advertising channels, counting on transmitter and receiver matching āenoughā of the time.
I understand that, but the problem lies elsewhere. I have the following as a setup for the test:
A Lora Node sends (OTAA mode) to my in-house gateway, which can process the full LoraWan spectrum, i.e. the large number of channels etc. each send is received perfectly so far so well.
Then I set up a ārepeaterā using an arduino pro mini 3.3v and an SX1276, as software I use the linked version, of course, adapted to my needs, e.g. SF7 / code rate 4_5 / frequency: 868.100MHz and bandwidth 125K
Now I have assumed that every signal that corresponds to the channel 868.100MHz is also received and continues to repeat accordingly, but unfortunately this only works very randomly and not always when a suitable signal in the channel range 868.100MHz arrives.
Of course it is clear to me that the SensorNode is on other channels, for example. 868.300MHz or 868.500MHz sends of course cannot be heard by the 1 channel repeater because I have set this to channel 868.100MHz;)
But I donāt understand why signals that correspond to the parameters of the repeater are rarely received and ultimately passed on.
the only thing I could imagine would be that it may be due to the frequency deviation, but how could I check that? I have an oscilloscope and a Malahit SDR up to 2GHz here.
Here my adjustment regarding Freq etc. in the code:
By the time you actually put something on a site with a weatherproof enclosure and find a way to power it, the difference between $10 and $90 for the radio isnāt that significant. Typically antennas go on poles anyway, and LoRa gear is compact enough to mount it on top of the pole at the antenna.
Yes i know, but for my projekt it will be right because:
Lora Node sends on 868.100MHz ā> repeater here only on 868.100MHz get the Payload wait a few seconds and retransmit it ā> my LoraWan Concentrator here it and send it online. so all good but the problem not all signals will here by the repeater and i dont know why ? regards
Trying to do this is deeply at odds with how LoRaWAN is designed to optimally use radio spectrum and legally allocated duty cycle.
First, you basically have to use multiple frequencies.
Next, even on a given frequency, LoRaWAN utilizes multiple spreading factors, but your node radio can only be configured to receive on one, unlike a gateway radio that receives on all at the same time.
What you are trying to do is not trivial in the slightest. People who really understand LoRaWAN have put a lot of thought into how to make this work, and rather than guess from a perspective lacking understanding of the ordinary operation, spend some time reading the white papers on LoRaWAN repeaters.
If I want to pass on a downlink Iāll do it when it suits me. I use P2P as I see fit and use LoRaWAN as designed and join up the two in the middle as appropriate to the application.
As I said, Iām NOT trying for a LoRaWAN repeater, Iāve something that can pickup sensor data in an out of LoRaWAN coverage area and relay it on. The recycling of the LG02 is pure convenience, a wise man once told me that Real Men are scavengers. If it doesnāt work, Iāll just wire two Pro Miniās back to back.
Itās not clear from reading this post if you are trying to relay LoRaWAN packets on just one channel - it seems you are. I can see how that could cause issues.
There are some tuning issues that we come across with LoRa to LoRa for High Altitude Ballooning - you can set both to 868.100 but have the tx actually on 868.105 and the rx thinks itās 868.095. So implementing some AFC scheme is a good idea.
If you have a LoRa device do your sensing and it transmit using LoRa to another box that sits listening for incoming LoRa signals and then transmits as an original LoRaWAN packet, Iād be pressed to understand why this shouldnāt be reasonably reliable.
If you want it to be received youāll need to pass on the downlink when the nodeās radio is awake and listening.
In a custom scheme you can chose when that is of course, but you have to match it, which is harder to do precisely under a Linux scheduler than with an MCU.
Extending the SPI driver to give some sort of stage & release at kernel timestamp might help (eg, with an SX1301 you load a packet into the buffer with a future time and the hardware transmits it exactly at that time with no software latency)
Can it be done? Yes, but less accurately, meaning youāll need wider receive windows than normal.
The recycling of the LG02 is pure convenience, a wise man once told me that Real Men are scavengers.
One interesting solution might be to graft the code into u-boot rather than run it under Linux, essentially using the AR9331 as an MCU. You could possible even not activate the clock PLL and save a lot of power. It would however put the whole thing under GPL.
I understand, but it doesnāt make sense ā¦ if it works great point to point. why doesnāt it work with me? I am currently not talking about the LoraWan gateway but about the fact that not all packets are heard even if they are only sent on one frequency, it does not work. I have my transmitter code (Lora Node) now so far that it ONLY transmits on 868.100MHz and then the repeater should āalwaysā hear the signal and send it out again. or what am I seeing / reading wrong? Greetings from Germany
this code :
for (int b = 0; b < 8; ++b) {
LMIC_disableSubBand(b);
}
My āplanā the sensornode uses the Code A but will not send every 60sec i will set it to send all 6 Hours one time.
The āRelay Nodeā will get the Code B because it is always listen and when it getās the data from the Sensor Node i set it to send out after 4 seconds at this time the āSensorNodeā is sleeping and the only member that can recognize the payload is now my gateway.