GPIO Relay Stuck On

[na7q]

If Dire Wolf fails while the GPIO is triggered for transmit, the GPIO stays active even though Dire Wolf has closed and restarted automatically. Big issue if we don't want continuous transmissions.
V1.4D

[dranch]

Can you elaborate on what you mean by "direwolf fails"? Did it crash (segfault, core, etc)? If you restarted Direwolf, would it remain running or would it immediately crash again? If it would continue to run ok, we have a new restart script in the alpha stage that should work for GUI and CLI users.

[na7q]

By fail I mean crash. It was a failure caused by a USB soundcard input/output error. I'm trying to repeat that specific issue, but haven't yet. But even when restarting the application it still doesn't release the GPIO. It required a reboot to fix both issues.
Even with a keyboard interrupt or terminal closure of dire wolf it does cause the GPIO to stay active if it were transmitting.

[dranch]

This sounds like something more than just Direwolf is crashing. If restarting Direwolf doesn't clear out the state and un-assert the PTT pin, then I'm curious what's happening to make things crash? I wonder if you're getting RFI into the Rpi and it's freaking it out bigtime. If you disconnect the PTT line and leave Direwolf as a receive-only device, do things stay up longer? If that helps, try adding some ferrites chokes on all wires going in/out of the sound device, power, GPIO wires, etc.

[na7q]

It may have been RF into the Pi. I still haven't been able to recreate it. But I've run into other isssues and confusions from this. In digipeater mode it repeats packets that were just repeated by another digi. It waits until the other digi finishes repeating, then mine says "drop redundant..." and still repeats it. To clarify, a station with wide2-1 or any hop is repeated by the other digi, mine will repeat the same packet, even though it's already been repeated and it sees it. Note the picture. NA7Q-1 and KNAPPA are both mine. Both repeated the wide1-1 when they shouldn't have. It happens 100% of the time.

[wb2osz]

This is received and eligible for digipeating because it has unused WIDEn-n in the via path. ASTRWX>BEACON,WIDE1-1,WIDE2-1: T#309 … etc. The first digipeater field is replaced by the digipeater name and it is put in the transmit queue. A record has been kept that this has been digipeated. ASTRWX>BEACON,KNAPPA*,WIDE2-1: T#309 … etc. It will be sent over the radio as soon as the channel becomes clear. These are heard and also eligible for digipeating because we have WIDE2-1 unused. ASTRWX>BEACON,MEGLER*,WIDE2-1: T#309 … etc. ASTRWX>BEACON,NA7Q-1*,WIDE2-1: T#309 … etc. This digipeater has already processed this same packet recently. These two are duplicates of something sent recently so the digipeater will not send them again. (“Sent” means put in the transmit queue, where it might still be waiting until the channel is clear.) This is the expected behavior. The duplicate suppression is based on what has been sent by this digipeater, not what is heard from some else. If everyone could hear everyone else, all 3 of the digipeaters would have sent the same thing at the same time. In this case, they each had a different idea about when the channel was clear so they ended up transmitting at different times. From: Mike [mailto:notifications@github.com] Sent: Saturday, March 11, 2017 9:16 PM To: wb2osz/direwolf Cc: Subscribed Subject: Re: [wb2osz/direwolf] GPIO Relay Stuck On (#89) It may have been RF into the Pi. I still haven't been able to recreate it. But I've run into other isssues and confusions from this. In digipeater mode it repeats packets that were just repeated by another digi. It waits until the other digi finishes repeating, then mine says "dropping redundant..." and still repeats it. To clarify, a station with wide2-1 or any hop is repeated by the other digi, mine will repeat the same packet, even though it's already been repeated and it sees it. Note the picture. <https://cloud.githubusercontent.com/assets/1294292/23828447/b11bec1c-0686-11e7-8331-45cb38f307fe.PNG> img_0021 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#89 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AGMul1nJEX3-jEFkr8saAunFXxIlrbXjks5rk1VEgaJpZM4MZcI7> . <https://github.com/notifications/beacon/AGMul5gAuFV5HrKJS_im0PeIelwuczRiks5rk1VEgaJpZM4MZcI7.gif>

[na7q]

Thanks for the clarification on that. Although I don't understand why that would be a good idea for any digipeater to do it that way. As any regular one would not repeat it. Or at least that's how it is in the PNW. Sure waiting is for a clear frequency is great, but repeating what shouldn't be repeated doesn't make sense.