search

skuep / AIOC

Ham Radio All-in-one-Cable
MIT License
759 stars 60 forks source link

PTT remains engaged after reading radio in Chirp_Next on Win10&11 machines #11

Closed virtual812 closed 9 months ago

virtual812 commented 1 year ago

To reproduce... Connect the AIOC to USB Wait for system to settle & USB Serial device show in Device manager Execute Chirp Do read radio process On completion of read radio appears to restart and be transmitting - red light on AIOC is lit. Unplugging USB and re-plugging USB seems to clear the PTT state and the AIOS can be used again.

Tested across 2 Windows 10 machines and 1 Win 11 machine. Test radio is Wouxun KG-UV9D Plus Will try another radio tomorrow and report back findings.

Interested to hear if anyone else is experiencing this.

skuep commented 1 year ago

I can not verify this problem with the KG-UV9D Mate (basically the same HT) on Linux, so it must be Windows-specific.

I am thinking, that upon closing the serial port, Windows does some re-configuring (e.g. enabling Hardware-Flow-Control) which leads to setting DTR=0 and RTS=1, which is required to turn PTT (and the red LED on).

I am wondering if that problem is more widespread. What could be the solution? Choosing RTS=0 and DTR=1 instead? What are other projects using, anyone know?

Can you, right after using CHIRP and the PTT staying on, use HTerm to find out what the state of DTR/RTS is? Or rather, if you can use HTerm to change those lines back to turn off the PTT. Just to make sure nothing crashed, or similar.

virtual812 commented 1 year ago

I'll try to get Chirp going on the Raspberry Pi ASAP so i can do side by side. I have a spare IBM Think Centre Ultra Small From Factor machine but it needs a power supply - this might give me an X86-64 Linux Platform to test on, might be easier.

On a non cursed machine here (not my main that leaves the DTR=0 RTS=1), tried my Puxing PX-888D radio in Chirp-next, seems Chirp does not support this model radio, but still after attempting a read the radio goes transmit and the AIOC red light remains illuminated.

Interestingly, Opening HTerm selecting the port and clicking connect clears the red light immediately.

As per other thread i'll look into Windows serial diagnosis deeper, any assistance here appreciated. It does indeed seem like this might affect all Windows users, it's readily able to be replicated here across any Windows machine. As for a potential solution, i have no idea, i can't program to save my life, but this stuff is all cool and I'm learning and happy to help anyway i can.

Edit to add.. i suck at code, but am actually pretty good at soldering, including SMD, so if any hardware mods are merrited i could have a go.

skuep commented 1 year ago

So the solution to this problem that I am currently thinking of is to change the behaviour for PTT activation.

I.e. currently, you need DTR=0 and RTS=1 to activate the PTT. We should try switching that to DTR=1 and RTS=0. That will most definitely solve this problem right here, however I am very unsure if this does provoke new problems, where the PTT will be activated unwantedly at some other time.. It really does not help, that Windows plays around with those DTR/RTS lines all the time.

If you like, I will produce a new firmware and attach it here, so you can try it out. Are you able to program the AIOC using the integrated bootloader? It just requires shorting those two pins near the USB connector before plugging the AIOC in and then using dfu-util to program the microcontroller.

MiM-TMassey commented 1 year ago

See https://github.com/skuep/AIOC/issues/10#issuecomment-1399727670 for background.

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.

I cannot say. I wasn’t looking for it, and it wasn’t until the error happened that I started looking for what might be wrong. But at that time, the error was consistent and repeatable: I redid it easily a half-dozen times, but iirc without power cycling the AIOC.

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?

At this point, no: afaict the only time the transmit led stays on is after the com port is closed. Then it stays that way until the AIOC is power-cycled.

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.

I will test that tonight before I agree to your statement. :) (Rereading this: are we talking about the same red led? I will document both the AIOC activity led and the radio transmit 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.

Yes, removing the AIOC turns off the transmit led: there’s nothing driving the PTT! :) Plugging the AIOC back in causes the transmit led to come on. Maybe you’re thinking the red activity led on the AIOC? That’s why I’ve switched to writing “transmit led” to avoid confusion. It wasn’t until late in my testing that I started noticing the AIOC’s red led (it’s on the back away from me when in the radio), and at no point did anything I write reflect the state of that led. The red led I was speaking of was consistently the transmit led. That is why I’m not using that verbiage now. :)

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’m here now. :)

My marching orders: Document how the process reacts (transmit led and AIOC activity led) before and after the com port is closed. Anything else you want tested?

MiM-TMassey commented 1 year ago

So the solution to this problem that I am currently thinking of is to change the behaviour for PTT activation.

One thing I would like to mention: it seems that none of this should need to be original. I’ve done PTT with com ports with other USB to serial cables and radios, with zero issues. I’ve done it with both DireWolf and SoundModem, and there hasn’t been an issue with the PTT staying on at any point. I have even used the same serial port for both CAT (requiring two-way serial port data) and DTR/RTS PTT control simultaneously. I can even switch between using DTR or RTS for PTT (and the other for, say, CW keying). All of it simply works, with a generic USB serial cable — actually, I’ve done it with four different serial chipsets.

That seems to imply to me that this can be made to work, and should not require a unique solution for AIOC no matter what Windows may or may not be doing. The only thing that I’m not certain about is the hybrid combination of CHIRP data access and PTT control from a single serial port: maybe there is an element of that intersection that might create unique challenges.

But I’m pretty sure that what AIOC is currently doing deviates from what a normal serial port provides. For example. SoundModem does not work with AIOC for PTT. DireWolf seems to, but SoundModem does not. Yet, if I use a generic USB serial port, they both do — and with the default configuration other than supplying the port number.

Ideally, it would be wonderful if the AIOC would be consistent with the functionality of a standard com port. If there is a concrete reason why that can’t happen, fine. And for debugging, go nuts. But it seems there are examples of that functionality working correctly with no unique configuration.

Just my $0.02, from a random stranger who isn’t paying for this in the first place… :)

MiM-TMassey commented 1 year ago

CHIRP communication process:

Initial State: Baofeng UV-82 off. AIOC unplugged from both radio and computer. AIOC previously plgged into computer, so all drivers loaded successfully.

Not for nothing, but if you're ever bored and looking to redesign the board, maybe consider mirroring the board left-to-right, so that the radio connectors are on the other side, and the components (such as the LED status lights!) are facing forward when plugged into the radio? :)

MiM-TMassey commented 1 year ago

For reference, here are the DTR/RTS statuses (as reported by "mode comX", where X=4 for Baofeng cable and 6 for AIOC):

After initial plug-in, before CHIRP download: BAOFENG:

Status for device COM4:
-----------------------
    Baud:            19200
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     ON
    RTS circuit:     ON

AIOC:

Status for device COM6:
-----------------------
    Baud:            115200
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     OFF
    RTS circuit:     ON

After CHIRP download: BAOFENG:

Status for device COM4:
-----------------------
    Baud:            9600
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     ON
    RTS circuit:     ON

AIOC:

Status for device COM6:
-----------------------
    Baud:            9600
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     ON
    RTS circuit:     ON
MiM-TMassey commented 1 year ago

I wanted to compare how AIOC is reacting compared to a known-good and very common configuration on Windows. Here are my results:

On Windows, I have a feeling that SoundModem is much more popular than DireWolf. I use both DireWolf and SoundModem, but changing configuration in SoundModem is faster and easier, so I started with it. In addition, I also used a RigBlaster Pro, also a very popular radio interface, along with a Kenwood TM-231a radio.

The first thing I found was: neither SoundModem nor the RigBlaster use DTR for PTT. They both use RTS. I'd never bothered to figure out which one was being used: it had always worked first time, every time. Unless there is a very good reason to abandon this, I would recommend that AIOC follow suit.

Using a typical USB Serial cable, SoundModem configured for that COM port (8) but with all other settings left at default, and the RigBlaster Pro in factory configuration, I was 100% able to get reliable PTT. The easiest way is using the "Calibrate" function. Turn on the calibration tone, the PTT engages. Turn off the tone, the PTT stops. Just like it's supposed to.

