I have been playing with the rtl_fm program and most of it works amazingly well but I can not seem to get the squelch to stay open when receiving signals.
I have not tried to analyze the source yet so I am asking what principle drives this squelch?
In the analog world, the best squelches for FM receivers tend to be noise-driven and use a high-pass filter to filter out normal audio. When the noise drops below a preset threshold, the squelch opens.
For AM receivers, a cheap and easy solution is to monitor the AGC and open the squelch when there is AGC voltage above a preset level.
What I am noticing is that if I set the l value to a point just above where the noise stops, signals do open the squelch but even strong signals will not keep it from flickering on and off constantly.
If I set the l value any lower, the squelch is always open so that is not the issue.
I have tried signals that are absolutely full-quieting, with and without CTCSS and the squelch opens briefly, closes for a fraction of a second, opens for another fraction of a second and randomly flickers on and off for the whole transmission.
On rare occasions, the squelch opens when the signal starts, stays open and then closes properly after the carrier leaves. Some of these signals are even ever so slightly noisy and I have heard this situation with and without PL tones or CTCSS so that doesn't seem to matter.
Finally, I thought it might have something to do with too narrow a bandwidth so I increased the sampling rate to 24 K which made no difference at all.
If the signal has voice on it, the flickering doesn't seem to be effected by the words.
Basically, what is this squelch responding to to keep flapping?
Martin McCormick WB5AGZ
Hi Martin,
I'll just address the question /what does the rtl_fm squelch do?/ very shortly: from rtl_fm.c
/* power squelch */ if (d->squelch_level) { sr = rms(d->lowpassed, d->lp_len, 1); if (sr < d->squelch_level) { d->squelch_hits++; for (i=0; i<d->lp_len; i++) { d->lowpassed[i] = 0; } } else { d->squelch_hits = 0;} }
The signal enters the squelch after being low-pass filtered, then the RMS (basically, the power) is calculated and saved in ´sr´; if that is below the squelch threshold, the signal is zeroed out. If it's above, the signal passes to the next state. The squelch_hits just implement kind of a hysteresis.
So, yeah, a couple lines below:
/* todo, fm noise squelch */
:) Soooo, maybe you'd want todo that?
CTCSS might be so low in frequency that their instantaneous amplitude might be sensed as energy or not, depending on how close they are to the LO (might get killed by the DC block).
So, basically, the squelch is only sensitive to power.
Best regards, Marcus On 10.02.2017 22:22, Martin McCormick wrote:
I have been playing with the rtl_fm program and most of it works amazingly well but I can not seem to get the squelch to stay open when receiving signals.
I have not tried to analyze the source yet so I am asking what principle drives this squelch?
In the analog world, the best squelches for FM receivers tend to be noise-driven and use a high-pass filter to filter out normal audio. When the noise drops below a preset threshold, the squelch opens.
For AM receivers, a cheap and easy solution is to monitor the AGC and open the squelch when there is AGC voltage above a preset level.
What I am noticing is that if I set the l value to a point just above where the noise stops, signals do open the squelch but even strong signals will not keep it from flickering on and off constantly.
If I set the l value any lower, the squelch is always open so that is not the issue.
I have tried signals that are absolutely full-quieting, with and without CTCSS and the squelch opens briefly, closes for a fraction of a second, opens for another fraction of a second and randomly flickers on and off for the whole transmission.
On rare occasions, the squelch opens when the signal starts, stays open and then closes properly after the carrier leaves. Some of these signals are even ever so slightly noisy and I have heard this situation with and without PL tones or CTCSS so that doesn't seem to matter.
Finally, I thought it might have something to do with too narrow a bandwidth so I increased the sampling rate to 24 K which made no difference at all.
If the signal has voice on it, the flickering doesn't seem to be effected by the words.
Basically, what is this squelch responding to to keep flapping?
Martin McCormick WB5AGZ
=?UTF-8?Q?Marcus_M=c3=bcller?= marcus.mueller@ettus.com writes:
Hi Martin,
I'll just address the question /what does the rtl_fm squelch do?/ very shortly: from rtl_fm.c
/* power squelch */ if (d->squelch_level) { sr = rms(d->lowpassed, d->lp_len, 1); if (sr < d->squelch_level) { d->squelch_hits++; for (i=0; i<d->lp_len; i++) { d->lowpassed[i] = 0; } } else { d->squelch_hits = 0;} }The signal enters the squelch after being low-pass filtered, then the RMS (basically, the power) is calculated and saved in ?sr?; if that is below the squelch threshold, the signal is zeroed out. If it's above, the signal passes to the next state. The squelch_hits just implement kind of a hysteresis.
So, yeah, a couple lines below:
/* todo, fm noise squelch */:) Soooo, maybe you'd want todo that?
Thank you very much. I feel a bit red-faced in that I could have stumbled on this as it is right there as you describe, about 700 lines in. and the source is good old C. I used gcc C for about 20 years at work so this looks like old times for me.:-) That doesn't mean I understand it all, but I will surely give it a try.
I tend to try ridiculously simple ideas first in hopes that one will work. In FM reception, the loudest noise occurs when there is no signal or on occasion if there is a nearby signal just outside the passband in which case the noise squelch is closed more tightly. When one has the loudest noise, there should be the largest variations in individual samples compared to anything one will see when receiving a valid voice or data signal that is within the passband. More reply to follow:
CTCSS might be so low in frequency that their instantaneous amplitude might be sensed as energy or not, depending on how close they are to the LO (might get killed by the DC block).
I did try receiving some signals which have no CTCSS or DCS and sometimes, the transmission was clear but usually it flickered.
I will first save some rtl_fm output to raw files and then experiment with perl to see which ideas may have merit. When something good happens, I will code the same logic in C.
Am I correct in that the 16-bit samples are signed integers so silence will look like 0x7fff or 0x8000 and extremes will be 0 or 0xffff?
I would imagine that the noise squelch might also fall short when receiving wide-band FM broadcasts as they contain numerous sub carriers for stereo, RDS and auxiliary services.
We will probably need both the noise and power squelches as the noise squelch will probably be useless for AM and SSB. The samples will probably not have enough of the right kind of noise in them to do any good on anything but FM.
Martin WB5AGZ
Hi Martin,
never feel ashamed for asking questions. I've learned (support stuff) that the more at ease you are at potentially missing something, the easier others feel at answering questions, and the more pleasant the process is for both sides. And yeah, I've got no doubts you /could/ have spotted this – but not spotting this in a couple hundred lines of code is really not a fauxpass nor a sign of anything negative. Instead, investigating what makes a piece of technology tick or misbehave (in this very case, more the latter) and writing an extensive email explaining your question and giving a bit of background – what more could FOSS projects ask for?!
I tend to try ridiculously simple ideas first in hopes that one will work. In FM reception, the loudest noise occurs when there is no signal or on occasion if there is a nearby signal just outside the passband in which case the noise squelch is closed more tightly.
Yep! Classical noise-squelch! Direct baseband mixing receiver problem: You might have a stable pseudo-carrier through LO leakage. Direct baseband mixer solution: DC block the heck out of your baseband :)
I'll let the others answer your further audio-signal questions; I must admit that I'm on a train, which isn't necessarily the easiest environment to diligently write emails :)
Best regards,
Marcus
-
Marcus Müller -
Martin McCormick