direwolf
direwolf copied to clipboard
wb2osz
PTT/GPIO Stuck On HIGH
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
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.
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.
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?
Try:
- run Direwolf with
-d ooption. It will show you when Direwolf changes PTT output - use a dummy load instead of a real antenna (just for test)
- decrease output power
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
Mpannen1979, that's unrelated to this. You're using a USB PTT device. I'm using the GPIO pins for PTT.
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.
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.
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.
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.
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!
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.
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.
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.
To add to this with another issue I opened up for Windows. Direwolf will just suddenly freeze and become unresponsive on Windows. I run both Direwolf and VARA FM side by side with RMS Packet, as it's a dual mode gateway for Winlink. Direwolf dies by frostbite, where VARA FM continues to run and function without issue. Since VARA isn't on Linux, I can't give any details there. But I run 1.7 on a Pi with no freezing. Related to the RF theory? No idea. But more details are better than none.
It might be worth running Direwolf on Windows with some additional debugging to see if you can see a bit more detail and then compare to the Windows System logs. I suppose it could be possible that your other programs you're running on the same RF frequencies might have more fault recovery in them (say recovery from a USB reset) from but I kinda doubt it. Once there is a USB issue due to RFI, the bus will reset and then Direwolf will freak out. This improved fault tolerance in that running instance of Direwolf might be something possible to add to Direwolf but it's implementation will be very specific each and every OS that Direwolf can run on. Beyond the additional logging to help correlate, I think you can do two things: 1) start Direwolf with restart abilities. The User Guide mentions how to do this with cron. I'm sure something similar could be done with Windows but I don't have any immediate ideas for you. 2) I still believe your root issue is RFI related. I recommend you go the path of RFI reduction by putting frequency-correct ferries on both sides of every cable on your setup (audio, power, RF coax, etc). Consider shortening various cables to only what you need, avoid coiling cables to make them need as this creates more RFI sensitivity, etc. It can be a serious pain to troubleshoot and mitigate RFI but I think it's your best course of action.
I just tested the RFI theory and I believe I am having the same issue but with using an FTDI and the RTS pin hooked up to an Easy Digi (octocoupler). I thought I was insane because when I switched to a test frequency, it worked fine, as soon as I tried it on 144.39, it stuck on every time! My test frequency was a UHF freq though (right next to each other in my memory bank). NOW I just tried on a VHF, and it stayed on. Fldigi also did it so it's not Direwolf. It happened with 2 different radios (Kenwood TH-F6A and a Baofeng), and 2 different FTDI adapters. Anyone solve this issue or at least find out if it's the computer itself, the octocoupler, the IC on the GPIO/RTS line?
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
By way of explanation: If you are using the Easy Digi board, both "RTS" and "DTR" are tied together on the input of the PTT optical switch IC. If you command Direwolf to set only RTS high, DTR will sit on high forever, and you will key as soon as you connect to the serial port, until the radio turns it off with the TOT.
So to have both RTS and DTR track high and low together is the way that Direwolf works properly with EasyDigi boards. FLDIGI has a similar way to set the RTS and DTR to track one another.
I just tested the RFI theory and I believe I am having the same issue but with using an FTDI and the RTS pin hooked up to an Easy Digi (octocoupler). I thought I was insane because when I switched to a test frequency, it worked fine, as soon as I tried it on 144.39, it stuck on every time! My test frequency was a UHF freq though (right next to each other in my memory bank). NOW I just tried on a VHF, and it stayed on. Fldigi also did it so it's not Direwolf. It happened with 2 different radios (Kenwood TH-F6A and a Baofeng), and 2 different FTDI adapters. Anyone solve this issue or at least find out if it's the computer itself, the octocoupler, the IC on the GPIO/RTS line?
If RFI is triggering the GPIO to stay high, I suggest a bypass 0.1uf across the GPIO and ground. I tend to add one from ptt to ground also. It has fixed that issue 100% for my custom hat cards I use where ptt would get stuck. 1 year later, it hasn't been an issue. Whereas before it was every time.
Easy Digi ties RTS and DTR together. You must configure Direwolf as RTS DTR on the end of the PTT line so they track together.
-- Mitch, AB4MW
Sent with Proton Mail secure email.
------- Original Message ------- On Thursday, June 23rd, 2022 at 10:18 AM, Mike @.***> wrote:
I just tested the RFI theory and I believe I am having the same issue but with using an FTDI and the RTS pin hooked up to an Easy Digi (octocoupler). I thought I was insane because when I switched to a test frequency, it worked fine, as soon as I tried it on 144.39, it stuck on every time! My test frequency was a UHF freq though (right next to each other in my memory bank). NOW I just tried on a VHF, and it stayed on. Fldigi also did it so it's not Direwolf. It happened with 2 different radios (Kenwood TH-F6A and a Baofeng), and 2 different FTDI adapters. Anyone solve this issue or at least find out if it's the computer itself, the octocoupler, the IC on the GPIO/RTS line?
If RFI is triggering the GPIO to stay high, I suggest a bypass 0.1uf across the GPIO and ground. I tend to add one from ptt to ground also. It has fixed that issue 100% for my custom hat cards I use where ptt would get stuck. 1.5 years later, it hasn't been an issue. Whereas before it was every time.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
It might be worth running Direwolf on Windows with some additional debugging to see if you can see a bit more detail and then compare to the Windows System logs. I suppose it could be possible that your other programs you're running on the same RF frequencies might have more fault recovery in them (say recovery from a USB reset) from but I kinda doubt it. Once there is a USB issue due to RFI, the bus will reset and then Direwolf will freak out. This improved fault tolerance in that running instance of Direwolf might be something possible to add to Direwolf but it's implementation will be very specific each and every OS that Direwolf can run on. Beyond the additional logging to help correlate, I think you can do two things: 1) start Direwolf with restart abilities. The User Guide mentions how to do this with cron. I'm sure something similar could be done with Windows but I don't have any immediate ideas for you. 2) I still believe your root issue is RFI related. I recommend you go the path of RFI reduction by putting frequency-correct ferries on both sides of every cable on your setup (audio, power, RF coax, etc). Consider shortening various cables to only what you need, avoid coiling cables to make them need as this creates more RFI sensitivity, etc. It can be a serious pain to troubleshoot and mitigate RFI but I think it's your best course of action.
I believe the issue was Direwolf and windows. I still think that. I only have that issue with Direwolf and no other software or OS. We do know there are issues. When a huge amount of users have the issues, you know there's a problem. We see it FREQUENTLY on Facebook.
PTT /dev/ttyWHATEVER RTS DTR
-- Mitch, AB4MW
Sent with Proton Mail secure email.
------- Original Message ------- On Thursday, June 23rd, 2022 at 10:20 AM, ab4mw @.***> wrote:
Easy Digi ties RTS and DTR together. You must configure Direwolf as RTS DTR on the end of the PTT line so they track together.
-- Mitch, AB4MW
Sent with Proton Mail secure email.
------- Original Message ------- On Thursday, June 23rd, 2022 at 10:18 AM, Mike @.***> wrote:
I just tested the RFI theory and I believe I am having the same issue but with using an FTDI and the RTS pin hooked up to an Easy Digi (octocoupler). I thought I was insane because when I switched to a test frequency, it worked fine, as soon as I tried it on 144.39, it stuck on every time! My test frequency was a UHF freq though (right next to each other in my memory bank). NOW I just tried on a VHF, and it stayed on. Fldigi also did it so it's not Direwolf. It happened with 2 different radios (Kenwood TH-F6A and a Baofeng), and 2 different FTDI adapters. Anyone solve this issue or at least find out if it's the computer itself, the octocoupler, the IC on the GPIO/RTS line?
If RFI is triggering the GPIO to stay high, I suggest a bypass 0.1uf across the GPIO and ground. I tend to add one from ptt to ground also. It has fixed that issue 100% for my custom hat cards I use where ptt would get stuck. 1.5 years later, it hasn't been an issue. Whereas before it was every time.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>