Repository navigation
[Bug]: Stations sometimes get locked in a loop when they're transmitting on top of each other until timeout #965
Description
FreeDATA Version
v0.17.0-beta
What operating system are you using?
Windows
Operating System Version
Windows 11 Home 24H2
Architecture
x64
Area of problem
Server - General
Describe the bug
Sometimes, two stations can try transmitting on top of each other, and the delay is such that neither station will receive anything because they transmitted while the other station was transmitting. This can resolve itself occasionally, but usually it results in a timeout and requires a retransmission.
To Reproduce
It's not easy to reproduce, but if you have a conversation that lasts longer than a few overs, this race condition can happen.
Expected behavior
It should be expected that one of the stations should delay for a few seconds to receive anything the other station is sending (i.e. if it is expecting an acknowledgement from the remote station).
Screenshots
No response
Log Files
No response
Additional context
It has been suggested to implement a randomized delay if a station is not receiving an acknowledgement from the remote station when it is attempting to send data to the remote station and get confirmation back that the data was sent.
Activity
DJ2LS commentedon Apr 26, 2025
https://github.com/DJ2LS/FreeDATA/blob/main/freedata_server/schedule_manager.py#L167C9-L167C20
We should add an additional channel busy check in schedule manager.
Also we could increase the waiting time and random delays
LA3QMA commentedon Apr 26, 2025
maybe add a retry-delay that increase each time it fails. the increase should be "random". ie first time 1sec next 2+rnd(2), 4+rnd(2)
if possible only the station that started the transmission should to this. The values for the delay has to be based on a real transmission as this can give an indicator of the "best" delay values.
DJ2LS commentedon Apr 26, 2025
Thanks for the suggestion, @LA3QMA , but the issue occurs only on first attempt. So we should mainly increase the first time + an additional channel check.
adjusted message processing for avoiding colissions #965
DJ2LS commentedon Apr 27, 2025
Okay, I pushed a commit which is checking more sensitive against a busy condition caused by receiveing codec2 signals within a waiting time of 10s. If the check fails, message stays queued and will be tried to send in next cycle ( every 15s ).
DJ2LS commentedon May 6, 2025
@LA3QMA this is the corresponding issue to t e topic regarding long queued state
DJ2LS commentedon Jun 1, 2025
Did this problem improve with latest releases?
k8wu commentedon Jun 1, 2025
I will report back when I next have a QSO whether this issue is still prevalent.
k8wu commentedon Jun 5, 2025
I sent a message over a poor link with a low SNR, and it looks like this issue isn't happening in that situation. I think we're probably fine here unless someone else complains. I can't do much QSOing in these current HF conditions.
DJ2LS commentedon Jun 6, 2025
thanks, @k8wu , I suggest testing this a bit more and if you feel its mostly solved, you can close this issue then. However, packet collusion always can happen, but its good if we have reduced this