Radiopaket transmission with response

RE: Radiopaket transmission with response

aro44444444 — Thu, 11 Apr 2024 07:59:30 GMT

Hello Edvin,

ok I understand.
We send 100 Byte from A to B and normally the resonse from B to A comes in the following
Connection Interval

Best regards

Andre

RE: Radiopaket transmission with response

Edvin — Wed, 10 Apr 2024 21:58:29 GMT

Hello Andre,

No, increasing the connection interval will not give you less timing variation, because if a packet fails (CRC error -> Not ACKed), then it will wait until the next connection interval before a retransmit. But how often are you sending 100 bytes? Every connection interval? Several times per connection interval? Or less frequently?

If range becomes an issue, you could try to make sure that you don't use 2MBPS. While it gives higher throughput, it is also prone to more packet loss as the distance increases.

BR,

Edvin

RE: Radiopaket transmission with response

aro44444444 — Wed, 10 Apr 2024 14:26:10 GMT

Hello Edvin,

ok, to be honest, we have mostly about 100 Byte average from A to B and B to A.
It is like MODBUS RTU cyclic communication.
But of course, if we need one more connection interval, the slave will respond later.

So I guess, to increase the connection intervall, let's say 10ms will stabilze and causes
less timing variation?

Best reagrds
Andre

RE: Radiopaket transmission with response

Edvin — Wed, 10 Apr 2024 14:11:01 GMT

[quote user="aro44444444"]

Do I understand you right, that a missing ack will lead to a retransmission in the next slot?

[/quote]

Yes. And this may be interpreted as "slower communication", because you can only send a limited amount of bytes every connection interval. When a packet is lost, it will be rescheduled for the next connection event (the event that occurs every connection interval). Depending on your setup, you may, or may not have room for the old packet in addition to a new one.

Let us say that you can fit 3 packets into your connection interval. (determined by buffer size (memory) and connection interval (timing). If one packet is not acked, it will be retransmitted. Then you will have the old packet, and perhaps a new one as well for the next connection interval. All fine. But if these are not acked in the next connection event either, then you may end up with 3, and eventually it will try to queue the 4th, which it will not be able to do, and it will have to wait until at least one packet is ACKed before it can queue the next.

This is a huge simplification. The buffer doesn't hold "maximum n packets". This is decided by the MTU that you are using, so it can hold N amount of bytes. If you send long packets, it will fill up more of the buffer. Shorter packets will naturally fill up less of the buffer.

In addition, longer packets have a higher risk of having a CRC error when received, so if your connection is bad, it may help to split the packets into smaller chunks. This does, however lead to more overhead vs payload, so it will "slow down the communication", but it will be more stable.

Best regards,

Edvin

RE: Radiopaket transmission with response

aro44444444 — Wed, 10 Apr 2024 10:00:39 GMT

Hello Edvin;

thankyou for your response.
Indeed we are using the uBlox NINA B311 (nRF52840) with uconnect express firmware.
But anyway, I guess they use GATT Write with Response.
Multipoint 1-7 works very fine.
But some customers report that if they have more disturbion (long distance) the communciation slows down.
this also happens if we have point to point communication.

Do I understand you right, that a missing ack will lead to a retransmission in the next slot?

Andre

RE: Radiopaket transmission with response

Edvin — Mon, 08 Apr 2024 23:01:52 GMT

Hello Andre,

Sorry for the late reply. I have had a bit of backlog since the Easter holidays here in Norway.

So you are trying to run one central with 7 connections to peripherals, each with a 7.5ms and an MTU of 244, if I understand correctly.

Having an MTU of 244 doesn't need that all packets needs to be 244 bytes long, but I suggest that you take a look at the Online Power Profiler tool. While this is mostly for checking the expected current consumption, you can enter your connection parameters, and it gives really nice graphs showing you what's going on on the air.

What you may notice is that maintaining one connection with MTU 244 (and actually sending 244 bytes) takes a while. In fact, it takes about 4ms. This means that squeezing in even two connections with 244 bytes every connection interval and 7.5ms connection interval means that you will not be able to keep up. But the SoftDevice (Bluetooth LE stack) will handle this as gracefully as it can, to try to serve all connections so that all connections are kept alive. But you will see a lot of packet loss.

Increasing the connection interval on your connections can make things more stable (but you will also have a larger latency). It will however be more predictable.

To your questions:

[quote user=""]

What happens if a gatt write does not get a response?

Is there an paket retransmission?

If so, how often is the retransmission started adn how long?

[/quote]

Basically the answer is yes. In Bluetooth Low Energy, all packets (with payload) are "will be sent, or die trying". This means that they will be retransmitted until one of two things happens:

1: The packet is acknowledged.

2: No packets have been acknowledged (incorrect CRC, or completely missed packet) for "Supervision Timeout" amount of time, meaning that the link will disconnect.

So if your link is lost (disconnected), all packets that are not ACKed are lost. It is however possible to keep track of the packets, and whether they are acknowledged or not, so if you have important information you can know whether it was Acked or not. (for details, please let me know what SDK version you are using).

Best regards,

Edvin