GPIO squelch opens but doesn't close

[maldea]

I'm using svxlink 17.12.1-2 on Bionic on a NanoPi Duo board with a DRA818 module. I'm trying to use GPIO to control both SQL and PTT. While PTT works fine and I can listen the radio traffic on my HT, when I try to key in the PTT on my HT, the SQL on svxlink opens and remains open after ending the TX and also after the SQL timeout expires. No matter what I do, once the SQL is open it can only be closed by restarting the svxlink service. The issue persists also on 19.09.1 compiled from sources on both NanoPi Duo and OrangePi Zero on both Bionic, or Buster, kernel 4.x and kernel 5.x and across multiple GPIO pins with either pull-up or pull-down resistors. I even removed the DRA818 and tried with dupont cables. I wasn't able to find any particular setup to reliably operate the Rx squelch.

########### [GLOBAL] MODULE_PATH=/usr/share/svxlink/modules.d LOGICS=SimplexLogic,ReflectorLogic CFG_DIR=/etc/svxlink/svxlink.d TIMESTAMP_FORMAT="%Y-%m-%d %H:%M:%S" CARD_SAMPLE_RATE=48000 CARD_CHANNELS=1 LINKS=ReflectorUpLink

[ReflectorUpLink] CONNECT_LOGICS=SimplexLogic:99:R,ReflectorLogic DEFAULT_ACTIVE=1 TIMEOUT=10

[ReflectorLogic] TYPE=Reflector HOST=[redacted] PORT=5300 AUTH_KEY=[redacted] CALLSIGN=[redacted] JITTER_BUFFER_DELAY=50 AUDIO_CODEC=OPUS EVENT_HANDLER=/usr/share/svxlink/events.tcl

[SimplexLogic] TYPE=Simplex RX=RxLocal TX=TxLocal EVENT_HANDLER=/usr/share/svxlink/events.tcl CALLSIGN=[redacted] RGR_SOUND_DELAY=100 RGR_SOUND_ALWAYS=1 FX_GAIN_NORMAL=0 FX_GAIN_LOW=-12 MUTE_TX_ON_RX=1 MUTE_RX_ON_TX=1

[RxLocal] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 SQL_DET=GPIO GPIO_SQL_PIN=gpio16 SQL_TIMEOUT=3 RxComp=1 RxCompThreshold=-30 RxCompRatio=0.5 RxCompAttack=50 RxCompDecay=5000 SQL_DELAY=0 SQL_HANGTIME=500 SQL_TAIL_ELIM=50 DTMF_DEC_TYPE=INTERNAL DTMF_HANGTIME=100 DTMF_MUTING=1 1750_MUTING=1

