Enhancement: throttle decode CPU usage on quiescent channel

[vandys]

I'm looking at a usage of pi3's at remotes. Mains, but with battery backup.

Power efficiency would go up quite a bit if the receive decode could be quiesced when a squelch
input line (i.e., a GPIO input tied to the receiver squelch output) stayed low for a configured number
of seconds. This would let the decoding stay on once there's work to do, but would let the CPU
idle if there's a lull of minutes. With a resulting savings in power consumption--mobile friendly.

I'll probably do the code anyway, but would be happy to offer it back and/or adapt it based on
dev thoughts here. TIA & 73's

[dranch]

Generally speaking, using squelch on packet is bad. When the radio finally figures out that a signal is present and opens up squelch, the first few bits of the packet's header could be lost and the packet is now corrupt. It all really depends on the remote station's TXDELAY settings that you cannot control. The use of squelch also hurts weak signal decoding very badly. Your idea does have merit but I don't know how many people would use it considering the decoding performance impact.

[vandys]

Sure, but think about this as a power saving mode. During an hour's idleness, keeping the CPU at (my measurements) 20% usage is OK for a home station on utility power, but not so much on batteries. Worst case, you need one extra retransmit to to get the channel back from idle, and then keep the decoder running until things have returned to a configurable number of minutes of idle.

It's the packet counterpart to Android's doze:
http://www.tomsguide.com/faq/id-3171959/doze-android-nougat.html

[dranch]

Yup.. I get it. I suppose that Direwolf could be enhanced to leverage the existing TXINH GPIO signal to suspend all decoders but I bet your overall package station will decode very few stations. Please check out the UserGuide's link to this problem:

https://illruminations.com/2014/01/15/baofeng-packet-radio-adventures/

Maybe if everyone on a given frequency setup very long TXDELAYS so squelch circuits could have enough time to react, this would work ok but that won't do anything for the remote weak station issue.
I suppose we'll have to see if WB2OSZ things that adding this feature makes sense and I imagine that it wouldn't be too difficult to configure on a per running Direwolf instance basis.

--David
KI6ZHD

[fcardona]

+1
especially useful for point to point digital links in an emergency scenario