I then switched over to using DireWolf. For its configuration, I used the following PTT line: "PTT COM8 RTS". This is again the typical DireWolf configuration: notice that specifying multiple control lines wasn't even possible before DireWolf 1.2 -- that's because this is not the typical way of doing it! (Ref: https://raw.githubusercontent.com/wb2osz/direwolf/dev/doc/User-Guide.pdf Section 9.2.9.1).

So, I have both SoundModem and DireWolf working 100% perfectly with a typical USB Serial cable and a typical hardware interface. Now, time for AIOC.

First, I tried to make AIOC work with SoundModem. It turns out that no matter whether I used DTR or RTS, I could not get the AIOC activity light to light up. So much for that.

Next, DireWolf. Using the (quite non-typical) PTT line in the AIOC readme ("PTT COM6 RTS -DTR"), I was able to get the PTT to work (as shown by the activity light). OK. However, if I used any PTT line that only specified a single control signal, the AIOC activity light would not light up. I tried "PTT COM6 RTS", "PTT COM6 DTR" and "PTT COM6 -DTR": none worked.

This last test seems to indicate to me that the AIOC will only respond to a specific state of both RTS and DTR before you enable PTT? (I haven't had a chance to look into the source to see what's going on here.) [Edited to add: I just re-read your last comment above, and I now realize that you wrote exactly that: RTS and DTR must both be in specific (and opposite) states for PTT to work. I wish I had understood that better a few hours ago! :) But I'm glad my testing got the right results.]

Was it your intention for the AIOC to work quite differently than the typical configuration used with normal serial connections? Without knowing how we ended up where we are now, it's hard to suggest where to go next. If your intention was to make the AIOC work like a typical serial cable does, I would suggest responding to RTS only instead of DTR or some combination of RTS and DTR. This seems like it would bring you in line with the most common expectations.

Also, while playing with all of this, I noticed a couple of other details:

I look forward to your thoughts. For me, using AIOC as a combination sound card/PTT is WAY more important than as a programming cable. Not only do I already own a programming cable, they are very cheap, easy to get and already work perfectly; but PTT-enabled sound interfaces for Baofengs are much harder to get -- and sound/PTT in a single device with a single USB connection is, I believe, unique at this time. If the PTT interface were brought in line with the common expectations (e.g. use RTS only!), this will be a powerful tool.

Let me know where you would like to go from here. It seems the problem comes down to a combination of cross-platform differences in how CHIRP manages DTR/RTS status (possibly contributed to by the underlying OS, and certainly because no one ever cared what the DTR/RTS statuses were when CHIRP was done!), and also the expectations of AIOC on how to trigger PTT. Unfortunately, I don't think this comes down to an actual bug per se, but much more a series of assumptions and expectations that are just not able to be assumed everywhere; unfortunately, these might need to be rethought.

I'm very happy to help with any additional testing, etc. you might wish. Please let me know how I can help.

skuep commented 1 year ago

Thanks for all the info! I have to take some time to churn through them all.

I am not a ham myself, so I am not aware of any de-factor standards of how things should be done. I was trying hard to find out what the de-factor standard is, but particularly for all the ham stuff, it is really hard to google since everything is kind of obscure. I am very interested in making the AIOC as universal as possible, so keep your feedback coming!

Ideally, it would be wonderful if the AIOC would be consistent with the functionality of a standard com port. If there is a concrete reason why that can’t happen, fine. And for debugging, go nuts. But it seems there are examples of that functionality working correctly with no unique configuration.

I totally agree. However things are not as easy as they might seem :-)

The cables you are using for RTS/DTR are FTDI or Silabs or similar cables. They have their own proprietary driver that gets installed via Windows Update. The AIOC uses the official USB CDC-ACM class and the driver for this class comes from Microsoft (at least on Windows OSes). So the issues that we are seeing here are directly related to Microsofts implementation of their CDC-ACM COM port (unfortunately).

One last thing: Currently, DTR=0 and RTS=1 activates PTT, i think it is even written in the direwolf manual that this is often used to prevent exactly what we are seeing today. SoundModem (and other software) apparently don't support a logic like this. However I suspect that just using RTS=1 and ignoring DTR for PTT will severely increase the problems we are having here and it is kind of bad that SoundModem does not support this. But we will find a way around that.

The main cause we are facing these issues with the AIOC is that the same port is used for programming and PTT control. After all, if you want to program your device (and RTS and DTR gets manipulated), you don't want to assert the PTT, since that will cause the programming to fail, because some lines on the K1 connectors are shared. This scenario is unique to the AIOC (is it?).

In the end we might need to settle for something like:

MiM-TMassey commented 1 year ago

One last thing: Currently, DTR=0 and RTS=1 activates PTT, i think it is even written in the direwolf manual that this is often used to prevent exactly what we are seeing today. SoundModem (and other software) apparently don't support a logic like this. However I suspect that just using RTS=1 and ignoring DTR for PTT will severely increase the problems we are having here and it is kind of bad that SoundModem does not support this. But we will find a way around that.

Sure, as a programmer I completely get it. And it might even be made to work — but only if the only software you want to use is DireWolf. Remember that this mechanism predates a lot of flexibility we have today: it started as simply using voltage to control a relay. And there’s a lot of software (like almost all of it!) that expects a single control line will control PTT — and doesn’t give you the ability to apply different logic to multiple pins….

Honestly, if you stick with the complex solution you have now, my thought is you’re going to lose the only advantage of using a serial based solution in the first place: backward compatibility with the majority of amateur radio software. And if you’re willing to do that, you might as well drop the serial port interface for PTT completely and simply go with direct GPIO — which DireWolf supports, too! :) (This is becoming more popular as more software supports Raspberry Pi’s, but ham software evolves slowly — why do you think we’re still screwing around with stupid obsolete serial ports? :) Personally, I can’t wait — I didn’t like serial ports when they were our only choice, let alone today…. But losing all that existing software is painful.)

In the end we might need to settle for something like: using RTS (or DTR) only for PTT change firmware that when data is sent, PTT is deactivated always from within the firmware and DTR/RTS are ignored.

Or just a m/c switch to a GPIO to toggle PTT awareness on and off…. Press it once, the AIOC won’t enable PTT no matter what; press it again and it does…. Call it a toggle between “programming mode” and “PTT mode”.

As for some sort of heuristic to use the presence of serial data to enable or disable control of PTT: I know that with other radios there are lots of times where data can be sent or received via the serial port simultaneously while control pins are being used for PTT — it’s not an either/or. Baofengs are more limited of course, so that either/or state may be sufficient. I’m just reluctant to say so definitively.

If you did assume that you will never want serial data and PTT control to coexist simultaneously, I can easily envision making the first character received disable PTT control. But two objections come to mind. First, what if the software you’re using for PTT control sends a character for whatever reason? No one would have ever likely noticed — just like no one ever noticed how CHIRP left the DTR/RTS pins! :) That will be a real tough bug to track down, and they will blame the AIOC, not the software that’s worked the way it’s worked forever. And second, what heuristic will you use to switch back to PTT control? A simple timer means that if I leave the AIOC plugged in, but don’t start PTT-controlling software before the timer expires (like if I start programming the radio and get distracted or walk away), I will now cause my radio to start transmitting, possibly jamming a repeater and certainly doing nothing good for my radio — these things get hot when they transmit….. I think neither the radio owner nor the government will like that…

You could also combine this with the m/c switch: the first character disables PTT control automatically; press the button when you’re done to enable PTT control. Now you can start the programming and walk away all you want… :)

I just want to say thank you for all of your hard work. This is a very neat device and I’m looking forward to digging into it more deeply. Please don’t take my reply as any kind of criticism or demand. I understand my opinion doesn’t mean much! That’s the beauty of open source: I can make it work the way I want, too…. :) Again, thank you very much.

