AIOC PTT locked on - Windows 10 PC, Fine on Raspberry PI

[virtual812]

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 - https://github.com/goldstar611/chirp-appimage/issues/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.

[skuep]

Hi @virtual812, Ah, thanks for the details. Firstly, I would like to ask other people to confirm if this is a general issue or is something related to @virtual812 environment in order to better narrow down the issue.

From what you are saying, it is likely that this issue is Windows related. What Windows Version do you use? (Win 10). Do you have any software installed that might try to open any COM Port they find on the PC? VISA Libraries or some kind of Modem softwares or serial printer drivers immediately come to mind. If I remember correctly, CHIRP on Windows did not work either, correct?

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 You should definitely try to manipulate those lines manually, using this tool. My suspicion is, that the tool will quite possibly say, that the COM port is already opened in another application (or something along those lines).

With respect to CHIRP, you can find the most current Version here: https://chirp.danplanet.com/projects/chirp/wiki/Download If you want to try on the Raspberry Pi, it should be possible to install the flatpak. You can find information on how to install the required flatpak environment here: https://flatpak.org/setup/Raspberry%20Pi%20OS

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.

[virtual812]

Hi @skuep , Didn't get a chance to try another Win10 box nor spend more time on pi. I did however quickly run it through my Win11 Notebook.

On the notebook is was fine. Enumerated and loaded drivers quickly, fired up an old copy of chirp on that machine and got a read of the radio with no issue. No persistent red light this time, instead it only seemed to come on when there was activity.

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. It's a great little device, i really quite like it.

edit:: Had a quick look at Hterm Indeed the app should fail with a comport locked by another app message... only if i am using another app. So I thought maybe I could close Chirp and all apps and just see if with Hterm alone I can manipulate the CTS/DSR and other stated... Tried it and..... still locked by another app. Maybe Windows just does stupid things to comports by default these days? So i select COM1 , header on my motherboard... Nope... i can access COM1 fine.

It's feeling very much like it's just a me problem, and i think i might be the only one reporting this behaviour. I'll persevere, would love to get to the bottom of it, and if we can learn something that helps someone else then that's even better.

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. I'll note that was an old version of chirp (early 2022 i think).

Bed calls, cheers.

[goldstar611]

Hi all, I'm just passing by,

If you want to try on the Raspberry Pi, it should be possible to install the flatpak. You can find information on how to install the required flatpak environment here: https://flatpak.org/setup/Raspberry%20Pi%20OS

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).

[skuep]

On the notebook is was fine. Enumerated and loaded drivers quickly, fired up an old copy of chirp on that machine and got a read of the radio with no issue. No persistent red light this time, instead it only seemed to come on when there was activity.

That is perfect. Red light means Tx and Green light means Rx on the COM Port

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.

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?

Will work on this more tomorrow. It's a great little device, i really quite like it.

I am glad you are having fun!

edit:: Had a quick look at Hterm Indeed the app should fail with a comport locked by another app message... only if i am using another app. So I thought maybe I could close Chirp and all apps and just see if with Hterm alone I can manipulate the CTS/DSR and other stated... Tried it and..... still locked by another app. Maybe Windows just does stupid things to comports by default these days? So i select COM1 , header on my motherboard... Nope... i can access COM1 fine.

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's feeling very much like it's just a me problem, and i think i might be the only one reporting this behaviour. I'll persevere, would love to get to the bottom of it, and if we can learn something that helps someone else then that's even better.

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.

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. I'll note that was an old version of chirp (early 2022 i think).

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).

[skuep]

If you want to try on the Raspberry Pi, it should be possible to install the flatpak. You can find information on how to install the required flatpak environment here: https://flatpak.org/setup/Raspberry%20Pi%20OS

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 :)

Ah too bad! Thanks for your work :-)

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.

Haven't noticed anything with mine, but might be different on older Baofengs?

[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).

Nice!

[virtual812]

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, @goldstar611 All connections have been USB first, then radio connected after everything is enumerated and settled.

