[Loren, W1UV]

I’m hoping to use the OpenRepeater Echolink feature on our wide area repeater. Two things to note, 1) The repeater is at an unattended remote site. 2) I have to share one of the Repeater Controller’s (referred hereon as the Controller) three ports with our 220 repeater. When Echolink is activated the Echolink Controller hardware (custom design hardware that will include the Pi) will disconnect the 220 repeater, connect the Echolink to the Controller, and then the Controller will link the Echolink interface to our two meter repeater. I need a few additional features to do this reliably. I’m good at hardware. Linux is completely new to me so I need help here.

1. I would like to use a Pi GPIO input to initiate a controlled shutdown (same function as sudo poweroff) upon detecting a system power failure. I will supply the Pi power long enough to complete this. Given the remote site I want to avoid the possibility of corrupting the FLASH as much as possible. The site loses power frequently and our battery backup is not as robust as it should be.

2. I would like to use a GPIO input to connect to Echolink and eliminate the us of “2#” to initiate the connection. I would also like to eliminate the voice message saying Echolink is connected. The Controller will handle these functions. As a corollary, I would like this same input to disconnect the link, eliminating the need for “##” and the voice announcement.

3. I would like a GPIO output that indicates a Echolink connection has been made. This would be asserted on both incoming and outgoing requests.

4. Finally, I need to eliminate the Morse Code ID’s generated by the PI. The Controller handles all repeater ID’s. Can I assume setting the ID timers to “0” will do this?

That’s it so far. From what I’ve seen and read ours is not a typical OpenRepeater implementation. I hope you can help.

One last nice feature I would like. The Repeater Log only provides a recent snapshot of activity and it does not allow scrolling back to see past events. I would like to see both a scroll back feature and the creation of a log file. I have to be able to review how the system is operating and being used.

To much??

73’s,
Loren – W1UV

[Dan, KG7PAR]

Let me take a stab at some of these

#1 – I believe this is a feature that is standard on raspberry pi now, check raspi-config menu. I think that’s where I saw it. Otherwise have a google for it, this is a widely used function on rpi.

There is a gotcha here, if the system is shutdown, but then power never actually fails, the pi will never turn back on until you can forcefully trip the power.

#2 – use gpio for echolink start. Whats your end goal here? I assume you want to setup echolink on a timer or such, if so there are ways to do it with cron/scripts directly using DTMF_pty_ctrl or something close to that config variable. This allows you to inject a dtmf tone via the console so its not audible, thus not audibly hackable.

I believe if you go this route though, you will still have audible dtmf tones to deal with but you could change the access code to something ridiculous that no one would guess.

As for disabling the modules, I am pretty sure that will still be #. That will be like changing the enter key on your computer to the space bar. Possible, but not practical. Not sure how to get around this off hand, but I think there might be a config variable to mute all dtmf, but that may be going too far.

For the announcements, check svxlink.groups.io I think this was discussed there a while back.

#3 – the first thought that comes to mind is a log file monitor script. There is also state_pty option I think Aaron was planning to tinker with, maybe the state of echolink is available there??

#4 – you got it right

[Loren, W1UV]

Thanks Dan for the quick response. As for #1: I will make provisions that if the power fails, the Pi will lose power after it shuts down. As a back up, I will be incorporating a Arduino Uno uController (not the board, just the chip) on a separate board for house keeping purposes. For instance, audio levels will be controlled by electronic pots so they can be adjusted remotely. No manual pots. I will also be able to cycle the power on the Pi with the Uno. Check my QRZ page to see one example of how I’ve used the Uno uControllers.

Let me mull on the rest and I’ll respond with clarification to #2. Getting rather late here in NH.

-LA

[Aaron, N3MBH]

#1 – For power cycling the Pi forcibly and remotely (i.e after a scripted shutdown), you could use a smart plug instead of a Arduino. It’s basically the relay and a microcontroller with wifi in a small package. I would just recommend getting something that is ESP based and Flashable with 3rd party firmware like Tasmota. Many of the popular ones on Amazon (like the Teckin ones) have switched to a RealTek chipset which is not flashable at all OR they have patched their stock frimware (Tuya) where it cannot be flashed OTA with something like Tuya-Convert. You can still crack them open and solder wires on to flash them with a 3.3v serial converter, but many of these plugs are glued shut and are difficult to open. Maybe check out the Sonoff S31…it’s easy to open (if you need to) and there are plenty of videos on YouTube about it. It’s available in a few flavors I believe (wifi/zigbee). Dan and I were just discussing these smart plugs he other day.

#3 – Per Dan’s comment I have implemented automatic outputs of PTY configuration for each logic section in the svxlink.conf for testing and future use in the 2.2.0 branch. I committed those not too long ago. They have not been fully tested, but in initial tests seem to work OK. If you build a 2.2.0 build and encounter errors with the PTY it would likely be a permissions issue.

73,
Aaron – N3MBH / WRFV871

OpenRepeater is offered free of charge. Find out how you can support us.

[Author]

Posts