Factors affecting Rx delay

1

Dear community,
I want a minimum Rx delay for my application. To my understanding, the SF of the receive (RX1 and RX2) windows, the distance between the end device and the gateway, and gateway-to-network server connectivity (GSM/Ethernet) should be taken into account while configuring the Rx delay. Are there any additional factors we should consider when setting the Rx delay? What are the benefits and drawbacks of extending or shortening the Rx delay?

Thanks

2

Might be an idea to tell the forum Which Arduino\Hardware and or nodes you are using ?

And why exactly you seemingly need a ‘minimum RX delay’ ?

3

First of all, why do you need that?

You do not own and control all components in the chain and as a result will never be able to get a reliable value that is a lot smaller then the current setting. So back to the question, why?

4

Where in the world are you and can you see the accretion disk of the black hole that’s affecting gravity / time-dilation and therefore the speed of light? I guess with a lower SF the chirps would be stretched less …

If it’s a battery consumption worry, then do you know what your device idle current is and where the biggest battery use is and what the impact of reducing from 5 seconds to say 3 seconds would be?

Is this because you set it too large in Sept? Rx window enlargement

5

The record distance for TTN is 832km, so that represents at 300M per uS, a time of 2.77mS.

For an average node to gateway distance of maybe 5km, the time would be 16.7uS.

6

I am using arduino uno and SX1276 Transciever. I want a minimum transmission delay between the packets. And thanks for the correction, my bad! the impact of distance is negligible.

7

My bad sir. The distance play negligible role.

8

Do you know what the legal minimum transmission delay is? Or the Fair Use Policy delay would be?

Either way, if you think you can send a packet every few seconds, TTN is not for you and you’d probably want to book mark some lawyers for your legal issues that will arise.

9

Ok sir. I got your point. I will switch to the private server if needed. If you can answer my question about the factors affecting Rx delay, that would be really helpful for me.

Thanks

10

You still haven’t said why you need to send so many packets so fast - which is not a good use case for LoRaWAN - it’s just not designed to transmit that frequently.

And if you are sending packets that fast, you can’t be using a TTI based system so that would be off topic for this forum.

And it’s not appropriate for the forum to facilitate a mis-use of the shared spectrum that is likely to be a breach of duty cycle with the consequent legal penalties.

11

I need it for some experimentation. I would not be transmitting the whole day. I guess duty cycle is applied on a whole day basis. However, in my country there is no duty cycle restriction (IN 865).

Thanks

12

You want to use a shared medium (airwaves) with a protocol that is not designed for sharing the frequencies it is transmitting on. Unlike WiFi LoRaWAN has no provisions to share the bandwidth available with other devices apart from not sending too frequently. And that one provision is the one you want to disable/circumvent.

Even when using it for part of a day, you would be DoSsing other LoRaWAN users within radio range during that time.

1 Like
13

Wrong……so fundamentally wrong! Go directly to jail do not pass go do not collect £/$/€/¥/#200! Depending on local regs it can be on a per Tx or per channel/sub-band basis or perhaps per minute or per hour, or some combination thereof…… the TTN FUP limit is per day!

1 Like
14

Yep, wrong.

Often assumed to be an hour, but you need to check the regs for each part of the World.

So which country has no duty cycle restrictions in the 868Mhz band ?

1 Like
15

India.