Decode CTCSS problem

App_rpt-users
1

I am using a Pi4 with RA-DR1XM interface with a Yaesu DR-2X and am having a couple problems. First, when using analog, things work great, but when trying to use digital, Allstar takes over the repeater and re-transmits the sound of digital modulation in FM. I assume that the repeater is sending CTCSS true when receiving digital…weird but whatever. I thought I could fix this by switching ASL to “ctcssfrom = dsp” instead of “ctcssfrom = usbinvert.” However, when I do this, after restarting Asterisk, ASL seems to no longer function at all. It will not retransmit received signals. In-fact, it will not even key up and send a bootup ID anymore. Setting “ctcssfrom = usbinvert” again and restarting Asterisk brings back FM function through ASL.

Any ideas on this one?

Settings for USBRadio channel driver are below:

carrierfrom = usbinvert
ctcssfrom = usbinvert
invertptt = no
rxboost = no
rxctcssfreqs = 136.5
txctcssfreqs = 136.5
txctcssdefault = 136.5
txtoctype = no
txmixa = voice
txmixb = tone
rxlpf = 2
duplex = 1
txprelim = yes
rxctcssoverride = no

2

Does ASL get analog CTCSS audio from the repeater? The audio line you are using would need to be discriminator/flat/unfiltered. If not, then the CTCSS would be filtered out of the audio signal before it ever leaves the repeater.

3

USBinvert is a logic line. don’t care what it is, but when true, you toggle the logic.(external)
dsp ctcss is decoded in software. See the wiki

Sound like an incomplete and.or incorrect set-up.

4

Yes, in-fact I had originally had it connected to pin 9 (AF OUT) on the repeater and was pretty sure that was the obvious problem, so I switched it to pin 8 (Discriminator out.) Still not functioning. When using the logic signal (CTCSS line) from the repeater, the audio being repeated through ASL sounds great. If it would work at all using “dsp,” I could further tweak levels to make sure it’s not an input level issue. The funny thing is though, when restarting Asterisk, ASL will TX ID the machine, if it is functioning normally (like when using “usbinvert.”) When I set the receive logic to “dsp,” ASL won’t even operate the PTT anymore, not even to perform the bootup ID. Isn’t that supposed to be not even related?

I’m thinking something is missing or not configured correctly somewhere else in ASL that is causing the whole application to fail, but I’m not sure where to start. I haven’t found anything helpful in the wiki yet.

5

I could be wrong, but I’m pretty sure this is actually a logic artifact in the channel driver code. I think that when using physical I/O for COS, depending on your polarity settings, app_rpt “sees” that COS is going from true >> false when it initializes the channel driver - essentially seeing a “kerchunk” when it first starts up, triggering the ID.

When using DSP, the logic is different since everything is internal and no I/O has to be initialized. My repeater system is all chan_voter clients, and I do not get a startup ID either because chan_voter does not initialize physical I/O. I did used to get the familiar startup ID back when I was using USB interfaces, though.

I’m pretty sure this is the correct explanation, but again, I could be wrong.

So, don’t fret over the ID. Watch the console/logs for errors, but the lack of “startup ID” probably means nothing.

1 Like
6

When you use the discriminator input, did you change the config to state you are using the discriminator as input ?

Can’t just switch input type without switching config.
When no ctcss is detected, from incorrect setting by type, no output.

7

Mason, thanks for the explanation! That makes perfect sense.

Mike, where do I change this? The interface only has one audio input. What I’m doing is either connecting interface pin 6 (receiver audio input) to repeater pin 9 (AF OUT) or interface pin 6 to repeater pin 8 (discriminator.)
The repeater’s outputs are 300mv AF, and 500mv discriminator. Connecting one or the other to the audio interface input should only require a small adjustment of input level setting in the channel driver. Am I wrong? What else would need to be changed?

Further information:
I attempted these settings:
ctcssfrom = dsp
rxctcssoverride = yes
(and all manners of “carrierfrom”)
Still, I have not been able to obtain any function in ASL unless I have inputs set to original settings at the top of this thread.

I may keep trying to adjust input level but I’m kind of shooting in the dark due to my service monitor currently being down.

8

I’m not able to help with that in asl3.
I’m still using v1.01 on systems with a URI.
I don’t see it listed in changes and fail to see it in the manual. Perhaps I missed it?

Perhaps someone will chime in with the answer.

This was the old method

rxdemod = flat   ;  input type from radio: no,speaker,flat
				; no - RX audio input not used
				; flat - Use RX audio from discriminator (before de-emphasis)
				; speaker - use de-emphasized audio

May not be relevant anymore ?

9

Mike, indeed these options are still present. The default is “flat,” and I have allowed the config to use the default value.

I may be making some progress.
I have set:
“ctcssfrom = dsp”
“carrierfrom = no”

I then re-ran the audio input level adjustments on auto-detect. Rxnoise, rxvoice, and rxtone have all been set to some degree. Minor adjustments were made by the interface tune CLI.

When checking the diagnostic display in Interface Tune CLI (I forget what it calls this display,) I see displays for Carrier, CTCSS, COR, and PTT logic status input and output.
The first position (Carrier) reads “off,” iirc.
The second position (CTCSS) reads “Keyed,” when I key my HT on the repeater input.
However:
Third position (COR) reads “Clear,”
and fourth position (PTT) also reads “Clear.”

Why would it be that CTCSS is reading “Keyed,” but PTT retains the state of “Clear?”