carrierfrom=dsp ; Carrier Detect Source
; Options - no,usb,usbinvert,dsp,vox
; no - no carrier detection at all
; usb - via USB radio adapter COR connection
; usbinvert - same as above but inverted polarity.
; dsp - from RX noise using dsp methods
; vox - voice activated via RX audio
Question I cannot seem to solve Does the VOX function work. I have been trying it out
but the VOX action does not seem to function Its likely I have not configured this correct
im sure someone will be kind enough to enlighten me?
Strange that no one replied to this before. The vox function works for me, however it has a significant hang/release time after I unkey. I’m using an HT for a node radio (which has no COS line) and the carrierfrom=vox setting works well in that detects Rx audio right away and even if I’m not actually talking it continues to properly register that I’m keyed up (as it should since there will be at least some small ~1mV of background noise on the Rx audio line in that case indicating that I am in fact keyed up). Once I unkey the Rx audio will go back to 0V and I would expect usbradio to then see that I’ve unkeyed, however it seems to take it 2 full seconds to do so and finally end the transmission. I found the following in asterisk/channels/xpmr/xpmr.c: #define XPMR_VOX_HANGTIME 2000.
So it looks like this is a hardcoded define that can only be changed if you compile the code, which will be my next project. See my other posts for updates on that.
It seems to me, at one time there were parameters for setting delay and decay etc of VOX.
I have been looking for a cheat sheet I made a long time ago but without result.
Perhaps someone will chime in here and we can get that in the wiki
Yes and No…
I was thinking of searching source later as I was going to walk away from computer. LOL
This issue keeps coming up. Needs a answer. I know I used it in a old HF remote set-up that I don’t seem to have the files for. Unlike myself or I’m just confused.
The segment you linked is for Xelatec channel section of the code.
I would think it similar.
Will look at this deeper later.
xpmr.c, which is included in chan_usbradio.c, appears to use rxSqVoxAdj as a squelch level threshold as opposed to a hold time. in createPmrChannel() it sets pSps->setpt = (pChan->rxSqVoxAdj); and setpt is then used in many places in the file when comparing amplitudes, eg.:
The only thing relating to the vox hold time however as far as I can see is the hardcoded #define XPMR_VOX_HANGTIME. I was able to get code compiling yesterday on my RPi and changed that define to 500 (mS) in channels/xpmr/xpmr.c and verified that everything now works very well with no long delays after I unkey, and I see no false drops in carrier detect even when not talking. Since the code is easy to compile (after following the instructions at GitHub - AllStarLink/ASL-Asterisk: Version of Asterisk used for AllStarLink) this was an easy fix for me, but hopefully for the benefit of other users of usbradio vox this will be made into a configuration parameter in a future ASL release.
If other vox parameters could be configurable that might also be nice, though in my case the level thresholds seem to work perfectly as they are - always detecting when I key up right away and properly holding until I have unkeyed, even if I wasn’t talking and thus there was only some quiet background room noise. I did try reducing the hangtime to 100mS and in that case did see some unintended drops in detecting my rx carrier but 500mS seems to be very reliable. As usual though ymmv so if this could all be configurable it would definitely give more flexibility. 73, NR9V
As I remember it, these settings were contained in usbradio_tune_XXXXX.conf
But I do not know that for sure. My memory is not always clear on things like this.
I will continue to look for my old configs.
But it also seems to me that the tune program had vox setting options back in the ACID version.
I could be wrong about that as well.
I may have a drive with all the old stuff on it if I can locate it. So it continues.
fyi I put in a pull request a couple weeks ago to make the vox hang time configurable. If you compile with that you can then add a voxhangtime parm to usbradio.conf and set it to a lower value than the default 2000 mS. I see that an earlier pull request was just merged today so it looks like these are getting merged in and should be available in the beta images soon.
And as mentioned the rxSqVoxAdj is already configurable, and between these 2 cfgs you have control over the main vox parameters. In my case the default setting of rxSqVoxAdj works perfectly so I haven’t needed to change it.
To answer the original question, yes the usbradio vox mode works great. But if anyone can dig up more detailed documentation on any of this that would be great. xpmr.c is the DSP code for the usbradio, voter and pi channel drivers, but it does not have many comments and I’ve seen no other documentation on the file.
@NR9V It would be great if couple of folks could clone the develop branch, merge your PR locally and test as we have very limited ability to test this ourselves. With a couple of github comments from folks that actually test we could merge your PR.
Hi Tim, I’m not sure I know anyone who’s on github and who would be able to test my PR soon. But I’ll ask around and mention it in some posts I have on a few sites (about how to build a very nice full-duplex node for < $200 using 2 Retevis RT85 HTs, using the carrierfrom=vox mode).
Anyone I do know that would be testing however would probably be testing in the same configuration I already tested though, so not sure how helpful that would be in terms of test coverage. I have tested the case of using usbradio with carrierfrom=vox mode on both a PC and RPi node. My only concern would be that the newly added voxhangtime cfg parm could somehow cause a compile warning or some other issue in other usbradio configurations. I do think the change to add the cfg parm is highly unlikely to affect any other usb driver configurations, though as programmers we all know that software can be unpredictable. But if you or other devs happened to be doing other testing with usbradio in carrierfrom=dsp mode and the changes caused no issues I’d be pretty confident the change was indeed very unlikely to affect any other configurations and should be good to go for a beta release.
I might suggest you post it in development and see who tries it and reports.
Ya never know. I’m sure the dev’s can pick it up from there. However silent they may be at times, they read the board from time to time.
Hi Mike, can you clarify where you mean by post in ‘development’? On github I opened Issue #33 on 11/6 and submitted pull request #34 on 11/24, but do not see a separate development forum on github or on the ASL forums here.