It makes perfect sense, to me.
That relay was, as I have said, set up for point to point LoRa mode.
Point to Point LoRa and LoRaWAN normally use different syncwords, so reception between the two is not fully compatible, although the odd packet gets through.
Now I know that the sync words are different, I can tell you it wonāt work. The sync word is the code that tells a LoRa radio itās worth listening to the rest of the transmission because it is for them and not some other LoRa networkās tx.
I have suggested a number of times that you use the code to create a Point 2 Point setup and then retransmit on LoRaWAN - is this something you can try??
This isnāt rocket science and is somewhat off-topic for TTN but it has itās merits so Iām sure weāll be happy to help.
Fortunately, if it gets complicated enough for Rocket Science, then at least one us (not me) has built his own satellite that has been in orbit, so we do have all eventualities covered.
There is an updated version of the relay code here;
The relay example does default to point to point mode (syncword 0x12) but can be set to use the TTN syncword (0x34) by adding the library command;
LT.setSyncWord(0x34);
In the sketch after the normal LoRa modem setup.
Thank you very much i will test it today and let you all know 
I dont want to waste your time i only search for a solution for my problem with the mountain and no signal.
if someone has another idea the maximum distance to my sensors is 8 km only the mountain is in the way
Regards
Fourth time of suggesting ā¦
@LoRaTracker Thank you very much what you tell me works perfect! the sensornode sends to the relay and the relay retransmit it with the SyncWord(0x34).
The last thing i need to know ist how can i get the relay on transmit side to send the payload to ttn because i need to set the keys etc for joining what is the best and code smallest solution?
@descartes
yes i have read your postĀ“s about it and searched a lot in den www but only the code.zip from @LoRaTracker was now able to get it work
Iām not a programmer and Iām new to the subject of lora, but I am very interested in it and after your initial pointers at the gateway I switched from a single channel to a fully supported gateway because of course I would like to contribute something to the fact that lora is also being expanded if I can only contribute with one gateway, itās one more
greetings Marc
Itās a relay, so the keys in the device it is relaying for will be embedded in to the uplink - it only hears a transmission and re-transmits it.
@descartes ok thats now clear but how can i set the keys in my sender to get accept later after the relay repleying from my ttn gateway?
regards
If you mean OTAA then either the relay may work in both directions subject to not working due to different channels being used for joins or you use ABP and just have uplinks and keep things simple, for values of āthis isnāt a simple situation in the first placeā
i have test now: sender normal ABP with standart <lmic.h> code to LoraRelay code from @LoRaTracker but both sync words are set to (0x34); then i get in the Serial Monitor of the Relay :
How close are they? Too close and they will overload the input stages - try to keep them 5m+ apart or behind a wall.
Note, you are NOT sending TO the Relay - the device is sending - the relay hears it, waits a short while and then re-transmits.
As such, this is going to be hard to test because your local gateway will hear the first transmission from the device and then hear the second transmission from the relay. I believe the network server will politely ignore the second transmission so Iām not sure if it will present in any logs on the TTN console.
But it should appear in the gateway log.
ok, before i test it on my table thats very close. but after your comment i test it in a range about +15meters and the same result. maybe the data is to long ? or what can i am doing wrong?
The relay is for point to point LoRa, where the same settings are normally used in both directions, uplink & downlink.
Does not TTN invert the IQ for downlinks ?
what do you mean with IQ?
The proposed scheme doesnāt handle downlinks at all (and doing so would require HUGE changes to the node) so thatās rather irrelevant.
Its a LoRa setting, transmitter and receiver need to use the same setting, normal or inverted, for the link to work.
ok so if i understand correctly:
I have a gateway that supports the Lora protocol and also contributes something to the general public because everyone can use the gateway and so the ttn network has more availability. But because the mountain is in the way for my use and I am unable to forward the data (simple temperature values) to the gateway due to lack of experience / and because of Loraās protocol, absolutely useless? That canāt be true; / now I realize why there are so many who program their own gateway software and donāt use the official solution. I personally think thatās a shame. Wouldnāt it make more sense to be able to allow a little more and thus to leave the gateways in such a way that TTN also benefits from it, just like the end user who does not always expect commercial goals.
what setting? because i have the sync word like you told me and the original message without the relay reaches the gateway
regards
LoRa is a modulation not a protocol, so this statement is meaningless.
That canāt be true; / now I realize why there are so many who program their own gateway software and donāt use the official solution.
Essentially nobody does this. People make changes to the system and Internet backhaul protocol but changes to the actual LoRa side of gateway software are exceedingly rare, because thereās really nothing interesting there. All of the interesting behavior is in the nodes and network server.
I personally think thatās a shame. Wouldnāt it make more sense to be able to allow a little more and thus to leave the gateways in such a way that TTN also benefits from it, just like the end user who does not always expect commercial goals.
Iāve repeatedly explained that there is a plan for LoRaWan repeaters, worked out by people who actually understand what they are doing. It is extremely complex because it has to be to meet the technical challenge. People are working on it, but itās not ready for deployment, and it will only work with nodes updated to know how to deal with it. If you are interested, spend some time studying the whitepapers and getting familiar with why this is necessarily so complicated.
But thatās what itās going to take to have something generally usable by the community.
Private experiments tossed together by someone who doesnāt yet understand how LoRaWAN works in even the ordinary everyday sense are not going to be useful to the community, and realistically probably not to the experimenter either.
As @cslorabox says, you are trying to warp time & space without even basic Quantum Physics knowledge on something that it was never advertised to do.
There are ways to achieve what you want to, but ANY form of radio relay to get a signal around a mountain is going to be tricky to setup. You could, for instance, look in to a satellite based device as that goes straight up. Or put your gateway (or another gateway) in a property in sight of the device you are trying to relay.