While doing some testing for VK7ZJA this morning, to track down a bug in the official Anytone firmware, I managed to cause the OpenGD77 Hotspot being used by Clayton VK7ZCR to lock-up it was transmitting.
Fabio IZ2BKS had reported this bug to me a few days ago, and I had attempted to fix it, however because I was not able to replicate the bug, the fix I sent to Fabio was based on guessing what was causing the problem, and my guess proved to be wrong.
Clayton VK7ZCR was able to cause my OpenGD77 Hotspot to hang during transmission, and because my hotspot was running in the debugger attached to my PC, I was able to see what the Hotspot was doing when it hung.
The Hotspot hung while waiting for the Tx buffer to re-fill, with DMR frames from the network, but due to a combination of conditions, no DMR data was being sent by MMDVMHost to the OpenGD77 hotspot, and hence the Hotspot stayed permanently in its TX_BUFFERING state.
Normally the TX_BUFFERING state occurs after the OpenGD77 Hotspot receives the Voice Link Connect frames from MMDVMHost, and while its waiting for a few DMR voice frames to arrive and be put into the Tx DMR frame buffer. Then once there are 4 frames in the buffer the GD-77 Tx hardware is turned to start transmitting the DMR audio.
The TX_BUFFER state is also used, if the TX DMR frame buffer has become empty, because the other station has stopped transmitting, but while the GD-77 Tx hardware is shutting down, and transmitting the 6 mandatory Link Terminator frames , (which takes 360mS to complete).. some more network data then arrives during that 360mS shutdown phase.
Consequentially, if during the Tx shutdown phase, a few extra DMR Voice frames arrives, the Hotspot would go back into TX_BUFFERING state, but would never leave that state, because not enough voice frames would arrive, because the transmission at the other end of the network had actually ended.
To correct this problem I’ve made several changes.
- I’ve added a 500mS timeout in the TX_BUFFERING state, so that if this timeout is exceeded whilst waiting for data from the network, the Hotspot will reinitialize and go back into Rx mode.
- Also if PiStar (MMDVMHost) sets the OpenGD77 Hotspot into IDLE mode while its in TX_BUFFERING mode, it immediately goes back into its Rx mode
The combination of these 2 changes seems to have made the Hotspot a lot more robust, and neither Clayton VK7ZCR or I can now replicate the same bug, no matter how quickly or how many times we re-key the PTT, even if we re-key multiple times in quick succession.
All OpenGD77 users should update to the new version (v0.0.5) before they use their OpenGD77 Hotspot again, from my “daily builds” link
After the update PiStar should show that the version of the Hotspot is now v0.0.5