Version 18 is now ready. Many features now work, like signal meter, compression, noise reduction, noise blanker, spend 1 day on reworking the audio decoder, now cracking and chopping solved.but lots of work to do...
[Sorry, extremely busy ATM] This is because the squelch action needs to bypass the delay of the audio buffering between server and client. So it occurs closer to realtime. Some of the packet flags transmitted by the server are inspected immediately upon reception by the client and acted upon, rather than being buffered along with the audio data.
Comments
I need help: I try to implement the SQUELCH function. After sniffing in the browser,
Don't sniff the web socket data using the browser network tab. READ AND UNDERSTAND THE CODE.
Version 18 is now ready. Many features now work, like signal meter, compression, noise reduction, noise blanker, spend 1 day on reworking the audio decoder, now cracking and chopping solved.but lots of work to do...
deleted because redundant
My SDR Radio is almost functional.
But I still cannot create a SQUELCH function.
I need help for this protocol.
I use the following commands:
SET squelch=0 param=0.00 (off)
SET squelch=<1-40> param=0.00 (max)
However, it does not work. What am I doing wrong?
Does SQUELCH need an initializer setting before?
I analyzed the python client code, but it contains obsolete code:
self._send_message('SET squelch=%d max=%d' % (sq, thresh))
As I read somewhere on this forum "max" is now replaced by "param".
From some servers I receive these messages on the sockets:
On the waterfall socket (and the waterfall does not start):
MSG badp=5
On the audio socket (and the audio stops):
MSG monitor
What does it mean?
Also I notice that some servers send audio only for a few seconds and then stop sending.
What could be the reason?
@jks I have a question about SQUELCH:
Is the SQUELCH filtering done at the KiwiServer side, or do I have to provide my own Squelch algorithm in the client?
I send the SET squelch=<1-40> param=0.00 (max) command to the server, but it does not affect the received audio packets.
Thank you for your answer.
Found out myself: even if squelch is on, audio packets are sent back, but client has to blank them out depending on flag 0x0040 (squelch flag).
[Sorry, extremely busy ATM] This is because the squelch action needs to bypass the delay of the audio buffering between server and client. So it occurs closer to realtime. Some of the packet flags transmitted by the server are inspected immediately upon reception by the client and acted upon, rather than being buffered along with the audio data.