/* * Copyright (C) 2010, 2011, 2012 by Scott Lawson KI4LKF * addition Copyright (C) 2018 by Thomas A. Early N7TAE * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ I have substantially modified (and hopefully simplified) the configuration of this software, now, modules QnetGateway, QnetLink, QnetDVAP and QnetDVRPTR all use a single configuration file. Further, and this is the exciting part, NEARLY ALL of the parameters these modules need have a useful default value. If the default value is acceptible to you (and it probably will be) then you only need to specify what you need to change. This means that for most users, you will only need to specify a few parameters. For example, if you want to set up a 70cm dvap, your working configuration file might be: ------------------------------------------------------------------- # my configuration, using rr.openquad.net with my DVAP Dongle # on startup link module b to REF020C ircddb = { login = "XX0XXX" } module = { b = { type = "dvap" frequency = 445.474 serial_number = "AP123456" } } link = { link_at_start = "CREF020A" admin = [ "XX0XXX"] } ------------------------------------------------------------------- Of course, you can add other parameters, such as latitude and longitude, or a URL that will show up on the "User Gateways" page of www.openquad.net. This software is highly flexible, so you can have different modules running on different computers and these hidden configuration parameters to allow that are there, waiting to be defined. However, most hams won't have to bother with them! Some other features are discussed below and are pretty much directly quoted from KI4LKF original documentation. Tom Early, n7tae (at) arrl (dot) net G2_ircDDB adapted from the OpenG2 DESCRIPTION ================= QnetGateway is a Dstar G2 gateway for the Dstar network with ircDDB routing and USroot routing. It runs on Linux(as a Linux service). ircddb originated from the OpenG2 with only one change. Instead of using the local Postgres database server, we use the remote IRC database server.(group2 or group1) So, the difference between OpenG2 and ircddb is 0.01% This new software QnetGateway has been approved for use on the ircDDB network. IRC Gateways such as g2_ircdb (other IRC gateways copied from our OpenG2) connect to group2 server(USA/Canada) or group1 server(Europe). What are these group1, group2 servers? Group1 and group2 servers are really the combination of 2 programs running together: These are: ---- An IRC (Internet Relay Chat) program, in this case it is the inspIRCd program ---- the LDAP (Light Directory Access Protocol) program So, ircDDB database servers are NOTHING new, they were designed by groups of people 20-30 years ago, before even the ICOM Dstar came out. The German IRC team, copied the above programs (IRC, LDAP) from those groups, and they called it group1 and group2. The reason for that was that an IRC(Internet Relay Chat) server, sends data immediately, while the ICOM dstar network sends data 5 minutes later after a user keyed up a Dstar repeater. So, IRC is faster, but it overloads your home-network. Using a PERSONAL callsign to set up an ircDBB gateway ===================================================== In qn.cfg, set OWNER equal to your personal callsign. In QnetLink.cfg, set OWNER equal to your personal callsign. In your repeater config file, set OWNER equal to your personal callsign. Using a REPEATER callsign to set up an ircDBB gateway ===================================================== In QnetGateway.cfg, set OWNER equal to a REPEATER callsign (that you received from the ham authority of your Country). In QnetLink.cfg, set OWNER equal to a REPEATER callsign (that you received from the ham authority of your Country) In your repeater config file, set OWNER equal to a REPEATER callsign (that you received from the ham authority of your Country). However, since the IRC database servers(group2 in Canada/USA, group1 in Europe) do NOT allow personal callsigns to be used as gateways, then you may be asking what is the point? Here is the logic: In some Countries, it is very difficult to receive a GATEWAY (club/group) callsign, sometimes it takes years. In cases such as these, hams only have their own personal callsign to use. So, how do we get around the problem when the IRC servers group1, group2 require a GATEWAY callsign, but the user only has a PERSONAL callsign? Some groups of hams got together and installed their own IRC database server. An IRC database server (like group1, group2) is really these 2 basic programs: ---- inspIRCd server software which is an IRC server (Internet Relay Chat) which was designed in 1988. One such IRC program is inspIRCd which was chosen by the German IRC team for use in their group1, group2 installations. --- LDAP server software, which is the Light Directory Access Protocol server, that was written in 1993. These 2 programs inspIRCd + LDAP make up the the IRC database servers as we know them today and were installed together by the IRC team on group1, group2 installations. That is all there is to it. When LDAP runs, it checks the Gateway password as listed in QnetGateway.cfg: IRC_PASS=... When LDAP does NOT run, then the IRC_PASS is NOT checked. So, some groups of hams, have installed the inspIRCd server, without installing the LDAP server. In such an installation, then the IRC_PASS is NOT checked, so you can use your personal callsign. g2_ircDDB supports the following commands in YRCALL Note: In the commands that folow, _ is a SPACE. 1) For Echotest/playback. YRCALL=_ _ _ _ _ _ _E 2) For Voice Mail: YRCALL=_ _ _ _ _ _ S0 The above command will Store/create voice mail in the dvtool file x_voicemail.dat. YRCALL=_ _ _ _ _ _ R0 The above command will Recall/playback voice mail from the dvtool file x_voicemail.dat. YRCALL=_ _ _ _ _ _ C0 The above command will Clear/delete voice mail. File x_voicemail.dat will be deleted. In all cases, the letter x in the file name x_voicemail is the module A,B or C. 3) For inquiring the status of the link: YRCALL=_ _ _ _ _ _ _I 4) For unlinking: YRCALL=_ _ _ _ _ _ _U 5) For linking: YRCALL=XXNYYYML Where XXNYYY is a friendly gateway, M is the gateways's module and L is the LINK command. YRCALL=XRFNNNML Where XRFNNN is a friendly reflector, M is the reflector's module and L is the LINK command. Note about linking: After linking succeeds, set YRCALL=CQCQCQ because your audio will go to the remote reflector ONLY if YRCALL=CQCQCQ. 6) For executing scripts: YRCALL=_ _ _ _ _ _ nX where n can be from 0-9 or A-Z. Example: YRCALL=_ _ _ _ _ _1X Then the script exec_1.sh will be executed. Two scripts, exec_R.sh and exec_H.sh are included to reboot and halt your system, respectively. Also note that rpt1 is passed to these scripts\ so you can use this as an input parameter for your scripts. Only admins can execute scripts, so set QnetLink.admin to your callsign 7) Enabling and disabling INCOMING HotSpotNode connections: To Enable: YRCALL=_ _ _ _ _ _ D1 To Disable: YRCALL=_ _ _ _ _ _ D0 Required software to run the QnetGateway gateway correctly: --- QnetGateway: The G2 audio gateway. --- QnetLink: This communicates with QnetGateway to link the local G2 gateway to reflectors. Note: QnetLink is NOT required if you only make routing calls or talk locally on the repeater. --- rptr: This is our dstar repeater software that uses a GMSK adapter/modem. Instead of rptr, you can use our QnetDVAP dstar repeater software which uses a DVAP device. Intead of rptr, you can use our QnetDVRPTR dstar repeater software which uses the DV-RPTR modem(dg1ht). ROUTING methods =============== Some Dstar routing examples follow. Please do not use the same data because KJ4NHF is one of our own Dstar repeaters, and KI4LKF is a personal callsign in our group. Example of ZONE routing: Lets say that your repeater is KJ4NHF, and you are currently on your local repeater module B, your callsign is KI4LKF and you want to reach remote gateway XXNYYY module C In this case, your radio should be programmed like this: MYCALL=KI4LKF YRCALL=/XXNYYYC RPT1=KJ4NHF B RPT2=KJ4NHF G Example of CALLSIGN routing: Lets say that your repeater is KJ4NHF, and you are currently on your local repeater module B, your callsign is KI4LKF and you want to talk to user XX0XXX In this case, your radio should be programmed like this: MYCALL=KI4LKF YRCALL=XX0XXX RPT1=KJ4NHF B RPT2=KJ4NHF G Example of Cross-Band routing: Lets say that your repeater is KJ4NHF, and you are currently on your local repeater module B, your callsign is KI4LKF and you want to talk from your local module B to your local module C In this case, your radio should be programmed like this: MYCALL=KI4LKF YRCALL=CQCQCQ RPT1=KJ4NHF B RPT2=KJ4NHF C DTMF decoding and processing ============================= Prepare the software to decode and process DTMF tones ----------------------------------------------------- Edit the Shell script proc_qnlinktest.sh Correct the value for G2 to be the local G2 gateway callsign(same value in qn.cfg ----> OWNER) Edit G2_INT_IP as follows: If your QnetGateway.cfg, says "G2_INTERNAL_IP=0.0.0.0" then set G2_INT_IP=127.0.0.1. If your QnetGateway, says G2_INTERNAL_IP= then set G2_INT_IP equal to the exact value of G2_INTERNAL_IP. Edit G2_INT_PORT to be equal to G2_INTERNAL_PORT in QnetGateway.cfg. Note: When local RF user has entered dtmf tones on the Dstar HT and then PTT is released, QnetGateway will print the whole sequence in the QnetGateway.log just before it creates the dtmf file under /tmp. How to enter DTMF tones correctly on your Dstar HT -------------------------------------------------- If you want to have perfect DTMF decoding/processing in QnetGateway, follow these suggestions: 1) Hold down each dtmf key for at least 150 milliseconds. 2) Leave at least 250 milliseconds of "silence", when you go from one dtmf key to the next dtmf key. If you use a DTMF autodialer on your Dstar radio, you can program the above numbers easily into the ICOM's radio "auto-dialer". Note: MAXIMUM dtmf sequence is up to 32 dtmf tones. What dtmf tones are being decoded and processed ----------------------------------------------- To link to an XRF reflector: Example: B02102 That says: link to XRF021 module B. So, we use the # dtmf key to mean that we're interested in linking to an XRF reflector. The last two digits are the remote module 01 thru 05 (which is translated to A thru E). To link to a DCS reflector: Example: D00126 That says: link to DCS001 module Z. So, we use the D dtmf key to mean that we're interested in linking to a DCS reflector. The last two digits are the remote module 01 thru 26 (which is translated to A thru Z). To link to REF: Example: *01601 That says: link to REF016 module A. So, we use the * dtmf key to mean that we're interested in linking to a REF reflector. The last two digits are the remote module 01 thru 05 (which is translated to A thru E). To unlink (from any reflector xrf or ref): # To get the "link status": 0 or 00 Note: You can extend the shell script to do more things. like force your repeater to ID itself. Any YRCALL command that can be executed by g2link_test, can be added to the shell script. Basically, the Linux shell script proc_QnetGateway_dtmfs.sh converts the decoded dtmf tones into YRCALL commands using g2link_test program. =========== QnetLink is a small program that is used to link a local RF repeater band to a remote reflector. QnetLink software is used by our QnetGateway (an IRCddb gateway) and by our g2_ccs (a CCS gateway). Before we begin, there are some dat files included in the QnetLink ZIP package. These dat files are: already_linked.dat already_unlinked.dat failed_linked.dat linked.dat unlinked.dat id.dat All of the above dat files are dvtool format files and they are used when certain events take place. For example, when the link between your gateway and a reflector is established, then the file "linked.dat" will be played over RF, so anyone listening on your repeater, will hear the announcement that the link has been established. You do not have to change these files, unless you want to have your own personal voice played over RF. These dat files were created using a computer and they are NOT anyone's voice. The only dat file most hams will need to change is id.dat. The file id.dat contains the audio "UNLINKED" and nothing else. When the gateway is not linked and the RF user sets YRCALL=_______I to request the status of the link, the file id.dat will be played back over RF. But you should create your own id.dat file that should identify your own repeater with extra information if you like. For example, you could create your own dvtool audio file that contains the audio: "This is repeater ...". A simple way to create your own recorded "repeater identification file" id.dat is to use your Dstar HT and set YRCALL command: YRCALL=______S0 and key up your repeater. Start talking, and the gateway will record your audio into the file x_voicemail.dat where x is one of A.B or C. Now copy that file: sudo cp -f /tmp/C_voicemail.dat /usr/local/etc/it.dat You may be thinking why did we put all this source code inside QnetLink instead of putting it all inside the Gateway software QnetGateway (or g2_ccs CCS gateway software). Because it is NOT a good design to burden the G2 gateway with code that is not DSTAR protocol and reflectors are NOT part of Dstar and they are not Dstar protocol. The only code that should be in a gateway, is G2 protocol code. This way we keep the gateway (QnetGateway) clean of any unneccesary source code logic and containing only pure G2/D-Star logic. QnetDVAP The serial number required in the .cfg file is obtained from the label that can be seen on the DVAP circuit board. In most cases set the power to maximum level. QnetDVRPTR The serial number required in the qn.cfg file can most easily be obtained by examining the /var/log/QnetDVRPTR.log file once the board has been powered up by the BBB or RasPi. Once you know the board serial number, edit /usr/local/etc/g2.cfg. Please note that once installed, you need to edit the configuration files in /usr/local/etc, not where you build the software. You need to be root to edit files in /usr/local/etc. After editing /usr/local/etc/g2.cfg file you can restart the effected program with "sudo service QnetDVRPTR restart". Or you can alway just reboot with "sudo reboot". Rig specific parameters are in "module.x.rf_rx_level", "module.x.inverse.rx" and "module.x.inverse.tx". You need to play with these to work best with your rig. With my Kenwood TM-V71, I use the default values. You can first start with inverse.rx, trying true or false. Use the echo command on your radio and look in the logs to see if you are getting into the dvprtr. Remember to restart the QnetDVRPTR service anytime you modify /usr/local/etc/g2.cfg. Once you are able to get into the QnetDVRPTR, then you can work out the inverse.tx paramter. Once you hear anything with in the echo mode, move rf_rx_level up or down to get the best audio. Once you have a working system, it's a good idea to back up you qn.cfg files.