Replies: 3 comments
-
This is beneficlal only in case when multiple SDRs are used simultaneously. With a single radio it makes no difference.
Virtually none of NFM transmissions that I receive in my location use CTCSS, so of course the defaults should stay as they are :-) Jokes aside, there are no universally correct values for these parameters and this is why they are configurable. The filters that are configured with
This is tricky because the squelch does not know whether a power drop is an end of transmission or just a momentary fade. Extending the hang time too much would cause annoying hiss clicks at the end of every transmission, both strong and weak. This could be addressed by extending the sample history buffer, so that the squelch could look further back in time. But large buffers increase delay and so I expect complaints about the fact that so far the signal was near-realtime and now it's delayed, say, by 1 second, which some find unacceptable. And of course thank you for sharing your thoughts! |
Beta Was this translation helpful? Give feedback.
-
FWIW I get better audio quality by disabling the |
Beta Was this translation helpful? Give feedback.
-
I was about to start a new thread re: CTCSS and notch. I've found setting |
Beta Was this translation helpful? Give feedback.
-
First, thanks to the author, maintainer(s) and contributors. This is useful software for me; I've only found it recently so please excuse any misunderstandings.
My use case is for NFM for "conventional" (e.g., not digital or trunked) frequencies. I currently use SDRTrunk to feed Rdio Scanner (thanks Chuot!), but SDRTrunk doesn't have FM squelch, and there are other various and sundry reasons to keep conventional demodulation separate.
I picked up an Intel NUC 10 i7 for this task as I'm using an Airspy at 10M sample rate and I wanted hardware that could easily keep up without heating up and the resulting fan noise. So far with 10 simultaneous frequencies, this is met. I've stopped keeping an eye on CPU usages, as it's rarely above 20% and is usally around 10%.. I have set multiple_demod_threads to true, but I can't say that I've seen much change yet.
I find it essentially mandatory to set the fft_size to 4096 - otherwise the squelch will open on close channels (30 KHz separation). I'd like to set it even higher but 8196 results in buffer errors.
Since the vast majority of transmissions are with CTCSS/PL, I set every frequency to have a passband of 300-3000 Hz. I'd even go so far as to recommend that if NFM is the modulation that the passband (lowpass/highpass) should be defaulted to these settings. Otherwise the PL hum is overwhelming - I would guess that some users would not be aware of why most channels have this loud hum... I do appreciate the notch functionality, but it's simpler to just set the passband and be done with it.
Following the squelch conversation with interest. While the automatic squelch is pretty good, I do find that I would like to have some optimizations added - listening to VHF NFM mobiles brings all sorts of picket-fencing and fades that some level of hysteresis and hang time would probably address. I do very much like the fact that even if the squelch closes momentarily that a new MP3 file isn't generated in a knee-jerk fashion but rather concatenated to the current file.
Since the end goal is to feed Rdio-Scanner, the tmp file fix for the mp3 files is also something that I'll try out - it looks like that's in the unstable branch, I may get brave enough to try that once I've worked through the learning curve.
Having CTCSS/DPL decode would be awesome - but still getting my feet wet here. There's still plenty on the RF side (antenna, preseletion, gain, etc) to work on...
Beta Was this translation helpful? Give feedback.
All reactions