PTT/GPIO Stuck On HIGH

[na7q]

I've been running Dire Wolf for a few years on a lot of devices. One common theme I have when using them on the regular Pi units is that the GPIO when used for PTT will sometimes stay on after a transmission. The radio then continues to transmit until the radios TOT cuts off that transmission. Then everything goes back to normal on the Pi. Happens on all versions of Dire Wolf. It may even be unrelated. I'm unsure of the problem specifically.

I have one Pi where I have the PTT and an LED on the same circuit through an audio isolation circuit. The circuit is one of those Easy Digi Boards. You can watch it transmit, with the LED going red, then stays on with the radio transmitting. When the radio stops, it stops.
This is the board I use.
https://www.ebay.com/itm/EASY-DIGI-Interface-Card-FT-8-PSK-RTTY-SSTV-NBEMS-JT-65-FT-8-FT-4-others/323587026051

[dranch]

This sounds like an RFI or radio issue as I've never seen this issue on my multiple Rpi+direwolf deployments nor have I heard of any other users experiencing bad scenario. Consider trying a different radio or removing the EasyDigi kit to see if either are introducing this issue. Also make sure the antenna is as far away from the Raspberry Pi and associated cabling.

[wb2osz]

I agree with what others are saying. Sometimes RF from a strong transmitter can get picked up by the logic signals and cause unexpected behavior. See if the same thing happens with lower power or the transmitter turned off entirely. The solution could be greater separation, better grounding, torroids around cables, perhaps a small RF bypass capacitor in the PTT circuitry.

[na7q]

I've used countless radios, same results. I have quite a few ferrites on the radio and Pi. The Pi and radio are separated by 8 feet. Although with those and distance it makes no difference. Both are well grounded also.
Where would you suggest a bypass capacitor be placed in the circuitry?

[ew1abz]

Try:

• run Direwolf with -d o option. It will show you when Direwolf changes PTT output
• use a dummy load instead of a real antenna (just for test)
• decrease output power

[mpannen1979]

I had the same thing with my easydigi until I used a modified config. I had to use RTS -and- DTR.

This is the line I use for my direwolf on rpi3:

PTT /dev/ttyUSB0 RTS DTR

[na7q]

Mpannen1979, that's unrelated to this. You're using a USB PTT device. I'm using the GPIO pins for PTT.

[n3xus1]

Which version of the Pi do you have? Also what OS are you running? Also curious to know what other software you may have installed or have running as well.
I have a very similar setup have used a few Pi's and no issues the most recent is Pi 4
I use a OPTO coupler and limit the current from the GPIO using a 1k resistor
I'm curious if some other application is causing issues.
Have you tried just a new installation of Rasbian with just Direwolf on it?
you could use a 555 timer circuit to stop PTT after a certain time frame, I know it would be a workaround but it would work.

[na7q]

Apparently I never saw the last comment. I'm using nearly ever Pi version from the Zero to 3B+. I also use everything from Jessie to the latest Pi OS. They all do it on GPIO. It happens significantly more so with optocouplers. I switched to MOSFETs with a 10K pull down resistor and now it doesn't do it nearly as much. There's just something about Direwolf that causes it. Other applications I use don't have this trouble. It's like the USB sound card errors, people only have it with Direwolf. But run Allstar and you never have either issue. It's quite goofy.
I have tried varying the GPIO I use. That changed nothing.

[na7q]

I've noticed a common problem with Direwolf across any system or setup. There are times where PTT locks up and the radio stays transmitting. It doesn't happen often, generally. But it only happens with Direwolf. I can use a setup of CM108 or GPIO (Pi) setups, they at one point or another get stuck HIGH. Until unplugging the device.

I use the same devices and setups with other packet applications, AND allstar, which transmit often and a lot. NO other applications have the issue, which to me is intriguing.

[dranch]

I see from two of your comments above, you're seeing this behavior on both GPIO-based PTT and CM108-GPIO PTT. Per one of the comments above in this issue, what do you see when you run Direwolf with -d o option. It will show you when Direwolf changes PTT output but once Direwolf drops PTT, does the Rpi GPIO pin or CM108 GPIO pin drop as well? I assume you're using Direwolf v1.6 or 1.7Beta.

[na7q]

I am using 1.5 or higher. Mostly 1.7 now. I have added bypass capacitors to the circuits for lowering the potentional. It helps generally. Though it's interesting that other software doesn't have this issue with or without the caps. So I'd like to spend more time figuring out why that is.
This is with GPIO or the CM108 GPIO.

I have not tried that option with Direwolf. I will give it a go and see what happens. Thanks!

[na7q]

I also notice on Windows that Direwolf sometimes just freezes completely. The sound card appears to be functioning still. But the window is completely frozen.
Another interesting problem is that Direwolf shouldn't shutdown and leave the GPIO on the cm108 or GPIO as high, but it does.
All these issues are solely tied to Direwolf, and it further intrigues me of why that is.

[dranch]

I have limited experience with Direwolf on Windows but I would be curious if you see errors in the System Event log. If this was RFI freaking out the USB bus, it could cause issues like what you're seeing. At that point, Direwolf and Windows has lost communications with the soundcard and it's GPIO pins and all bets are off. It is interesting why you're not seeing issue with other programs but do those other programs run on the same packet frequencies? RFI can be very frequency specific. Might be worth trying out those other programs transmitting on these packet frequencies for a comparison.

[na7q]

That's exactly it. I use the other applications on the same frequencies in some areas, and many other frequencies also. Never have I had the same issues, or any for that matter. Windows or Linux. I don't know much about the Windows logs. It's been a while since I've looked at the Linux logs. But I know from time to time I would get an input output error with Direwolf. But again, never ever on any other software. From Allstar to Packet to VARA and other digital modes, if Direwolf isn't involved, there's never an issue. Direwolf as a TNC has all the things I need. So it's why I use it, in case you're wondering.