search

wb2osz / direwolf

Dire Wolf is a software "soundcard" AX.25 packet modem/TNC and APRS encoder/decoder. It can be used stand-alone to observe APRS traffic, as a tracker, digipeater, APRStt gateway, or Internet Gateway (IGate). For more information, look at the bottom 1/4 of this page and in https://github.com/wb2osz/direwolf/blob/dev/doc/README.md
GNU General Public License v2.0
1.59k stars 307 forks source link

Enhancement: throttle decode CPU usage on quiescent channel #175

Open vandys opened 6 years ago

vandys commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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