On 01/06/2017 20:10, Jc Martin wrote:
Actually, I have been looking at this option too.
The use case is a remote rig usage where audio transport over the internet
makes WSJT sad (or more exactly, JT65/9 is not happy with jitter).
An alternative is remote display - but there the only benefit would be to see
the waterfall, and the desktop streaming itself is bandwidth hungry.
Hi JC,
using a decent VNC server and client should minimize remote desktop
bandwidth and not showing the waterfall or making it as small and as
slow as is reasonable will reduce the network bandwidth of screen
updates considerably.
I would contest that the required bandwidth for remote desktop control
is less than that required for low latency audio at 16-bit 48000Hz.
Added to that the latency requirements for the remote desktop are far
less demanding.
If you are able to have a computer running WSJT(-X) at the receiver site
then you will have far less problems. It need be no more than a recent
Raspberry Pi model for most modes (MSK144 is not going to be possible
with small SoC systems).
73
Bill
G4WJS.
------------------------------------------------------------------------------
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
