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.58k stars 307 forks source link

GPIO Relay Stuck On #89

Closed na7q closed 4 years ago

na7q commented 7 years ago

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

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

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

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

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.

img_0021

wb2osz commented 7 years ago

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 https://github.com/wb2osz/direwolf/issues/89#issuecomment-285916249 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGMul1nJEX3-jEFkr8saAunFXxIlrbXjks5rk1VEgaJpZM4MZcI7 . https://github.com/notifications/beacon/AGMul5gAuFV5HrKJS_im0PeIelwuczRiks5rk1VEgaJpZM4MZcI7.gif

na7q commented 7 years ago

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.