Craig Lamparter

Possibly, but I can't guarantee every radio will like the voltage drop over the diode (may not engage transmitter), nor can I guarantee the size of the current limiting resistor...

Nope, I'm using the kernel's inotify service for a state change... not polling, so cpu isn't really bad, it's mostly the overhead of yet-another-python-interpretery-loaded-into-memory just to monitor the direwolf ptt...

I'd like to see a compressed MicE transmit as well. it's the only way to trigger an "EMERGENCY!" position comment, which lights up most near by radios in an emergency....

Pi ZeroW gets this now and then, maybe once an hour, almost nothing to worry about, plus it seems to happen after I get an [ig>tx] line from the aprs...

I'm referring to the average cpu utilization from top... which correlates a bit with uptime/load averages.

Agreed, it's hard to use this with repeater systems which transmit a PL tone. You can use sox to filter it out, but really inconvenient, and introduces some lag. socat...

Give kissutil a few seconds to connect with a stdin pipe. I'm not sure why but there is about a 10 second lag before direwolf actually transmits this. buffer flush...

thanks, on closer inspection, it's not waiting 10 seconds, probably waiting for a clear channel on the direwolf side.

``` from gpiozero import Button button24 = Button(24) button23 = Button(23) button23.when_pressed = button_callback_23 ``` Just instantiating the button objects drives the cpu up (2% on pi5, about 7% on...

Can you provide a specific example? using is_pressed, when_pressed, etc, makes no difference. The CPU load shoots up as soon as you define the button. I'm talking about a Pi...