On 3/7/18 01:33, Игорь Ч via wsjt-devel wrote: > Playing out silence in place of the lost packets is not a good idea: > it will distrurb sychronization and will bring wrong Delta Time values > to the weak signals at demodulation. I would suggest usage of some > averaging instead of the silence. > . > 73 Igor UA3DJY
Igor, the whole point of playing out silence is to maintain synchronization. If, for example, the sampling rate is 48 kHz and your RTP packets each contain 240 samples (5 milliseconds), then I would replace a single missing packet with 240 samples of binary zeroes. Your signal blanks for 5 ms, but synchronization is maintained when it reappears. Most of the slower JT schemes wouldn't even notice. My experience is that local wired Ethernet networks are extremely reliable unless overloaded. Lost packets are very rare and reordered or corrupted packets are almost unheard of unless something is *very* broken. WiFi 802.11 is a different and somewhat complex story. Delays are much more variable due to contention and other physical layer problems. Packet loss depends on whether they're sent as physical multicasts or unicasts. Physical unicasts are acknowledged at the physical layer so they can might arrive late (i.e., with a lot of delay variance) but are usually not dropped. Multicast is different. A physical layer 802.11 multicast is sent at a very low "base rate" to maximize reception probability at every user station. They're not acknowledged. Not only can that lose packets, the low base rate can make the channel almost unusable if there's a lot of multicast traffic (like one of my I/Q streams). Some access points (like my Engenius 600) have a "multicast to unicast conversion" feature so that a multicast frame arriving on the Ethernet is sent as a series of unicast frames, one for each mobile station that has subscribed to the multicast group. Then each unicast can be sent at whatever speed that link can bear, and they're individually acknowledged for reliability. This is almost always vastly faster than a physical multicast. Phil ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
