LoRa E5 Transceiver Peer to Peer low data rate

Support Wireless/RF
1

I cannot achieve a data packet transmission rate exceeding 5Hz between two LoRa transceivers in TEST mode.

I am using LoRa E5 boards to send data packets (18 bytes), peer to peer/wirelessly, between Arduino hardware serial ports. I purchased the boards without understanding they are designed to work specifically with WAN and Server (rooky mistake) but I have worked out I can enter TEST mode on the LoRa boards and achieve the same peer/peer outcome which allows me to broadcast data to other devices.

The LoRa transceivers and Arduino boards are wired as a simple transmitter/receiver. I adapted the information from here to configure the arrangement. Note: I have changed all softwareSerial comms referenced in the article to hardware serial ports and I am using two Arduino Mega boards :facepunch:

I have set the TX LoRa board to TX mode (AT+TEST and send each packet of data using the AT+TEST=TXLRPKT, command). The LoRa receiver is configured similarly with AT+TEST and receive data using the AT+TEST=RXLRPKT command).

During initial tests, I successfully “talked” to both LoRa boards (AT commands) and then broadcast data from the transmitter end to the receiver end by using the serial command line (happy days :grinning:).

I then set about to have the Arduino TX hardware serial port continuously sending packets of data to the LoRa TX serial port. The other LoRa receiver serial port is connected to a second Arduino Hardware Serial port. The Arduino connected to the LoRa receiver serial port is simply polling the LoRa serial port continuously and any data it receives is printed to the Arduino Serial screen.

My dilemma is, after automating the data sending process from the transmitter end, I can only successfully receive data at the receiver end when the transmitter sends data packets at intervals of 200mS or greater. If I increase the frequency of transmissions to more than about 5 Hz, the receiver stops receiving data. To be accurate, the Arduino receiver stops printing data to the screen, but I am assuming that the LoRa receiver does not have data at its serial port. This is based on the fact if I remove the LoRa boards and hardwire the two Arduino hardware serial ports together, the is no restriction on transmission rates. So, I don’t know if the LoRa transmitter is unable to send the data or if it is the LoRa receiver is unable to receive the data at the increased rates.

In an attempt to increase the throughput speed, I have increased the LoRa UART speeds to 115200, varied the radio data rates to from 250bits/s up to the maximum 50kB/s, varied the frequencies between 433MHz and 868MHz, changed channels and varied the data packet size (being sent from the Arduino) from 1 to 18 bytes. I have also removed any timeout restrictions and set the duty cycle restriction to ‘off’ on each of the LoRa boards (clutching at straws at this point :confused:).

None of the changes have provided me with any faster transfer rate of data. Interestingly, the size of the data packet (1 byte up to 18 bytes) seems to make no difference.

I am unable to determine if it’s the LoRa is TX mode or the LoRa in RX mode (or both) that is causing the bottleneck.

Before I abandon the hardware :frowning_face: and look for something that will operate at a higher rate, has anyone had any experience with the LoRa E5 configuration, in TEST mode, that might shed some light on the data rate restriction and more importantly, if it is possible to double/triple the data rate.

Thanks Tim

1 Like
2

Hey Tim,

At a glance, it seems like this issue may be rooted in the inherent limitations of LoRa technology when used in p2p mode. LoRa was designed for low-power, long-range communications, and it typically sacrifices data transmission speed for these benefits.

I’m not confident that changing parameters such as data rate, frequency, channels, etc., will significantly affect your throughput if you are hitting the limit of what LoRa is designed to do in p2p mode, especially given that you’ve already disabled the duty cycle.

The fact that you are able to send data packets at 200ms intervals (5 Hz) but not more frequently suggests that you may be hitting a sort of ceiling for your current setup. It might be that the devices need a certain amount of ‘rest’ between transmissions to properly handle and transfer data however frustrating that may be.

If you absolutely need to send data more frequently than every 200 ms and can’t find a way to make it work with your current setup, then you may indeed need to consider different hardware or perhaps a different communication protocol that is better-suited to higher transmission rates.

If anyone else has any other solutions please let us know!
Sam

1 Like
3

Im with Samuel on this one. There are lots of limits on how much radio time you can use.
One key guideline is to only TX when you have to. Continues transmission means you are not letting other around you “share” the radio space.
So when it talkes about bandwidth, that will have more to do with how fast the data is clocked out in one packet.

if you have a read of
LoRa — LoRa documentation.
you will see things like (for the things network; not lora as such)

  • The uplink airtime is limited to 30 seconds per day (24 hours) per node.
  • The downlink messages are limited to 10 messages per day (24 hours) per node.

And then things like (In Europe)

  • There is an 0.1% and 1.0% duty cycle per day depending on the channel.
    So you need to wait between TXs to allow others time to use it.

Note: I would need to search to find the actual information to say what the rules would be in Australia, but there will be rules and guidelines (as per the warning on the item page :slight_smile:

So, channel hopping is an option. Sending data less frequently with more data (max packet size) may help. But its really a short message setup.

1 Like
4

Keep an eye on that; from what I believe, in Australia we can only use the 915 Mhz band. for lora.

From the E5 guide we have this nice table
image

So from that table, ignoring the FSK and sticking with lora, we have a max bit rate of 21.9Kbps

So Im wondering of part of you “delay” is processing time. i.e. clock in the data, build data packet, tx packet, clean up and repeat.

How much data is your test sending each time ?

Dont forget
“… The preamble is used to keep the receiver in sync with the incoming data stream…”
So, it could just be getting out of sync.
Have a play with RXPR and TXPR in the AT+TEST=RFCFG setup.

1 Like
5

Thanks for the response Sam,

I agree with everything you are stating and it confirms my current strategy is less than ideal and I will need to reconsider how I marry the LoRa capability with my system requirements (There is more than 1 way to cook an egg :grinning:.

Hi Michael,

I too agree with everything you have stated and thank you for offering a means to improve the current performance. I will keep tinkering. At this stage I am only attempting to understand the LoRa topology and to firm up my understanding of its capability and limitations. (I had zero awareness when I started this part of my project 10 days ago :stuck_out_tongue_winking_eye:).

Final freq, bandwidth etc, (if I retain the LoRa option) will all become compliant once I have matched the LoRa requirements/capacity/capability with my system requirements. As a point of interest, I suspect my duty cycle will be less that 2%, but in heavy shorts bursts (consider machine gun analogy) and then sit quiet for a long time until the next set of data packets (bytes only) are required to be broadcast…

Thank you both again for taking the time to provided detailed responses.

Cheers,

Tim