ASL bug at startup?


I’m actually building a new repeater with a Raspberry Pi and a home made URI that we use on all of our nodes.

I noticed that when the Rpi is started and for one or another reason the COR level is active (in my case when the received is switched off and the COR line is not driven low as in normal operation), the PTT is activated and stays activated for ever, even if the receiver is powered and COR line goes in its normal state.
There are no ID and timeout generated by Asterisk.

I need to make an asterisk restart or a Rpi reboot.

Do I miss something or is it a bug ? Can something be done ?

Vy 73,



Assuming this is a simplex node make sure duplex=1 is set in rpt.conf. Also note the polarity of COR can be set in simpleusb.conf.


Sorry, I should have mentioned that it is a full duplex repeater project.
And are using the usbradio.conf.

Polarity are correcty set. Everything runs smooth under normal conditions.
We have :
carrierfrom = usbinvert
ctcssfrom = no

73 Patrick

I think there can be instances where, depending on actual physical and software logic, the cor and or ptt can be inverted until fully booted as both the usb driver and the software are loading.

I kinda doubt that is the issue.

Probably take some time to trace that out, But you could hook-up a speaker to the audio output of the sound fob and test boot it for a better indication what is and is not happening…
And perhaps meter the cor and ptt lines during the same.

But perhaps you can post your rpt.conf & simpleusb/usbradio files and we can take a looksy for something that may not be obvious to you ?

And state rx cor voltage when active ? & inactive ?
ptt when active ? and inactive ?

It may just be you have what I call ‘double inverted logic’.

For if the cor gate is inverted incorrectly, you will never hear anything from the node as the audio gates will be closed.

You might try disconnecting it on a boot for a test and manually engaging it for one more boot test.

Hi Mike,

Thanks for your attention.
I don’t think anything is wrong on my side. Everything works as expected under normal conditions.
It only goes mad when the controller boots up and the RX is not connected to URI or not powered.

The state of the COR should not affect the way the controller boots, should the state be high or low, in opposition of the settings, etc…

Let me explain what happens :
With the RX switched OFF or not connected, when the Rpi boots up, the COR LED lights up (normal), the PTT goes HIGH and the heartbeat LED blinks normally.
Nothing is transmitted at the sound output.

After a while, the Heardbeat LED blinks differently and PTT stays HIGH even if COR goes down (RX switched ON).
Everything then stays locked for ever.

Curiously, if I switch the RX ON during the time the HB LED blinks normally, the CT and ID are transmitted and everything works as expected.

I still have access to the Rpi and Asterisk and can reboot it.
So, I really think it’s a software issue.

Just in case, here the URI input schematic.
I NEED to tie the input high as the receiver output is an open collector.

I have set :
duplex = 2
carrierfrom = usbinvert
ctcssfrom = no
rxdemod = speaker
invertptt = 0


OK, I can live with it, as this situation should not happen, but maybe someone can dig into the code.
73 Patrick

What model raspi and ver of software are you using ?

Rpi 3 model 8 v 1.2
with image found on site, asl 2.0.0 beta
When I type core version : Asterisk a4245fb

73, Patrick

Only 2 things I can suggest…

Verify usb device ID with what is in your set-up file.
lsusb > devstr=4-2:1.0

If you can try one other URI if you have it. I have had a few that just get weird results.

One other note…
If you have other usb devices, make sure your uri is on it’s own usb header, and don’t share that header with other devices.

Out of ideas.

I deleted previous post, as I misunderstood something. :face_with_hand_over_mouth:

I’m not sure to understand why you dump the lsusb result into such a filename.

The lsusb command gives me :
Bus 001 Device 004: ID 0d8c:013a C-Media Electronics, Inc.

I didn’t take care of the setting of the devstr and I had in usbradio_tune_usb.conf :
devstr = 1-1.5:1.0

I changed it to :
devstr = 1-4

But it didn’t change anything.

I’m waiting for some components to finish 2 other URIs, but I don’t think it has something to do with it.
It’s more software related.

As said, I can live with it until someone can dig into the code.

73 and thanks for the help,

I just noticed that the changes made in the usbradio_tune_usb.conf are overwritten after a radio tune save command !
So, changing it manually , doesn’t help.

Is this normal ?

Yes, when you do a radio tune save from the asterisk CLI, the values are written to the usbradio_tune_usb.conf file. You should refrain from making changes directly to that file and make them through the asterisk cli.

Jim, K6JWN

So, are you saying that the device string does not match that what you see from doing a ‘ls usb’ ?
That was my question. Verify.
If you need to change it or change it often, there is some other issue going on. Likely the sound fob.
Try a different usb header. Set device string appropriately.

Hi Mike,

Yes, that is what I meant.

I checked on 3 other nodes and none of them has the device string that matches the one shown with lsusb.
But all do show the same number with lsusb, and all nodes are working perfectly.

So, I’m not worried about this.

73 Patrick