[Dan, KG7PAR]

Hi Klaus,

Sorry for the lag in further response. We have been chasing down another bug that we think we are now getting squashed.

If you would like, you can use my version of the build script to get your system setup with the trunk builds now which has the updated code for the metar module. note I have not touched the core svxlink code, so any bugs that are there are part of the trunk code and will need patched later on.

You can grab the installer here, or wait for the 2.1 Open Repeater release (Date pending, but getting closer) which will also include the same changes (assuming they are accepted to the project)
https://github.com/dloranger/scripts/

[Dan, KG7PAR]

Klaus,

it appears the svxlink trunk is broken at the moment’ best to hold off for a bit on this

[Dan, KG7PAR]

For your situation, I would recommend building and testing locally and then deploying to your field system.

This looks to be compiled into the source code so not easily remotely implemented.

If you have a knowledgable linux guru around, you should be able to do it remotely, but I am certainly not well enough versed to provide guidance on how to do it safely and not risk taking the system down completely.

[Dan, KG7PAR]

Hi Klaus,

This is an issue for the underlying svxlink software, and is known about.

https://github.com/sm0svx/svxlink/issues/439

There is a fix checked into the master trunk. For right now we don’t support building from trunk directly as it has not been well tested, we are sticking to released versions of svxlink source code.

Now having said that, we do have the option in the build script (under advanced menu) to select to build from the trunk if you want to try doing a build yourself. This version is not released so we can’t guarantee there won’t be bugs (we actually know about several that are outstanding so far).

The process is fairly straight forward if you are comfortable doing the basics of creating an image from scratch and getting logged into your system on the console. Few commands to copy and paste and then you should be up and running with the trunk version.

Just follow the instructions and everything should go smoothly.

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

Dan, KG7PAR

[Dan, KG7PAR]

progress again, strange that would affect the alsa settings, I can’t reconcile that but perhaps the failure was causing something in the audio to fault back to defaults when the software tried to load up and failed.

As for the tones, I believe this can be done as there are options to set them dynamically in the tcl files, but this is well outside anything I have touched and would likely need a fair amount of trial and error. A good place to ask this question would be at https://groups.io/g/svxlink, There are a couple really smart folks in there that know svxlink details a lot better than I do. You may or may not get an answer, it seems to be hit and miss, but is worth a try.

[Dan, KG7PAR]

Okay, I heard back that this is the service file that needs patched. In the units section add the after statement below to prevent the race condition.

This should keep the repeater from failing to start normally.

/lib/systemd/system/svxlink_gpio_setup.service

[Units]
…
After=network.target
…

[Dan, KG7PAR]

Okay, first problem is solved then, you now have audio! Hazaa!!

For the second one, this is an issue we recently identified as a race condition in the system booting up sequence. I will need to chase down the file path, but its a simple file edit once I find the details of which file to edit. It always takes me a while to find that pesky file.

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

We haven’t implemented this yet in our latest beta, but it will be done soon. The fix has been tested by the one developer and it fixed his system that was failing to come up and I have also encountered this.

As for the CTCSS, you should be able to put it directly in with the audio out, unless the rig blocks its. again in svxlink (not the ORP gui) there is the option to add in the PL tone synthetically. I don’t know that any of us have played with this portion of the software yet, but I am not aware of any bugs in the core software against it functionally.

[Dan, KG7PAR]

As a missed note, to reenable the OR webserver issue the following command

sudo systemctl enable nginx

and reboot to get back to normal behavior for the web UI.

[Dan, KG7PAR]

@arron,

Can you double check that the update settings routine doesn’t rewrite the alsamixer levels? I know we set them when loading the preconfigured settings, but I am not sure if they get written again any time the settings are recompiled due to a setting change. This might be an issue behind this depending on how that was implemented.

@Jack,

Assuming my comment to arron is NOT correct, This sounds like an alsa/kernel issue more than anything in hardware. I have ran into this with some experimental hardware a while back so I understand what you are facing. Very frustrating indeed. Admittedly I never have needed to adjust the mixer from the default for my setup, so I can’t say for sure this isn’t a bug.

try setting the alsamixer settings and then execute

sudo alsactl store

This should force the settings into the file immediately.

Reboot and see if the issue persists

If the issue persists, issue the following command

sudo systemctl disable nginx,

This will disable the Open Repeater webserver (just to make sure its not stepping on your toes)

and reboot again.

Hopefully one of these will help to narrow down where the issue is originating

Now for the synthesized audio, This is actually opposite of the common issue, where the synthetic voice is very loud and the RX is quiet. I am not sure how this could be quiet while the voice portion is okay. I believe there are some commands in the config file that can be used to adjust all this, but I haven’t played with them. It would take some trial and error

Some commentary related,

We have found that pulling the power will defintely cause the alsamixer settings to not be written to file. It is best to issue a “shutdown”, allow sufficient time for everything to come to a complete stop before power cycling. Once the settings are locked in, you can power cycle, although there is well documented evidence this is a risky behavior, but sometimes can’t be avoided. I have personally corrupted a few SD cards by doing power cycles unceremoniously.

Strangely enough, it seems to like messing with the audio and I2C bus the most from my personal experience.

If this continues to be an issue, I would suggest writing down your settings and reimaging the sdcard or grabbing a seconds SD card (Be sure to use name brand high speed ones) and using it to experiment with. On my setup that acted this way, this reimaging of the card immediately cleared up the problem after going several rounds with the tech support for the product thinking it was a driver issue.

In the CPS utility, there is a gain (-dB as I recall) setting for the external mic connector on the back of the radio, as I recall we had to turn this up almost to maximum with the sound set at 60% (the previous default in the ICS images). We then found out through trial and error with the OR image that on the CDM radios we had, that the 70% defaults should be plenty loud. On the units I touched for a customer, this mic setting was turned way down, not sure if that is default or someone had messed with it while experimenting.

Hopefully some of this will get you going. This should be solvable, just need to figure out which (virtual) knob to turn.

[Dan, KG7PAR]

I agree the settings for alsamixer should stick.

Can you elaborate on what events are causing the settings to change? Are you setting them and then rebooting/power-cycling/reconfiguring ORP/?.

By default the settings I believe are around 70% in alsamixer and this should be plenty loud. Beyond this it sounds like potentially a deaf TX radio, is the input levels on your tx rig programmable? We have encountered this a few times now where the input levels are incorrect inside the radio.

Dan

[Author]

Posts