[TxLocal] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 PTT_TYPE=GPIO PTT_PIN=gpio15 TX_DELAY=0 PTT_HANGTIME=50 TIMEOUT=300 PREEMPHASIS=1 TxLimit=1 TxComp=1 TxCompThreshold=-90 TxCompRatio=0 TxCompAttack=10 TxCompDecay=5000` ###########

That is the svxlink.conf. There must be something that eludes me, maybe something to do with the svxlink inner logics. I'm struggling with this for two weeks now and got nowhere. Is there the slightest chance that this is a svxlink bug or most likely it is me, not fully understanding how svxlink is supposed to work? I went through this page: http://www.svxlink.org/doc/man/man5/svxlink.conf.5.html dozens of times, and while most individual settings make sense, it's hard for a new user to put the puzzle pieces together and build a correct svxlink.conf from scratch, or troubleshoot an existing one.

[f5vmr]

You have a strange string of commands, that I have never seen  - RxComp and TxComp, and I have never used them in the 19.1 version on my repeaters. Remove all of these and your functions should work. AlsoRemove the command SQL_TIMEOUT by # in front - you should not need it.Increase the SQL_TAIL_ELIM=270  to stop any kerchunking.There are a couple of other things you may try but they are tailored to individual systems. Good luck with Bionic Beaver, I work entirely in Raspberry Pi OS. Chris Jackson05.55.64.84.2006.68.70.87.20 "The art of diplomacy in everything is completely understanding the others point of view, anticipating the response, and prospecting common ground.""L'art de la diplomatie dans tout est de comprendre complètement le point de vue des autres, d'anticiper la réponse et de rechercher une entente cordiale."envoyé : 5 juin 2020 à 08:14de : maldea notifications@github.comà : sm0svx/svxlink svxlink@noreply.github.comcc : Subscribed subscribed@noreply.github.comobjet : [sm0svx/svxlink] GPIO squelch opens but doesn't close (#500) I'm using svxlink 17.12.1-2 on Bionic on a NanoPi Duo board with a DRA818 module. I'm trying to use GPIO to control both SQL and PTT. While PTT works fine and I can listen the radio traffic on my HT, when I try to key in the PTT on my HT, the SQL on svxlink opens and remains open after ending the TX and also after the SQL timeout expires. No matter what I do, once the SQL is open it can only be closed by restarting the svxlink service. The issue persists also on 19.09.1 compiled from sources on both NanoPi Duo and OrangePi Zero on both Bionic, or Buster, kernel 4.x and kernel 5.x and across multiple GPIO pins with either pull-up or pull-down resistors. I even removed the DRA818 and tried with dupont cables. I wasn't able to find any particular setup to reliably operate the Rx squelch.[GLOBAL] MODULE_PATH=/usr/share/svxlink/modules.d LOGICS=SimplexLogic,ReflectorLogic CFG_DIR=/etc/svxlink/svxlink.d TIMESTAMP_FORMAT="%Y-%m-%d %H:%M:%S" CARD_SAMPLE_RATE=48000 CARD_CHANNELS=1 LINKS=ReflectorUpLink[ReflectorUpLink] CONNECT_LOGICS=SimplexLogic:99:R,ReflectorLogic DEFAULT_ACTIVE=1 TIMEOUT=10[ReflectorLogic] TYPE=Reflector HOST=[redacted] PORT=5300 AUTH_KEY=[redacted] CALLSIGN=[redacted] JITTER_BUFFER_DELAY=50 AUDIO_CODEC=OPUS EVENT_HANDLER=/usr/share/svxlink/events.tcl[SimplexLogic] TYPE=Simplex RX=RxLocal TX=TxLocal EVENT_HANDLER=/usr/share/svxlink/events.tcl CALLSIGN=[redacted] RGR_SOUND_DELAY=100 RGR_SOUND_ALWAYS=1 FX_GAIN_NORMAL=0 FX_GAIN_LOW=-12 MUTE_TX_ON_RX=1 MUTE_RX_ON_TX=1[RxLocal] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 SQL_DET=GPIO GPIO_SQL_PIN=gpio16 SQL_TIMEOUT=3 RxComp=1 RxCompThreshold=-30 RxCompRatio=0.5 RxCompAttack=50 RxCompDecay=5000 SQL_DELAY=0 SQL_HANGTIME=500 SQL_TAIL_ELIM=50 DTMF_DEC_TYPE=INTERNAL DTMF_HANGTIME=100 DTMF_MUTING=1 1750_MUTING=1[TxLocal] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 PTT_TYPE=GPIO PTT_PIN=gpio15 TX_DELAY=0 PTT_HANGTIME=50 TIMEOUT=300 PREEMPHASIS=1 TxLimit=1 TxComp=1 TxCompThreshold=-90 TxCompRatio=0 TxCompAttack=10 TxCompDecay=5000That is the svxlink.conf. There must be something that eludes me, maybe something to do with the svxlink inner logics. I'm struggling with this for two weeks now and got nowhere. Is there the slightest chance that this is a svxlink bug or most likely it is me, not fully understanding how svxlink is supposed to work? I went through this page: http://www.svxlink.org/doc/man/man5/svxlink.conf.5.html dozens of times, and while most individual settings make sense, it's hard for a new user to put the puzzle pieces together and build a correct svxlink.conf from scratch, or troubleshoot an existing one.—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[f5nlg]

hello try to use ctcss on dra818 , and don't put it on tx , only rx and half power so 0,5w it works perfectly on spotnik who is based on svxlink 19.09.1 orangepi0 card .

see http://f5nlg.wordpress.com

73" de Jean-Philippe f5nlg.

Le ven. 5 juin 2020 à 08:14, maldea notifications@github.com a écrit :

I'm using svxlink 17.12.1-2 on Bionic on a NanoPi Duo board with a DRA818 module. I'm trying to use GPIO to control both SQL and PTT. While PTT works fine and I can listen the radio traffic on my HT, when I try to key in the PTT on my HT, the SQL on svxlink opens and remains open after ending the TX and also after the SQL timeout expires. No matter what I do, once the SQL is open it can only be closed by restarting the svxlink service. The issue persists also on 19.09.1 compiled from sources on both NanoPi Duo and OrangePi Zero on both Bionic, or Buster, kernel 4.x and kernel 5.x and across multiple GPIO pins with either pull-up or pull-down resistors. I even removed the DRA818 and tried with dupont cables. I wasn't able to find any particular setup to reliably operate the Rx squelch.

`[GLOBAL] MODULE_PATH=/usr/share/svxlink/modules.d LOGICS=SimplexLogic,ReflectorLogic CFG_DIR=/etc/svxlink/svxlink.d TIMESTAMP_FORMAT="%Y-%m-%d %H:%M:%S" CARD_SAMPLE_RATE=48000 CARD_CHANNELS=1 LINKS=ReflectorUpLink

[ReflectorUpLink] CONNECT_LOGICS=SimplexLogic:99:R,ReflectorLogic DEFAULT_ACTIVE=1 TIMEOUT=10

