Auto-PTT and Auto-COS Feature (Built-in High-Performance Low Latency VOX)

[skuep]

Referencing comment #11 (comment)_

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 idea is to implement AIOC-based "Auto-PTT", which is basically a fancy VOX feature for digital modes, with very low latency.

Ideas/comments/feature welcome!

EDIT: Branching off of issue #17

The "plan" from #17 (comment):

Got ya. I have thought about how I could go about it with my slim resources. What about the following plan:

1. Implement a simple Auto-PTT and Auto-COS using a threshold of the digital data and a time-out. Is the data above the threshold, enable PTT and reset the time-out. If the time-out expires (e.g. 1ms or 10ms), disable PTT
2. For now, release two firmware binaries, one with Auto-PTT enabled and also the "regular" firmware (PTT via serial/CM108 only).
3. Profit At some point in the future, set Auto-PTT as default, if it turns out, that it is more requested, than the current default (serial/CM108). And/or include a configuration feature, where you can configure the AIOC using a python script (and a currently unused HID endpoint). Enable/Disable various PTT sources and set threshold/timeout.

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

[skuep]

I started working on this feature in pull request #25.

I implemented a very basic thresholding mechanism both on the data that is being sent and received by the AIOC. This means that with this change, you can

• Configure e.g. direwolf without any PTT mechanism. Just the soundcard. If the AIOC detects data to be sent, it activates the PTT (red light goes on). After a (currently hardcoded) timeout of 10ms, it deactivates the PTT again (red light goes off).
• Sense when analog data (i.e. more than just pure silence) is coming from the radio. If the AIOC detects any noticable volume of audio data being received by the ADC, it uses the CM108 button functionality to assert the "Volume Down" button (compatible to how AllStarLink does it) and lights up the green led. After (currently) 10ms of total silence, it deactivates the "Volume Down" button and the green led goes back to dim brightness.

I have attached a firmware file that you can use for testing purposes. Note that this is purely for testing and not a release (will follow later).

Automatic PTT (to be renamed) works quite well. Tested with direwolf. However from my testing so far there are the following issues with the Automatic COS:

• It works only, when the ADC is running, i.e. the host has to open the audio device for recording. Otherwise the AIOC disables the ADC (currently). I think this is a big issue for AllStarLink, since it probably only starts recording once it sees the COS being asserted, right?
• What imbecile (Sorry!) thought it was a good idea, to map the COS input on the "Volume-Down" button of the CM108? It interferes with the system and turns down the PC volume - for real. Why not use another GPIO... Anyway, I have taken the liberty to modify the HID report descriptor for the AIOC to account for that. This means, that the AIOC (in contrast to the CM108) will not interfere with the volume controls of the PC anymore, because I have set the reported functionality to "Unassigned" instead of "Volume Down". The operating system then just ignores the COS-messages from the AIOC. (see 9913eaf). This of-course makes the AIOC "less compatible" to the CM108, but I currently suspect, that this is not generally an issue.
• The Automatic COS detection is a bit flaky with low or no amplitude audio. I.e. if I just push the PTT of a second radio, the green LED on the AIOC on the receiving radio flickers. However if I talk into the radio and produce some volume, the green LED stays lit. This would be something we have to test with AllStarLink to see if its an issue and how to solve it.

Feel free to play around with the new features and let me know what works for you and what doesn't. I have actually not tested this feature with real data transmission between to APRS nodes. I invite you to do so.

I thought about using the DCD pin of the virtual COM port as a COS input to the PC, but I had some issues with the USB stack. Do you think this feature is worthwhile, then I will try again and find out what exactly the problem is. If not, COS via CM108 is currently the only way to get COS to the PC.

aioc-fw-1.2.0-autopttcos.zip

