Gabriel Huang BV5DJ has produced a remarkable device, giving the possibility of further enhancing the use of SVXLink and its associated modules.

The DJSpot is a combination package of Raspberry Pi Zero, a 500 mw walkie-talkie board and an FM / Repeater interface card for EchoLink/SVXLink.

Excellent value.

For further information email bv5dj@hotmail.com

Because of my advanced interest in SVXLink and a future SVXReflector project, I wrote to Gabriel, and thanks to a major Parcels Delivery company, it was received rapidly.

Gabriel is very thorough in his explanation of the operation of the device, so I have to re-iterate the following sage advice.

The DJSpot arrives with software already installed on a MicrSD Card and ready to run. However the first thing that must be done is to immediately make an image from the content. This is simple enough using Win32DiskImager, and is the reverse process of writing to a card. Just create an empty file_name.img, and read the sdCard content to it. It takes a little over 20 minutes.

The next piece of advice is to NOT do the updates to the operating system, at risk of damaging the software. I chose to ignore the advice as a matter of test. It broke, damaging one of the directories for the dpkg updates irrevocably.

The unit contains a remarkably small UHF Transceiver controlled with a software module, set at 430.050 MHz as standard. It is configurable to other UHF frequencies, but with its small range, I would hardly think it necessary. CTCSS of 123 Hz is also standard. The Network, and sound card settings from the HAT are controlled by the SVXLink software, and together with the GPIO settings are pre-configured in the setup. The DJSpot comes with a small loudspeaker unit and a radio connection lead, that for the moment are not used in my case.

Having re-written the card from the saved image, I commenced to set up the software, with my default G4NAB settings.

Here is where I confess to be a little disappointed. Instead of pure SVXLink, I found the OpenRepeater software pre-installed, leaving little option for the significant changes that I wished to make. The OpenRepeater software is fine for someone wanting a near plug ‘n play option for his station, but as a purist delving into the advanced code changes and requirement for voice changes, I found myself having to delve into someone-else’s mindset to trace where the svxlink.conf was being built on an Ad-Hoc basis, rather than it being fixed and configurable by myself. As clever as it is, the OpenRepeater build lacks my need to change the configuration to incorporate the svxreflector blocks of code, and the settings to link to my operational svxreflector server. However I can do it, but the dashboard will have to be bypassed, as changes that I make, will be overwritten by those imported by the dashboard.

Another thing I noted is that OpenRepeater and the administration to the device is carried out as ‘root’, in my view in practice is not a good thing, as with every repeater I have ever built, I have used the user “pi” and ‘sudo’ prior to each command.

One other very small niggle, is that the unit as you see is very compact. The Wifi module is restricted in coverage, and I found that unless it was within 10 metres of the Host modem, it would not connect.

How to set up the Wifi?

Fortunately with Raspberry Pi and MMDVM/Pi-Star experience, it is very easy to accomplish. At Pistar.uk/wifi_builder.php is the tool to accomplish this. Complete the browser page at this url, and it generates a download of a file wpa_supplicant.conf. Before removing the MicroSD card from the PC, simply copy this file to the Card to the top BOOT sector. When installed into the Raspberry Pi Zero, this will be copied into the operating system, and after about 5-10 minutes shall appear on the home network.

The URL of the entry point for SSH can be achieved by carrying out a local network scan to find the IP address. The URL OpenRepeater.local should open the dashboard in a browser on a PC in the network.

I explained that I wished to make some major changes to the software, so I had to find where the svxlink.conf file was being built in order to change the DEFAULT_LANG=en_GB, as the en_US voice lacks some samples and the voice is not “British” enough. Bearing in mind that the building of the new svxlink.conf is carried out by .PHP and Java, it was just a little challenge to find the generator to make the change. I also noted that some DTMF tones were being ignored, especially the “3”, so at the same time I changed the DEEMPHASIS=1 in the [Rx1] to =0. It now works.

The en_GB files are downloadable from these pages in an earlier blog. To incorporate them in this card I carried out the following code in ssh.

cd /usr/share/svxlink/sounds

mkdir en_GB

cd en_GB

wget http://g4nab.co.uk/wp-content/uploads/2021/07/en_GB.tar.gz

tar -xvzf en_GB.tar.gz

This loads all the sound samples for all the modules, and ready for use by the changes I made to the earlier files.

I have not included the location of the files but I can share the information if there is a demand.

My next steps will be to make the changes to incorporate the connection to my svxreflector server.

In all despite the software, this unit is extremely valuable to the user who for one reason or another cannot access his nearby repeater. With a UHF handheld radio, this unit opens up an otherwise untapped area to further use.

I recommend it as a useful addition to the shack.

The changes necessary to revert to standard SVXLink.

As I explained, the OpenRepeater software lacks the niceties of being able to edit the nuances I find necessary to control the intimacies within the hardware. Not only that, the SVXLink version is several steps behind the latest build, so in my case I find it necessary to significantly alter the .conf files. But before I could do that I have to first stop the services that were running in the Hotspot.

Firstly the OpenRepeater is running on a secure webserver on nginx. So having changed the user to ‘pi’ I logged in and issued the following two commands, the first to stop the webserver, and the second to stop the current svxlink.service.

sudo systemctl stop nginx.service

sudo systemctl stop svxlink.service

Next I halt the current running application – sudo killall svxlink.

For the most part all the current .conf files remain unchanged, but in each of the directories /etc/svxlink and /etc/svxlink/svxlink.d I copied each .conf to .conf.bak.

The next step was to preserve the gpio configuration by installing it in the /etc/rc.local with a new daemon start-up line for when we commence the rebuild.

The next steps are a little more complicated, as I needed to upgrade SVXLink to the latest build. Firstly to preserve the current .tcl files, I moved them in this fashion. sudo mv /usr/share/svxlink/events.d /usr/share/svxlink/events.old.

Certain software packages had to be added. Rather than repeat them here, go to the SVXLink Build page here and look for the lines in red. The code I then applied to rebuild svxlink is also there in red.

In the /etc/svxlink/svxlink.conf file, it was necessary for me to add the [ReflectorLogic] section, and edit the [ORP_SimplexLogic_Port1] to become [SimplexLogic] in every case.

What the new compile and build will do is to overwrite all the library .so files in /lib/arm-linux-gnueabihf and replace all the .tcl files in a new /usr/share/svxlink/events.d folder. If you are going to change some of the parameters in these .tcl files then sudo mkdir local and copy all the .tcl files there and work on these, leaving the originals intact in case of mistakes.

The next stage in the changes was to make changes to the /etc/rc.local to include the set up for gpio26 as transmit, and gpio13 as receive. An example of that can be seen in the other blog article. I also created a script for changing and reseting the log each 24 hours, and for warm-restarting the svxlink install after each modification. If you would like to know how that is achieve then drop me a line.

So far the hotspot has set a milestone for me. Previously I have used svxreflector by activating my home repeater consisting of two Kenwood Transceivers, A RPI b+, and its interface on a 13.8V power pack, but the DJSpot with its tiny footprint and minimal power consumption does the same thing, despite being only simplex. I tested it with GB3EV yesterday evening, using my svxreflector server (also on a raspberry pi) and received a good report. EchoLink still works with it, but needs MUTE_LOGIC_LINKING=1 in the ModuleEchoLink.conf to avoid linking the connection output onto any connected repeater.

For detailed advice or explanation. Please email me at g4nab.ne63@gmail.com for an appointment for a video conference on Google Duo.

Leave a Reply