skuep commented 1 year ago

I am back in town and thought about the problem. I also received some valuable information from a few people. For SoundModem there is a workaround to get the AIOC to work (currently). Apparently setting InvPTTPins=1and SwapPTTPins=1 to get the -DTR RTS behaviour. In Fldigi apparently ticking all 4 boxes related to the PTT pins should do the trick.

However I agree, that this is utter bullcarp. There has to be a better solution.

For reference, here are the DTR/RTS statuses (as reported by "mode comX", where X=4 for Baofeng cable and 6 for AIOC):

Hmm, I had a second look and according to your data, DTR=ON and RTS=ON after programming with CHIRP for the AIOC should not activate the PTT. So something must be off here? Can you confirm?

I also had a look at the digirig, it just uses the RTS line for controlling PTT. Thought about doing the same, but opening this serial port in CHIRP will probably lead to PTT being asserted always and would need to be turned off with the first character received (no problem). But according to your diagrams, PTT will most definitely be asserted after the COM port is closed?

Not for nothing, but if you're ever bored and looking to redesign the board, maybe consider mirroring the board left-to-right, so that the radio connectors are on the other side, and the components (such as the LED status lights!) are facing forward when plugged into the radio? :)

If you want, you can move the LEDs from the front and solder them to the back side. The pads are mirrored ;-) Unfortunately MCU pinout does not allow the design any other way in the compact form factor.

MiM-TMassey commented 1 year ago

For SoundModem there is a workaround to get the AIOC to work (currently).

A quick test seems to indicate that this works (using calibration for testing). Next nitpick: SoundModem won't allow a sample rate above 12000... :) When you're dealing with a whopping 3k of bandwidth maximum, even 12k sample rate is overkill. A lot of (Windows) Amateur Radio software uses 11,025 sample rate by default because of this. The AIOC readme seems to indicate that 11,025 or 12,000 are not supported. I get audio with those settings, but I have no idea how it's being mangled.

Another issue: with the new SoundModem settings, when you exit SoundModem, you get the stuck PTT, just like CHIRP! This does not happen with the default SoundModem settings.

For reference, here are the DTR/RTS statuses (as reported by "mode comX", where X=4 for Baofeng cable and 6 for AIOC):

Hmm, I had a second look and according to your data, DTR=ON and RTS=ON after programming with CHIRP for the AIOC should not activate the PTT. So something must be off here? Can you confirm?

Can confirm:

C:\Windows\system32>REM Initial State - Just plugged in - AIOC Green LED only.
C:\Windows\system32>mode com6
Status for device COM6:
-----------------------
    Baud:            115200
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     OFF
    RTS circuit:     ON

C:\Windows\system32>REM After initial CHIRP download - AIOC red led locked on
C:\Windows\system32>mode com6
Status for device COM6:
-----------------------
    Baud:            9600
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     ON
    RTS circuit:     ON

Without an ability to wedge a RS-232 breakout box in the flow, I can't physically see the status of the RTS/DTR lines themselves. I can only report what the software is telling me. I am not sure how confident to be with that information. I agree it seems obviously wrong.

Here's how to manipulate the port via PowerShell. This may help you or others in your debugging: it only uses software included with the OS.

$port = New-Object system.io.ports.serialport COM6
$port.Open()
# Print out the current states:
$port.DtrEnable
$port.RtsEnable 
# Example to turn on the signal:
$port.DtrEnable = $true
$port.RtsEnable = $true
# Example to turn off the signal:
$port.DtrEnable = $false
$port.RtsEnable = $false
# Do whatever debugging, etc.  When done:
$port.Close()

A miscellaneous note: I've mentioned previously that after the initial CHIRP download (i.e. with the AIOC left in its stuck-on state), if I immediately do a second download attempt I get an error: "Radio identifies as BTECH UV-X3". However, if after that first download completes I use PowerShell to open the port, the PTT goes off. If I then close the port, the PTT stays off. If I then redo the CHIRP download, it works successfully. I don't think it's a surprise that it works correctly after the PTT is cleared. What is a surprise (to me, anyway), is why doesn't CHIRP work without doing so? Why can't it open the port like PowerShell does and do what it needs to start the communication properly?

I'm out of clever ideas on what I might be able to play with on the PTT side. Like I've said before: I have a separate programming cable, I rarely program the radio anyway, and therefore I have very little need to use the AIOC as a programming cable. My interest comes in using it as a PTT-enabled interface for APRS. And at least I can make it work with DireWolf at this time, so that's what I'm playing with. But if you've got something that I can test or whatever, please let me know.

(And my original idea for AIOC was to use VOX to handle PTT, like a SignaLink USB. That would make all of this PTT nonsense completely superfluous. I was pleased that I might not have to bother because you had already added serial-based PTT, but given the difficulties, I'm again wishing for VOX PTT... :) )

skuep commented 1 year ago

Man, thanks a lot for the investigation!

A quick test seems to indicate that this works (using calibration for testing). Next nitpick: SoundModem won't allow a sample rate above 12000... :) When you're dealing with a whopping 3k of bandwidth maximum, even 12k sample rate is overkill. A lot of (Windows) Amateur Radio software uses 11,025 sample rate by default because of this. The AIOC readme seems to indicate that 11,025 or 12,000 are not supported. I get audio with those settings, but I have no idea how it's being mangled.

Nice! Well, kind of :-) Is there no way to select 22050, 24000 or 48000 Hz? I guess I will need to implement 11025 and/or 12000. You are of course correct with the 3kHz Bandwidth and the sample rate. Should be an easy fix though!

Can confirm: ... Without an ability to wedge a RS-232 breakout box in the flow, I can't physically see the status of the RTS/DTR lines themselves. I can only report what the software is telling me. I am not sure how confident to be with that information. I agree it seems obviously wrong.

So what you are saying is, that the mode command shows DTR=1 and RTS=1 and the PTT is on (red LED on your HT and on the AIOC)? That is odd. Then the output of the mode command probably is overriden (DTR forced to 0, RTS stays as before) at the time where the port is being closed. Once the port is opened, the DTR is restored to whats shown in mode output. Especially since the first output of the mode command should make the AIOC transmit, but apparently it does not. This somehow tells me, that the output of mode is only applied when the port is open. Otherwise the CDC driver plays around with the RTS/DTR lines as it likes.. You could try your little script with 

$port.DtrEnable = $true
$port.RtsEnable = $true

And try again. Does it turn the PTT now on after closing?

But yeah, why does your script not leave the port in this state? Beats me... I think we will need to trial & error unfortunately. What about I generate some test-firmwares, where PTT is configured as RTS-only and DTR-only and maybe -RTS +DTR just for kicks. Would you be willing to test them?

I think VOX-PTT would be a nice solution, but it's probably not done in the short run. Gotta name it something different, because (regular) "VOX" with digital modes has a bad reputation. :-)

MiM-TMassey commented 1 year ago

Is there no way to select 22050, 24000 or 48000 Hz?

It's a text box. When you put a number larger than 12000, you are told that you must use a number no larger than 12000.

You could try your little script with [raising DTR and RTS]

Happy to! (Spoiler alert: DTR/RTS changes seem to be cached when the port is closed.)

PS C:\Users\tmassey> $port = New-Object system.io.ports.serialport COM6
PS C:\Users\tmassey> # Print out the current states before open:
PS C:\Users\tmassey> mode com6

Status for device COM6:
-----------------------
    Baud:            9600
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         ON
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     OFF
    RTS circuit:     OFF

PS C:\Users\tmassey> $port.DtrEnable
False
PS C:\Users\tmassey> $port.RtsEnable
False
PS C:\Users\tmassey> # Alter the states in a way to see feedback:
PS C:\Users\tmassey> $port.DtrEnable = $false
PS C:\Users\tmassey> $port.RtsEnable = $true
PS C:\Users\tmassey> # PTT is still OFF!
PS C:\Users\tmassey> # Check the state:
PS C:\Users\tmassey> mode com6

