I'm working in a project with LoRa ra-02 devices, but I have a problem if I have multiple LoRa senders a single receiver can receive data from every sender and also if I have multiple receivers and just one sender every receiver can receive data from that sender, so I want to know if there is a way that I can make my receiver ignore others senders except from the one I want
Use different frequency channels. Only units using the same frequency can communicate.
Otherwise, assign each receiver an ID, put the receiver ID in the transmitted message and have the receiving software ignore messages with the wrong ID.
Using unique frequecies would be easy.
And as also suggested, its not difficult to have the first byte or two of a LoRa packet act as the ID of the sender.
In theory LoRa devices can use a syncword which is meant to identify different networks. Although a LoRa device will receive a packet with a non-matching syncword, the receiver should then flag the non-matching syncword.
As suggested in #1 & #2 above use some form of device identity in the data packet so your receiver can reject data not from your device.
From experience of using point to point LoRa changing the channel may help but cannot guarantee someone else using the same frequency. My receiver prints all packets received but only act on packets that have idents from my transmitters so I sometimes see random/encrypted data from other devices.
If communication is to be restricted to a pair of devices then operating them on a different frequency from other pairs makes sense.
However if communication needs to operate between several devices but with some messages intended for specific devices it will be much easier to operate all the devices on a common frequency and use an ID within a message to identify the intended recipient.
Switching frequencies under program control is possible but there is a great risk that the system gets confused and the sender is sending on one frequency and the listener is listening on another frequency. Then you need code that enables the system to identify the problem and recover from it.
...R
My own LoRa tracking software implements a simple 3 byte addressing scheme, the three bytes are automatically sent before the buffer containing the payload and stripped from the LoRa receiving FiFo before the receive buffer is filled, the details are;
##Packet Addressing
LoRa is a two way technology, each device is a transceiver. Most often on a particular frequency there will be one transmitter and one receiver. However, this may not always be the case and there could be several trackers in use on the same frequency.
In order to keep the software simple and allow for the receipt of signals from multiple receivers or directed commands to a particular tracker, a basic addressing scheme has been implemented. The key to this is that regardless of the data content of the actual payload each payload is preceded in the transmitted packet with 3 control bytes. In general the control bytes have been restricted to ASCII printable characters so that they can be shown directly on a terminal\monitor, the 3 bytes are;
###Packet type.
This either describes the content of the packet, which could be a GPS location payload or is a command to do something and there is no payload.
###Packet Destination.
The node number that the packet is destined for.
###Packet Source.
The node number that the packet was sent from.
The destination and source packet bytes mean that node ‘2’ (could be your base station receiver) can send a command that only station ‘3’ will respond to. This command could be a reset command, a request to turn on and off certain transmission types etc. Node ‘3’ can be set-up so that it only accepts commands from a particular node.
Thus a receiver can respond to only packets transmitted from say node '3';
if (lora_Source == '3')
{
do_something();
}
else
{
do_nothing();
}
or a receiver as node '2' can respond to packets only directed to it;
if (lora_Destination == '2')
{
do_something();
}
else
{
do_nothing();
}
Its simple and works.
Riva:
so I sometimes see random/encrypted data from other devices.
Those could be from your own receiver.
Depending on how careful the library you are using has been built, LoRa receivers can in effect produce their own 'phantom packets'.
There is a series of investigations on this topic here;
http://www.loratracker.uk/?p=744
http://www.loratracker.uk/?p=765
http://www.loratracker.uk/?p=782