Comments (48)
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 ๐
from aioc.
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.
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?
from aioc.
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.
from aioc.
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.
from aioc.
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.
from aioc.
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.
from aioc.
Will test asap today evening.
from aioc.
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
from aioc.
Regarding the name, what about virtual PTT/COS? VPTT and VCOS?
from aioc.
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!
from aioc.
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.
from aioc.
Have not gotten any feedback so far. From my limited testing it works.. feel free to test ๐
from aioc.
@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!
from aioc.
@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.
from aioc.
@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.
from aioc.
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.
from aioc.
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.
from aioc.
3 more questions for you:
-
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.
-
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?
-
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.
from aioc.
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
- 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?
from aioc.
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.
from aioc.
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!
from aioc.
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
- 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.
- 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!
from aioc.
I created a new issue regarding the configuration interface. Your help is appreciated!
#30
from aioc.
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.
from aioc.
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.
from aioc.
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.
from aioc.
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?
from aioc.
@gordonthree - that doesnt sound related to this issue on interfence. I'd start a new issue.
from aioc.
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.
from aioc.
Yes, that is the current testing version still ๐
from aioc.
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
from aioc.
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
from aioc.
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.
from aioc.
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?
from aioc.
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)
from aioc.
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
from aioc.
Thank you for your feedback and the adapted new FW in the near future. happy easter
from aioc.
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
from aioc.
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
from aioc.
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.
from aioc.
Tested that virtual PTT test firmware but without success. Maybe i toke the wrong one? martin
from aioc.
Hello Simon, any further update for us?
from aioc.
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
from aioc.
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
from aioc.
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
from aioc.
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.
from aioc.
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 ?
from aioc.
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:
from aioc.
Related Issues (20)
- Integrate a TNC Modem with KISS interface HOT 3
- PTT Remains engaged and Audio/Serial Devices crash on Linux and Mac HOT 5
- create a group buy list HOT 3
- Unable to flash Firmware with AIOC HOT 17
- Parts unavailable at jlcpcb HOT 4
- Feature Request: Yeasu Style Mic and speaker HOT 2
- AIOC board plus Bluetooth = HAM radio connected to Vehicle Mic & Speakers? HOT 4
- cannot write a bin file in non-BOOT mode HOT 5
- AIOC and AllStarLink with simple_usb Module HOT 83
- Retevis RT73 HOT 3
- AprsDroid PTT request HOT 2
- Suggestions on what to use to short pins for flashing? HOT 8
- Alternative USB-C connector HOT 8
- Problems getting HID libraries functioning in Python 3 on Raspberry Pi OS HOT 2
- Increase overhang timer for Virtual-COS feature HOT 5
- Fatal error while building on cubeIDE HOT 2
- Error while debugging on a nucleo f302 HOT 3
- Inventory shortage for the MIC5330-SSYML HOT 1
- Why Amphenol 12401832E40-2A? HOT 1
- I bricked an AIOC, is there anyway to recover it? HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aioc.