Status for device COM6:
-----------------------
    Baud:            9600
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         ON
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     OFF
    RTS circuit:     OFF

PS C:\Users\tmassey> $port.DtrEnable
False
PS C:\Users\tmassey> $port.RtsEnable
True
PS C:\Users\tmassey> # Open the port and see what happens:
PS C:\Users\tmassey> $port.Open()
PS C:\Users\tmassey> # PTT is now ON!
PS C:\Users\tmassey> # Print out the current states:
PS C:\Users\tmassey> mode com6
Device COM6 is not currently available.
PS C:\Users\tmassey> $port.DtrEnable
False
PS C:\Users\tmassey> $port.RtsEnable
True
PS C:\Users\tmassey> # Make another change:
PS C:\Users\tmassey> $port.DtrEnable = $true
PS C:\Users\tmassey> $port.RtsEnable = $true
PS C:\Users\tmassey> # PTT is immediately off!
PS C:\Users\tmassey> # Print out the current states:
PS C:\Users\tmassey> mode com6
Device COM6 is not currently available.
PS C:\Users\tmassey> $port.DtrEnable
True
PS C:\Users\tmassey> $port.RtsEnable
True
PS C:\Users\tmassey> # Close port:
PS C:\Users\tmassey> $port.Close()
PS C:\Users\tmassey> # PTT is back ON!
PS C:\Users\tmassey> # Print out the current states:
PS C:\Users\tmassey> mode com6

Status for device COM6:
-----------------------
    Baud:            9600
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         ON
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     ON
    RTS circuit:     ON

PS C:\Users\tmassey> $port.DtrEnable
True
PS C:\Users\tmassey> $port.RtsEnable
True
PS C:\Users\tmassey> # Try to lower the signals:
PS C:\Users\tmassey> $port.DtrEnable = $false
PS C:\Users\tmassey> $port.RtsEnable = $false
PS C:\Users\tmassey> # Check the state:
PS C:\Users\tmassey> mode com6

Status for device COM6:
-----------------------
    Baud:            9600
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         ON
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     ON
    RTS circuit:     ON

PS C:\Users\tmassey> $port.DtrEnable
False
PS C:\Users\tmassey> $port.RtsEnable
False
PS C:\Users\tmassey> # PTT is still on!
PS C:\Users\tmassey> # Open the port
PS C:\Users\tmassey> $port.Open()
PS C:\Users\tmassey> # PTT is now off.
PS C:\Users\tmassey> # Check the state:
PS C:\Users\tmassey> mode com6
Device COM6 is not currently available.
PS C:\Users\tmassey> $port.DtrEnable
False
PS C:\Users\tmassey> $port.RtsEnable
False
PS C:\Users\tmassey> # Close the port
PS C:\Users\tmassey> $port.Close()
PS C:\Users\tmassey> # PTT is still off.
PS C:\Users\tmassey> # Check the state:
PS C:\Users\tmassey> mode com6

Status for device COM6:
-----------------------
    Baud:            9600
    Parity:          None
    Data Bits:       8
    Stop Bits:       1
    Timeout:         ON
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     OFF
    RTS circuit:     OFF

PS C:\Users\tmassey> $port.DtrEnable
False
PS C:\Users\tmassey> $port.RtsEnable
False
PS C:\Users\tmassey>

So as you can see, the system seems to cache the states and report what you've asked for them to be, but only changes them when the port is actually open.

The weird one is when I close the port with both DTR and RTS high, the PTT engages. Both mode and PowerShell (PS) show that DTR and RTS are both high. I would love to be able to actually measure DTR/RTS with a breakout box (or even a multimeter) but I'm assuming that those never exist as discrete signals on the board -- why should they? They're only used internally by the microcontroller.

I redid the PTT state before and after the port close with all combinations of DTR and RTS status:

Lvl @ Close |  PTT @ Close
DTR | RTS   | Before | After
----|-------|--------|-------
Off | Off   | Off    | Off
Off | On    | On     | On
On  | Off   | Off    | Off
On  | On    | Off    | On

My guess is that something is silently clearing DTR as part of port close (maybe the driver?) -- after all, the terminal is most certainly not ready... :) But the only way to know for sure is with a multimeter (though probably we can trust the firmware to report this accurately? At least we'll know what it thinks it's seeing.)

What about I generate some test-firmwares, where PTT is configured as RTS-only and DTR-only and maybe -RTS +DTR just for kicks. Would you be willing to test them?

Absolutely.

I really wish there were a m/c switch on this thing: you can do so much reconfiguration with simply a single button... it would be nice to temporarily repurpose the green LED for showing DTR or RTS status -- and I would start with DTR, seeing as it's the one that seems to be changing behind our back. (But a switch would allow us to see the status of multiple signals, and cycle through them with a press... Just saying...)

I think VOX-PTT would be a nice solution, but it's probably not done in the short run. Gotta name it something different, because (regular) "VOX" with digital modes has a bad reputation. :-)

Call it "Auto-PTT" then. And yes, radio-based Vox has a (deservedly) bad rep -- especially on Baofengs, but both RigBlasters and SignaLink USB have Vox-based modes -- and the SignaLink ONLY uses VOX... And being Vox-only hasn't hurt the SignaLink one bit: the SignaLink is the most desirable interface for the average ham. (The Masters Communications RA-Series interfaces are a bit more sophisticated -- they support CM119A-based GPIO! -- but a lot more ugly.) The only reason people use lesser interfaces is cost.

And we can add Vox to the AIOC without changing the cost... :)

Now that Winter Field Day is past, I'll have bit more time -- but I leave for a Florida cave diving trip in 3 weeks, so preparation for that will start to chew into my free time. But I'll make sure I've got some time for this: if you have firmware to test, I'll get it done. But digging into my own custom firmware (and possibly hacking at a VOX soution) will have to wait until mid-March at the earliest. (And then there's spring yard cleanup, and... :) )

skuep commented 1 year ago

The weird one is when I close the port with both DTR and RTS high, the PTT engages. Both mode and PowerShell (PS) show that DTR and RTS are both high. I would love to be able to actually measure DTR/RTS with a breakout box (or even a multimeter) but I'm assuming that those never exist as discrete signals on the board -- why should they? They're only used internally by the microcontroller.

Yeah exactly. But the Red LED on the AIOC pretty much only lights up (currently), when it received DTR=0 and RTS=1. So if it lights up, you can be sure that the Host send this combination to the AIOC.

Call it "Auto-PTT" then. And yes, radio-based Vox has a (deservedly) bad rep -- especially on Baofengs, but both RigBlasters and SignaLink USB have Vox-based modes -- and the SignaLink ONLY uses VOX... And being Vox-only hasn't hurt the SignaLink one bit: the SignaLink is the most desirable interface for the average ham. (The Masters Communications RA-Series interfaces are a bit more sophisticated -- they support CM119A-based GPIO! -- but a lot more ugly.) The only reason people use lesser interfaces is cost.

And we can add Vox to the AIOC without changing the cost... :)

I like "Auto-PTT". Nice! Before implementing this feature I would like to add a HID endpoint for configuring the AIOC. Then we can decide whether we choose the Manual-PTT (current) or the Auto-PTT as default setting. Since you said that even the SignaLink does it, I am a bit more convinced. CM119A based GPIO should be quite easy to implement btw.. If you think it's worthwhile.

As you say, we don't need to pay a thing :-)

See in my attachment 3 firmwares with RTS-only, DTR-only and DTR=1 and RTS=0 PTT behaviour. Feel free to try them. I would assume, that RTS-only, although preferable since that seems to be some kind of quasi-standard, will enable PTT after your CHIRP session all the time, which is no good. DTR-only should be fine (TM)?

I tested these combinations on Linux CHIRP variant. As suspected, CHIRP sets the RTS=1 and DTR=1, which enables PTT and inhibits programming. So I had to implement a feature in these variants, that disables the PTT no-matter-what, once it receives the first character from the PC to send out via UART. It stays disabled, until an pplication changes the RTS/DTR lines and the host sends a new message with the updated RTS/DTR state.

