[Dan, KG7PAR]

We have been working on it as time allows, I know aaron wants to get 2.1 out sooner than later but we haven’t set a hard target yet. There are only a few of us working on it actively right now so it tends to go in spurts.

If interested you can build a copy of the current beta image which is stable, but the UI has an issue where it runs with a bit of lag that we haven’t chased down yet

https://github.com/OpenRepeater/scripts/tree/2.1.x

Just start with a clean SD card with the latest raspian LITE image from the pi foundation (https://raspberrypi.org/downloads) and then follow the instructions on the github link above.

[Dan, KG7PAR]

Hi Randy,

The 1x is just a radio interface and a sound card essentially, so it all really comes down to your software configuration. I don’t think the 2.0 release really supports the simplex logic, but the next release (2.1) should have ready support for simplex.

As for the sound files, there is a folder for all the sounds, but essentially they are prerecorded wav files, 16k mono format as I recall. Browsing “/usr/share/svxlink/sounds” folder will get your started

[Dan, KG7PAR]

I don’t have any experience with using the ttyS0 ports, but I do know it is supported as I have seen it in the “manual” as excerpted below for the PTT portion

http://www.svxlink.org/doc/man/man5/svxlink.conf.5.html#STATE%20PTY%20FORMAT

PTT_TYPE

Use this configuration variable to specify which type of hardware to use to control the PTT. Specify “SerialPin” for using a pin in the serial port, “GPIO” to use a pin in a GPIO port, “PTY” if you want to use an external interface script via a pseudo tty port or “Hidraw” to use the linux/hidraw driver to support hidraw devices like CM108 sound card, e.g. URI device from DMK.

Set PTT_TYPE to “Dummy” or “NONE” to not use any PTT hardware at all. It is an error to not specify PTT_TYPE.

Use PTT_PIN to specify the pin to use for “SerialPin” or “GPIO”.

PTT_PORT

Specify the serial port that the PTT is connected to. E.g. /dev/ttyS0 for COM1.

PTT_PIN

If PTT_TYPE is set to “SerialPin”, specify the pin(s) in the serial port that the PTT is connected to. It is possible to specify one or two serial port pins. Some interface boards require that you specify two pins since one pin does not provide enough drive power to the circuit. A “!” in front of the pin name indicates inverted operation. Some of the possible values are RTS, DTRRTS, !DTR!RTS or even DTR!RTS.

[Dan, KG7PAR]

Hi Tom,

Reading more closely you are already using the overrides so that is a good start.

Maybe I misunderstood your question now with a 3rd read. I normally don’t hear the ident when svxlink stock first boots up, I typically customize my install to announce that it is “online” so I know it is running sucessfully. I do notice that the system likes to ident on the first transmission over the top of the person keying the mic. Is this what you are talking about?

There is also this setting that might help lower down the chatter level, I need to do this on my system as well.

https://github.com/OpenRepeater/openrepeater/issues/58

[Dan, KG7PAR]

Hi Tom,

I am not at a station at the moment, but in the ident tab at the bottom you should be able to change the ID from CW to voice or both. I found a bug in the current development that may have been lingering so try that first and if it doesn’t work assume this is the same bug which has been fixed already in the development code.

assuming you hit the bug, you need to create a overrides file for the logics, this is actually the prescribed way of svxlink for doing custom idents.

read here to learn the prescribed way to override the idents behaviors. This is a useful thing to know about in general
https://github.com/sm0svx/svxlink/wiki/InstallationInstructions
in “The Event Handling Subsystem”

[Dan, KG7PAR]

Are you using a distributed image of orp or a self built one? If a distributed image, a reimage may help to resolve your issue as well if the below doesn’t work.

It should be there by default, but you could try running

apt-get install alsa-utils

To reinstall the utility.

[Dan, KG7PAR]

Mario,

You can use the soft audio adjustments through the SSH interface. Once you login via ssh, you can open the alsamixer utility to adjust the audio, but the adjustment levels are usually very rough (20%) so you are better off using a potentiometer in the audio path for fine adjustments on both the input and output audio.

[Dan, KG7PAR]

Sorry, helping several people at one time! Mind in a blender today lol

[Dan, KG7PAR]

I am not a great authority for anything echolink in general or tuning the audio levels,, but I would start with setting the audio where it sounds reasonable volume without distortion. I test with a pc based sine wave generator and sweep the frequency through a few 1khz steps looking for distortion on an oscilloscope at the input to the audio chipset (“Q1/Q2” on the controller board. These are actually 0-ohm resistors not transistors on the board. just above the ethernet interface on the raspberry pi.

Then after I am comfortable with the input signal, I would say do the same thing going through the echo server and check the output that goes into the audio amp.

I think we will need to play with your scenerio some to come up with the best approach here.

Since you have the 2x controller, you by default of the current image have a simplex and duplex port at hand to swap back and forth against.

Port 1 is full duplex, while port 2 is simplex only at this time. I think we will need to get you into the config file outside the menu tree, but Aaron and I can work with you on that.

I usually test echolink on my mobile, I have my base callsign ID on my phone and have the callsign-R ID on the controller. Be sure to have the mobile on the cell network and not wifi, then its easy to “call” yourself for testing both directions. Power is out at my QTH or I would offer to let you use it as a dead end remote node for testing. the range on the setup is about 10 ft so the risk of issues is extremely low. 50 ohm dummy load right on the radio port keeps all but very local signals out of the receiver and the Tx doesn’t even get outside the shack.

[Dan, KG7PAR]

Hi Randy,

use the setting you have that causes the leds to work right. On when expected, off when not expected. It sounds like from a COS hardware standpoint you are in good shape as you are seeing the correct behaviors with the LEDS, and being you are getting the DTMF messages you have the right receive audio connections and the backend audio settings are reasonable.

Can you summarize again what symptom you are seeing now that we know the hardware is configured correctly?

[Author]

Posts