LoRaWAN Relay has long been discussed as a potential capability and (IIRC) 1st aired on the Forum following a presentation by Nicolas Sornin (Semtech) at a Things Conference lost in the mists of time…ok about 5 years back!. It is a subject that regularly gets raised by Forumites so with the recent emergence of the news of 1st commercial deployments as covered here
And with some devices showing potential for early capability to support Relay functions, including even D2D Space based IoT applications, its perhaps time to have a seperate thread to handle LoRaWAN Relay merits and issues discussions…
Before everyone gets super excited, this is not backward compatible with existing firmware, nor is it a mesh. The relay is not a device, it’s a relay. It potentially looks feasible to use device hardware as a relay, but they can’t do both, hence this is not a mesh.
The device(s) that is/are out of range of a gateway need to send a particular preamble to wake the relay, send it’s message and deal with the response. This will require additions / upgrade to the core firmware / stack. This means recompile & flashing as well as implementation.
It’s also got some non-trivial configuration going on on both device, relay and LNS, so not really plug & play for the casual user.
It is going to be great for enabling a few off-the-shelf devices that are just a squeak out of range of a gateway with no feasible way of putting in a filler gateway.
But it’s not a substitute for a gateway if you want to pump hundreds of uplinks through, are obsessed with timely downlinks or generally hoping it’s some miracle cure or going to enable you to go cheap when you should be buying proper gateways.
For many many situations and for the casual LoRaWAN user, if you need a relay because you have a few things you want to monitor that is behind the big metal thing that blocks the signal, I’d look at doing LoRa peer to peer either using any number of the radio libraries that do an out the box mesh, or just create your own LoRa device just like a LoRaWAN device, transmit to your own other LoRa radio device that is setup as a relay and when it gets to a relay that’s in range of a gateway, wrap the message in to a standard uplink with some identifying info. Sandeep Mistry’s Arduino-LoRa lib is excitingly simple compared to the joy of a full LoRaWAN stack, so eminently doable. If I was building a LoRa or ANO other radio to LoRaWAN radio adapter / relay, I’d have two MCU’s with two radios, joined via serial or I2c. Switching a device between plain LoRa & LoRaWAN is fraught with the fun of saving the session state. Also both can listen at the same time.
I2C is fine for master\slave type operations but a LoRa relay type operation requires a master\master setup and the SPI part of the LoRa module interferes with the I2C side interrupts.
I did try for quite a while to make a I2C connected LoRa device using a SAMD21, could not get it to work reliably.
There is of course another lib (mine) that actually has a working example sketch for a one way LoRa relay …
Or you just poll. Or have a separate IO line between the two that is normally set as input wake on interrupt, when either party wants to signal it just makes it an output.
Which chips suffer that unpleasant gotcha??
Dang, sorry Stuart, absolutely, you have far more examples at all levels in your repro. I so rarely use LoRa directly it slipped my mind for that, but I do use your radio drivers when they are required. For others reference: GitHub - StuartsProjects/SX12XX-LoRa: Library for SX12XX LoRa devices
I was trying to do it so that the comms was at LoRa register level, which would mean it was library independant to an extent. Simple stuff was OK but too difficult to get the remote LoRa device to notify, over I2C, when something happened. There is also the complication that I2C transfers are limited to 32 bytes a go.
A high level approach might work, such as in the Serial UART front ended LoRa and LoRaWAN modules. But then why not just do it with Serial UART anyway.
Or maybe just connect two LoRa devices to one MCU.
For client work I do, I’ve got an ESP32 LoRa board with an nRF24L01 and a 433MHz keyfob receiver doing all sorts as a mini-gateway/relay - just need to add BLE at the same time as WiFi or put it on Ethernet so I can do BLE via the ESP32 and a RFID & NFC reader …
As it happens I had tested my lib with two instances of the LoRa device and both LoRa devices were transmitting OK.
A couple of years back I designed a couple of DUE (lots of IO pins on a DUE and its 3.3V logic !) based shield PCBs that will take two or three Mikrobus compatible plugin boards. I also have matching breadboard friendly Mikrobus compatible boards that will take SX126X, SX127X, SX128X, NRF24, GPS, SD etc which is handy at times.
Live presentation from Semtech on LoRaWAN Relay right now at TT Conference Amsterdam. Can be viewed here https://www.youtube.com/watch?v=sw7WuJfkIrg no doubt will be avaiable on YT after the event
Note initial limit is 16 end devices per Relay - L-A tech team/working group looking at spec updates to possibly expand? (But remember LoRaWAN Relay is NOT a Gateway!)
LoRaWAN Relay hopping NOT allowed - re-encapsulation issues - potential for maybe one extra hop being considered…
Where Tim Cooper’s (Semtech) pitch yesterday refered to the SX126x & SX128x & LR11xx devices as candidate end nodes due to need for CAD embedded on newer Si word is that experimental code (not supported!!!) available on Semtech Github that should work wth earlierSX127x Si - obviously dependent on ability to push newer firmware… time to go hunting?
Opps, omitted that one, I’m sure many will aspire to having that.
Thereby exponentially adding to the chain of failure - RF and otherwise.
Apart from a single relay being use to get a signal around an obstacle, servicing the handful of devices that are on the other side, I have someone ask about using them instead of filler gateways in a controlled industrial environment - seems feasible but the “early-adaptor” tax and the “Nick needs to learn it tax” on the budget is thankfully slowing down that potential train wreck, if I was a marketing led provider of extraterrestrial IoT comms I may be inclined to tell them the small TTIG shaped boxes are relays …
I’d give it a year, let someone else debug it. I will debug it and write instructions, but only if someone funds that to their own early adopter advantage.
You may not be aware that Johan at TTI sits on various LoRaWAN Alliance technical committees and that the stated goal for TTS is 100% spec compliance. So Jeff’s comment that it was announced isn’t surprising at all!
Hence amended my one liner above to ‘publically’ announced - been rumoured/hinted at for a while
Thinking the same - not sure on price of Relays yet - need to ask I guess - only problem with filler GW is need internet backhaul of course, where battery based Relay with long life is fullfilling a specific off grid/network role in many use cases…