aioc-fw-dtr.bin.zip aioc-fw-dtrnrts.bin.zip aioc-fw-rts.bin.zip

MiM-TMassey commented 1 year ago

First, an aside: do you want to keep using this issue as a free-form communication channel? It's your project, so what you say goes. I try not to be as pushy as the guy in issue 10, but I too understand his desire to keep issues from morphing all over the place. Should we either split some of this stuff out, or use some other vehicle for back and forth communication related to new features, state of the Amateur Radio hobby, etc.? :)

PTT-related issues

See in my attachment 3 firmwares with RTS-only, DTR-only and DTR=1 and RTS=0 PTT behaviour. Feel free to try them. I would assume, that RTS-only, although preferable since that seems to be some kind of quasi-standard, will enable PTT after your CHIRP session all the time, which is no good. DTR-only should be fine (TM)?

Seeing as (we guess) Windows is dropping DTR when it's high when a port closes, the current firmware and RTS-only should practically function the same -- poorly. The one that has a chance to work correctly without user intervention is the DTR-only one. IME, this can be made to work with most (if not all) common software, even if it isn't the default or ideal setting. Certain hardware devices (like the original RigBlaster) are hard-wired for RTS, but that's not especially relevant for the AIOC: as long as the software supports DTR, it's fine; and DTR-only is not a big ask. (Coordinated DTR and RTS is, IMHO.)

If CHRIP on Linux leaves DTR high, though, it might not be any more useful on Linux than DTR low/RTS high is on Windows... Without your heuristics described below, anyway.

I tested these combinations on Linux CHIRP variant. As suspected, CHIRP sets the RTS=1 and DTR=1, which enables PTT and inhibits programming. So I had to implement a feature in these variants, that disables the PTT no-matter-what, once it receives the first character from the PC to send out via UART. It stays disabled, until an pplication changes the RTS/DTR lines and the host sends a new message with the updated RTS/DTR state.

I'm not sure what "changes the RTS/DTR lines" means exactly: changes them to what, exactly? I assume drop them both to 0? And I have no idea what "sends a new message" means: things that control PTT don't send any "message": they (should) only manipulate the states. It's not vital that I understand it at this moment, but for completeness it might be good to document this a little more rigorously.

In the interim: exactly what would you like me to test? What procedure would you like me to do (even in general), and what results do you want me to record and report?

As a wild guess, I'm going to start with: Perform a series of CHIRP downloads, and have it A) not lock PTT, and B), work correctly. Then without rebooting the device, use the device for audio/PTT control and ensure that they work there. Then probably go back to CHIRP. Then reboot the thing and reverse: Audio/CHRIP/Audio. I can report on each process and whether it was successful or not, and if not, what exactly I see.

Is this on the right track? Do you have different or more specific thoughts?

Alternative PTT Control Techniques

I like "Auto-PTT". Nice! Before implementing this feature I would like to add a HID endpoint for configuring the AIOC. Then we can decide whether we choose the Manual-PTT (current) or the Auto-PTT as default setting. Since you said that even the SignaLink does it, I am a bit more convinced. CM119A based GPIO should be quite easy to implement btw.. If you think it's worthwhile.

The SignaLink USB does indeed use VOX exclusively for PTT. The radio may support CAT control and you might choose to use that, but it's unnecessary. For example, when using a radio with a 6-pin Mini-DIN (which includes audio and PTT in a single connector), you will be using the SignaLink's VOX control exclusively via a single cable. It's very nice. And no need for software support, either: just push the audio and it works.

And CM119A GPIO would be flat-out amazing. If you want to really geek out, check out AllStartLink -- a worldwide network of Asterisk PBX systems combined with repeaters (both big public repeaters and home-sized nodes). The most common way to connect radios to ASL requires modifying a CM108/CM119A-based sound card dongle to expose a couple of the GPIO pins to use for PTT and COS/COR control. If all of that could be integrated into the AIOC, you'd have a complete ASL RF interface... (There are details. like how to make COS work, because I don't think the 2.5/3.5mm interface gives you what you need for a COS interface, but when you have the power of a microcontroller directly at the analog/digital interface, there are ways... Like reverse-VOX... :) ).

As you say, we don't need to pay a thing :-)

Crazy cool. Awesome project.

skuep commented 1 year ago

First, an aside: do you want to keep using this issue as a free-form communication channel? It's your project, so what you say goes. I try not to be as pushy as the guy in issue 10, but I too understand his desire to keep issues from morphing all over the place. Should we either split some of this stuff out, or use some other vehicle for back and forth communication related to new features, state of the Amateur Radio hobby, etc.? :)

Related to this issue I see no problem. Regarding the other stuff (CM118A PTT, Auto-VOX) feel very free to open a new issue, where we can collect the information required to implement it :-)

Seeing as (we guess) Windows is dropping DTR when it's high when a port closes, the current firmware and RTS-only should practically function the same -- poorly. The one that has a chance to work correctly without user intervention is the DTR-only one. IME, this can be made to work with most (if not all) common software, even if it isn't the default or ideal setting. Certain hardware devices (like the original RigBlaster) are hard-wired for RTS, but that's not especially relevant for the AIOC: as long as the software supports DTR, it's fine; and DTR-only is not a big ask. (Coordinated DTR and RTS is, IMHO.) If CHRIP on Linux leaves DTR high, though, it might not be any more useful on Linux than DTR low/RTS high is on Windows... Without your heuristics described below, anyway.

Okay, I checked again on Linux, as soon as I open a terminal such as picocom on the serial port, despite flowcontrol=none, RTS and DTR gets raised (same as Windows?). As soon as I leave the terminal, both lines go down again (Windows does this only for DTR as far as we know now). When I press ANY key during the terminal session, PTT goes off until RTS or DTR gets cycled on-off-on again.

So ideally, the bullet-proof behaviour would be RTS=0 and DTR=1 for the PTT. This would result in no erronous PTT assertion under any circumstances (haven't tested MacOS but I think it might be the same as Linux). As I understand you, that is no good, because there exist applications that don't allow such a logic pattern. In this case, I think the second-best course of action would be to use DTR-only and rely on the above mentioned TX-PTT-Force-Off feature to keep PTT off during CHIRP. Is that okay for you/all?

I'm not sure what "changes the RTS/DTR lines" means exactly: changes them to what, exactly? I assume drop them both to 0? And I have no idea what "sends a new message" means: things that control PTT don't send any "message": they (should) only manipulate the states. It's not vital that I understand it at this moment, but for completeness it might be good to document this a little more rigorously.

From the AIOC's view point, any change at all. There is a single packet being sent via USB containing the state of all control lines. So as soon as the application changes anything on the control lines, the RTS/DTR logic is checked against our requirement (RTS-only, DTR-only or RTS-DTR combinations) and directly controls the PTT lines. Sending a "message" (what I meant was, sending any character via the terminal) causes the PTT to be de-asserted instantly. As you say, applications controlling the PTT will not send anything, thus they will not trigger this functionality. However, CHIRP for example will trigger this feature. If CHIRP opens the port, it automatically sets RTS and DTR - i.e. for RTS-only and DTR-only schemes, the radio will PTT=on until it receives the first character, then it switches PTT off so it can transmit via UART.

In the interim: exactly what would you like me to test? What procedure would you like me to do (even in general), and what results do you want me to record and report?

As a wild guess, I'm going to start with: Perform a series of CHIRP downloads, and have it A) not lock PTT, and B), work correctly. Then without rebooting the device, use the device for audio/PTT control and ensure that they work there. Then probably go back to CHIRP. Then reboot the thing and reverse: Audio/CHRIP/Audio. I can report on each process and whether it was successful or not, and if not, what exactly I see.

Is this on the right track? Do you have different or more specific thoughts?

Yeah, exactly what I thought. Do some CHIRPing first, directly hop into a modem application (Direwolf, SoundModem, ...), hop back to CHIRP. Check everything works, PTT does not stay stranded to assert state at any point. You can also try Audio/CHIRP/Audio, if you like, then we are pretty sure that the thing is not transmitting while it shouldn't but still everything works.

The SignaLink USB does indeed use VOX exclusively for PTT. The radio may support CAT control and you might choose to use that, but it's unnecessary. For example, when using a radio with a 6-pin Mini-DIN (which includes audio and PTT in a single connector), you will be using the SignaLink's VOX control exclusively via a single cable. It's very nice. And no need for software support, either: just push the audio and it works.

I am a bit intrigued to be honest. Most importantly since this will allow using APRSdroid without them implementing any PTT feature (which I don't expect actually)... Maybe we should open a feature request issue for that.

And CM119A GPIO would be flat-out amazing. If you want to really geek out, check out AllStartLink -- a worldwide network of Asterisk PBX systems combined with repeaters (both big public repeaters and home-sized nodes). The most common way to connect radios to ASL requires modifying a CM108/CM119A-based sound card dongle to expose a couple of the GPIO pins to use for PTT and COS/COR control. If all of that could be integrated into the AIOC, you'd have a complete ASL RF interface... (There are details. like how to make COS work, because I don't think the 2.5/3.5mm interface gives you what you need for a COS interface, but when you have the power of a microcontroller directly at the analog/digital interface, there are ways... Like reverse-VOX... :) ).

