[Andrew, N9KET]

Thank you to the team for all the work thus far. We are in the midst of moving our repeater and considered OpenRepeater to replace an arcomm RC210. The feature that is currently missing for us is a scheduler, mostly to change voice announcements based on the day of the week.

Join the repeater net on Monday, HF net on Tuesday, etc…

I suspect I could hack it using cron and some scripting, but my programming skills are a bit scary 🙂

Thanks for the consideration,
Andrew N9KET

[Dan, KG7PAR]

This feature is something we all desire ?. We have discussed this feature many times, but we don’t have enough of a development team to push out many features on the Open Repeater platform.  Really there are 2 of us that are the core of Open Repeater, and random folks join and dissolve without jumping in much. Wish that would change, but wish in 1 hand… as the saying goes.

There is a couple possible ways to implement this that I think are reasonably feasible, but they are all hacks at the moment as there is no native infrastructure in the svxlink software platform for dynamic announcements.

None of this has been tested, but should work.  I saw a long time ago a module similar to #2, but the code was taken down before I could grab it so it needs recreated. Something on my list for a long time now, but no bandwidth to recreate from scratch.

1) using cron/pytjon/etc and the infrastructure we are exploring for using voice control (very early alpha side application, but proof of concept is working). Join the open repeater development team if you want to get into the voice work. It is on hold at the moment as I am buried with dayjob work.

2) there is the ability to create modules (TCL or C language, strongly suggest TCL) that plug into the svxlink features which can subscribe to a timer.  Within the module, it could do some math to figure out the time, day, etc and then play an announcement as appropriate.

3) get into the user interface files  (basic TCL scripting, don’t jump overboard yet), and do some work similar to #2, so the system uses a dynamically selected file based on some criteria.  This is the best approach, and uses the native structure which will be the most graceful.  The challenge will be having it be able to change behavior without rebooting the system.  I have some ideas for this though.

I would be happy to help guide you in any of these approaches if you are willing to put in the legwork and share the code with the open repeater/svxlink team for possible inclusion somewhere in the future, or just as reference material for others who follow.

I know I could get any of these going given enough time, but alas, its in short supply for volunteer work right now.

Dan

[Aaron, N3MBH]

This is something that as been on my todo list for a while and trying to figure out how to achieve it. I do have some thoughts on it and have been brainstorming as to how to accomplish it. The SVXLink core as Dan mentions does not support anything like this.

The best way I feel to achieve this is to build an ORP Module of sorts. An ORP module is an SVXLink module (the TCL code mentioned above in 2 & 3) wrapped with some ORP code that includes a UI and code to read and write the settings to the ORP database and build config files.

While we are working on some code changes in the 2.2.x code which will eventually lead into a new design for version 3.x. I think the UI will be best suited for a 3.x or later release because of the pending UI changes. The frame work that I am using for the new 3.x design does have some calendar UI features. My thought would be to start with the UI design and use that to guide the SVXLink TCL code that is created.

My thought would be to have a calendar UI where you could visually add items and set parameters for each calendar item. By clicking on a calendar item it would bring up a popup or modal window with the options in it for that item. This would allow for attaching of audio files to use for announcements. This way we can use some the the components that ORP has that straight SVXLink does not. Which is facilities to upload and process audio as well as a graphical UI. The was a lot of thought put into the background class that handles the audio. Not only does it process the upload but it uses the Linux subsystem to process the audio into the correct format required by SVXLink…making it much simpler for the user.

On the SVXLink side, as Dan said we would need to hook into the timer procedures of SVXLink to track triggering. The use the play back procedures at the appropriate times. Or even take it a step farther and try to override the short and long ID procedures where applicable by schedule. I think the building blocks are there, I myself am not a TCL expert. The PHP and UI side is more of my comfort zone. So it would definitely be a team effort.

If you’d like to be involve with the development/testing group, let me know and I can send you an invite.

73,
Aaron – N3MBH / WRFV871

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

[Adi, DL1HRC]

Hello everyone,
I think that SvxLink can do more than you think.
There is the every_second procedure that could be used to check every second whether there is a new message to issue but I think that once per minute should be ok.
I would have the idea here that sound files are stored in a specific file format in a spool directory (from the calendar application), e.g.

/var/spool/svxlink/announcements/DB0HRC_3_01062020_143000.wav

The call sign should be at the beginning so that SvxLink can check which repeater the output should take place on.
The first number could define the number of issues, e.g. 3 times every half hour or similar. We can still talk about that…
This is followed by the date (also in US notation if you want) and then the time of announcement.
The associated Tcl procedure for the output should not be very difficult to write. The advantage is that everything works at runtime and SvxLink does not have to be restarted. What do you all mean?
vy 73s de Adi / DL1HRC

[Aaron, N3MBH]

Hello Adi,
I don’t disagree with you that SVXLink is capable. I am aware of the time procedures. Am I correct in say that building a TCL module for SVXLink is the best way to handle the announcements?

The way ORP modules work is it has some additional wrapper code around SVXLink TCL code that allows it to be packaged and installed into ORP much like a WordPress plugin. There are some extra UI functions I would like to build to aid with scheduling. ORP also has some audio classes that aid with uploading the files and processing them with SOX so that SVXLink likes them.

73,
Aaron – N3MBH / WRFV871

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

• This reply was modified 4 years, 5 months ago by Aaron, N3MBH.

[Adi, DL1HRC]

Hi Aaron,

yes the announcements should be done inside the tcl-framework. In my opinion the best way would be to check a directory periodically and announce the wav when the defined time is right as explained above. The delay is 60 seconds as maximum.
I’ve done it here on my repeaters in a similar way for special application like (thunder-)storm warnings, official disaster warnings from authorities or just an email-to-announcement-function when an email from a legitimated hamradio operator has been received. In my application, texts from emails are converted into wav files (by a Perl-skript) and output immediately by SvxLink, but it is not a problem to install a function that checks whether the planned output time has been reached.
The locale concept makes it easy to replace certain standard functions with your own extensions.
vy 73s de Adi / DL1HRC

[Author]

Posts