RAK3172 broadcasting to multiple receiver

Please include the following information, in order for us to help you as effectively as possible.

  • What product do you wish to discuss? RAK4631, RAK3372, RAK11200, RAK11310, RAK11722?
    RAK3172

  • What firmware are you using? (RUI3 or Arduino BSP or other IDE (e.g. STM32CubeIDE)?
    Arduino IDE

  • What firmware version? Can it be obtained with AT+VER=?
    AT+VER=RUI_4.2.0_RAK3172-E.

  • Computer OS? (MacOS, Linux, Windows)
    Windows

  • What Computer OS version?
    22H2

  • How often does the problem happen?

  • How can we replicate the problem?
  • Provide source code if custom firmware is used or link to example if RAKwireless example code is used.

We are going to deploy a system that uses 5–10 RAK3172 devices. The device that powers on first will act as the master (Tx), while the others will operate as slaves (Rx). If the master device stops functioning, the next device—based on the timestamp—will automatically assume the role of master. This architecture will be implemented to monitor various parameters, and we want to ensure that no other LoRa device can connect to our network if it is using our designated frequency.

We have successfully developed a solution for 1-to-1 communication; however, the message (string) length is too small. How can we upgrade it? as of api.lora.psend(sizeof(payload), payload); this command in code.
And is there any network stack available for the RAK3172 so we can update it as per our requirement

The payload size of LoRa is limited to 255 bytes, you cannot extend it.

It is not advisable to send “text” as payload. If you are measuring sensor values, send the values only in a defined format.
An example could be to use LPP format. There is a library for it called Cayenne LPP.

1 Like

But as you mentioned The payload size of LoRa is limited to 255 bytes, then why it is no sending the payload length greater than 12

13:03:21.104 → Hardware ID: stm32wle5xx
13:03:21.105 → Model ID: rak3172
13:03:21.105 → RUI API Version: 3.2.9
13:03:21.105 → Firmware Version: RUI_4.0.6_RAK3172-E
13:03:21.105 → AT Command Version: 1.5.11
13:03:21.105 → Set P2P mode frequency 868.000: Success
13:03:21.105 → Set P2P mode spreading factor 12: Success
13:03:21.105 → Set P2P mode bandwidth 0: Success
13:03:21.149 → Set P2P mode code rate 4/5: Success
13:03:21.149 → Set P2P mode preamble length 8: Success
13:03:21.149 → Set P2P mode tx power 22: Success
13:03:21.149 → P2P set Rx mode Success
13:03:21.149 → Current Work Mode: LoRa P2P.
13:03:23.770 → +EVT:RXP2P:-72:-20:52555348494B455348204241CA2D7E290F1C41091300865826
13:03:23.801 → Incoming message, length: 25, RSSI: -72, SNR: -20
13:03:23.801 → ±-----------------------------------------------+ ±---------------+
13:03:23.801 → |.0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .a .b .c .d .e .f | | ASCII |
13:03:23.801 → ±-----------------------------------------------+ ±---------------+
13:03:23.801 → 0.|52 55 53 48 49 4b 45 53 48 20 42 41 ca 2d 7e 29 | |RUSHIKESH BA.-~)|
13:03:23.833 → 1.|0f 1c 41 09 13 00 86 58 26 | |…A…X& |
13:03:23.833 → ±-----------------------------------------------+ ±---------------+

It received 25 bytes, not 12 bytes:

13:03:23.770 → +EVT:RXP2P:-72:-20:52555348494B455348204241CA2D7E290F1C41091300865826
13:03:23.801 → Incoming message, _**length: 25**_, RSSI: -72, SNR: -20

Where do you get the 12 bytes from?

Ohhh! sorry previous byte length i added by mistakenly, but the logs are 25 bytes.
but still why it is not receiving the all the payload data?
and the response is coming only for the 2 -3 mins later it stops the receiving the data.

You have to check your code.
I can send and receive large packets without problems. Here it is 84 bytes.

Same if I send AT commands:

P2P-TX.ino (3.2 KB)
LoRa_P2P.ino (4.3 KB)

i am using P2P-TX file as transmitter program and LoRa_P2P as receiver
can you please check what is wrong in that?

Your LoRa_P2P.ino code doesn’t compile. There is a stray println in it:

After removing that, it works when I send 84 bytes of data from my own code:

For LoRa-TX.ino, it works, but I don’t understand why you switch to RX mode in the send callback. You never get the response from LoRa_P2P.ino

Fixing that with

void send_cb(void)
{
//   Serial.printf("P2P set Tx mode %s\r\n",
//                 api.lora.precv(0) ? "Success" : "Fail");
  Serial.printf("P2P set Tx mode %s\r\n",
				api.lora.precv(65534) ? "Success" : "Fail");
}

And changing the payload to a much longer one, it works as well and it receives the response value:

Your P2P settings on the two codes are very different. I saw:

uint16_t sf = 7, bw = 8, cr = 3, preamble = 8, txPower = 7;    // sf=spreading factor, bw=bandwidth, cr=coderate, preamble=preamble length, txpower=Transmitter power

Above tests were running with

uint16_t sf = 12, bw = 0, cr = 0, preamble = 8, txPower = 22;

So there must be something else in your “real” code that is not in the examples you shared. They would not be able to communicate anyway with the different P2P settings.

Hello Bernd Giesecke,
below the code file that i have changed, please check this out
LoRa_P2P.ino (4.3 KB)
P2P-TX.ino (3.2 KB)

and the response for the both code is as below,


this is Tx code response


this is P2P code response

For now, I have removed the board to take steady screenshots and to make any further changes I need to, as it is still not sending more than a 12-byte payload. There seems to be a significant difference between your response and mine, and I’m not sure why.

Latest RUI3 version is 4.2.0, try to update your modules.
I don’t need to check your code, I already tested and it works.

Thank you for confirming your code’s functionality. It’s helpful to know it works in your testing. However, I’m using RUI3 version 4.2.0, and there seems to be a discrepancy as I’m still facing the problem.
Therefore, I’ll be adapting the code to address the issue within my specific environment. I appreciate your assistance.

LoRa_P2P.ino (4.6 KB)
P2P-TX.ino (3.6 KB)

This works, I cannot debug your code.
If these don’t work for you, then then you have something else in your code that you didn’t share.