Wow, that escalated quickly.. ;-) Is there any technical documentation you can point me to? The HID protocol should not be hard to implement. What I worry about a bit is, that (saw it in Direwolf sourcecode) it seems to be quite hard to find the correct HID device that belongs to a certain Audio device. Often the software just searches for CM108/119 USB VID/PID pairs, which obviously differ from the AIOC VID/PID pair so this search would fail (at least until the software gets adapted). What is COS/COR control if I might ask? And is there a specific hardware interface that we can adapt to (aka AIOC-ASL hardware)? GPIOs should be no problem at-all. Another feature request issue right there ;-)

Crazy cool. Awesome project.

Thanks! Didn't think this small thing could be that useful. After all it's no rocket-science. Just took parts that were already there and arranged them in a (seemingly) very useful way.. :-D

MiM-TMassey commented 1 year ago

AIOC Radio Interface I've found that the AIOC radio interface seems to be very sensitive. It's quite easy to get it to not work properly. The first CHIRP test I ran failed, but repeating it succeeded. Also, I found that sometimes my SoundModem calibration test did not sound correct: the low tone worked, the high tone was inaudible, and the both tone was audible but sounded very wrong. Jiggling the AIOC around on the radio could eventually resolve this. I'm mostly certain that it's not a digital/firmware problem, but related to how it's inserted into the radio. It seems that at least mine isn't real happy with the connection to the radio. I won't go nearly as far as saying it's a "horrid design" (Issue #3), but it may need some additional attention.

Now, on to firmware testing!

Firmware testing: DTR-only

Firmware: aioc-fw-dtr.bin

Firmware programming

Firmware downloaded successfully. All as expected.

APRS

PTT turns on, radio transmits and I receive the tone on a different radio!

PTT turns off and radio stops transmitting! All works as expected.

Now let's send and receive some APRS messages:

PTT turns on, radio transmits and I hear the message on a different radio! I also hear the ack and it is received into YAAC, and I get the SMS on my phone. I then reply to the message on my phone: I hear the APRS come in on a different radio, as well as receive the message within YAAC. I then hear the ack go out on a different radio. In the end PTT is off and the radio is not transmitting. All as expected.

PTT stays off. All as expected.

CHIRP

PTT turns on and radio data downloaded successfully. PTT then turns off. All as expected.

PTT stays off. All as expected.

Back to APRS For the fun of it, I repeated the SoundModem test through to the calibration tones, then close SoundModem. Once again, PTT reacts exactly as it's supposed to. All as expected.

Firmware testing: RTS-only

See the DTR-only for detailed process: this will only show the results. Also, due to a combination of laziness and connection sensitivity, at no point did I remove the AIOC from the radio.

Firmware: aioc-fw-rts.bin

Firmware programming Firmware downloaded successfully. All as expected.

APRS

Unfortunately, when I use Calibrate, I get no PTT. If I simply switch COM6 to COM4 (an FTDI-based USB serial adapter connected to a RigBlaster), PTT works just fine:. Changing the COM4 back to COM6 and I get nothing from the AIOC.

I also tried using DireWolf with the following config:

ADEVICE "AIOC" "AIOC"
ARATE 48000
PTT COM6 RTS

Once again, no PTT. Once again, changing COM6 to COM4 and changing the audio input/output and I was able to send and receive messages. Back to COM6: no PTT.

So, I used my PowerShell commands:

PS C:\Users\tmassey> $port = New-Object system.io.ports.serialport COM6
PS C:\Users\tmassey> $port.Open()
PS C:\Users\tmassey> # Print out the current states:
PS C:\Users\tmassey> $port.DtrEnable
False
PS C:\Users\tmassey> $port.RtsEnable
False
PS C:\Users\tmassey> # Try to turn on PTT:
PS C:\Users\tmassey> $port.RtsEnable = $true
PS C:\Users\tmassey> # PTT is on!
PS C:\Users\tmassey> $port.RtsEnable = $false
PS C:\Users\tmassey> # PTT is off!
PS C:\Users\tmassey>

So the AIOC seems to be responding to the RTS signal, but there's something about the way DireWolf and SoundModem is doing it that is not working. And yet, simply changing COM6 to COM4 works perfectly.

I even tried re-flashing the AIOC at this point: no difference. THIS IS NOT AS EXPECTED.

CHIRP PTT turns on and radio data downloaded successfully. PTT then stays on. When CHIRP closes, PTT stays on. THIS IS NOT AS EXPECTED.

Actually, this kind of is as expected: we knew CHIRP was going to leave RTS high when the port was closed, and that with this firmware that would cause the AIOC to engage the PTT. It seems whatever heuristic you tried to add to mitigate this did not work. I used PowerShell to open the port, lower RTS and close the port.

Back to APRS For the fun of it, I repeated the SoundModem test: same results. No PTT. I also repeated the DireWolf settings: same results. No PTT. THIS IS NOT AS EXPECTED.

My initial silly wild guess is that maybe your heuristic to completely ignore RTS for PTT control failed twice: it's stopping DireWolf and SoundModem from working, and doesn't stop CHIRP from failing.

If your HID plans allow for logging lines to be output to the user, the faster you add that the better it will be... :) I would love to be able to know what's going on internally. For testing, I think we could use the current LED's better (the green "power on" light could be better utilized...), but actual logging would be really nice at this point...

Firmware testing: DTR+/RTS-

Firmware: aioc-fw-dtrnrts.bin Firmware programming Firmware downloaded successfully. All as expected.

APRS

When I use Calibrate, PTT turns on, radio transmits and I receive the tone on a different radio! When I stop, PTT turns off and radio stops transmitting! All works as expected. I did not repeat testing via sending and receive messages. When I exit SoundModem, PTT stays off. All as expected.

CHIRP PTT turns on and radio data downloaded successfully. PTT then turns off. All as expected. When I close CHIRP, PTT stays off. All as expected.

Back to APRS For the fun of it, I repeated the SoundModem test through to the calibration tones, then close SoundModem. Once again, PTT reacts exactly as it's supposed to. All as expected.

So, this firmware works as expected. But seeing as DTR-only works as expected as well, I really don't think adding RTS to this process buys us anything. All of the (limited) software I've tested all allow you to choose DTR or RTS for PTT, so it seems to me that for now, simply having AIOC pay attention to only DTR will give you what you need consistently on Windows.

Other Items

While I was doing this, another reply came in, which I will address here:

