开云体育

I'm now up and running with remote Quisk. It works amazingly well and are very, very easy to set up!

I will not be able to use it efficiently at my remote site where I use 4G cellular connection in the outskirts of the cell tower coverage though as the bandwidth of 1.7MBit/s in both directions will both be more than my available bandwidth from time to time and will also eat my limited data available.
My plan is to replace this rig with my HL2 when possible to get the more competent rig at home.

I use WFView today to control an IC-7300 which uses opus 1ch codec with very good both latency and quality. The bandwidth for the entire remote control is around 120kbit/s which is very more what my connection will cope with.
I have also previously used mumble to transport the audio on the side which also had low bandwidth codecs with very good audio quality if the settings are correct.

My questions are if there are soon to be a more efficient coding planned to implemented for Quisk remote or if it would be possible to locally route the audio at the remote site somehow via an external program such as mumble to manually reduce the bandwidth?

Bj?rn
SM0SBL

Hello Bj?rn,

I will implement sample rate reduction from 48 ksps to either 8 or 12 ksps. It is not hard to do, but it will not be ready for the next release.

Jim
N2AD

Ok. Looking forward to that.
It will reduce the bit rate a lot. Perhaps not all the way down to compressing using Opus or similar but very much easier to implement.

If I calculate the bandwidth of around 1.7Mbit by dividing 1.7M/48k I get around 32 bit transfer. Correct?
Is it because you send 32 bit one channel data for each sample or because you send two channel data?

If it is of any value to you my experience from different settings with WFView using one channel raw bit data or PCM coded data is that 8bit resolution is not enough to create the expected sound quality but 1 channel 16bit is definitely good enough in both 16 bit at 8ksps and 16ksps sample rate which should result in around 128kbps or 256kbps in one direction.
The 8-bit resolution bad audio might of course be due to a bad interpolation or other implementing issues and the down sampling to 16ksps or 8ksps depends of a good low pass pre-filtering to avoid convolution issues.

If it is possible to turn off the transportation of audio by commenting some if-statement out I'm happy to try to use mumble as an alternative method of transferring audio.
Please point me to the appropriate line in that case, if you have time to give it a quick check.
I also don't know if there is any other dependencies of the audio channel such as remoting CW using an audio channel or so.

Hello Bj?rn,

I am surprised at your 1.7 Mbit as that is the traffic I get from the remote to my HL2. From remote to ctl-head my traffic is 212 kiB/s on receive and 198.7 KiBs on transmit. This is easily run over an internet connection and not too hungry when using a mobile phone as a hotspot. Having said that I am very interested in how a divide by 4 would go and 12 KHz would be a more useful audio bandwidth as it gives some measure of fidelity when listening to broadcast band music. FreeDV codecs are another possibility and although there is a fair bit of unnatural sound to the voice it is perfectly good communications quality and we are looking at sub 2 KHz bandwidths here.

73, Graeme ZL2APV

Hello Graeme!

Are you sure you don't mix up bits and bytes?
212kByte/s is around 1.7Mbit/s
If not I'm very interested in how you have done your setup and your hardwarefiles.

73 de Bj?rn, SM0SBL

Hello Bj?rn,

I need further education hi. Thanks for thT.

73, Graeme