Status of RX or TX for companion apps?

[scottredd]

Is there a way in software, like a lock file or something in the file system, to detect if the system is actively in a TX or RX state?

I have some cron job shell scripts that ID with weather, time, special announcement, but it’s unaware if there’s a QSO in progress, and will stomp over a conversation.

If there was a lock file when a TX or RX is active, I could make the script aware and delay the ID until there is no activity.

Thanks!

Scott

[allebb]

Pirrot doesn't expose such a thing (I never thought about it), that said, however, if you plan to use a BASH script, you can simply "cat" the GPIO I/O value to retrieve the value and then, based on the output choose to delay if you need; You'd simply read the value of the COR pin by using a command like this (you'll probably want to assign it to a variable too): "cat /sys/class/gpio/gpio23/value" (change the GPIO pin to the one you need - Pirrot uses GPIO 23 by default, also pay attention as to if you've inverted the values too!) Hope this helps :)

…

On Thu, 22 Jun 2023 at 15:11, scottredd ***@***.***> wrote: Is there a way in software, like a lock file or something in the file system, to detect if the system is actively in a TX or RX state? I have some cron job shell scripts that ID with weather, time, special announcement, but it’s unaware if there’s a QSO in progress, and will stomp over a conversation. If there was a lock file when a TX or RX is active, I could make the script aware and delay the ID until there is no activity. Thanks! Scott — Reply to this email directly, view it on GitHub <#56>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAF3NDAKHSOIPNNHWYSCMQTXMRHAVANCNFSM6AAAAAAZQIWYXE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[scottredd]

Hi Bobby:

I made a test script (see below) to monitor the pins while I TX and RX. The value read from pin 23 (OUT PTT) and 22 (OUT TX LED) both change to "1" when the repeater is transmitting. Reading this value can be used to help my script know not to TX when the repeater is already transmitting.

I was expecting pin 27 (OUT RX LED) to change from 0 to 1 when a transmission was being received, but it does not change.

Am I interpreting this wrong, or maybe missing something in my config to make that happen?

Thanks,

Scott

while [ 1 ];
do

  P18=`cat /sys/class/gpio/gpio18/value`
  P23=`cat /sys/class/gpio/gpio23/value`
  P17=`cat /sys/class/gpio/gpio17/value`
  P27=`cat /sys/class/gpio/gpio27/value`
  P22=`cat /sys/class/gpio/gpio22/value`

  echo "$P18 | $P23 | $P17 | $P27 | $P22"

  sleep 0.25

done

[scottredd]

That sounds like exactly what I’m looking for. I’ll try it out and let you know how it works. Thanks!ScottSent from my iPhoneOn Jun 22, 2023, at 9:37 AM, Bobby Allen ***@***.***> wrote: Pirrot doesn't expose such a thing (I never thought about it), that said, however, if you plan to use a BASH script, you can simply "cat" the GPIO I/O value to retrieve the value and then, based on the output choose to delay if you need; You'd simply read the value of the COR pin by using a command like this (you'll probably want to assign it to a variable too): "cat /sys/class/gpio/gpio23/value" (change the GPIO pin to the one you need - Pirrot uses GPIO 23 by default, also pay attention as to if you've inverted the values too!) Hope this helps :)

On Thu, 22 Jun 2023 at 15:11, scottredd ***@***.***> wrote: Is there a way in software, like a lock file or something in the file system, to detect if the system is actively in a TX or RX state? I have some cron job shell scripts that ID with weather, time, special announcement, but it’s unaware if there’s a QSO in progress, and will stomp over a conversation. If there was a lock file when a TX or RX is active, I could make the script aware and delay the ID until there is no activity. Thanks! Scott — Reply to this email directly, view it on GitHub <#56>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAF3NDAKHSOIPNNHWYSCMQTXMRHAVANCNFSM6AAAAAAZQIWYXE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>