search

ka9q / ka9q-radio

Multichannel SDR based on fast convolution and IP multicasting
GNU General Public License v3.0
147 stars 32 forks source link

Squelch causes "packet" to miss most APRS packets #7

Closed argilo closed 2 years ago

argilo commented 2 years ago

I'm running the packet program with the -v option to watch APRS packets, and it looks like only about 25% of packets transmitted by my local digipeater (which is less than 1 km away) are printed.

Before I dig into this, I wondered whether you might already know the cause @ka9q.

ka9q commented 2 years ago

Not offhand. I run this as part of a receive-only i-gate and haven't noticed any problems that can't be explained by weak signals. But I've never quantified its performance, so it's entirely possible that it's subpar.

On 4/18/22 06:30, Clayton Smith wrote:

I'm running the packet program with the |-v| option to watch APRS packets, and it looks like only about 25% of packets transmitted by my local digipeater (which is less than 1 km away) are printed.

Before I dig into this, I wondered whether you might already know the cause @ka9q https://github.com/ka9q.

— Reply to this email directly, view it on GitHub https://github.com/ka9q/ka9q-radio/issues/7, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJDI44VISZK5CBSAX7FHYLVFVPYXANCNFSM5TV34Q4A. You are receiving this because you were mentioned.Message ID: @.***>

argilo commented 2 years ago

OK. I'll have a look at it soon and let you know what I find.

argilo commented 2 years ago

I had a look at some recordings made with pcmrecord, and it seems like radio's squelch is cutting off the ends of the packets.

argilo commented 2 years ago

I increased squelchtail in fm.c from 0 to 1, and that seems to have fixed it. Packet tails are no longer chopped off, and all 10 of the most recent packets decoded correctly.

ka9q commented 2 years ago

I've been thinking of making that a config file option.

On 4/18/22 17:01, Clayton Smith wrote:

I increased |squelchtail| in fm.c from 0 to 1, and that seems to have fixed it. Packet tails are no longer chopped off, and all 10 of the most recent packets decoded correctly.

— Reply to this email directly, view it on GitHub https://github.com/ka9q/ka9q-radio/issues/7#issuecomment-1101866459, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJDI42Z4KIXUJCBI473CVLVFXZWJANCNFSM5TV34Q4A. You are receiving this because you were mentioned.Message ID: @.***>

ka9q commented 2 years ago

I introduced that squelchtail mechanism to fix precisely this problem some time ago, and I guess I forgot to do enough regression testing when I later tweaked it to tighten up audible squelch tails on non-data signals.

It has to do with how the squelch is either open or closed during each 20 ms (typical) block.

I think it's (almost) another classic off-by-one error. The SNR is computed as an average over a block. So if a signal just above the squelch closing threshold disappears during the block so the average SNR for the block falls below the closing threshold, the whole block will be squelched, chopping off (on average) 10 ms of actual signal.

I should make squelchtail a configuration option so it can be kept tight on voice channels without clipping off the tails of packet transmissions. I already configure voice and data differently by enabling de-emphasis only on voice (this is a recent change).

On 4/18/22 17:01, Clayton Smith wrote:

I increased |squelchtail| in fm.c from 0 to 1, and that seems to have fixed it. Packet tails are no longer chopped off, and all 10 of the most recent packets decoded correctly.

— Reply to this email directly, view it on GitHub https://github.com/ka9q/ka9q-radio/issues/7#issuecomment-1101866459, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJDI42Z4KIXUJCBI473CVLVFXZWJANCNFSM5TV34Q4A. You are receiving this because you were mentioned.Message ID: @.***>

ka9q commented 2 years ago

OK, I've created a "squelchtail" config parameter in modes.conf with a default of 1 frame.

This default is used in modes.conf by the FM and FMN entries, i.e., flat FM for digital modes like packet.

The PM and PMN entries set squelchtail=0 to eliminate audible squelch tails on analog voice channels.

NBFM with pre- & de-emphasis is really phase modulation above the 300 Hz corner frequency, hence the PM name.

I also cleaned up the modes.conf file, listing all the options and their defaults in comments at the end.

Give it all a try. --Phil

On 4/18/22 17:01, Clayton Smith wrote:

I increased |squelchtail| in fm.c from 0 to 1, and that seems to have fixed it. Packet tails are no longer chopped off, and all 10 of the most recent packets decoded correctly.

— Reply to this email directly, view it on GitHub https://github.com/ka9q/ka9q-radio/issues/7#issuecomment-1101866459, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJDI42Z4KIXUJCBI473CVLVFXZWJANCNFSM5TV34Q4A. You are receiving this because you were mentioned.Message ID: @.***>

argilo commented 2 years ago

Looks good! Packets are no longer getting cut off.

ka9q commented 1 year ago

Interesting. I had that problem a while ago, and put logic into fm.c to hold the squelch open for a configurable number of frames after the SNR drops below a threshold. Maybe that needs tweaking.

On 4/18/22 14:06, Clayton Smith wrote:

I had a look at some recordings made with pcmrecord, and it seems like radio's squelch is cutting off the ends of the packets.

— Reply to this email directly, view it on GitHub https://github.com/ka9q/ka9q-radio/issues/7#issuecomment-1101767475, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJDI46WKN22SFYD2WTM5Y3VFXFDVANCNFSM5TV34Q4A. You are receiving this because you were mentioned.Message ID: @.***>

argilo commented 1 year ago

The change you made back in April (94667e614610a8ddacb0b787f18e46ad842fe122) did fix the problem for me.