QRQ CW LAB - Testing a REMOTE RIG CW KEYING setup using a Raspberry PI::Rig interface

[Chuck aa0hw]

REMOTE RIG QRQ CW KEYING - over ip - using Gstreamer scripts on a Raspberry PI 2b::RIG hardware interface, and a remote OP's Linux laptop, on the local area network, wired Ethernet, going through a Router and network switches

NETWORK CONDITIONS = poor

ROUTER = 20 yr old router, 100 mb limit...
ETHERNET CABLES = two "CAT 4" - 100 foot cables - old...
cheap network "dumb" switch...
busy network - 5 other computers running using network bandwidth, one of them was streaming YouTube video playlists from BOB ROSS...

SETUP:
2 Gstreamer RTSP SERVERS & CLIENTS are running at the same time - for full duplex, 1 channel, 32 bit uncompressed PCM AUDIO over ETHERNET - using Gstreamer scripts
THE PI is using ALSA audio engine ONLY
the remote OP's linux lapto using JACK AUDIO CONNECTION KIT
- another uncompressed- straight UDP send & receive Gstreamer scripts were used to visually monitor the TRANSMIT CW AUDIO waveshape and audio spectrum

NOTE: this test runs for almost an hour and there were over 30 X-runs on the remote OP's Laptop::Jack audio connection bay...the SCREEN RECORDER was stressing the system too much...perhaps by raising the buffer frames from 64 to 96 or 128, it might have solved that issue...the settings were 48k sample rate, 3 periods of 64 buffer frames on the LINUX LAPTOP where the SCREEN RECORDER was running

there were audio glitches on RECEIVE, but most of those were not showing up on the RF SCOPE or the TRANSMIT AUDIO MONITOR's spectrum analyzer, which is good... so those glitches did not go out and get transmitted on RF(dummy load used in this example at 1 watt)....so these audio glitches that were heard, were mostly a sign that the RECEIVE Gstreamer SCRIPTS need some adaptation to help resolve their issues...JITTER-BUFFER SETTINGS et al etc...not to mention that the HOME NETWORK needs a serious UPGRADE !

for AUDIO OVER IP, some benefit from going into the router with QOS instructions might also help to prioritize the UDP packets...
another possible route...might be setting up a VLAN so that only the PI and the REMOTE OP are on that network ID ...etc..