[Aaron, N3MBH]

Yes that would be a great starting point. If you can just do a straight raspbian install on your spare Pi, get serial working and see if you can communicate with the radio via HamLib/Rigctrl…that would be a great first step and proof of concept.

73,
Aaron – N3MBH / WRFV871

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

[Aaron, N3MBH]

You don’t need to be a PHP programmer to help. If you feel like you have experience with svxlinkreflector and straight SVXLink, then your advice would be of great help. As you are probably aware the SVXLink documentation is sparse. Someone with firsthand knowledge would be of great benefit. I can develop the PHP off of working config files.

73,
Aaron – N3MBH / WRFV871

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

[Aaron, N3MBH]

Not ruled out yet, just tackling other features. Also I do not have direct experience with AllStar…yet. I’ve also hear that there are theoretical ways to make AllStar which uses Asterisks at it’s core and make it play with SVXLink. The ideal thing would be to package it as a SVXLink modules…much like EchoLink is a module.

If that can be done, We are current working on the new module framework for the next release of ORP that should facilitate adding off additional modules.

If you have experience with AllStar and/or SVXLink in any way, let me know and you might be able to offer some helpful direction. If so, we can discuss further. Thanks.

73,
Aaron – N3MBH / WRFV871

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

[Aaron, N3MBH]

Hello Patrick,
Thanks for posting to the forums to help others. My question to is what version of ORP were you trying to boot on your 3B+? I can say with certainly the 1.1.0 image uses a version of Raspbian prior to the release of the 3B+. As you suggested you should be able to boot the 1.1.0 (or prior version) on a supported board and do the updates you described.

2.0.0 was built with a newer version of Raspbian that has kernel support for the 3B+. I thought that I had another user test the image prior to release for compatibility. If this is the case be sure to let us know.

I think one of the guys that has a 3B+ will try to test and report back. Thanks.

73,
Aaron – N3MBH / WRFV871

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

[Aaron, N3MBH]

Greetings Marco,
Thanks for your interest in the project. There has been interest express in svxlinkreflector before. We just haven’t personally had the chance to figure it out, but it’s been on the radar. If you have an interworking of it you may be able to help move this feature forward. Our development team collaborates via Slack. Let me know if you are interested and I can send you an invite on the side. Thanks.

73,
Aaron – N3MBH / WRFV871

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

[Aaron, N3MBH]

As Dan had mentioned, we are working on a new module framework for the next release that will facilitate development and installation of easier to install modules by end users. Still a work in progress, but looking very promising.

73,
Aaron – N3MBH / WRFV871

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

[Aaron, N3MBH]

Hello guys,
I would recommend looking into using something like Hamlib / Rigctrl. It supports a number of radios and can be accessed via the command line. We might be able to use the module/tcl to decode the DTMF commands and pass commands along to rigctrl to interface with the radio. The hamlib library would need installed on the Pi along with the the module, but then we don’t have to maintain or worry about the direct radio support and all the variations. No need to reinvent that wheel. It would also allow the flexibility for the module to work with a number of other radios.

As of Hamlib 3.0.1, the list of supported radios looks to be around 200+ radios.
https://github.com/Hamlib/Hamlib/wiki/Supported-Radios

73,
Aaron – N3MBH / WRFV871

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

[Aaron, N3MBH]

Gregg,
Thanks for your support. We have a beta “advanced mode” that allows direct entry of the svxlink.conf file and the gpio.conf files. But it doesn’t currently support editing of the EchoLink config or any of the other logic files of SVXLink.

I will shoot you a side email as well.

73,
Aaron – N3MBH / WRFV871

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

[Aaron, N3MBH]

Greetings Gregg,

You are correct that you cannot make changes to the .conf files as they are dynamically generated. You would need to make the changes in the PHP that writes these files. There was an older Knowledge Base article (that could use some updating) that described how to do some editing of the svxlink_update.php, but as of version 2.0.0 that script has been drastically overhauled in preparation for current and future improvements.

Previously most of the build functions were within the svxlink_update.php file, but that has been rewritten into object oriented PHP classes. So you will see in /var/www/openrepeater/functions/svxlink_update.php where it calls out to some functions that are in a new class. That class is located here: /var/www/openrepeater/includes/classes/SVXLink.php

That is where the Echolink config is built. All the modules are generated by the same class method so it might be a little hard to track down.

This is roughly how it is invoked: The svxlink_update.php file calls the function/method build_logic_repeater() within the SVXLink.php class.

That function calls another function in the class called: build_module_list()

That in turn calls write_module_configs() where all the module info is pulled from the database and looped through and processed into an array It is constructed as a PHP array, then passed on to a write function that will call another sub function to reformat the PHP array into an INI format before writing to the ModuleEcholink.conf file.

You could put soemthing inside of the loop of write_module_configs() to catch and custom process just the Echolink Module, or all the settings that are unique to each module are stored withing the database in a serialized array under the moduleOptions field.

If you just want to customize the Echolink config file then you might want to edit the array in /var/www/openrepeater/modules/EchoLink/build_config.php. This is a PHP array that will get serialized and stored in the database that gets called and processed by the method described above.

As for the [LocationInfo] section in the main config, that is probably something that should ultimately need a class method built for it, but you probably could modify the svxlink_update.php script and insert and array for this section after line 107 ($config_array[‘GLOBAL’]…). Maybe something like this:

$config_array[‘LocationInfo’] += [
‘STATUS_SERVER_LIST’ => ‘aprs.echolink.org:5199’,
‘LON_POSITION’ => ‘74.04.6W’,
‘LAT_POSITION’ => ‘40.04.59N’,
(etc, etc, etc…)
];

Hope that is a good starting point. I will be glad to work with you to try to improve this functionality in a future release.

73,
Aaron – N3MBH / WRFV871

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

[Aaron, N3MBH]

James,
Glad to hear you found a solution. Yeah unfortunately when interfacing hardware together you can encounter some strange situations like that. I know when interfacing my ICS board to my Motorola repeater, I had some issues with it holding the PTT active after the initial key up with was baffling me. Ended up having to remove an LED that was functioning as voltage divider in my case can causing the pin to float.

73,
Aaron – N3MBH / WRFV871

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

[Author]

Posts