Hi everyone
I’m very new to LoRaWAN so bear with me please
We have two locations about 1 km apart , each location has a bunch of small IoT nodes doing their IoT things.
In each location we have one RPi+RAK2245 gateway.
What we’d like to do is have the two gateways talk to each other over LoRa in a peer-to-peer two-way manner, while within each location the gateway talks to the IoT nodes via MQTT over Wifi.
It’s a kind of a reverse LoRa concentrator situation I suppose.
Has anyone one done that before? what’s the best way to go about it?
Does this mean you are using Wifi and not LoRaWAN within each site cluster?
If so, a gateway class radio isn’t really what you want, a cheap node radio would have been fine. That said, you can use the gateway concentrator card, as long as you are not in a country which requires listening for channel occupancy before transmitting (node radios can measure the power present on a channel even if it is some other modulation, gateway radios can only receive signals of a type they understand)
The more general case is of a gateway that both functions as a LoRaWAN gateway, and wants to send messages to another gateway. In fact LoRaServer has some limited built in capability for this called “gateway discovery” where gateways will send occasional pings to see which can hear each other.
In a LoRaWAN network, nodes most typically transmit at low bandwidth settings (125 KHz) on a variety of adjacent narrow channels which the gateway’s concentrator can receive at once. In contrast gateways reply using a wider bandwidth (500 KHz) and in countries where enough spectrum is allocated may do so on a different block of frequencies than used for uplinks. Traditionally gateway transmissions also have the IQ polarity inverted, while node transmissions do not. If you look up the LoRaWAN regional parameters for your country you can see the recommended settings.
Given all of this, to make one gateway talk to another, the simplest thing to do is to make it send the type of transmission a node would - 125 KHz bandwidth, IQ not inverted, and on one of the configured node uplink frequencies. However when Semtech designed the chips they also considered the case of gateway-to-gateway links, so each gateway chip can also receive on a single 500 KHz LoRa channel, and a comparable FSK channel. You can transmit with those settings as well.
Something like the LoRaServer topology where the gateways talk through the gateway bridge to a an MQTT broker is very useful for experiments, as you can subscribe to the MQTT topics and watch the existing traffic. You can then start injecting your own compatibly formatted transmit requests - if there is time collision with a downlink requested by the server one will lose, but otherwise it works fine.
Some things to keep in mind:
The IQ polarity setting is opposite when transmitting to a node vs. when transmitting to another gateway
The packet forwarder configuration file may specify a range of transmit frequencies. Some versions of the code do not enforce this, but some do. If you want to transmit on uplink frequencies in a location where those are different from downlink ones, you’ll need to expand the allowed frequency range in that file to cover what you want to do.
If the gateway is serving a cloud of nodes, you can’t really hop the receive frequencies around beyond the two chunks of spectrum supporting 4 narrow channels each, and the wideband channels that have to be mapped within one or the other of those. But if the concentrator is not supporting nodes, you could in theory hop the channel assignments, though you’d have to invent a synchronization mechanism and do more software work to dyamically configure the receiver.
If you are not planning to support LoRaWAN nodes, buying node class radios generally makes more sense than gateway radios for point-to-point links.
Consider applicable regulations, for example you may be required to use a lower power level than the gateway hardware is capable of.