On 27/03/2019 11:39, Magne Mæhre wrote:
A couple of my club mates have written about a weird issues which
showed up when trying to use WSJT-X with an IC-9100. I've seen the
same issues with IC-7100 as well. Even though WSJT-X is not the real
culprit here, I thought some of you might find it amusing...
https://www.la1k.no/?p=4219
"Exploring why WSJT-X didn’t want to decode – an illustrated guide to
printf-debugging"
Perhaps some of you have deeper USB knowledge, and can shed a light on
what's _really_ going on?
--Magne / LA1BFA
Hi Magne,
this is a known issue with external USB hubs. Most are poor at handling
streaming data (audio) and interrupt driven data (serial port emulation)
simultaneously. The problem being seen is due to dropped audio packets,
it is not a change in sampling rate but lost data that means WSJT-X
never receives enough data to complete a full received message. The
decoding only starts once a full receive period of audio samples has
been captured.
I don't think the problem is specific to the hub alone, after all the
USB connections on the PC are a hub as well. The problem seems related
to how the USB protocol is handled when there is more than one hub
between the communicating end-points.
Bottom line, don't use external USB hubs when connecting a rig that has
a USB connection that provides both audio and CAT.
The extensive detective work listed in the link above does appear to
show that USB 3.0 hubs do not show this problem, or at least it seems
less prevalent.
It should be noted that there is no point in modifying WSJT-X to somehow
work around this problem by accepting more audio samples to make up form
the missing ones, this is because the dropped samples mean that the rx
period data is pretty much useless.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
