-
-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AIOC PTT locked on - Windows 10 PC, Fine on Raspberry PI #10
Comments
Hi @virtual812, From what you are saying, it is likely that this issue is Windows related. There is a nifty Utility called HTerm, that can be used to control the DTR and RTS lines on COM Ports. However I am not sure if that is compatible with the newest Versions of Windows: https://www.der-hammer.info/pages/terminal.html With respect to CHIRP, you can find the most current Version here: https://chirp.danplanet.com/projects/chirp/wiki/Download I hope this somewhat helps to narrow down the problem. Just plugging it into another Windows machine just for kicks and giggles is a good idea too. By default, The red LED should blink twice after plugging in and then switch off. |
Hi @skuep , On the notebook is was fine. I did however encounter one hiccup, on completion of the read the radio switched to transmit and the red light remained on, but an unplug / replug of the USB cable bought it back to idle with a green light only. Will work on this more tomorrow. edit:: It's feeling very much like it's just a me problem, and i think i might be the only one reporting this behaviour. Still the separate but maybe vaguely related issue of the device leaving a radio in transmit after a chirp read is also worth following up.. I'll see if i can reproduce this tomorrow on that Win11 notebook. Interested to hear if others are seeing this. Bed calls, cheers. |
Hi all, I'm just passing by,
The flatpak that Dan publishes is unfortunately only built for amd64. It can be built from source for other architectures but compiling on the pi is quite slow so I maintain the chirp-appimage repo mentioned above :) And a curious question for @virtual812 , when you plug in the USB adapter into the computer, is the radio already connected? If yes, I would first connect the USB cable to the computer and then after it is identified by Windows, plug it into the radio. I've seen this stuck PTT issue on some baofengs before when they are connected to the serial adapter first. [Edit] Oh and I completely forgot! Dan has updated CHIRP to python3 and gnome 3. That is called chirp-next and it's way easier to install on modern systems than the older python2 based version were (hence the need for flatpak, snap, appimage and so on). |
That is perfect. Red light means Tx and Green light means Rx on the COM Port
Interesting.. Could this maybe have to do with an old CHIRP version leaving DTR and RTS in some kind of bogus state before closing the connection?
I am glad you are having fun!
Damn, so it looks like there is some application installed on your computer, that grabs CDC ACM USB COM Ports. I doubt that it's actually Windows doing this.
It might be a problem with your particular setup, nevertheless it is good to know for me and future users where the pitfalls are. Since we have full control of the AIOC firmware, we might even built something to work around these issues and not leave the radio in transmit mode.
Could you maybe try to run HTerm after you noticed this problem and get the status of DTR and RTS? I suspect that something leaves those lines in a unfavorable state (for whatever reason). |
Ah too bad! Thanks for your work :-)
Haven't noticed anything with mine, but might be different on older Baofengs?
Nice! |
So, updating the Windows issue.. As far as the PTT stuck on all the time it is pointing to be an issue fairly local to my main PC. On 2 other machines, a Win11 notebook and Win10 desktop the PTT is not permanently on,
This specifically I'm going to make another issue for the sake of tidiness. Back to my main machine / PTT always on issue. On a side note I really feel that being more comfortable in an Linux environment would be beneficial to me. That said i'll put more time and effort into the Pi4.. i essentially have a "Pi Laptop" currently, with a Pi4, Argon One enclosure and NexDock Keyboard/Trackpad/Monitor/Battery . @goldstar611 I'll have a crack at getting chirp up on this "PiBook" tomorrow. |
I found an interesting way to find out, wo exactly is blocking your COM port. Maybe this could help in finding out where to look: https://superuser.com/questions/55334/now-whos-using-my-com-port EDIT: Also interesting: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YGw9CAG&l=de-DE Don't worry with Windows vs Linux. Personally I am not a big fan of Windows, but they AIOC should work regardless. |
I'm not smart often but i actually thought of this one myself :) Sadly it didn't work :( The last link is the one i'd found and i get a frustrating result. The service value is 'usbser', and cannot be found in ProcessExplorer... i suspect 'usbser' might be the value assigned to service when the device is (supposed to be) idle. The service name out of curiosity for COM1 is simply 'serial' Out of interest i opened HTerm and attempted to connect to COM10 Re-opoened device manager and checked service for COM1 in hope that i would see HTerm listed as the service utilising the port.. no.. still says 'serial'. I closed HTerm and opened the Arduino IDE and attempted to open a serial console - found COM10 'busy' It feels as if Windows is really trying hard to hide what's going on under the hood. Ignoring the issue with the AIOC, clearly when the COM1 is opened in Arduino IDE and before that in HTerm is WAS in use, so why is Windows hiding this? Tried on another machine with the same result. I'll sniff around for a better way to do this, and will watch here for more info / suggestions. |
Some Progress... |
I have been able to reproduce this issue. OS: Windows 10 22H2 x64 The first time I used it, I plugged it into my radio, then plugged the USB into the computer. It was properly identified and drivers were loaded: a TinyUSB audio device, and a COM port (in my case, COM6). I then started CHIRP and attempted to download from my radio (a Baofeng UV-82). I received an error: "Radio identifies as BTECH UV-5X3. Please choose the proper vendor/model and try again." I noticed that the radio's red LED was on. After I saw this issue and someone mentioning plug-in order, I re-did the test, but this time, I changed the order: I plugged the USB in first, then plugged it into the radio. No red LED. I then used CHIRP and was able to download from the radio; I had the typical intermittent blinking red LED. I was then given the results of the download. A quick glance and rapid comparison with a previously-saved file seems to indicate that the data is correct. However, when the download is done, the radio reboots. When it comes back from its reboot, the red LED is again on solidly. And I have confirmed that the radio is indeed transmitting in that state. I took a different radio and tuned it to the same frequency, with the squelch off. When the Baofeng does not have the red LED on solidly, I hear static, as expected. When the Baofeng does have the solid red LED, I hear silence, which seems to indicate an unmodulated carrier being transmitted. If I turn off the Baofeng, the other radio returns to static, as expected. At that point, power cycling the Baofeng has no change: I will get the solid red LED. If I pull the AIOC and reinsert it, same thing: no red LED when it's removed, red LED when it's inserted. The only way to get it to stop is to remove the USB cable. Once I do that, the radio works as expected -- until I use CHIRP to download the data again, and then I'm right back where I was, with a solidly-lit red LED. Further testing: I used PuTTY to open the COM port @ 9600 bps. Nothing happened in my PuTTY session, but when I typed characters I would get a flashing LED on the AIOC -- nothing on the Baofeng. BUT: when I closed the PuTTY session, I got a solid red LED on my Baofeng, and the only way to rectify this is to pull the USB cable. I also reproduced this simply by opening the terminal and closing it, without sending any data from my side. Same thing: solid red LED when the terminal is closed. I repeated all of the testing with my Baofeng programming cable. I suspect that my cable is not an OEM Baofeng cable, but is made by ABBREE: Baofeng use FTDI chips and mine uses a Pacific; however, mine has worked flawlessly so far. With the "oem" cable, I can plug it into the radio first, have the radio turned on, then plug it into the computer and everything works fine. I can use CHIRP to download and everything works fine. I can then change nothing and simply download it again into CHIRP and everything works fine. At no point does the other radio I have monitoring next to it ever receive a signal: I'm pretty sure at no point does the Baofeng transmit during this entire process. I also tested it with PuTTY: no feedback on the terminal (as expected), but when I closed the session no red LED and the radio did NOT start transmitting (again, as expected). So: my completely uneducated guess: there's a problem with the way the AIOC is responding to the way Windows is closing the COM port. This might be something that Windows is doing differently than Linux, but I'm not sure I'd call this a Windows problem, seeing as the "oem" cable does not have the same issue. It's also not a CHIRP problem, either, seeing as I could reproduce it with PuTTY. It seems that most of the issues discussed above are problems with trying to interact with the serial port, which I do not have; but I admit to not reading it in deep detail, so if I missed something I apologize. I'm happy to do whatever testing I can if you have suggestions of things to try. I'm reasonably comfortable with working with COM ports (in other words, I'm old enough to have had to do this for real in the bad old days... :) ). Please let me know how I can help. |
Hi @MiM-TMassey I think your issues is different the the one describes here. Try posting your experience to this this issue that better matches... Or if possible maybe someone can move it. This i suspect will be a common issue for Windows users like us. For the sake of tidyness I'd be happy for these comments to be moved or hidden when they're in the right place. |
Interesting, curious to know what might have happened there... Was the red LED on before you started the readout using CHIRP? If so, that could be a problem.
Just to clarify, if you do not do it that way (i.e. first plugging in the radio, then the AIOC), did the red LED already light up, before you even tried to download from the radio via CHIRP? That would be interesting to know, especially for this issue here. Also, if the red LED is lit up, I expect all the COM port programming stuff to fail, because the PTT line is (IIRC) shared with one of the UART lines.
Wait, the red LED goes off, if you disconnect the AIOC from the Baofeng? That should not be the case. Replugging the AIOC from the USB port however should cause this.
Thats helpful, thanks. So it does indeed have nothing to do with how CHIRP closes the port. It seems to be related to closing the port in general. I suspect Windows re-configures the RTS/DTR handshake lines after the port is closed. But already said, this can better be discussed in issue #11
I am not aware that GitHub allows to move comments between issues.. unfortunately. @MiM-TMassey: feel free to post again in the other issue @virtual812: I have been thinking in the mean time.. It is odd, that you cannot see any application actually opening the COM port, yet it is blocked for opening. Is there some antivirus or general PC security solution that you are running on your computer that may be responsible for blocking the COM port without being noticable? |
100% agree with everything you say. I suspect if i do a fresh windows install the problem will disappear. I think as you suggest it's a security / environment / driver issue. Asus X570 board / Ryzen 5800 / 32GB DDR4 / RTX 3070 I'm happy for this to be closed or left aside. |
I received another tip from a helpful person on the Internets. Not sure if it helps but at least you can try (if you have not already wiped your Windows partition :-)). This tip has to do with old serial mouses being probed (who uses them even anymore?). Apprently the following disables this behaviour: |
Will try in a few days, tied up currently but keen to help. |
I will handle this issue as a fluke. If there are still issues or more people experience this behaviour, feel free to reopen! |
Hi @skuep from v81 on Reddit
Have spent some time bringing a fresh setup of a Pi4 together.
Have found that on the Pi4 the issue with the red light / PTT stuck on does not happen.
I'm yet to successfully actually do anything with this board, Linux is not my strong point.
I'm aiming to have Chirp running soon, i have no idea how to install it... i did find an appimage, but couldn't get that to work.
I opened an issue regarding that - goldstar611/chirp-appimage#7
Happy to persist with some advice / suggestions to try.
I'm feeling like if there were a utility in Windows that allowed complex control of the serial device that might be worth trying.
The advice "The configuration for PTT is RTS set and DTR cleared." has me wanting to some how see if there is a way to check this in Windows, and see if there is a way i can alter this.
For the hell of it i also will try it in another Windows machine just to see what happens.
Looking forward to hearing from you, and i'll post any updates as i have them.
The text was updated successfully, but these errors were encountered: