LoRa transmission delays

I want to continuously send and receive data packets of 64 bytes over a long distance (>1km). One transaction should happen in less than 200 ms. In other words, I want to send and also receive 320 bytes in one second.

I have never worked with LoRa before. It looked like a perfect candidate at first, but do I understand correctly that I will experience huge delays (500-1000 ms) between each transmission? I cannot find a definitive answer. If that is the case, what can I do about it? Are the any alternatives to LoRa that fit my requirements?

Your having a laugh surely ?

Where did you read such garbage ?

See here;

Even a humble 8Mhz Pro Mini can manage 100 packets a second @ 8 bytes a packet, 32 packets a second for 64 byte packets.

Thank you. I guess I got confused after:

  1. Watching a few videos, like LoRa Based Remote Controller | Control devices over large distances | lora lorawan - YouTube (2:30, see how long it takes to switch on the LED).
  2. Speaking with a manufacturer of a commercial remote controller based on LoRa. I was told that after pressing a button on a remote control it will take about 2 seconds to receive a confirmation and light an LED on that remote.
  3. Reading about 1% max duty cycle and not fully understanding its implications.

A side question. Are there any advantages to choose SPI LoRa modules over the UART ones? I will not loose any functionality if I use UART?

It’s not totally garbage. in Europe there are ISM band rules: when using the ISM band frequencies (863 MHz - 870 MHz) users must comply with a 0.1% and 1.0% duty cycle per day depending on the channel.

Duty cycle / time on air (ToA)
When a signal is send from a sender it takes a certain amount of time before a receiver receives this signal. This time is called Time on Air (ToA).
Duty cycle is the proportion of time during which a component, device, or system is operated. The duty cycle can be expressed as a ratio or as a percentage. As mentioned previously in Europe there is a 0.1% and 1.0% duty cycle per day depending on the channel.

To respect the 1% duty cycle :
For example : ToA = 530ms => affer sending a message, we have to wait 99x530ms = 52.47s before sending a new message.

Easy to get confused by that one. There may be a few places in the World that enforce a dwell time between packets on some ISM bands but its not common.

LoRa is used quite legally for RC control applications, these need packets at between 50hz and 200hz, so there is no significant transmission delay inherent in the use of LoRa.

You said LoRa and you can indeed use it at that range (1km) at 100% duty cycle if you wish, just choose the right band and settings.

I will not loose any functionality if I use UART?

You will loose a lot of functionality and ability to fine tune. Plenty of libraries and examples for SPI modules, very limited support for UART modules.

LoraWan requires some friendly cooperation

There may be a few places in the World that enforce a dwell time between packets on some ISM bands but its not common.

Well Europe is not such a small place last I checked :wink:

The duty cycle of radio devices is often regulated by government. If this is the case, the duty cycle is commonly set to 1%, but make sure to check the regulations of your local government to be sure.

I’ve about 10 third party "The Things Network" gateways visible from my home with already lots of activity.

There are also Lots of interference In the ISM (863 MHz - 870 MHz) bands because anyone can use these frequencies, that’s why there are basic rules for gentle cooperation (including on power). You’d be annoyed if you can’t send your messages because someone else is sending so many messages or at such a power that yours can’t go thru.

If you use The Things Network, they add even more restrictions and the following fair use policy applies:

  • 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.

More information about the TTN fair use policy: Duty Cycle | The Things Network

I know.

Sure you can choose to use bands\frequencies that limit air time and the average time beteween transmissions, but you dont have to.

You can, if you choose, use an hours duty cycle allocation all in one go, no gaps between those transmissions, although you would need to wait another hour before transmitting again.

If you want to transmit more often just use a band\frequency that allows for 10% or 100% duty cycle.

That works until your neighbor uses the same band @ 100% DC and you start a power competition :wink:

I am only interested in fixed transmission at 433 MHz (Europe).

That 433Mhz band is mostly 10% duty cycle but you can operate at 100% if you use a low LoRa bandwidth of 20800hz. This is used in the UK for the continuous transmit of SSDV from high altitude balloons.

The low bandwidth probably needs to be used with AFC on SX127X devices but the SX126X devices will operate without AFC at that low bandwidth since they normally use TCXOs.

Do consider the use of 2.4Ghz LoRa, no duty cycle restrictions, small antennas, high speed.

.. and shorter range?

The OP said;

"over a long distance (>1km)"

And 2.4Ghz LoRa is well capable of that, I would not have suggested it if it was not.

I wasn't addressing the OP's requirements, just adding to the features of 2.4GHz.

If you do an A-B comparison of a 800-900MHz LoRa point to point with 2.4GHz, the lower frequency will have longer range.

Thank you everyone for your help. I have decided to order a couple of SX1268 modules to try them out. As I need to have an SMA connector, I was limited to UART options only. Modules that support SPI are not user friendly as they have no antenna connectors or u.fl only and they have no pin headers. If everything goes well, I will consider trying SX1280 modules and SPI.

You can get boards that turn the LoRa modules into breaboard friendly ones, choice of SMA,u.fl or plain wire antennas;

https://www.tindie.com/stores/stuartsprojects/

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.