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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to