EDIT: Also we still need a new name for this feature, since Auto-PTT is taken (and trademarked) by SignaLink. There was already a suggestion for "CATless PTT" by ITCMD (#17 (comment)). For symmetry reason I would love something that applies to PTT as well as COS. Such as APTT and ACOS (for Automatic PTT and Automatic COS), but that might be too close to the AutoPTT(tm) from SignaLink. Any suggestions?

[skuep]

Regarding the name, what about virtual PTT/COS? VPTT and VCOS?

[ITCMD]

Just cuz I like catless PTT, what about "Catless PTT" and "Autocat COS?"
OR maybe "CleanRX COS" and "CatlessTX PTT"
I will be in no way offended if you don't pick my suggestions, just thoughts!

I really appreciate your hard work on the VOX mode!

[ITCMD]

Any updates on this? How stable does the virtual ptt firmware seem to be?

Could I get a version that has the automatic ptt but none of the COS stuff? I don't think many of us have a use for COS.

[skuep]

Have not gotten any feedback so far. From my limited testing it works.. feel free to test 😁

[ITCMD]

@skuep does the linked file have COS stuff that hasn't been working also enabled?

Also, side note, I talked with John on wb2osz/direwolf#448 (he's in the same radio club as me) a few weeks ago and he's looking into the issue!

Edit: Looks like he's already had some back and fourth with you, which is good!

[skuep]

@ITCMD yeah, thanks for getting him into contact with me, much appreciated 😁 say thanks to him from me.

What do you mean with "COS stuff that hasn't been working"? The firmware file has both the automatic PTT and COS enabled, yep.

[ITCMD]

@ITCMD yeah, thanks for getting him into contact with me, much appreciated 😁 say thanks to him from me.

What do you mean with "COS stuff that hasn't been working"? The firmware file has both the automatic PTT and COS enabled, yep.

I think it comes from my misunderstanding of what the COS does or would be for. If it doesn't interfere with basic use of the VOX function out and receiving audio in, then it should be perfect for what we need. I'm assembling and installing the firmware on some today.

[skuep]

Ah, yeah. The COS stuff doesn't interfere with the functionality, you are right. It's just an indicator (a virtual CM108 input gpio reflecting whether there is audio coming from the radio. It's basically VOX in the other direction as an information there for the PC. If the PC doesn't read this information, it's just fine.

[ITCMD]

Gotchya makes sense. Flashed it and it works, although for all my HTs the rfi seems to be messing with it. It transmits for a sec then disconnects if I have more than 1w out.

Might be the usb hub vs the AIOC, however. Does make me wish the usb c port pointed down instead of up so the usb cable wasnt next to the antenna.

[ITCMD]

3 more questions for you:

1. Does CAT PTT still work when using the automatic ptt firmware? I wouldn't see this being useful much, except maybe when using actual voice, but it'd be a kind of nice feature I suppose. I assume it would still not work for radio programming.

2. know of any alternatives to dfu-util for Windows? I want to make a Windows batch script to switch firmware version automatically, but requiring users to use Zadig to get libusb seems... rough. Alternatively, perhaps anyone would know how to use wdi-simple to do what zadig does reliably via a script?

3. would you be interested in approving me as an authorized reseller? I make sure to make each one per the instructions, verify low-resistance connectivity on each connector, and run basic tests on each unit before selling.

[skuep]

Gotchya makes sense. Flashed it and it works, although for all my HTs the rfi seems to be messing with it. It transmits for a sec then disconnects if I have more than 1w out.

Might be the usb hub vs the AIOC, however. Does make me wish the usb c port pointed down instead of up so the usb cable wasnt next to the antenna.

Interesting.. was it different with the regular firmware? Other than that there have been some reports hinting that the USB cable works as a tiger tail, which introduces high RF currents into the USB Line. Still not sure what to do about it, other than inserting a ferrite into the aioc-to-radio ground line. Still needs to be tested tho

1. Does CAT PTT still work when using the automatic ptt firmware? I wouldn't see this being useful much, except maybe when using actual voice, but it'd be a kind of nice feature I suppose. I assume it would still not work for radio programming.

No, CAT PTT is disabled, exactly for the reason you stated.

2. know of any alternatives to dfu-util for Windows? I want to make a Windows batch script to switch firmware version automatically, but requiring users to use Zadig to get libusb seems... rough. Alternatively, perhaps anyone would know how to use wdi-simple to do what zadig does reliably via a script?

I am a Linux user myself, so I don't actually know. From what I have heard, zadig might not even be necessary to install the driver? But I am unsure

3. would you be interested in approving me as an authorized reseller? I make sure to make each one per the instructions, verify low-resistance connectivity on each connector, and run basic tests on each unit before selling.

Anyone is free to make and sell them. I have not thought about doing an actual authorized seller list. Do you think it's beneficial?

[ITCMD]

I found that using a right-angle cable solves the problem. Im selling cables with RFI clips on my website for the AIOCs. I also have extra connector options, notes, driver instructions, optional heat-shrink wrapping, and accessories on the site.

I'd say an authorized seller would be beneficial. That way the buyer knows:

• The seller is following the design they see here
• The seller is not stealing the code or not providing acknowledgments to the author (I know not required but people do care)
• Potential users don't have to go searching
• Shows your design is more viable

Also

• It would add viability to me selling it
• it would certainly help my sales if you linked to it from the github.

[ITCMD]

After further testing of this firmware I'd say the automatic ptt is ready for action. Customers agree.

As far as a CLI to change between the two modes of operation, while that'd be super helpful, I'd say it isn't a must since the command to switch firmware versions is just one line of simple code with dfu-util.

However, the hardcoded 10ms time-out could be restrictive in some environments, for example morse code operation. Having some way to configure that is definitely a must-have feature. However, if you're tight on time you could have it as hacky as you want.

For example, you could create an individual version of the firmware for 10ms, 20ms, 60ms, 100ms, 200ms, and 300ms. Yeah, it's hacky and kind of stupid, but it works, and I've learned that shipping something is what's most important.

I'm still working on a Windows TUI that switches between firmware versions, so that could act as a config console for you basically.

Alternatively, some hacky command to change it would also be fine because again a simple program can run that command for the user.

Finally, Having support for a physical switch of some kind to switch firmware, or a potentiometer to change timeout would also be powerful.

Just a few of my thoughts. Let me know what you think!

[skuep]

I found that using a right-angle cable solves the problem.

That's quite curious, I would not have guessed this to be a radiated EMI problem (99% of EMI problems are conducted EMI in practice e.g. what I have described above). Good information that an angled cable might help. This could be something for a "known issues" or similar section in the README.

I'd say an authorized seller would be beneficial.

I'll take that into consideration. Since I am not interested in turning this thing into a "commercial product first - open-source tinkerability second" (truSDX.. cough), I want to keep this kind of advertisement limited. But a list of trusted vendors in the README might be a good idea. I (as the maintainer) would rather like to see the project grow naturally than have a lot of "sales", but being able to buy this thing easily of course helps.

After further testing of this firmware I'd say the automatic ptt is ready for action. Customers agree.

That sounds good! Out of curiosity, what was the size of group of people testing the feature and with what software? So far I did not receive any feedback from someone else, so I am not so keen on pushing this feature out, yet. Maybe as a preview firmware.

You did say in the pull-request, that programming the radio didn't work. Is that so? Should not be an issue, just the COM PTT (and CM108 PTT) is disabled, and virtual PTT is enabled. (Basically via a pre-processor directive)

For example, you could create an individual version of the firmware for 10ms, 20ms, 60ms, 100ms, 200ms, and 300ms.

Nah, that's a lot of work and a big mess. If I, at some point, would like to add another distinction, the number of firmwares I need to generate go up exponentially. I have made some provisions to use vendor calls on the HID endpoint for sending or receiving some small data blocks to/from the AIOC. For linux based operating systems, connecting to this endpoint should be no problem at all. I don't know yet, how difficult this would be on Windows. I assume, the AIOC HID endpoint is listed in the Device Manager as a real HID device? Can you confirm? In that case, maybe it's quite easy to send HID messages to this endpoint from a python script. (I am thinking hidapi Python module).

I am not a ham myself, so I am unsure how important manual PTT (i.e. COM PTT or CM108 PTT) is for people, or whether virtual PTT is universally a good idea for everyone (or at least 99%). I am currently thinking of doing to following steps

1. Implement virtual PTT + HID configurability, but leave the default settings of the AIOC as they are now (to not break things). This means CM108+COM PTT is enabled, virtual PTT is disabled. Push this as the next official firmware.
2. Announce availability of virtual PTT (and virtual COS) and how to enable it. If we find out, that these features are popular, we could change the default settings in the future to virtual PTT-only with CM108+COM PTT disabled. But the original functionality can be reverted back using the Python script

Yeah, it's hacky and kind of stupid, but it works, and I've learned that shipping something is what's most important.

For a product, that's true. This is, so far, just a hobby project ;-)

I'm still working on a Windows TUI that switches between firmware versions, so that could act as a config console for you basically.

Sounds nice, let me know if I can have a look at it somewhere.

Just a few of my thoughts. Let me know what you think!

Thanks for all the input, I will think about it!

[skuep]

I created a new issue regarding the configuration interface. Your help is appreciated!
#30

[ITCMD]

Happy I've been able to help out!

I think in this case the Vox functionality will be what many people will want, but the manual ptt is still very useful. Some modes play much better with manual ptt. One extreme example is Morse code, where you want to just leave the ptt on while sending out morse instead of constantly triggering ptt. Neither is a winner over the other, they're both very useful for very different use cases. Quickly being able to switch modes would be powerful.

Have not tested programming, I will. Will also test the HID stuff in Device Manager. One great thing is that as a programming cable your chips work much better than the current commercial options. Theyre a mess with drivers and outdated support. AIOC just plugs in and works.

I do have one user where whenever he connects his AIOC with the vox firmware to any android device, the device lags like crazy and no matter what he does he cant get it to trigger ptt on audio. Works fine on windows / laptops. Working with him more now.

As far as test size, probably about 8 users, soon to be more like 15. Only one user with an issue so far, and nothing to report from that one, yet.

[JoshuaCarroll]

Might be the usb hub vs the AIOC, however. Does make me wish the usb c port pointed down instead of up so the usb cable wasn't next to the antenna.

I've thought that a few hundred times. It would be better for two reasons: keep the USB cable away from the antenna and wouldn't put stress on the USB cable going down to the PC.

BTW.. I've been silently following these two issues around the auto-PTT. I need to try the new firmware; I'm trying to use the AIOC with Allstar. We're going to deploy about 30 of them around the state to support Skywarn operations.

[skuep]

I've thought that a few hundred times. It would be better for two reasons: keep the USB cable away from the antenna and wouldn't put stress on the USB cable going down to the PC.

So far, only very few people have had problems with this and I am not sure why. In general the coaxial cable should not have any current running on the outside of the shield, thus the proximity to the USB cable should not be a problem. If it is s problem, your antenna is not working/behaving correctly anyway, so you should fix that issue first. Having said that, I know that in (amateur) radio you are very often satisfied with a non optimal antenna solution (such as a monopole on a galvanically isolated ungrounded HT. I am think if it's possible to flip the layout without much effort to realize a reverse-k1-aioc. Gotta test this.

BTW.. I've been silently following these two issues around the auto-PTT. I need to try the new firmware; I'm trying to use the AIOC with Allstar. We're going to deploy about 30 of them around the state to support Skywarn operations.

That is really cool! You can try the beta firmware hidden in the issue and report any problems you encounter. I am especially interested in your feedback of the virtual COS. As far as I can tell as an outsider, Allstar is where you need something like this.

In the future, these functionalities will be integrated in the main firmware and activated and configured (e.g. virtual-COS threshold) using a separate python application.

[ITCMD]

I've thought that a few hundred times. It would be better for two reasons: keep the USB cable away from the antenna and wouldn't put stress on the USB cable going down to the PC.

So far, only very few people have had problems with this and I am not sure why. In general the coaxial cable should not have any current running on the outside of the shield, thus the proximity to the USB cable should not be a problem. If it is s problem, your antenna is not working/behaving correctly anyway, so you should fix that issue first. Having said that, I know that in (amateur) radio you are very often satisfied with a non optimal antenna solution (such as a monopole on a galvanically isolated ungrounded HT. I am think if it's possible to flip the layout without much effort to realize a reverse-k1-aioc. Gotta test this.

You're assuming there is a coaxial cable. In my testing, this issue only occurs when using an antenna on the HT (like the included rubber ducky), not an external one attached over a coax cable. When using an external antenna up in a tree or something like that there was no issue.

The AIOC is super compact, making it very attractive for on-the-go HT-based operations.

[gordonthree]

I want to test the auto ptt / auto cos with a Alinco mobile radio and Allstar. Any suggestions for connections? The DB9 "data" connector on the radio offers a COR signal that is active-low and requires a pull-up. It has both 9600 baud and 1200 baud audio inputs and outputs and PTT input that is active-low.

Here's the connections I think I need: DB9 pin 4 audio output connect to AIOC Radio-Spk line. DB9 pin 7 radio PTT connect to AIOC PTT1 (or PTT2?), why is PTT2 listed twice on the schematic? DB9 pin 9 microphone input connect to AIOC Radio-Mic.

In Allstar I would use the usbradio module? Any hints on settings?

[ITCMD]

@gordonthree - that doesnt sound related to this issue on interfence. I'd start a new issue.

[Thunter96]

Is the firmware linked here: https://github.com/skuep/AIOC/files/11524529/aioc-fw-1.2.0-autopttcos.zip

The latest firmware with a software VOX enabled? Apologies if it's a dumb question, it's not appartent to me if a 'live' version is in the main git repository.

[skuep]

Yes, that is the current testing version still 🙂

[rxt1077]

Regarding Auto-COS, you may want to consider the SIGLEV approach that svxlink employs. Basically you leave the squelch open and listen to the noise. If it suddenly gets quieter you assume there is a signal. To quote from their man page:

Type NOISE use a bandpass filter in the range of 5 - 5.5kHz (CARD_SAMPLE_RATE >= 16000) or a highpass filter at 3.5kHz (CARD_SAMPLE_RATE = 8000) to estimate the amount of noise present on the signal. If the passband contain a small amount of energy, a strong signal is assumed. If the passband contain more energy, a weaker signal is assumed. The noise detector must be calibrated for the receiver and audio levels you use. This is done using the SIGLEV_SLOPE and SIGLEV_OFFSET configuration variables. See chapter CALIBRATING THE SIGNAL LEVEL DETECTOR below for more information.

This works surprisingly well compared to just trying to detect voice. You have the added benefit of triggering easily when there is no voice, just carrier, and not missing the first syllable because the squelch (Auto-COS in our case) was slow to open.

[skuep]

I just pre-released the new v1.3.0 firmware that contains a lot of new features, such as Auto-PTT and Auto-COS. It has to be enabled using some python scripting (for now, that is).
See https://github.com/skuep/AIOC/releases/tag/v1.3.0-rc.1

[DE8MSH]

Name it

CAPTTain -- CAtless PTTalkin

Kidding. ;)

But: This virtual auto PTT thingy is a must have. So we can use this APPs:

https://play.google.com/store/apps/developer?id=aicodix+GmbH&hl=en_US

With an OTG cable AIOC device should work as a external soundcard for Android smartphone. So CAPTTain -- uhm -- virtual auto vox PTT should work. Or am I wrong here?

Thank you very much for your work!

de DO7OO

[skuep]

CAPTTain -- CAtless PTTalkin

:-)

With an OTG cable AIOC device should work as a external soundcard for Android smartphone. So CAPTTain -- uhm -- virtual auto vox PTT should work. Or am I wrong here?

Yeah, pretty much correct. The AIOC should work as a soundcard for your Android phone. I tried it with APRSdroid and it worked, others tried and had mixed results (there are some issues open for this stuff, but it is really hard to debug the problem).

You can try the old testing firmware above or use the v1.3.0-rc.1. However this firmware requires some python magic to select the virtual PTT and store it back to the AIOC. If there is enough interest in trying this out, I can help with that.

[oe9fwv]

I would like to try the new 1.3.0rc1 firmware, but I do not know how to configure it for my purpose. I would like to try it with my Anytone and AprsDroid on the Samsung A32. Can you tell me how to configure the script to switch AutoPTT on?

[oe9fwv]

So far, only very few people have had problems with this and I am not sure why. In general the coaxial cable should not
have any current running on the outside of the shield,

in an ideal symmetric antenna this is correct, but in real world no antenna is exactly symmetric and there are always more or less sheath waves. (a common mode filter after the antenna should block them)

[skuep]

You can find a generic script in the v1.3.0-rc.1 Release page on Github.
Especially for activating AutoPTT can you try this:

import sys
import hid
from struct import Struct
from enum import IntEnum, IntFlag

class Register(IntEnum):
    MAGIC = 0x00
    USBID = 0x08
    AIOC_IOMUX0 = 0x24
    AIOC_IOMUX1 = 0x25
    CM108_IOMUX0 = 0x44
    CM108_IOMUX1 = 0x45
    CM108_IOMUX2 = 0x46
    CM108_IOMUX3 = 0x47
    SERIAL_CTRL = 0x60
    SERIAL_IOMUX0 = 0x64
    SERIAL_IOMUX1 = 0x65
    SERIAL_IOMUX2 = 0x66
    SERIAL_IOMUX3 = 0x67
    VPTT_LVLCTRL = 0x82
    VPTT_TIMCTRL = 0x84
    VCOS_LVLCTRL = 0x92
    VCOS_TIMCTRL = 0x94

    
class Command(IntFlag):
    DEFAULTS = 0x10
    RECALL = 0x40
    STORE = 0x80

class PTTSource(IntFlag):
    NONE = 0x00000000
    CM108GPIO1 = 0x00000001
    CM108GPIO2 = 0x00000002
    CM108GPIO3 = 0x00000004
    CM108GPIO4 = 0x00000008
    SERIALDTR = 0x00000100
    SERIALRTS = 0x00000200
    SERIALDTRNRTS = 0x00000400
    SERIALNDTRRTS = 0x00000800
    VPTT = 0x00001000


def read(device, address):
    data = device.get_feature_report(int(address), 5)
    address, value = Struct('<BL').unpack(data)
    return value

def write(device, address, value):
    data = Struct('<BL').pack(address, value)
    device.send_feature_report(data)

def dump(device):
    for r in Register:
        print(f'Reg. {r.value:02x}: {read(device, r.value):08x}')

aioc = hid.Device(vid=0x1209, pid=0x7388)

magic = Struct("<L").pack(read(aioc, Register.MAGIC))

if (magic != b'AIOC'):
    sys.exit(-1)

print(f'Manufacturer: {aioc.manufacturer}')
print(f'Product: {aioc.product}')
print(f'Serial No: {aioc.serial}')
print(f'Magic: {magic}')

if True:
    # Load the hardware defaults
    print(f'Loading Defaults...')
    write(aioc, 0, Command.DEFAULTS)

if True:
    # Dump all known registers
    dump(aioc)

ptt1_source = PTTSource(read(aioc, Register.AIOC_IOMUX0))
ptt2_source = PTTSource(read(aioc, Register.AIOC_IOMUX1))

print(f'Current PTT1 Source: {str(ptt1_source)}')
print(f'Current PTT2 Source: {str(ptt2_source)}')

if False:
    # Swap PTT1/PTT2
    ptt1_source, ptt2_source = ptt2_source, ptt1_source
    print(f'Setting PTT1 Source to {str(ptt1_source)}')
    write(aioc, Register.AIOC_IOMUX0, ptt1_source)
    print(f'Setting PTT2 Source to {str(ptt2_source)}')
    write(aioc, Register.AIOC_IOMUX1, ptt2_source)

    print(f'Now PTT1 Source: {str(PTTSource(read(aioc, Register.AIOC_IOMUX0)))}')
    print(f'Now PTT2 Source: {str(PTTSource(read(aioc, Register.AIOC_IOMUX1)))}')

if True:
    # Set to AutoPTT on PTT1
    write(aioc, Register.AIOC_IOMUX0, PTTSource.VPTT)


if False:
    # Set USB VID and PID (use with caution. Will need changes above to be able to re-configure the AIOC)
    write(aioc, Register.USBID, (0x1209 << 0) | (0x7388 << 16))
    print(f'Now USBID: {read(aioc, Register.USBID):08x}')

if True:
    # Store settings into flash
    print(f'Storing...')
    write(aioc, 0, Command.STORE)

You need to install the hid package (https://pypi.org/project/hid/) e.g. using pip. Let me know how it works out, it's best if you include the output of the script.

[OE9SAU]

Hello Simon,
I tried out your script above and got this output. Whats wrong or missing? Using v1.3.0-rc.1.

Traceback (most recent call last):
File "D:\Neuer Ordner\AIOC_FW1.3.py", line 59, in
magic = Struct("<L").pack(read(aioc, Register.MAGIC))
File "D:\Neuer Ordner\AIOC_FW1.3.py", line 45, in read
data = device.get_feature_report(int(address), 5)
File "C:\Users\Sauti\AppData\Local\Programs\Python\Python310\lib\site-packages\hid_init.py", line 232, in get_feature_report
size = self._hidcall(
File "C:\Users\Sauti\AppData\Local\Programs\Python\Python310\lib\site-packages\hid_init.py", line 190, in _hidcall
raise HIDException(err)
hid.HIDException: Get Input/Feature Report DeviceIoControl: (0x00000001) Unzulässige Funktion.

The "hid" package is working. With another script i got the infos from the AIOC.
Manufacturer: AIOC
Product: AIOC HID
Serial No: b59d132e

Thx for feedback. Martin

[skuep]

Thanks for testing.. this looks like you're the first one on Windows to try this. From a quick search the problem is, that Windows is really strict about the HID reports. I think the AIOC firmware currently does not list the "feature reports" (that are used for transferring configuration data) in its own HID report descriptor. Which windows notices as soon as you try to request a feature report and blocks you from doing so. Interesting, it appears that Linux doesn't care about this 😁 I will try to update the firmware in the near future and release an RC.2 version.

[OE9SAU]

Thank you for your feedback and the adapted new FW in the near future. happy easter

[skuep]

Can you have a quick test of this new firmware? I added an entry in the report descriptors, but I am not entirely sure if Windows is satisfied with this. If not, I need to spin up a Windows machine and dig deeper.

Happy easter holidays! ;-)

aioc-fw-1.3.0-rc.1-featurereport.bin.zip

[OE9SAU]

Will test asap today evening.

[OE9SAU]

Hi Simon, unfortunately the test was negative. Same output.

Traceback (most recent call last):
File "D:\Neuer Ordner\AIOC_FW1.3.py", line 59, in
magic = Struct("<L").pack(read(aioc, Register.MAGIC))
File "D:\Neuer Ordner\AIOC_FW1.3.py", line 45, in read
data = device.get_feature_report(int(address), 5)
File "C:\Users\Sauti\AppData\Local\Programs\Python\Python310\lib\site-packages\hid_init.py", line 232, in get_feature_report
size = self._hidcall(
File "C:\Users\Sauti\AppData\Local\Programs\Python\Python310\lib\site-packages\hid_init.py", line 190, in _hidcall
raise HIDException(err)
hid.HIDException: Get Input/Feature Report DeviceIoControl: (0x00000057) Falscher Parameter.

Regards Martin

[skuep]

It's not the same error 😁 it's now "wrong Parameter" but it looks like I have to be more specific with the descriptor.. I will set up a Windows station and need to play around a bit.

In the meantime you could use the virtual PTT test firmware I posted earlier in this issue.

[OE9SAU]

Tested that virtual PTT test firmware but without success. Maybe i toke the wrong one? martin

[OE9SAU]

Hello Simon, any further update for us?

[skuep]

Hello Simon, any further update for us?

Sorry for the late reply, I am currently swamped with work.

What does "without success" mean? No PTT action? Which one did you use?

This should be the correct one, if I am not mistaken:
https://github.com/skuep/AIOC/files/11524529/aioc-fw-1.2.0-autopttcos.zip

[OE9SAU]

Hi Simon, Work comes first, clearly. Thank you here for your commitment. "without success" mean? No PTT action? YES. I will try the linked one and report back to you. Many thanks martin

[OE9SAU]

Hi Simon, Work comes first, clearly. Thank you here for your commitment. "without success" mean? No PTT action? YES. I will try the linked one and report back to you. Many thanks martin

Update:
With the linked FW the AUTOPTT works fine with VARA FM and Aprsdroid. Many Thanks my friend. 73 de OE9SAU + OE9FWV

[skuep]

That's cool! Now I got to work on making the new firmware work on Windows so that you can also configure the thresholds for Auto PTT 😁

[W1BTR]

Back into the swing of things for this project again. Once you have an updated Windows and linux script let me know, happy to test on both.

Obviously when work, allows the extra time! :D

[oe9fwv]

hi Simon,
I have to add a comment to the AUTOPTT feature. I found out that in APRSdroid outgoing beacons are not decoded when I use AutoPTT with the default settings in AprsDroid. When I manually press the PTT on the handheld, beacons are decoded by the digipeater. I think it must be the Tx delay of the AutoPTT. There is a setting called frame-sync-prefix in the aprsdroid connection settings. Default is 200msec. I tried to set it higher, to 500 msec, and this seemed to help. The frame-sync-prefix can be distinguished by monitoring the signal, and I think if you can hear the prefix, if it is long enough. It might be also dependent from the transceiver you are using.

[stgapr]

I'm waiting for my AIOC module shipping from shenzhen. In this while, I wonder if anyone tried to use AIOC to made FT8 possible by using FT8CN and Quansheng-UV-K5 ?

[ITCMD]

hi Simon, I have to add a comment to the AUTOPTT feature. I found out that in APRSdroid outgoing beacons are not decoded when I use AutoPTT with the default settings in AprsDroid. When I manually press the PTT on the handheld, beacons are decoded by the digipeater. I think it must be the Tx delay of the AutoPTT. There is a setting called frame-sync-prefix in the aprsdroid connection settings. Default is 200msec. I tried to set it higher, to 500 msec, and this seemed to help. The frame-sync-prefix can be distinguished by monitoring the signal, and I think if you can hear the prefix, it is long enough. It might be also dependent from the transceiver you are using.

This is an issue with all automatic ptt methods (Aioc, signalink, custom circuit, etc), as the device cant predict when it will receive audio.

Luckily Aprsdroid has a built in feature for this called Frame sync prefix:

[oe9fwv]

@ITCMD that's exaxtly what I wrote in my comment: :-)
"there is a setting called frame-sync-prefix in the aprsdroid connection settings."

[ITCMD]

Would it be possible to still allow serial control over PTT while running in automatic firmware, or alternatively allowing it to at least control PTT2?

I notice the light comes on but it does not key up from serial.

[skuep]

@ITCMD sorry for the late reply.. you can theoretically select multiple sources for the PTT signal, such as Auto PTT and serial. All enables sources will be logically or'ed.

You need to set up the aioc configuration using the script.