These would effect the TX’r output. I am not sure if the source would change anything.
Seeing how there are many duplex modes and other variations, It’s a good question I guess. But I believe at a minimum, you would need to be using internal DSP.
Well, I can only say that IRLP software is a different animal. I did not see that in original post.
And sorry, I am not a voter user… yet. Had plans for years.
I was trying to keep your post bumped up so it may get noticed better by voter users.
Unfortunately, I don’t have any specific information surrounding why COP 58/59 may, or may not work with chan_voter, without doing some deep research.
I can speculate though…
I think you need to consider how that COP command would work.
I am pretty sure it ONLY works for repeaters where you are using the chan_usbradio driver, since that driver supports generating the CTCSS tone for transmit.
If you were using chan_simpleusb… that doesn’t support generating CTCSS… so how/what would cop 58 be controlling? Unless there were some mechanism to control a GPIO line (which there may be, but I haven’t looked into either), which in turn would control an input to the repeater’s transmitter, to allow for CTCSS enable/disable. I don’t see any mention of that sort of functionality… that also would need require the transmitter to be able to change CTCSS encode “on the fly” while it is already keyed… not very likely.
Sort of the same idea with chan_voter. One would need to dive into the channel driver code, but I would suspect there are no hooks in there to support COP 58. Remember, while your voter.conf does let you specify the CTCSS tone and level, all that is doing is telling the firmware in the VOTER/RTCM what to generate. The firmware in the VOTER/RTCM is doing the actual tone generation (as opposed to chan_usbradio, which is doing it in Asterisk before sending the audio to the radio). Also remember too that the VOTER/RTCM has the offline option to set the CTCSS tone and level, for when it loses connection to the host (not that COP 58 would have any effect if you’re not connected to the host to begin with though).
So, I suspect that is why you don’t see COP 58 working in your application. I also don’t know of any easy way around that problem either.
I just had a thought that may help…
If you do not use pass-though tone, then you must ‘filter’ it in DSP. (stop pass through)
Then you should be able to use cop 58 if the tone is generated by DSP on the TX side.
I think that is what cop 58 controls, but you likely have not filtered it from the rx.
But again, with a voted system, I’m not sure.
Look in the file for the options and I think you will understand what I am conveying.
I think I know what you mean, but not entirely sure. The VOTER/RTCM adds a layer of complexity, especially when wiring to a repeater for de-emphasis and pre-emphasis.
The VOTER/RTCM filters tone in hardware. If you set the noplfilter flag in voter.conf on each client then that should turn off the filtering.
Then also in voter.conf you set txctcss/txctcsslevel/txtoctype to what you require.
I’ve tested with a txctcss & level set and cop 58 on, and it does nothing, or not what I expect.
I also tried simply passing the tone from the users radios through by setting noplfilter on all the clients, still no dice. It only worked once I set nodeemp, noplfilter and commented out the txctcss lines.
It “worked” but tone was easily talked off and it adds a whole new set of issues with the way it’s wired to my receiver and transmitter.
Here is my voter.conf for those interested:
port = 667
buflen = 160
password = BLAH
Mt.Wellington = xxxxx,master,transmit
Grey.Mt = xxxx
Domain = xxxx ; ;
; streams = 18.104.22.168:1667
;plfilter = y ; DSP high pass filter
txctcss = 141.3
txctcsslevel = 30 ; Transmit CTCSS level. Set to zero for off
txtoctype = notone ; chicken burst
;thresholds = 180,80=5