You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
QnetGateway/BUILDING

139 lines
7.1 KiB

Creating a DVAP or a Version 1 DVRPTR hotspot based on a Raspberry Pi or a BeagleBone
Black that can connect to both DStar reflectors as well as XREF reflectors based on
QnetGateway software is easy.
Start with a Raspberry Pi with the latest Raspbian image (see http://raspberrypi.org)
or most any other computer with the latest Debian-based image. For this latest version
of QnetGateway requires the c++ compiler of at least version 4.9.
Even if you are building an MMDVMHost-based hot-spot, the executables and their
source code are very small, so you can get away with a system with minimum storage
capacity. We have build gui-less versions on two gigabyte partitions!
On the RPi, do "sudo raspi-config" and expand the partition, change the password
for the 'pi' user and do any other configuration setup. You don't need to overclock
the RPi for QnetGateway, the default clock rate is just fine.
If you are using a DVAP Dongle or a DVRPTR_V1, login and plug in your device to see
if the OS is recognizing it. The kernel should auto load drivers and you will see
that with the "lsusb" command. The DVAP uses a FTDI chip and the DVRPTR uses Atmel.
If you don't see an approprite output from "lsusb" after your device is plugged in,
you need to enable it by executing:
sudo depmod
sudo modprobe <YOURDEVICEMODULE>
where YOURDEVICEMODULE is "ftdi_sio" for the DVAP or is "cdc_acm" for the DVRPTR.
After a reboot you should see the device in the "lsusb" list. If you don't see
the device listed, QnetGateway software will never be able to open it either.
You will need several packages to build the QnetGateway gateway. You will probably
already have all or most of these but it still doesn't hurt to be sure:
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install make g++ unzip git libconfig++-dev
If you are building a QnetGateway + MMDVMHost system, please use the instructions
in the MMDVM.README file. If you are building a QnetGateway for a DVAP or a
DVRPTR_V1 read on...
git clone git://github.com/n7tae/QnetGateway.git
This will create a QnetGateway directory with everything you need to build a dvap or
dvrptr ircddb gateway.
The first thing to do is change to the build directory with "cd QnetGateway" and then
type "make" to build all the QnetGateway executables. If you need DTMFS then also
execute "make g2link_test".
Next, create your qn.cfg configuration file. There are two example for you to look
at:
. qn.everything.cfg contains all parameter with lengthly comments about what
each parameter does. The definitions that are commented out are defined with
their default value.
. qn.dvap.cfg is the simplest possible configuration for a 2m DVAP. If you have
a 70cm DVAP rename the module to "b" and change the frequency.
Remeber the everything file contain detailed comments about all of the values you
can set. Just read through it and edit accordingly. In the end you will need
a configuration file called "qn.cfg".
Additional information about the configuration as well as other important and
useful features are also in the CONFIGURING file.
The gwys.txt file is the internet address and port numbers for any gateway you
would like your ircddb gateway to be able to connect to. The one delivered with
this package is special: It has only DCS reflectors, X-reflectors and DStar
reflectors and the X-reflectors are configured with the 20001 port instead of the
default 30001 prot. This will allow you to connect to these XREF reflectors without
creating any port-forwarding rules on your home router. You will also want to move
X-reflectors to port 20001 if you are going to tether you device via WiFi to a
smart-phone for internet access. Most phone companies will not let you configure
port-forwarding rules on you phone internet account. If you operate behing a
router/firewall without port forwarding in place, you will not be able to
do most callsign routing techniques discussed in CONFIGURING.txt, but you should
still be able to connect to reflectors. You will be able to route to the new
smart-group-server if you are mobile. They have solved the "mobile routing
problem"!
There are MANY OTHER gateways to which you can connect. Executing get_gwys_list.sh
will download a HUGE list of reflectors and gateways from www.va3uv.com with port
address that may need port-forwarding to your sytem. I have provided anotherscript,
'get_reflectors.sh' that will download the same list from va3uv.com, but filter it
so that it only contains DCS x-reflectors (DCSXXX), DStar reflectors (REFXXX) and
X-reflectors (XRFXXX) and it will put all x-reflectors on port 20001 so you
probably won't need any port-forwarding on your home router.
There is another script, reflist.sh, that will download REF, XRF and DCS reflectors
from another source. This is probably the preferred method to getting a gwys.txt
file.
Based on the above discussion, execute either "./reflist.sh", "./get_reflectors.sh" or
"./get_gwy_list.sh".
If you plan on using DTMFS, you can also edit proc_qnlinktest to add new
dtmfs commands.
Then install your system. you have two choices, either DVAP or DVRPTR_V1 by
typing "sudo make installdvap" or "sudo make installdvrptr", respectively.
This should get you up and running. It will take a few minutes for QnetGateway
to get fully connected to the IRCDDB network.
Finally, if you want/need DTMFS, type "sudo make installdtmfs".
The service scripts in /lib/systemd/system and everything else in /usr/local:
The executables will be in /usr/local/bin and the qn.cfg file and other data
will be in /usr/local/etc.
If you find that you need to modify the configuration file, remember that the
installed systems read the /usr/local/etc/qn.cfg file, NOT THE ONE IN YOUR
BUILD DIRECTORY. To keep them synced, it is good admin practice to modify the
qn.cfg file in your build directory and then do a "sudo make uninstall<dvap or
dvrptr>" followed by an "sudo make install<dvap or dvrptr>.
If you are having trouble connecting, use journalctl to view the log output
of each process. "sudo journalctl -u <service name> will show the log from that
service. The QnetGateway service is qngateway, QnetLink is qnlink, QnetDVAP is
qndvap and QnetDVRPTR is qndvrptr.
The beginning of each log file will report the values of all the configuration
parameters (even the ones you didn't specify in qm.cfg) and after that
you will see the verbose reports of what each service is doing. These logs are
invaluable for traking down problems with your qn.cfg file. You can see in real
time what is being added to the logs during operation appending "-f" to the
journalctl command.
You can clean up the build directory of intermediate *.o files with "make clean"
or, you can remove the intermediate *.o files and binary executables with "make
realclean". Note that "make realclean" only removes the binary files from your
build directory and not the copies you installed into /usr/local/bin with the
"sudo make install..." command.
If you want to uninstall everything return to the build directory and type either
"sudo make unistalldvap" or "sudo make uninstalldvrptr" and possibly "sudo make
uninstalldtmfs". This will shutdown the services and remove the service scripts
and everything from /usr/local.
Tom Early, n7tae (at) arrl (dot) net

Powered by TurnKey Linux.