Missing retransmits causing connection drops

TL_SW

The SDK does not support the solution you mentioned. Please adjust the 32k crystal on your hardware.

Flole

Okay.

Is there any way to get the time that a packet was last received? I want to know if I am getting close to hitting the supervision timeout. I have an interval of 3.998 seconds, latency 3, so every 16s there is a packet received. If due to interference 2 packets get lost the supervision timeout of 32s is hit. So I would like to detect this situation, by seeing that the last packet from the central was 20s ago, and then set the manual latency to 0 to prevent the connection from getting interrupted.

Any news regarding the issue you confirmed in https://forum.telink-semi.cn/for ... d=1024&pid=3346 ? The datasheet mentions "Auto acknowledgement, retransmission and flow control" for the RF transceiver, so I assume it worked at some point and it's a simple bug that causes it to not work now?

TL_SW

Sorry, there is no API to get the time that a packet was last received. It is suggested that you can confirm it by adding GPIO Toggle in the interrupt handling function.
Why did you choose such a large interval?

Flole

The large interval is chosen for maximum power saving

TL_SW

Currently, the 32k RC does not support the function of extremely long sleep time (>3 seconds), and this will be evaluated. What need to know is that when 32k RC uses an extremely long sleep time, it does not significantly reduce power consumption. This is because the inherent ppm factor causes the receiving window to expand as the sleep time increases.
Furthermore, why is it that the same bin file （In https://forum.telink-semi.cn/for ... d=1024&pid=3493）works fine on EVK but not for you? Please check your hardware.

Flole

We have switched to the external oscillator to support the long sleep times and that seems to work fine now.

My oscillator requires a higher startup time, so I have to adjust the settings by doing

1. pm_set_xtal_stable_timer_param(135, 10, 400);

复制代码

, then it works with the external oscillator.

The only thing that is still an issue are the missing retransmissions, this makes Read/Write operations time out if the response goes missing and if an indicate gets stuck without seeing the "accepted" response it's no longer possible to send indicates. It should be easy to only remove the message from the FIFO if the sequence number of the next packet confirms that the previous packet was received properly, otherwise retransmit it. I only need it for the slave device, I am not using the host feature.

TL_SW

The retransmission mechanism is available in our SDK. Could you please describe in detail the timing when it occurred?

Flole

Does the retransmission mechanism need to be enabled? The capture I provided in https://forum.telink-semi.cn/for ... &ptid=1024&pid=3198 shows that there are no retransmissions occuring. Didn't you confirm the issue in https://forum.telink-semi.cn/for ... &ptid=1024&pid=3346 ? If retransmissions would work properly the lost indicate would not be a problem as it would be retransmitted? Or was it fixed in a later SDK version? I have checked the changelog and its not mentioned in there. I am currently using version v3.4.2.4_patch0003. EDIT: Just updated to version 3.4.2.7, same result. I attached a capture that shows how a response went missing and the SDK never retransmitted it. MissingResponse.zip (819 Bytes, 下载次数: 2)

2025-9-8 21:10 上传

点击文件名下载附件

TL_SW

The retransmission mechanism is part of the protocol and there is no possibility of it being shut down. Additionally, from the packet capture data you provided, I couldn't find any errors in the SN and NESN sections. The peripheral devices only transmit the next packet after receiving the ACK signal.

Flole

Indeed there is nothing wrong with the SN and NESN, but that's been the case in https://forum.telink-semi.cn/for ... d=1024&pid=3198 aswell. The packet is simply missing as if it was never transmitted in the first place, but the debug logs clearly show that it was queued/scheduled for transmitting. Why could that be?