开云体育

I think I finally got to the bottom of the problem with TAP modes. I'm suppose to wait until I get an "all clear, ready for the next packet" message before I send the next packet. From what I can tell, there is a limited buffer in the Icom radios that will hold a few (maybe a dozen?) packets. Of course packets in its queue will be emptied at the rate of one every 20 milliseconds, but I won't get the all clear message until the radio has space available for another packet. Of course UDP D-Star packets are send individually and may not arrive in perfect timing (or even the correct order)*.? The problem is, there is a bug in the radio firmware where I never receive the all clear message. Sometimes this happens right away, sometimes it can take hours to happen.

New code in the master branch will now detect this condition and reset the serial port in order to clear the firmware lockup in the radio. It only takes about 60 milliseconds to detect the problem and about 2 seconds to reset the serial port. During this time any incoming packets from the gateway are queued and will be played once the serial port is reopened. In the qnitap log, you'll set a message that the radio is connected when it resets the serial port. Keep in mind that immediately after the reset, you will be hearing audio that actually was received about two seconds earlier, at least until there is a two second gap in activity where the qnitap queue can clear itself by playing out the queued packets.

As I indicated in an earlier message, I expect Icom to release new firmware soon that will hopefully fix the problem.

*That is one reason why digital communications is always delayed and is the main reason you should always wait a few seconds after someone keys off before keying up your radio. (Don't tailgate!)