When communicating with 900mhz, the speed remains at 40kbps, and after a period of communication, data cannot be sent again

[tuopu]

Hello experts, when communicating at 900MHz, the speed remains at 40kbps, and after a period of communication, data cannot be sent again.

I found that the networking was successful, and UDP protocol was used in the middle. I was able to communicate for about 5 minutes, but then I was unable to send data. Calling UDP did not respond.
Please ask whether the current openthread protocol stack can support such low-speed applications, and if so, what parameters need to be changed?

[jwhui]

Yes, it should be possible to implement OpenThread on top of a lower speed link. What you are observing sounds like a platform driver issue. Note that OpenThread's sub-GHz implementation is a prototype contributed by Silicon Labs. I would consider reaching out to them if you need help in diagnosing the issue.

[tuopu]

Thank you very much, I will carefully study it.

[tuopu]

Hello, after testing at different RF rates, a comparative analysis was conducted between Openthread and other protocol stacks. When the speed is greater than 250kbps, the Openthread network is more efficient than the comparison protocol stack. However, when the speed is below 90kbps, the Openthread network starts to oscillate, the network networking is slow, and it is often disconnected. There are three network devices, forming a 2-hop network. The comparison protocol stack can work normally until the speed is compared to 10kbps. The current question is whether Openthread performs poorly at low speeds and whether it needs to modify any network parameters to make the network work properly, or for any other reason.

[jwhui]

Adjusting the PHY data rate will affect the transmission time for packets. I believe you will also need to look into adjusting various protocol timers and timeouts.

As mentioned above, OpenThread has been successfully deployed on LoRa radios, which operate at relatively low data rates.

[tuopu]

You are right. I have made adjustments to the ACK time and CSMA time, but it is not clear which parameters need to be adjusted for the protocol stack. Currently, only the UDP protocol is applied, and this protocol does not involve time. Can you clarify which time parameters need to be adjusted for normal communication?

[jwhui]

It's hard to know without a better understanding of communication delays and overall channel capacity. I would also look at the various MLE protocol parameters, as those are responsible for establishing and maintaining links with neighboring nodes, as well as establishing routes.