Feature: Non-serial PTT / COS control #17
Comments
|
Thanks a bunch for the extensive writeup. That's a lot for me to digest for the next days :-) |
|
I started with implementing basic CM108-style PTT control. I request heavy testing :-)
|
|
Thanks again for all the information. I have taken some time and sorting through the information. COS taken from inside of radio
COS via "reverse-VOX"
Opinions? |
|
I will reply in detail when I can, probably in a few days; but I want to add a really quick note for the moment. Right now, the most common way to get a COS enabled sound interface is to break out a soldering iron. The entire system is a raw Asterisk system with no real GUI. The idea of a simple command line utility that you use to make some basic configuration changes once is not even in the top 10 list of hurdles to this entire process. :-). (It needs to run on Linux, and of course ideally also run on Windows; but seeing as you are a Linux guy anyway, the Linux side certainly won’t be a problem.) Also, perfect is the enemy of good enough: as a first pass, a command line utility would be just fine. GUIs can be wrapped around such tools later. :-) It will definitely be next week before I will have a chance, but I am very, very excited to test out the GPIO support. Conceptually, I’m not sure why auto PTT and DTR based PTT are mutually exclusive. I haven’t looked at the source code or anything, but as a basic state machine, it seems pretty straightforward: is DTR enabled? Raise PTT. Is audio detectable? Raise PTT. Otherwise, drop PTT. Whether auto PTT is enabled by default or not to me should be determined by how well it works, but once it works well, I don’t see a reason why they both can’t be enabled at the same time. If you don’t touch the serial port, nothing will happen. But needing to configure it at set up one time isn’t exactly a problem. |
|
Are there any status updates for VOX / Auto PTT? I'm making and selling these at my local club and this is the most requested feature as this would be excellent for APRSDroid. The rest of the features are good nice-to-haves but that's really the only "This is why Im not buying / making this" I'm running into. |
|
I have not really worked on this. I am assessing how much interest there is for it 😁 This would be the first feature where we need some way of configuring/enabling it. For this I need to implement an interface and python script to do so. |
|
I'd really appreciate it, and I can confirm there would be a lot of interest. This is what would bring it from a more compact USB sound card and cat cable setup to a Signalink alternative. It would be plug-and-play super easy to use and would be very valuable to many hams. Everyone I've talked about this to, literally everyone, asked if it had vox ptt trigger. Honestly, if it could be implemented as the default first, that would be a bigger priority to me than being able to configure it. |
|
Got ya. I have thought about how I could go about it with my slim resources. What about the following plan:
Whats your opinion on that? I know we have had this discussion before on whether we should make Auto-PTT enabled by default. But I have not yet found a decisive argument for that (except that SignaLink does it too... IIRC). EDIT: I just noticed, SignaLink calls it Auto-PTT™ as well. I think its better to change the name for the feature. Any suggestions? |
|
That would be super helpful, yes! |
|
How about "CATless-PTT" to indicate the scenarios you'd use it? (When cat controlled PTT isn't necessary or available) |
|
Good news everyone, I started working on some basic Automatic PTT and COS functionality (to be renamed of course ;-)). I will close this for now, unless I have forgotten something, feel free to reopen. |
A write-up inspired by off-topic discussion from Issue #11. I wanted to describe in detail several options for PTT besides RS-232 control lines used by other devices, as well as introduce the possibility of using AIOC more advanced applications like ASL/HamVoIP nodes and other similar full-duplex radio uses.
Currently, AIOC supports PTT control by presenting a virtual RS-232 port via USB and using status "pins" to trigger PTT (v1.0.0: DTR Low/RTS High; in the future likely just DTR High). This is a classic PTT control mechanism in the Amateur Radio world, dating back to when computers actually had physical RS-232 ports -- and very few other ports! Serial ports were the only convenient way to trigger a relay, which was the most straightforward way to control PTT! Well, none of that is true today: are there other ways to control PTT that might be both easier and more effective?
Alternatives for PTT control
Because we're not trying to trigger relays with actual RS-232 ports, we have a lot more flexibility in triggering PTT. Here are some alternatives:
Computers are not the first time where people wanted to get away from having to activate a mechanical switch or relay just to transmit. VOX is a very common solution to this: when the sound level is loud enough, start transmitting. This, though, has issues: if the background is too noisy it can activate incorrectly; if the signal is not loud enough it may not activate properly at all; and because the sound we might want to transmit is not continuous (like pauses between letters or words), the VOX needs to keep transmitting after the silence begins because it can't be sure that the transmission is yet complete. These issues make radio-based VOX unreliable, especially for digital signals that may need to transition from send to receive very quickly.
However, with AIOC, we have some advantages. First of all, there is no microphone, so there's no background noise. If noise is received from the computer, something intentionally generated it, so we can switch to VOX immediately. Second of all, there is no "loud" or "quiet". If the computer is playing sound, sound data is flowing into the AIOC -- even if a human might perceive that sound as "quiet' or even "silence". Therefore, there does not need to be additional VOX 'hang time'.
The beauty of this is that neither the sound-generating software on the computer nor the AIOC really have any need for any out-of-band PTT-signalling mechanism. The sound itself is a reliable signal. On higher-end computer radio interfaces, VOX has become a common technique and has proven to be very effective. The most common example of this is the SignaLink USB: https://www.tigertronics.com/slusbmain.htm This is used in numerous digital applications, including AX.25 packet, which requires fast send/receive turnaround.
This really isn't the same as traditional microphone-based VOX. Don't think of it as VOX: think of it as Auto-PTT. :) And as you have previously mentioned, Auto-PTT would allow AIOC to support applications where serial ports are difficult to use or are just not supported -- like APRSdroid. Sound data would simply magically flow into APRSdroid, and when sound data flows out of APRSdroid, it would automatically engage the PTT.
Even if there is a desire for an out-of-band PTT-signalling mechanism, there are alternatives to RS-232 signalling. A GPIO interface can be used instead. This is already used by software that targets the Raspberry PI; in addition, some more advanced software (such as AllStarLink) has the ability to use GPIO pins provided on CMedia CM108/119A sound chips. In fact, modifying USB sound dongles to expose these pins and interface them to radios is one of the most common radio interfaces for AllStarLink. (Ref: https://wiki.allstarlink.org/wiki/Radio_Connections#Modified_CM108.2FCM119_USB_FOB )
GPIO and RS-232 signalling are very similar. However, for RS-232, those signals are only a small part of the RS-232 standard. There's lots of other factors involved, and some of them are not under the control of the application. At the very least, the operating system is also involved, and it may not understand -- or care -- how those status pins are being used. With GPIO, there is a lot less going on. These pins are designed to simply turn on or turn off (or sense if they're turned on or off), and that's exactly all we want to do with them. Therefore, there's a lot less possibility for things to go wrong.
This technique is used in certain voice and digital applications; however, these are more common in repeater controller or digital node applications, where more advanced control is needed. However, these applications need more than just PTT. This is covered in the next section.
Full flow control: COR/COS
PTT is a common and well understood need: the radio is not smart enough to know when to send or not. After all, there's sound data at the microphone all the time, so theoretically there's always data that could be sent. The radio has to be told when there is actually data that needs to be sent. And that's what Push To Talk (PTT) does: it signals the radio when it needs to actually start sending data.
But imagine a more complex configuration such as a repeater or a node. These can be thought of as two radios connected together, the microphone of one radio connected to the speaker of the other, and vice-versa. Those radios may be directly connected or might be connected across the Internet, but the concept is the same either way. In this case, there isn't just a single source of data, there are now two radios, both capable of sending and receiving data.
Just like with a single radio, each radio needs to be told when when there is data that needs to be transmitted. That signal is PTT. Each radio also needs a way to tell the other radio when it has legitimate data that it is trying to pass it along. That signal is called COS: Carrier Operated Switch. (The original name was COR: Carrier Operated Relay. It's the same thing.) The COS is an outbound signal on one radio that is connected to the inbound PTT of the other radio, and vice-versa. When one radio receives a radio carrier (i.e. receives legitimate data), that radio activates the COS signal, which is passed to the other radio's PTT, which causes it to then transmits that data. (For more details and history, see "So What's The COR or COS?? " here: https://www.repeater-builder.com/tech-info/repeater-term.html)
As you can see, because both radios can move data in two directions, both radios need both PTT and COS, to deliver signals in both directions. And yes, this is exactly the same type of flow control you see in numerous other applications, such as RS-232 RTS/CTS or DTR/DSR!
COS is really only essential when you trying to connect two radios together, such as in a repeater or node. This is exactly what you are doing with something like an AllStarLink node: bridging a remote repeater to a local radio. This literally allows you to connect to a far-away repeater and use it as if it were right in your home. And you can do this even with a simple Baofeng and a Raspberry Pi -- if you have COS...
Unfortunately, most radios do not have a COS signal. Because they simply receive and pass along data any time they are not actually being asked to transmit, there is no need for a specific two-way flow-control signal like COS. If you think about it, though, radios do kind of have a COS signal: that is the exact purpose of squelch! When squelch is blocking the data, this is the same as the COS signal being inactive: the radio is telling you "there's no legitimate data here." When the squelch opens up and the radio passes the data along, this is the same as the COS signal being active: the radio is telling you "I have legitimate data: please do something with it." In fact, this is how a COS signal is usually gotten from a radio that doesn't actually have one: go inside the radio and tap into the squelch signal!
In order for AIOC to provide a COS signal to a computer, there needs to be two elements: A way to get a COS signal from the radio, and a way to pass it along to the computer. Passing it along to the computer is relatively straightforward. Most software that expects COS uses some sort of GPIO to do this. Whatever GPIO is used to handle PTT could likely handle COS as well. (Theoretically, DSR or CTS could be used as well.) Actually getting the COS signal from the radio is more difficult.
Getting the COS from the radio, though, is more difficult. The most effective way is to open up the radio and tap into something that could substitute for the COS signal. Simply using the RX LED signal could be sufficient. But seeing as this requires opening up the radio, it's probably not a good match for the AIOC.
Another choice would be to use the AIOC microcontroller to detect the presence of audio from the radio -- VOX. Because this is VOX on an analog source, it will have some of the same limitations as a radio's VOX system for PTT. However, because the radio's squelch can listen for CTCSS/DCS tones and will be completely stopping extraneous noise from being sent to the AIOC -- and because we are dealing with electrical connections and not an actual microphone -- the VOX detection should be much more straightforward and reliable.
In short, once COS as well as PTT is available, the AIOC would allow the simplest possible connection between a computer trying to function as a node and a radio: just the computer (such as a Raspberry Pi), the AIOC and the radio. In order to do this, we need to generate a COS signal (probably from the analog audio data coming into the microcontroller) and a way to pass it to the computer that is compatible with the software (probably GPIO, such as the CM108/119A most commonly used today).
For further reading:
The text was updated successfully, but these errors were encountered: