ASL3 Simplex node Transmit stuck in transmit when Asterisk is restarted or rebooted

I’ll provide more details as I go, first step might be to try a different PC.
I have setup an up to date ASL simplex node on Debian12.
Have everything working but my transmitter stick on the air on any reboot or Asterisk restart.
USB FOB is holding the transmit line low. NO audio is gated, (callsign traffic etc).
The ONLY way I have been able to clear this is by running the “F” command under the 8. Interface Tune CLI in the node config menu.
This keys the transmitter 3 times and after this everything works perfectly until rebooted or Asterisk is restarted.
Looking for clues/guidance on what to do next in order to troubleshoot this.
Any help with this is greatly appreciated.
FOB shows normal flash and everything “looks” good while in this stuck state.
FOB is clearly holding the line low and keeping the transmitter keyed forever untile intervened with as mentioned above.
Even replugging the USB FOB does not help and it come back to this state. flashing LED but PTT line is held low by the FOB.
I have a voltmeter on the PTT line and it’s at .03V (low).
If I run that Fslash TX command it clears and goes to 3.3V and then everything works normally.
It never gets stuck like this again until Asterisk is restarted or the machine is rebooted (starting Asterisk) This seems to be some kind of driver hang.
But replugging the USB device does not help… (of course the transmit is released while the USB is unplugged) but as soon as you plug it back in the driver reloads and is stuck again in this state.

Some details, more as we go:
ASL3 “clean install” Callsign configured Simplex node (1) configured and basic logic and audio levels configured.
Hardware: AMD 64bit dual core laptop (bit older Turion64 X2 CPU)
CPU at 4% max during normal node operation.
CPU at 3% max (total) during TX stuck condition (I do not see any difference or much use of the CPU).
8GB of RAM.
Using simpleusb.conf

Active radio interface is [nodenum]
Device String is 2-1:1.0
Card is 0
Rx Level currently set to 625
Tx A Level currently set to 500
Tx B Level currently set to 0

Active Simple USB Radio device is [27298].

  1. Select active USB device
  2. Set Rx Voice Level (using display)
  3. Set Transmit A Level (currently ‘600’)
  4. Set Transmit B Level (currently ‘0’)
    B) Toggle RX Boost (currently ‘disabled’)
    C) Toggle Pre-emphasis (currently ‘disabled’)
    D) Toggle De-emphasis (currently ‘disabled’)
    E) Toggle Echo Mode (currently ‘disabled’)
    F) Flash (Toggle PTT and Tone output several times)
    G) Toggle PL Filter (currently ‘enabled’)
    H) Toggle PTT mode (currently ‘open’)
    I) Change Carrier From (currently ‘usb’)
    J) Change CTCSS From (currently ‘no’)
    K) Change RX On Delay (currently ‘0’)
    L) Change TX Off Delay (currently ‘5’) (yep I’m using this for the radio and familiar with how to use it)
    P) Print Current Parameter Values
    R) View Rx Audio Statistics
    S) Swap Current USB device with another USB device
    T) Toggle Transmit Test Tone/Keying (currently ‘disabled’)
    V) View COS, CTCSS and PTT Status
    W) Write (Save) Current Parameter Values
  5. Exit Menu
    Thanks!!!

Why not test this with VOM with and without the ptt line removed and see if it is a threshold voltage issue. If it does not do it with it removed you need a buffer in between the logic line and the ptt.

But know if the ptt line is set to active low and a reboot is preformed the logic is low until everything is initialized and the line is pushed high again. You can add a buffer transistor to invert the logic and change your software logic accordingly to avert this situation if it is a problem…
I think I said all that correctly.

1 Like

Those steps are next.
I need to determine if the FOB is doing this on its own with just a pullup resistor.
This will also tell me if the pullup is built into the fob or if it is using the external pullup (radio).
I was also trying to make this work without a buffer transistor if possible.
Anyhow pretty much what you mentioned is the next thing to try.
Along with simply a different PC.

I’m at the next steps –
A buffer transistor is not going to do anything in this case.
I have the FOB disconnected from the radio, and when rebooted or if asterisk is restarted
It comes up stuck with the PTT line from the fob itself asserted low (0V).
The FOB does have internal pullup to 3.3V.
If I run that flash command from the menu this problem stops and the line goes high as it should.
I have a problem right at the software and FOB.
How might I troubleshoot this further and fix it?

Furthermore and just to clarify again:
app_rpt/Asterisk has no idea the FOB has transmit/low asserted.
This is a real problem.
And I’ll repeat again, the only way I have to temporarily “fix” thsi is to run the flash command from the menu that keys the TX 3-times and the problem goes away.
Running normal commands from the asterisk command prompt that would normally cause the transmitter to key do not clear this problem.
But the flash TX 3 times thing in the ASL-Menu does, how is this different?

Any ideas?

Receiver/Transmitter Status Display:
COS | CTCSS | COS | PTT
Input | Input | Out | Out
Clear | Off | Clear | Clear

With Interface Tune list option I set as usb you are expecting an input that is low when idle and high when receiving. If the fob is a CM1XX chip the problem could be something I have experienced too. With two different transmitters I found the COS/carrier output of the radio needed a pull-down resistor to be brought low enough for the chip GPIO pin to detect low condition. The chip itself does not sink much current–if at all-so no pull-down action. With a CM119A chip I found 15-33 Kohm from the GPIO pin to ground would ensure a solid low signal detection. With your carrier=usb selection, your PTT would remain keyed unless the chip can sense low (idle) signal state at the COS/carrier input. Hope this helps.

I am seeing this problem while carrier detect at the FOB is 0V (no carrier present).
The carrier detect and PTT are not in any way floating or need to be pulled up or down.
And again the only way to clear this is to run the flash-3-times command from the menu.
Forcing or pulling lines low or high have no affect and they are already wired and working properly.
There’s something bad going on here in software or the driver for the CM108.
What is this flash command actually doing, how does it work?
It’s doing something that fixes the issue temporily. Nothing else I have tried fixes it.
And the system can’t be used this way not being able to reboot or restart asterisk.
I need to figure out what’s going on and thanks very much for any help here!

I have a solid 0V when no signal is present then goes to 3.3V as expected on RX.
I’m also watching the PTT and COS lines with voltmeters connected to PTT and COS at the FOB.
While restarting asterisk, they do not change or do anything strange.
They remain where they should be 3.3V on PTT line and 0V on COS line.
After restarting asterisk the FOB is pulling PTT low (0V) and of course sticking the transmitter on.
While COS remains at 0V as it should be.
And software(app_rot/asterisk shows the transmitter is NOT keyed.
Software/status shows all as it is and should be.
But CM108 FOB is pulling PTT line low.
And running the flash feature from the menu makes the problem go away.
Receiver/Transmitter Status Display:
COS | CTCSS | COS | PTT
Input | Input | Out | Out
Clear | Off | Clear | Clear

Have you connected an Oscilloscope to the COS line?

A test meter is slow to react and will not show all problems.

The input to the fob may have been damaged by spikes from the connected radio or differences in supply voltages. I always fit a diode in the COS line.

Does a new fob not connected to your radio give the correct results?

Hi, this is not being affected by the COS line.
I am also testing this on the bench with a standalone FOB no radio.
It is exhibiting the same exact problem.
I think I may have identified a bug with ASL3 that should be reported as detailed above.
This problem is very easy to duplicate.
It happens if you configure PTT to be active low instead of active high (the default setting).
And what most people are using with a transistor.
So this as possibly gone unnoticed. or may have crept in unnoticed.

PTT active low / to ground is the default setting. All of my nodes use it and it’s the most common configuration. If app_rpt has marked PTT as clear, than it iself is not what’s pulling PTT to ground. What, specifically, do you have invertptt set to? And what do you have set for carreierfrom and ctcssfrom?

My understanding is that default configuration (regardless of what it is called) is setup to pull the pin on the FOB high when it is transmitting.
This also I’m guessing is assumed the inverting transistor is being used.
The transistor takes the high from the FOB conducts and pulls the output (collector) (usually hooked to a transmitter, low)
So the radio itself is getting an active low from the transistor in that configuration.
I am using/needing the opposite.
And it is supposed to work.
I am also testing with a FOB by itself to simplify this troubleshooting where we do not have a radio
or RF /COS concerns to worry about while we work on this actual issue I am describing.
The FOBs when configured to pull the line low on transmit are stuck in putting a low on that pin
when Asterisk is restarted, and the only way to clear this is to run the
F) Flash (Toggle PTT and Tone output several times)
From the Interface Tune CLI menu.
Nothing else I have tried clears it.
It then works perfectly and as expected until asterisk is restarted.
We are most certainly looking at a bug here.
I’m in the process of filing an issue for it.
I will link to that when filed.
Also anything I can do to help please let me know!
Don’t mind getting my hands wet and I’d like to get this working/fixed.
And to your question:

invertptt = yes
carrierfrom = usb
ctcssfrom = no

Bug filed: SimpleUSB When configured PTT active low CM108 FOBs PTT line asserted low 'permanently' on asterisk startup - restart · Issue #424 · AllStarLink/app_rpt · GitHub
I’m pretty confident this is actually a bug or issue that’s just never been fixed or maybe has cropped up recently unnoticed.
Does anyone know how the “F) Flash (Toggle PTT and Tone output several times)”
thing is “different” than anything else that calls for the transmitter to turn on?
Because this clears/unsticks the problem while nothing that I have tried else does.
And is likely going to be useful information/pointer concerning the issue.

This was very much so a bug, and was fixed in beta about 1-month ago.
It will be in a new release soon if that has not already happened.

The fix was included in the AllStarLink v3 Software Updates Release - 2024-12-31 update.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.