P2P/Mesh without Gateway

WisBlock
1

Hi,

Hopefully straightforward-ish question. So have looked at the examples for P2P setups with Wisblock LoRa modules.

But i need to have several “nodes” sending to one wisblock lora “receiver”. Is that possible? I need to do it this way due to needing real-time updates, and reasonably frequent messages. So cant put it over our gateway to ttn in a lorawan style.

If i cant use one lora node as a receiver, is there a way to deploy a gateway, but it be a private local network? Id still prefer the wisblock node as a receiver, as the ability to just serial out the incoming data over USB or similar is ideal.

Thanks!

P.S - is there a section here for paid commissions for code work?

2

This may run into technical limitations (LoRa is a fairly “slow” modulation, extremely so in its longers range (high spreading factor modes) and legal limitations in terms of allowed channel occupancy in your location.

Key things that a gateway does is allow you to monitor up to 8 uplink frequencies at once, reducing the channel occupancy on each vs the radio regulations.

Also, a gateway lets you monitor all the main spreading factor settings at the same time, instead of having to have a scheme to agree on the single one that a “node” radio can be configured to receive at any given time.

TTN’s use restrictions do go beyond the legal restrictions in some areas, but are at least one take on what “appropriate” usage of shared frequency bands are.

One of the first things you’re going to have to consider are the actual radio regulations applicable to your region. The LoRa Alliance put out a paper with their (unofficial) interpretation of those for a number of countries which would be a good introduction to the matter.

If you conclude that you can legally and appropriately do more, there are various ways to run a private LoRaWAN server. Most of the RAK gateways can run a sort of mini install in the gateway computer itself, though it’s usually considered preferable to put the network server in the cloud both because that can let multiple gateways cooperate, and because it means that the network server data isn’t sitting on a little box that could be easily lost, damaged, or stolen.

3

Thanks for the reply.

I have already checked regarding regulations. It works out fine, as it is along the lines of 20 messages, 10 seconds apart. But only 2 or 3 times a day. Each message is just 3 number values. Range is only 400m line of site.

I already have gateways setup here, that go to ttn etc, for our facilities environmental monitors. That was all nice and straightforward.

So in theory, your saying, i could set up each of these nodes as normal nodes, that would go via a gateway. But then just repurpose the gateway to be private.

I could then see locally the data as it comes in? I need to get the values received as easily as possible into a computer on that local network. So would a private gateway allow easy reading/viewing of the data?

Just to add, i also have the wisgate developer base i just received, can this be used to get the data from nodes onto a connected Pi/Desktop? I wasnt sure if it needed the OS to just be the gateway software only, or it can just be another bit of software installed on that device, and then receive the data as well.

4

Hello @Neutrino , welcome to the forum.

I did what you want do (LoRa P2P) but without the TTN LoRaWAN part.

In my setup I had 5 LoRa P2P nodes, sending frequent messages to a LoRa P2P node with WiFi. From there I broadcasted the data over UDP into my local network. Never published the code, but it should be still somewhere on my harddisk.

About using a gateway as P2P packet receiver, I don’t think that is possible, at least I never saw this usage.

5

Hi, thanks, and thanks for the reply.

Ok, great hat sounds exactly like what i was wanting to do. Id then just connect the receiving node by USB to the computer, and monitor the serial output for the data i need.

If you have any pointers to resources/examples on that, id be very grateful.

6

@Neutrino
I think the easiest way is to start with the RAK4631 LoRa P2P examples.

LoRaP2P_RX would be your receiving node and LoRaP2P_TX the sending node.

However, if you have multiple nodes sending, you should implement the listen before talk feature.

This example PingPong is similar to above but uses the lbt feature.

I have written as well (proof of concept) a mesh network for LoRa SX126x-Mesh-Network. And of course, not to forget Meshtastic. It is designed for text messaging over LoRa, but as the sources are open, you can adapt it to send sensor values instead.

7

Unless the P2P scheme is odd, it should be possible.

The question is if it would be advantageous. The main advantage of gateway silicon is being able to monitor multiple 125 KHz channels at a range of spreading rates. If a P2P scheme takes advantage of that, then this is great.

However if a P2P scheme locks itself into one channel and one spreading rate, or tries to do time-coordinated hopping, that gateway capability is less useful.

And if a P2P scheme wants to use 500 KHz channels exclusively, then a gateway becomes a little inconvenient, as it can only monitor one 500 KHz channel at one spreading factor, and it’s harder to change that configuration on the fly since the usual packet forwarder software for operating gateway silicon which could easily be interefaced to a P2P engine, can’t really do that kind of dynamic reconfiguration.

8

Regarding RAKwireless P2P example:

Am in the process of transitioning successful LoRa P2P network software to RAKwireless. Using RAK19001 baseboard and RAK11310 computational core.

As suggested in this thread, tried LoRaP2P_RX and LoRaP2P_TX basic P2P examples. Received only one set of data so modified those according to the attached code.

LoRaP2P_RX_modified.ino (3.4 KB)

LoRaP2P_TX_modified.ino (2.8 KB)

At issue is that everything works as expected if the sender is started first. The receiver does not detect messages anymore if the sender stops for a period of time and then restarts. Calling the receiver’s setup() again does not help. Have searched Google, GitHub, and RAKwireless forum but cannot find something that points at a solution.

May I have the community’s input on this matter?

Many thanks for your insights.

9

Not sure why, but I got stuck with the example as well.

I changed one thing in the RX code.

Set the last parameter in the Radio.SetRxConfig() to false:

	// Set Radio RX configuration
	Radio.SetRxConfig(MODEM_LORA, LORA_BANDWIDTH, LORA_SPREADING_FACTOR,
					  LORA_CODINGRATE, 0, LORA_PREAMBLE_LENGTH,
					  LORA_SYMBOL_TIMEOUT, LORA_FIX_LENGTH_PAYLOAD_ON,
					  0, true, 0, 0, LORA_IQ_INVERSION_ON, true);

with

	// Set Radio RX configuration
	Radio.SetRxConfig(MODEM_LORA, LORA_BANDWIDTH, LORA_SPREADING_FACTOR,
					  LORA_CODINGRATE, 0, LORA_PREAMBLE_LENGTH,
					  LORA_SYMBOL_TIMEOUT, LORA_FIX_LENGTH_PAYLOAD_ON,
					  0, true, 0, 0, LORA_IQ_INVERSION_ON, false);

which switches the RX behavior of the receiver part from continuous on to timed mode.

Then it worked, independent of the power-on sequence.

1 Like
10

Many Many thanks for this @beegee. That sure solved the problem. Tested with sender and receiver starting first. Killed the sender during its cycle and then restarted it. All went well. Going to continue with the transition now.

Here are the two new codes for others to use:
(RAK19001 baseboard, RAK11310 computational core)

LoRaP2P_TX_modified.ino (2.6 KB)

LoRaP2P_RX_modified.ino (3.4 KB)