• However * on the 2 working machines I have seen the PTT remain on after reading the radio happening on every singe read, and need to disconnect and re-connect USB for it to stop.

This specifically I'm going to make another issue for the sake of tidiness.

Back to my main machine / PTT always on issue. I tried uninstalling the device in device manager - disconnecting - re-booting and re-connecting. It works then, can connect to and read a radio in CHIRP ---- and then the TX remains stuck on, but unlike the other PC's disconnecting and re-connecting does not resolve it. With my main box the only solution is removing the driver, unplugging the device and then plugging it in again. It's definitely something odd, and i'll continue to look in it with any assistance i can get. Considering it's just a me thing it's probably not worthy of any priority currently.

On a side note I really feel that being more comfortable in an Linux environment would be beneficial to me. I feel cheated that i can't dump Windows and put more time into Linux. Flight sim is another passion and getting all of the applications required for the complete experience to work just isn't happening.

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. Cheers.

[skuep]

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 You can use https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer for this

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.

[virtual812]

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 You can use https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer for this

EDIT: Also interesting: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YGw9CAG&l=de-DE

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 Tried COM1 - it works

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' Found COM1 ok and the serial console opened. Re-opened Device Manager again and service still says 'serial'.

It feels as if Windows is really trying hard to hide what's going on under the hood. BTW, tried with Process Explorer running as admin as well in case that made a difference.

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.

[virtual812]

Some Progress... Not at my desktop, but found this little executable here and it correctly ID's HTerm as having a port open when i connect to COM1 with HTerm. https://rigexpert.com/which-program-is-using-a-serial-port/

[MiM-TMassey]

I have been able to reproduce this issue.

OS: Windows 10 22H2 x64 CHIRP: CHIRP daily-20221217 AIOC: v1.0

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.

[virtual812]

Hi @MiM-TMassey

I think your issues is different the the one describes here. This issue is the RED LED remains on NO MATTER WHAT.

Try posting your experience to this this issue that better matches... PTT remains engaged after reading radio in Chirp_Next on Win10&11 machines https://github.com/skuep/AIOC/issues/11

Or if possible maybe someone can move it.

This i suspect will be a common issue for Windows users like us. I've replicated it across 3 machines total now.

For the sake of tidyness I'd be happy for these comments to be moved or hidden when they're in the right place.

[skuep]

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.

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.

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.

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.

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.

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.

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.

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 https://github.com/skuep/AIOC/issues/11

For the sake of tidyness I'd be happy for these comments to be moved or hidden when they're in the right place.

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?

[virtual812]

@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. It's so wierd. I'm considering it from a level deeper than an application... so OS / driver / security. You thoughts of AV are something sensible to check, but i run a fairly lean system and only use the builtin Windows Defender.

I suspect if i do a fresh windows install the problem will disappear. I certainly is a Windows or a Me problem, not a product issue with the exception that is affects this product specifically.

I think as you suggest it's a security / environment / driver issue. I hope it's not annoying but I'm going to list some stuff about my system that might prompt questions.

Asus X570 board / Ryzen 5800 / 32GB DDR4 / RTX 3070 Win10 Pro approx 2year old install TrackIR (head tracking for flight sim), Thrustmaster stick + throttle, MFG Crosswind rudder pedals Connected via GbE, network attached printer, NAS. Firefox, Steam, Uplay/Ubisoft connect, EA Origin, GoG Games. WSL installed could this be of interest? Visual Studio Installed Arduino IDE + Ardino drivers The Arduino install does install some serial drivers, also of interest?

I'm happy for this to be closed or left aside. Either way I'll still continue to look into it whenever i get any new ideas.

[skuep]

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: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1234&PID_1234\...\Device Parameters where VID and PID are 1209 and 7388 (hexadecimal) in the newest firmware. Add new DWORD SkipEnumerations -> 0xFFFFFFFF

[virtual812]

Will try in a few days, tied up currently but keen to help.

[skuep]

I will handle this issue as a fluke. If there are still issues or more people experience this behaviour, feel free to reopen!