So ideally, the bullet-proof behaviour would be RTS=0 and DTR=1 for the PTT. This would result in no erronous PTT assertion under any circumstances (haven't tested MacOS but I think it might be the same as Linux). As I understand you, that is no good, because there exist applications that don't allow such a logic pattern. In this case, I think the second-best course of action would be to use DTR-only and rely on the above mentioned TX-PTT-Force-Off feature to keep PTT off during CHIRP. Is that okay for you/all?

Yes, my thinking is that DTR=1/RTS=0 buys nothing over simply DTR=1. I have yet to see a piece of software that can't do DTR-based signalling. So for now, I see no reason to simply use that. (One thing for you to think about: Dual PTT. SoundModem, for example, understands Dual PTT: it can use RTS for one channel, and DTR for the other channel. I think the Baofeng interface only has a single PTT pin. If so, we can probably ignore this, but I thought I'd mention it just in case.)

(Status- and Packet-related information)

Ah, I see. I wasn't thinking about the USB side, I was only thinking about the RS-232 side. RS-232 and USB definitely make for an awkward pairing. (Reason #263 to use true GPIO rather than (ab)using RS-232 status pins...) Makes sense, though I'm not thrilled with using heuristics to try to detect "programming" vs "PTT control". But it seems to be OK across CHIRP, DireWolf and SoundModem -- and it's not my project, and I'm not doing the work! :)

(Testing procedure)

As you can see, I moved forward with Audio/CHIRP/Audio, which puts the one I want the most first... :) The transition was at no point an issue: things that worked kept working, things that didn't work stayed broken.

(Non-serial PTT stuff)

I'll move this to a new issue.

Thanks! Didn't think this small thing could be that useful. After all it's no rocket-science. Just took parts that were already there and arranged them in a (seemingly) very useful way.. :-D

As someone who is already doing all of this stuff with different radios and interfaces, and would love to off-load these tasks to much less expensive radios, I knew there was a lot of power here. That's why I was so excited to get this thing! :) Far more than just APRS: even just nodes for AllStarLink or D-Star or Fusion or P25 or DMR or M17 or ... There is a TON of functionality that can be done with a Pi and a cheap 5w radio, and AIOC can make that happen.

skuep commented 1 year ago

AIOC Radio Interface I've found that the AIOC radio interface seems to be very sensitive. It's quite easy to get it to not work properly. The first CHIRP test I ran failed, but repeating it succeeded. Also, I found that sometimes my SoundModem calibration test did not sound correct: the low tone worked, the high tone was inaudible, and the both tone was audible but sounded very wrong. Jiggling the AIOC around on the radio could eventually resolve this. I'm mostly certain that it's not a digital/firmware problem, but related to how it's inserted into the radio. It seems that at least mine isn't real happy with the connection to the radio. I won't go nearly as far as saying it's a "horrid design" (Issue #3), but it may need some additional attention.

Bummer! I remember having some reliability problems with the 2.5mm connector (radio "speaker" connector) with a few of the beta devices I sent out. You received one of those right? I am thinking about changing the design to using this and this connector. But I am having trouble to get these. The 2.5mm version seems to only be sourcable from this one company and I suspect they want to sell more like >1K of them.

Until we find a way to source them, we are a bit out of luck regarding these issues.

Firmware testing: DTR-only ... PTT stays off. All as expected.

That is good to hear

So the AIOC seems to be responding to the RTS signal, but there's something about the way DireWolf and SoundModem is doing it that is not working. And yet, simply changing COM6 to COM4 works perfectly.

That is odd... I am wondering why that is, especially since manually controlling those lines works. Maybe I should try if I can reproduce this. Did I make a mistake and label the files wrongly? Is it reacting on RTS=1 and DTR=0 instead of RTS-only? Hmm.

So if I understand you correctly, DTR-only with the included heuristic to prevent PTT during CHIRP should be working universally correct? No erroneous assertion of the PTT? I think we might settle on this configuration for now then, until a better alternative comes along.

Yes, my thinking is that DTR=1/RTS=0 buys nothing over simply DTR=1. I have yet to see a piece of software that can't do DTR-based signalling. So for now, I see no reason to simply use that. (One thing for you to think about: Dual PTT. SoundModem, for example, understands Dual PTT: it can use RTS for one channel, and DTR for the other channel. I think the Baofeng interface only has a single PTT pin. If so, we can probably ignore this, but I thought I'd mention it just in case.)

Yeah, the hardware even has some provisions for the second PTT (I think your UV-82R has dual PTT right?). For the record, since only one PTT can be asserted at a time, theoretically you could assign DTR=1/RTS=0 to one, DTR=0/RTS=1 to the other. I am however very unsure if even Direwolf understands putting those two patterns for two radios. I think each RTS or DTR can only be used once in the configuration.

As you can see, I moved forward with Audio/CHIRP/Audio, which puts the one I want the most first... :) The transition was at no point an issue: things that worked kept working, things that didn't work stayed broken.

No worries, thanks a bunch for testing it on Windows. I will do some more testing on Linux and if everything looks good, settle on DTR. I haven't checked the behaviour for MacOS but I think it will be fine. I think the most important operating system support for the AIOC is in the order: Windows, Linux, MacOS. Sorry Mac users! ;-)

MiM-TMassey commented 1 year ago

Bummer! I remember having some reliability problems with the 2.5mm connector (radio "speaker" connector) with a few of the beta devices I sent out. You received one of those right?

Not certain, but I believe you said mine was a beta board. The only version marking on mine is "AIOC V1.0 S. Kueppers".

I am thinking about changing the design [to nicer PCB-mounted 3.5mm/2.5mm connectors]

While I wanted you to be aware of the issue I was having, it is not a deal-breaker. I now simply turn the squelch off and listen to the audio on my computer to verify I have a proper connection. Having ideas for improvement would be good, but it doesn't stop it from being usable right now. Besides, when an entire headset is under $2 on Aliexpress, maybe using a cable might make more sense? (https://www.aliexpress.us/item/3256804280751657.html) Or even a pair of 2.5mm/3.5mm extension cables. But I'll just jiggle for now. :)

So if I understand you correctly, DTR-only with the included heuristic to prevent PTT during CHIRP should be working universally correct? No erroneous assertion of the PTT? I think we might settle on this configuration for now then, until a better alternative comes along.

That's the firmware I'm leaving on my board... :)

Yeah, the hardware even has some provisions for the second PTT (I think your UV-82R has dual PTT right?). For the record, since only one PTT can be asserted at a time, theoretically you could assign DTR=1/RTS=0 to one, DTR=0/RTS=1 to the other. I am however very unsure if even Direwolf understands putting those two patterns for two radios. I think each RTS or DTR can only be used once in the configuration.

I haven't personally felt the need for dual-PTT with digital applications, but the hardware is capable of doing it: now that I think about it, the headset that came with my radio has two PTT buttons, just like the radio itself does. So there is a way to make that work through the 3.5/2.5 interface. I don't personally know how, and the diagrams I've seen only show a single PTT line: is it a tie-to-high/tie-to-ground situation? Total guess. And I just tested SoundModem: with Dual PTT checked, it uses RTS for channel A and DTR for channel B. That's why the other checkbox says "Swap COM pins". With Dual PTT unchecked, it only uses whatever it uses for channel A. With Dual PTT checked, it uses both independently. (It also uses the left audio channel for channel A and the right for B.)

Like I said, not high on my own personal requirements. I just want to make sure you either keep it in mind or decide to definitely ignore it, so you don't accidentally make choices you might regret down the road. :)

MiM-TMassey commented 1 year ago

I’ve been busy, so I haven’t put much time into this. But the bigger factor is I don’t have any outstanding tasks to do, either. No pressure, but is there something I can do for you?

virtual812 commented 1 year ago