[ReflectorLogic] TYPE=Reflector HOST=[redacted] PORT=5300 AUTH_KEY=[redacted] CALLSIGN=[redacted] JITTER_BUFFER_DELAY=50 AUDIO_CODEC=OPUS EVENT_HANDLER=/usr/share/svxlink/events.tcl

[SimplexLogic] TYPE=Simplex RX=RxLocal TX=TxLocal EVENT_HANDLER=/usr/share/svxlink/events.tcl CALLSIGN=[redacted] RGR_SOUND_DELAY=100 RGR_SOUND_ALWAYS=1 FX_GAIN_NORMAL=0 FX_GAIN_LOW=-12 MUTE_TX_ON_RX=1 MUTE_RX_ON_TX=1

[RxLocal] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 SQL_DET=GPIO GPIO_SQL_PIN=gpio16 SQL_TIMEOUT=3 RxComp=1 RxCompThreshold=-30 RxCompRatio=0.5 RxCompAttack=50 RxCompDecay=5000 SQL_DELAY=0 SQL_HANGTIME=500 SQL_TAIL_ELIM=50 DTMF_DEC_TYPE=INTERNAL DTMF_HANGTIME=100 DTMF_MUTING=1 1750_MUTING=1

[TxLocal] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 PTT_TYPE=GPIO PTT_PIN=gpio15 TX_DELAY=0 PTT_HANGTIME=50 TIMEOUT=300 PREEMPHASIS=1 TxLimit=1 TxComp=1 TxCompThreshold=-90 TxCompRatio=0 TxCompAttack=10 TxCompDecay=5000`

That is the svxlink.conf. There must be something that eludes me, maybe something to do with the svxlink inner logics. I'm struggling with this for two weeks now and got nowhere. Is there the slightest chance that this is a svxlink bug or most likely it is me, not fully understanding how svxlink is supposed to work? I went through this page: http://www.svxlink.org/doc/man/man5/svxlink.conf.5.html dozens of times, and while most individual settings make sense, it's hard for a new user to put the puzzle pieces together and build a correct svxlink.conf from scratch, or troubleshoot an existing one.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sm0svx/svxlink/issues/500, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBOWWQXNGOLZMVIXDPUWJ3RVCEM7ANCNFSM4NTIFJ5Q .

[maldea]

@f5vmr: Here's my current svxlink.conf now:

[GLOBAL] MODULE_PATH=/usr/share/svxlink/modules.d LOGICS=SimplexLogic,ReflectorLogic CFG_DIR=/etc/svxlink/svxlink.d TIMESTAMP_FORMAT="%Y-%m-%d %H:%M:%S" CARD_SAMPLE_RATE=48000 CARD_CHANNELS=1 LINKS=ReflectorUpLink

[ReflectorUpLink] CONNECT_LOGICS=SimplexLogic:99:R,ReflectorLogic DEFAULT_ACTIVE=1 TIMEOUT=10

[ReflectorLogic] TYPE=Reflector HOST=[redacted] PORT=5300 AUTH_KEY=[redacted] CALLSIGN=[redacted] JITTER_BUFFER_DELAY=50 AUDIO_CODEC=OPUS EVENT_HANDLER=/usr/share/svxlink/events.tcl

[SimplexLogic] TYPE=Simplex RX=RxLocal TX=TxLocal EVENT_HANDLER=/usr/share/svxlink/events.tcl CALLSIGN=[redacted]

SHORT_IDENT_INTERVAL=10

LONG_IDENT_INTERVAL=30

DEFAULT_LANG=en_US RGR_SOUND_DELAY=100 RGR_SOUND_ALWAYS=1 FX_GAIN_NORMAL=0 FX_GAIN_LOW=-12 MUTE_TX_ON_RX=1 MUTE_RX_ON_TX=1

[RxLocal] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 SQL_DET=GPIO GPIO_SQL_PIN=gpio16

SQL_TIMEOUT=3

OPEN_SQL_FLANK=CLOSE SQL_DELAY=0 SQL_HANGTIME=500 SQL_TAIL_ELIM=50 DTMF_DEC_TYPE=INTERNAL DTMF_HANGTIME=100 DTMF_MUTING=1 1750_MUTING=1

[TxLocal] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 PTT_TYPE=GPIO PTT_PIN=gpio15 TX_DELAY=0 PTT_HANGTIME=50 TIMEOUT=300 PREEMPHASIS=1 TxLimit=1

@f5nlg:

AT+DMOSETGROUP=1,144.6500,144.6500,0000,6,0013 +DMOSETGROUP:0 I've disabled CTCSS on RX and left it on in TX only. The module was already set up on 0.5W. Sadly it can't go as low as 10mW like my DVmega board. I did notice though that even during heavy TX'ing it only gets a little warm.

Nothing changed anything, the squelch opens and remains open, although GPIO16 goes from 0 to 1 during DRA818 RX and from 1 to 0 when I stop TX'ing from my HT.

@f5vmr: I would've loved using the NanoPi Duo due to its very small form factor, would've been OK with OrangePi too, as other seem to have no issue with it, but I'll also try with a Raspberry Pi as well. If that one works with the above svxlink.conf, I will use an RPi Zero with an USB soundcard.

[f5vmr]

Hi again, I see no value in CTCSS on TX unless you want the users to be comfortable with no other extraneous noise. You still have TX limit in place, and as far as I know is not an svxlink thing either. The line OPEN_SQL_FLANK=CLOSE is wrong. This should in [RepeaterLogic] only a repeater function, and should be set as OPEN in any case. It means that when someone calls in, their audio immediately is transmitted, rather than in CLOSE, the repeater has to be opened first by a first call, then the user transmits a second time to pass the audio, definitely not in [RxLocal]. Do you really need Preemphasis=1 in Tx1?

Envoyé depuis l'application Mail Orange ----------------Le 05/06/2020, à 14:37, maldea a écrit : @f5vmr: Here's my current svxlink.conf now: [GLOBAL] MODULE_PATH=/usr/share/svxlink/modules.d LOGICS=SimplexLogic,ReflectorLogic CFG_DIR=/etc/svxlink/svxlink.d TIMESTAMP_FORMAT="%Y-%m-%d %H:%M:%S" CARD_SAMPLE_RATE=48000 CARD_CHANNELS=1 LINKS=ReflectorUpLink [ReflectorUpLink] CONNECT_LOGICS=SimplexLogic:99:R,ReflectorLogic DEFAULT_ACTIVE=1 TIMEOUT=10 [ReflectorLogic] TYPE=Reflector HOST=[redacted] PORT=5300 AUTH_KEY=[redacted] CALLSIGN=[redacted] JITTER_BUFFER_DELAY=50 AUDIO_CODEC=OPUS EVENT_HANDLER=/usr/share/svxlink/events.tcl [SimplexLogic] TYPE=Simplex RX=RxLocal TX=TxLocal EVENT_HANDLER=/usr/share/svxlink/events.tcl CALLSIGN=[redacted]

SHORT_IDENT_INTERVAL=10

LONG_IDENT_INTERVAL=30

DEFAULT_LANG=en_US RGR_SOUND_DELAY=100 RGR_SOUND_ALWAYS=1 FX_GAIN_NORMAL=0 FX_GAIN_LOW=-12 MUTE_TX_ON_RX=1 MUTE_RX_ON_TX=1 [RxLocal] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 SQL_DET=GPIO GPIO_SQL_PIN=gpio16

SQL_TIMEOUT=3

OPEN_SQL_FLANK=CLOSE SQL_DELAY=0 SQL_HANGTIME=500 SQL_TAIL_ELIM=50 DTMF_DEC_TYPE=INTERNAL DTMF_HANGTIME=100 DTMF_MUTING=1 1750_MUTING=1 [TxLocal] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 PTT_TYPE=GPIO PTT_PIN=gpio15 TX_DELAY=0 PTT_HANGTIME=50 TIMEOUT=300 PREEMPHASIS=1 TxLimit=1 @f5nlg:

AT+DMOSETGROUP=1,144.6500,144.6500,0000,6,0013 +DMOSETGROUP:0 I've disabled CTCSS on RX and left it on in TX only. The module was already set up on 0.5W. Sadly it can't go as low as 10mW like my DVmega board. I did notice though that even during heavy TX'ing it only gets a little warm.

Nothing changed anything, the squelch opens and remains open, although GPIO16 goes from 0 to 1 during DRA818 RX and from 1 to 0 when I stop TX'ing from my HT. @f5vmr: I would've loved using the NanoPi Duo due to its very small form factor, would've been OK with OrangePi too, as other seem to have no issue with it, but I'll also try with a Raspberry Pi as well. If that one works with the above svxlink.conf, I will use an RPi Zero with an USB soundcard.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[maldea]

OK, new environment: RPi 3B+ Raspberry Pi OS (32-bit) Lite Using GPIO6 as SQL Using "udp:127.0.0.1:10000" for simplicity Instead of using wires I used echo "0 / 1" > /sys/class/gpio/gpio6/active_low The tests were performed with both 17.12.2 apt according to: https://github.com/sm0svx/svxlink/wiki/InstallBinRaspbian as well as with 19.09.1 compiled from sources according to: https://github.com/sm0svx/svxlink/wiki/InstallSrcHwRpi

When I echo "0" > /sys/class/gpio/gpio6/active_low the SQL opens. When echo "1" > /sys/class/gpio/gpio6/active_low the SQL does nothing and remains open.

Now, I may not be an expert in SVXLink but I am managing Linux based infrastructure for over 15 years now and I have a very deep understanding on both development boards and Linux. Before rausing this issue I tinkered for over a week (as this is how I learn) and I tried countless ways. I followed your every suggestion and went fully compliant. And if you're saying that you have a RPi 3B+ with the RPi OS Buster and you're running the latest SVXLink version, you're using a GPIO as SQL detect that actuall opens it when it goes HIGH and closes the SQL when it gets LOW, please share that config file with me, removing anything you don't want. CTCSS didn't seem to make the trick, moreover, this issue is about GPIO SQL, not CTCSS.

That's what I'm trying to say: If the GPIO goes HIGH and the SQL opens, why doesn't it close when the GPIO goes low? This is what I can't wrap my head around and you maybe understand the frustration of spending close to two weeks on such a simple issue which is either a bug, or the lack of clear and concise documentation.

Can I see the simplest example of a working svxlink.conf using GPIO (not something else) for SQL detect? Google got me nowhere.

[dl1hrc]

Maybe echo 1 > /sys/class/gpio/gpioXX/value controls it, not active_low? I've running 3 Pi's with the latest trunk and a very simple config:

[Rx1]
SQL_DET=GPIO
GPIO_SQL_PIN=!gpio3
SQL_START_DELAY=0
SQL_DELAY=0
SQL_HANGTIME=130

[f5vmr]

Hello again, If you register on “Svxlink Amateur Radio Users” on Facebook there are some ready and working examples of the files in the files section.

73 Chris

On 6 Jun 2020, at 14:19, maldea notifications@github.com wrote:

OK, new environment: RPi 3B+ Raspberry Pi OS (32-bit) Lite Using GPIO6 as SQL Using "udp:127.0.0.1:10000" for simplicity Instead of using wires I used echo "0 / 1" > /sys/class/gpio/gpio6/active_low The tests were performed with both 17.12.2 apt according to: https://github.com/sm0svx/svxlink/wiki/InstallBinRaspbian https://github.com/sm0svx/svxlink/wiki/InstallBinRaspbian as well as with 19.09.1 compiled from sources according to: https://github.com/sm0svx/svxlink/wiki/InstallSrcHwRpi https://github.com/sm0svx/svxlink/wiki/InstallSrcHwRpi When I echo "0" > /sys/class/gpio/gpio6/active_low the SQL opens. When echo "1" > /sys/class/gpio/gpio6/active_low the SQL does nothing and remains open.

Now, I may not be an expert in SVXLink but I am managing Linux based infrastructure for over 15 years now and I have a very deep understanding on both development boards and Linux. Before rausing this issue I tinkered for over a week (as this is how I learn) and I tried countless ways. I followed your every suggestion and went fully compliant. And if you're saying that you have a RPi 3B+ with the RPi OS Buster and you're running the latest SVXLink version, you're using a GPIO as SQL detect that actuall opens it when it goes HIGH and closes the SQL when it gets LOW, please share that config file with me, removing anything you don't want. CTCSS didn't seem to make the trick, moreover, this issue is about GPIO SQL, not CTCSS.

That's what I'm trying to say: If the GPIO goes HIGH and the SQL opens, why doesn't it close when the GPIO goes low? This is what I can't wrap my head around and you maybe understand the frustration of spending close to two weeks on such a simple issue which is either a bug, or the lack of clear and concise documentation.

Can I see the simplest example of a working svxlink.conf using GPIO (not something else) for SQL detect? Google got me nowhere.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sm0svx/svxlink/issues/500#issuecomment-640051538, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAKA5FUO6S6OQFQ5K3MA7TRVIX6XANCNFSM4NTIFJ5Q.

[maldea]

I am a member, I looked for an example svxlink.conf for a fairly popular setup with an RPi or whatever board, an SA818/DRA818 connecting to a reflector.

This is the most stripped down version of svxlink.conf I could come up with, plain and simple.

# cat /etc/svxlink/svxlink.conf
[GLOBAL]
MODULE_PATH=/usr/share/svxlink/modules.d
LOGICS=SimplexLogic,ReflectorLogic
CFG_DIR=svxlink.d
TIMESTAMP_FORMAT="%c"
CARD_SAMPLE_RATE=48000
CARD_CHANNELS=1
LINKS=ReflectorUpLink

[ReflectorUpLink]
CONNECT_LOGICS=SimplexLogic:99:R,ReflectorLogic
DEFAULT_ACTIVE=1
TIMEOUT=10

[ReflectorLogic]
TYPE=Reflector
HOST=[redacted]
PORT=5300
AUTH_KEY=[redacted]
CALLSIGN=[redacted]
JITTER_BUFFER_DELAY=50
AUDIO_CODEC=OPUS
EVENT_HANDLER=/usr/share/svxlink/events.tcl

[SimplexLogic]
TYPE=Simplex
RX=RxLocal
TX=TxLocal
CALLSIGN=[redacted]
EVENT_HANDLER=/usr/share/svxlink/events.tcl

[RxLocal]
TYPE=Local
AUDIO_DEV=udp:127.0.0.1:10000
AUDIO_CHANNEL=0
SQL_DET=GPIO
GPIO_SQL_PIN=gpio6
SQL_START_DELAY=0
SQL_HANGTIME=1500
SQL_TIMEOUT=180

[TxLocal]
TYPE=Local
AUDIO_DEV=udp:127.0.0.1:10001
AUDIO_CHANNEL=0
PTT_TYPE=GPIO
PTT_PIN=gpio5
TX_DELAY=0
PTT_HANGTIME=50
TIMEOUT=300

For simplicity I am launching svxlink in a screen session: svxlink --logfile=/var/log/svxlink --config=/etc/svxlink/svxlink.conf --runasuser=root The log shows no errors:

# tail -F /var/log/svxlink

Sat Jun  6 20:31:41 2020: Using configuration file: /etc/svxlink/svxlink.conf
Sat Jun  6 20:31:41 2020: --- Using sample rate 48000Hz
Sat Jun  6 20:31:41 2020:
Sat Jun  6 20:31:41 2020: Starting logic: SimplexLogic
Sat Jun  6 20:31:41 2020: Loading RX: RxLocal
Sat Jun  6 20:31:41 2020: Loading TX: TxLocal
Sat Jun  6 20:31:41 2020: SimplexLogic: Event handler script successfully loaded.
Sat Jun  6 20:31:41 2020:
Sat Jun  6 20:31:41 2020: Starting logic: ReflectorLogic
Sat Jun  6 20:31:41 2020: ReflectorLogic: Connecting to [redacted]:5300
Sat Jun  6 20:31:41 2020: Activating link ReflectorUpLink
Sat Jun  6 20:31:41 2020: ReflectorLogic: Connection established to [redacted]:5300
Sat Jun  6 20:31:41 2020: ReflectorLogic: Authentication OK
Sat Jun  6 20:31:41 2020: ReflectorLogic: Connected nodes: [redacted]
Sat Jun  6 20:31:41 2020: ------ Opus encoder parameters ------
Sat Jun  6 20:31:41 2020: Frame size           = 320
Sat Jun  6 20:31:41 2020: Complexity           = 9
Sat Jun  6 20:31:41 2020: Bitrate              = 20000
Sat Jun  6 20:31:41 2020: VBR                  = YES
Sat Jun  6 20:31:41 2020: Constrained VBR      = YES
Sat Jun  6 20:31:41 2020: Maximum audio bw     = MEDIUMBAND
Sat Jun  6 20:31:41 2020: Audio bw             = FULLBAND
Sat Jun  6 20:31:41 2020: Signal type          = VOICE
Sat Jun  6 20:31:41 2020: Application type     = AUDIO
Sat Jun  6 20:31:41 2020: Inband FEC           = NO
Sat Jun  6 20:31:41 2020: Expected Packet Loss = 0%
Sat Jun  6 20:31:41 2020: DTX                  = NO
Sat Jun  6 20:31:41 2020: LSB depth            = 16
Sat Jun  6 20:31:41 2020: --------------------------------------
Sat Jun  6 20:31:41 2020: ------ Opus decoder parameters ------
Sat Jun  6 20:31:41 2020: Gain       = 0dB
Sat Jun  6 20:31:41 2020: --------------------------------------
Sat Jun  6 20:31:41 2020: ReflectorLogic: Using audio codec "OPUS"

Let's check GPIO6 value:

# cat /sys/class/gpio/gpio6/value
0

Then set it high and check its value. I went the plain simple way, but the same could've been done with WirinPi

# echo "0" >  /sys/class/gpio/gpio6/active_low
# cat /sys/class/gpio/gpio6/value
1

And the SQL opens:

# tail -F /var/log/svxlink
Sat Jun  6 20:39:50 2020: RxLocal: The squelch is OPEN (0)

Now let's take it low and check what happens.

# echo "1" >  /sys/class/gpio/gpio6/active_low
# cat /sys/class/gpio/gpio6/value
0

Nothing happens, SQL is still open and it will remain open indefinitely.

# tail -F /var/log/svxlink
Sat Jun  6 20:39:50 2020: RxLocal: The squelch is OPEN (0)

Killing svxlink:

# tail -F /var/log/svxlink
Sat Jun  6 20:39:50 2020: RxLocal: The squelch is OPEN (0)
Sat Jun  6 20:40:12 2020: SIGINT received. Shutting down application...

In had my fair share of debugging and tinkering as a professional but I never heard of a piece of software running without a hitch for everyone else, yet having the exact same bug on a wide variety of hardware and software environments. It's not that it doesn't fire off but a very specific behaviour. If the above svxlink.conf is 100% correct to the letter and you're saying it should work, yet for me it doesn't, on three different boards with various distros and kernel version, both from packages and from from sources, yet every single time it get stuck on SQL not closing, then by all means, this is no software bug or miscofiguration on my end and I should just accept that svxlink doesn't like me and I should let it go. And I will do just that as I don't want to waste any more of your time.

[f5vmr]

Did you check out the rc.local.txt on the page? You haven't mentioned how you have set the GPIO at all as far as I recall.Chris Jackson05.55.64.84.2006.68.70.87.20 "The art of diplomacy in everything is completely understanding the others point of view, anticipating the response, and prospecting common ground.""L'art de la diplomatie dans tout est de comprendre complètement le point de vue des autres, d'anticiper la réponse et de rechercher une entente cordiale."envoyé : 6 juin 2020 à 22:05de : maldea notifications@github.comà : sm0svx/svxlink svxlink@noreply.github.comcc : Chris F5VMR f5vmr@orange.fr, Mention mention@noreply.github.comobjet : Re: [sm0svx/svxlink] GPIO squelch opens but doesn't close (#500) I am a member, I looked for an example svxlink.conf for a fairly popular setup with an RPi or whatever board, an SA818/DRA818 connecting to a reflector.This is the most stripped down version of svxlink.conf I could come up with, plain and simple.# cat /etc/svxlink/svxlink.conf [GLOBAL] MODULE_PATH=/usr/share/svxlink/modules.d LOGICS=SimplexLogic,ReflectorLogic CFG_DIR=svxlink.d TIMESTAMP_FORMAT="%c" CARD_SAMPLE_RATE=48000 CARD_CHANNELS=1 LINKS=ReflectorUpLink

[ReflectorUpLink] CONNECT_LOGICS=SimplexLogic:99:R,ReflectorLogic DEFAULT_ACTIVE=1 TIMEOUT=10

[ReflectorLogic] TYPE=Reflector HOST=[redacted] PORT=5300 AUTH_KEY=[redacted] CALLSIGN=[redacted] JITTER_BUFFER_DELAY=50 AUDIO_CODEC=OPUS EVENT_HANDLER=/usr/share/svxlink/events.tcl

[SimplexLogic] TYPE=Simplex RX=RxLocal TX=TxLocal CALLSIGN=[redacted] EVENT_HANDLER=/usr/share/svxlink/events.tcl

[RxLocal] TYPE=Local AUDIO_DEV=udp:127.0.0.1:10000 AUDIO_CHANNEL=0 SQL_DET=GPIO GPIO_SQL_PIN=gpio6 SQL_START_DELAY=0 SQL_HANGTIME=1500 SQL_TIMEOUT=180

[TxLocal] TYPE=Local AUDIO_DEV=udp:127.0.0.1:10001 AUDIO_CHANNEL=0 PTT_TYPE=GPIO PTT_PIN=gpio5 TX_DELAY=0 PTT_HANGTIME=50 TIMEOUT=300 For simplicity I am launching svxlink in a screen session: svxlink --logfile=/var/log/svxlink --config=/etc/svxlink/svxlink.conf --runasuser=root The log shows no errors:# tail -F /var/log/svxlink

Sat Jun 6 20:31:41 2020: Using configuration file: /etc/svxlink/svxlink.conf Sat Jun 6 20:31:41 2020: --- Using sample rate 48000Hz Sat Jun 6 20:31:41 2020: Sat Jun 6 20:31:41 2020: Starting logic: SimplexLogic Sat Jun 6 20:31:41 2020: Loading RX: RxLocal Sat Jun 6 20:31:41 2020: Loading TX: TxLocal Sat Jun 6 20:31:41 2020: SimplexLogic: Event handler script successfully loaded. Sat Jun 6 20:31:41 2020: Sat Jun 6 20:31:41 2020: Starting logic: ReflectorLogic Sat Jun 6 20:31:41 2020: ReflectorLogic: Connecting to [redacted]:5300 Sat Jun 6 20:31:41 2020: Activating link ReflectorUpLink Sat Jun 6 20:31:41 2020: ReflectorLogic: Connection established to [redacted]:5300 Sat Jun 6 20:31:41 2020: ReflectorLogic: Authentication OK Sat Jun 6 20:31:41 2020: ReflectorLogic: Connected nodes: [redacted] Sat Jun 6 20:31:41 2020: ------ Opus encoder parameters ------ Sat Jun 6 20:31:41 2020: Frame size = 320 Sat Jun 6 20:31:41 2020: Complexity = 9 Sat Jun 6 20:31:41 2020: Bitrate = 20000 Sat Jun 6 20:31:41 2020: VBR = YES Sat Jun 6 20:31:41 2020: Constrained VBR = YES Sat Jun 6 20:31:41 2020: Maximum audio bw = MEDIUMBAND Sat Jun 6 20:31:41 2020: Audio bw = FULLBAND Sat Jun 6 20:31:41 2020: Signal type = VOICE Sat Jun 6 20:31:41 2020: Application type = AUDIO Sat Jun 6 20:31:41 2020: Inband FEC = NO Sat Jun 6 20:31:41 2020: Expected Packet Loss = 0% Sat Jun 6 20:31:41 2020: DTX = NO Sat Jun 6 20:31:41 2020: LSB depth = 16 Sat Jun 6 20:31:41 2020: -------------------------------------- Sat Jun 6 20:31:41 2020: ------ Opus decoder parameters ------ Sat Jun 6 20:31:41 2020: Gain = 0dB Sat Jun 6 20:31:41 2020: -------------------------------------- Sat Jun 6 20:31:41 2020: ReflectorLogic: Using audio codec "OPUS" Let's check GPIO6 value:# cat /sys/class/gpio/gpio6/value 0 Then set it high and check its value. I went the plain simple way, but the same could've been done with WirinPi# echo "0" > /sys/class/gpio/gpio6/active_low

cat /sys/class/gpio/gpio6/value

1 And the SQL opens:# tail -F /var/log/svxlink Sat Jun 6 20:39:50 2020: RxLocal: The squelch is OPEN (0) Now let's take it low and check what happens.# echo "1" > /sys/class/gpio/gpio6/active_low

cat /sys/class/gpio/gpio6/value

0 Nothing happens, SQL is still open and it will remain open indefinitely.# tail -F /var/log/svxlink Sat Jun 6 20:39:50 2020: RxLocal: The squelch is OPEN (0) Killing svxlink:# tail -F /var/log/svxlink Sat Jun 6 20:39:50 2020: RxLocal: The squelch is OPEN (0) Sat Jun 6 20:40:12 2020: SIGINT received. Shutting down application... In had my fair share of debugging and tinkering as a professional but I never heard of a piece of software running without a hitch for everyone else, yet having the exact same bug on a wide variety of hardware and software environments. It's not that it doesn't fire off but a very specific behaviour. If the above svxlink.conf is 100% correct to the letter and you're saying it should work, yet for me it doesn't, on three different boards with various distros and kernel version, both from packages and from from sources, yet every single time it get stuck on SQL not closing, then by all means, this is no software bug or miscofiguration on my end and I should just accept that svxlink doesn't like me and I should let it go. And I will do just that as I don't want to waste any more of your time.—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[maldea]

Yes, I did set up the GPIO inputs in rc.local. Else the svxlink would throw an error, but it loads RxLocal just fine. Moreover, not setting the GPIO pin number right would not open the SQL when setting it high. But the damn thing only opens but doesn’t close.

[Dloranger]

I have run into this several times and it can be related to the audio input device. There is a fundamental link to the audio input device clocking. I don't understand the mechanics exactly, but basically if the receiver audio isn't streaming data (thus nothing to clock against) then the svxlink software will effectively lock up. I would suggest to review the audio circuitry to ensure it is always on. Many device drivers do not behave this way by default.

[maldea]

@Dloranger thanks for the hint. Once I had some time to troubleshoot some more I got it figured. You were right, it was an audio issue. Although I'm a heavy Linux user for years, I only dealt with servers and have little to no knowledge about its multimedia features so I had to learn a bit about alsa and its CLI. The problem is that indeed, svxlink RX locks up when the squelch opens, most likely waiting for the audio stream. The app doesn't hang, as tailing the log shows other talkers activity, it's just that its RX side is endlessly waiting for an audio stream.

More specifically, if alsa isn't configure to capture the audio stream, svxlink just waits for it. Not sure if this works as designed, there is something else that relies on this behaviour or is it something that can be changed in future versions to avoid others to go through the same grief.

I got to the solution by running: arecord --device=hw:0,0 --format S16_LE --rate 44100 -c1 -V mono test.wav which always ended up with a 44 byte WAV file. So apparently there was indeed something wrong with the capture device configuration.

User kutysam on the Armbian forum provided the fix for the capture device:

1) alsamixer 2) press TAB (Make sure it falls to F4: CAPTURE) 3) Move to Mic1 (Use arrow keys) 4) Press SPACE and (L R Capture will appear)

Once the capture device was properly configured, the GPIO driven SQL started working like a charm.

Perhaps this prerequisite should be documented as all the distros I tested on all the dev boards I used had that capture option disabled by default.

Anyway guys, thank you for your support. Without it, I was about to give up.

73's de YO9IYE

[Dloranger]

Glad the pain I went through to discover it was able to prevent you from further heartache, it drove me nuts trying to figure out the cause, but thankfully I had a working solution I could toggle back and forth between to figure it out. Don't forget to mark this issue as closed since you have a solution.