search

sm0svx / svxlink

Advanced repeater system software with EchoLink support for Linux including a GUI, Qtel - the Qt EchoLink client
http://svxlink.org/
Other
432 stars 170 forks source link

SQL_START_DELAY does not work with hardware squelch #137

Closed granitepenguin closed 5 years ago

granitepenguin commented 9 years ago

A brief background of my setup:

A remote-repeater link using SimplexLogic SQL_DET=GPIO

If I use the radio manually and connect to my repeater when I unkey, I get the squelch tail back from the repeater. Using svxlink to transmit, when it unkeys, the squelch tail that comes back triggers the GPIO briefly, which opens the squelch. This isn't a huge deal during an actual QSO, but it means ANY transmission by svxlink will result in a brief squelch open/close:

Mon Apr 20 22:30:00 2015: SimplexLogic: Sending short identification...
Mon Apr 20 22:30:00 2015: Tx1: Turning the transmitter ON
Mon Apr 20 22:30:05 2015: Tx1: Turning the transmitter OFF
Mon Apr 20 22:30:05 2015: Rx1: The squelch is OPEN (4.8478)
Mon Apr 20 22:30:06 2015: Rx1: The squelch is CLOSED (4.74761)

When I was using SQL_DET=VOX, this wasn't an issue, but I was having noise floor issues causing dropouts when people would pause to breath. Using SQL_DET=GPIO fixes that issue, but introduced the brief open on the received squelch tail.

I've tried playing around with SQL_START_DELAY, but that doesn't seem to have any effect on GPIO squelch detection. I've set it as high as 5000 and it doesn't behave any differently than setting it to 5, 50 or 500.

From the mailing list discussion, it appears that SQL_START_DELAY with hardware squelch is not implemented. I would like to see this added.

sm0svx commented 8 years ago

Strangely enough I cannot seem to reproduce this now. SQL_START_DELAY seem to work just fine with both serial port squelch and GPIO squelch. Can you please verify on your system that this is still a problem. If it is, we need to identify some difference in configuration that cause this behaviour.

Update to latest master branch from GitHub before testing.

granitepenguin commented 8 years ago

I'll have to review this a bit and see how things look. Have there been any code updates since the issue was opened that may have had an impact? I have not built anything new for a while, so I don't expect any change.

I'll let you know.

sm0svx commented 8 years ago

I have not knowingly changed anything related to this but if I'm going to hunt for a bug I want to know for sure that it's still there.

(Tip: If you answer on an issue by email, please trim it down to a minimal. Quoting and signatures are almost always unnecessary since the whole conversation and identity are available in the complete issue. Quoting just look messy on the web page which make the issue thread harder to follow. I have edited your answer above.)

granitepenguin commented 8 years ago

Sorry about that. It didn't click with me that it was part of the issue comment list. I'll let you know what I find.

granitepenguin commented 8 years ago

I just finished updating to the latest 1.5. I'm going to play around with the setup a little bit and see if I can make the squelch tail go away now

sm3sgp commented 7 years ago

@granitepenguin Is the SQL_START_DELAY working as i should in your setup with hardware squelch?

granitepenguin commented 7 years ago

I have been unable to determine if SQL_START_DELAY has any appreciable impact on the squelch tail. To be honest, we've mostly just gotten used to how the system behaves and left it alone. For right now, I'd just leave it alone and close this. We can always open a new issue if I ever get irritated enough by it.