I really thought this was just a me problem to begin with, but it seems a lot has happened. Excuse my absence, injury / illness... not much fun :(

Also are there any further tests i can do? New firmware i can try out?

skuep commented 1 year ago

Thanks for asking, @MiM-TMassey and @virtual812! Much appreciated. I am very busy with work lately but during my short holiday next week I will catch up and produce new firmwares with fixes and additional features!

skuep commented 1 year ago

@MiM-TMassey, @virtual812 I released v1.1.0 that includes the DTR fix (among other things). Testing is very much appreciated :-) There should be no difference to the firmware version attached in this issue above somewhere with regards to the PTT assertion. Testing SoundModem with one of the new sample rates would also be cool!

MiM-TMassey commented 1 year ago

tl;dr: Updated firmware successfully. Sent APRS correctly (PTT and audio) but could not receive APRS. May be a reception/antenna issue on my end (not AIOC), but I'm out of time to test further.

Details: Updated firmware as per Issue #15 successfully. Connected SoundModem, selecting the correct Sound Input and Output devices, with TX and RX sample rate of 12000. COM port on correct port, as well as Dual PTT unchecked, Swap COM pins for PTT (RTS is the default, so swap uses DTR instead). Tested calibration successfully: received tones on a different radio.

Adjusted volume to 1/3 level. Used a different tool (SPECTRAN) to monitor audio levels: peaks at ~-30dB. At this point, I had not received any APRS tones, so I went ahead and tested sending a test message to SMSGATE. When the message was sent, I heard it on a different radio and received the SMS on my phone. So the signal left my radio just fine. But I did NOT get the ACK message back. I could hear a really quiet APRS tone which might have been the ACK, but it wasn't decoded by SoundModem.

I ended up spending some time just trying to listen for APRS tones through the AIOC and SPECTRAN and had very little success. However, I'm not sure if its AIOC or antenna/propogation issues on my side. The hard part is I only have one good-quality 2m antenna, so I don't have a way to tell whether no APRS is coming in, or if I'm missing good signals. Sadly, I just flat out ran out of time. I'm leaving on a trip tomorrow and have very little time between now and then, and it'll at least 10 days (possibly up to 14) before I can revisit this.

The good news is that when I get back I'll have a second high-quality 2m antenna to test with that will help me to test. In addition, the next goal is to set up a second computer with an old 2m mobile that I can use to generate my own APRS signals.

So, I apologize for the weak update, but I wanted to give you some feedback before I left.

One last thing I noticed: the waterfall changes quite noticeable when I switch between sample rates of 12000 and 11025. I get the idea of a slight shift (there isn't a solid intger relationship between 48k and 11025 like there is with 12k), but I was surprised how much the waterfall shifted. I switched between 11k and 12k a couple of times and the change was consistent. I'm including a screenshot below.

I was most surprised by the shift in the left low-frequency cutoff frequency. I worry that the frequency shift will not play well with decoding the signals, and it's hard to know if that is the case giving my possible receiving issues. I don't know if this shift is just due to the necessary blurriness between the rates, or if it's something else. Do with that information what you will! :)

image

I'll touch base as soon as I'm back and able to continue the testing. But I can at least report that it doesn't seem to brick the device, and that PTT and audio sending are just fine... Maybe it'll encourage others to give it a shot too! :)

skuep commented 1 year ago

Thanks for the quick testing. Take your time, have a nice holiday!

I tested it thoroughly and cannot find a difference between Release v1.0.0 and v1.1.0 in terms of APRS receiving. Both work the same. Maybe a problem with a wonky contact on one of the TRS connectors? Maybe wrong audio device? Did you pickup the static?

The change on the waterfall diagram is interesting. Yes, in theory there should be a shift of about 1-2 Hz, but this seems to be more than that. I generated an external 1kHz tone and confirmed using the PC, that it was recorded at 1kHz, just to check.

I just started Spectran Version 2 using wine on Linux Mint. I could not find how to change the sample rate to 12K (only 11025, 22050, 48000). But I notice that the X-axis scale changes to the new setting when changing the sample-rate, but the history of the old recording (old sample-rate) does not get re-mapped to the new axis. I think this is the reason for your confusion.

skuep commented 1 year ago

In the meantime I will close this issue. Feel free to reopen if there are still issues.

skuep commented 1 year ago

With the new DTR PTT, I noticed that my Baofeng would transmit a carrier (no audio though) during the entire programming sequence. I currently suspect, that the "PTT lockout feature" is the problem. It is required, because during programming, DTR (and thus PTT) is always asserted by CHIRP. So with this feature, upon the first data byte to be sent to the radar, PTT gets turned off.

However, it seems to me like, the time between turning off PTT and sending the first data byte via UART to the radio is not long enough for the radio to actually notice that PTT was disabled again, prior to the start of the programming sequence. Instead it recognizes the UART transmission and internally shuts off any PTT detection, leaving the PTT in the on-state.

I will have to think about how to solve this issue satisfyingly. It looks like we might need to put +DTR/-RTS back on the table as PTT assertion indicator, since I don't have these issues in this case.

G1LRO commented 1 year ago

To reproduce... Connect the AIOC to USB Wait for system to settle & USB Serial device show in Device manager Execute Chirp Do read radio process On completion of read radio appears to restart and be transmitting - red light on AIOC is lit. Unplugging USB and re-plugging USB seems to clear the PTT state and the AIOS can be used again.

Tested across 2 Windows 10 machines and 1 Win 11 machine. Test radio is Wouxun KG-UV9D Plus Will try another radio tomorrow and report back findings.

Interested to hear if anyone else is experiencing this.

I have this issue consistently when using the antenna on top of the HT. If I switch to a coax and external (or even an antenna just a few meters away) then it's fine. I'm thinking that RF in transmit is causing the AOIC to lock-up. Obviously a problem when it's built to plug into the side of an HT!

When the AOIC locks up the host looses the sound card and starts erroring. Tested on Linux and Windows with Baofeng and Quanshgeng HTs

Has anyone else seen this?

skuep commented 1 year ago

Yes, we had some people that had this problem. Especially with high transmit power. Can you try to put a ferrite sleeve around the USB Kabel to stop any antenna currents flowing back through the AIOC? Also it could be worthwhile to add a ferrite in between the AIOC ground and radio ground (basically in line of the tab of the small 2.5mm plug)

G1LRO commented 1 year ago

Yes, we had some people that had this problem. Especially with high transmit power. Can you try to put a ferrite sleeve around the USB Kabel to stop any antenna currents flowing back through the AIOC? Also it could be worthwhile to add a ferrite in between the AIOC ground and radio ground (basically in line of the tab of the small 2.5mm plug)

Hi Simon, I have added a ferrite sleeve to the USB cable near to the AOIC, also with the USB cabl;e wound 4 turns through the core but this did not resolve the issue.

Your second suggestion for adding ferrite to the 2.5mm jack, do you suggest lifting the large tab and connecting a ferrite with a few turns between the tab and the board? I am not sure I understood this fully.

Currently I am using an external antenna about 2M from the radio and it's all good but would be good to fix this for using on portable operation.

My radio is on the lowest power setting. and I am connected to a laptop running on battery (I have tried a desktop PC with the same results)

skuep commented 1 year ago

Hi Simon, I have added a ferrite sleeve to the USB cable near to the AOIC, also with the USB cabl;e wound 4 turns through the core but this did not resolve the issue.

Hmmm, too bad. Would've thought this could help.

Your second suggestion for adding ferrite to the 2.5mm jack, do you suggest lifting the large tab and connecting a ferrite with a few turns between the tab and the board? I am not sure I understood this fully.

Yeah pretty much what I am suggesting. Of course this would be undesirable for a permanent solution but it would be nice to know if this improves things. There are small SMD ferrites available (such as the one used on the V+ USB Line on the top side of the AIOC). I think it is 0603 size and had 600R st 100MHz.

Edit: instead of lifting the tab, you could cut the connection from the tab to ground with a scalpel. It's just a thick trace. Then you remove some soldermask next to it and bridge the opened connection with an SMD ferrite

skuep commented 9 months ago

For EMI issues, let's continue here https://github.com/skuep/AIOC/issues/54 I will close this for now, since the original issue with RTS/DTR is resolved.