You can reach us at: ham44865 (at) yahoo (dot) com
[Go to download page] [Our Dstar G2/IRCddb Gateway]
1)
Updated Dstar XRF reflector dxrfd v2.86 for BROADCASTING-Repeater-Multi-Linking.
Updated g2_link v2.87 for BROADCASTING-Repeater-Multi-Linking for Dstar XRF reflectors.
Some users asked for these BROADCASTING-Repeater-Multi-Link features in Dstar XRF reflectors.
BROADCASTING-Repeater-Multi-Link features have been added to Dstar XRF reflector,
so that you can link two or more of your local repeater bands to the same remote Dstar XRF reflector/same module.
This brings XRF reflector one step closer to REF reflector features.
Example, if your gateway is XX0XXX, you can link all or some of your Dstar repeater bands to Dstar XRF reflector/same module.
XX0XXX B ----> XRF005 A
XX0XXX C ----> XRF005 A
This kind of multi-linking is useful for Dstar repeater clubs that have multiple bands and would like to have all their bands
linked to the same reflector module.
The administrators of the Dstar XRF reflectors are responsible for upgrading their reflector, if they want these new features.
Gateways that would like to have these BROADCASTING-Repeater-Multi-Link features must upgrade to g2_link v2.87
Other gateways will not be able to do multi-Link, unless they update also.
Updated XRF reflector(dxrfd v2.83)
dxrfd v2.83 will also re-transmit the header to all connected dongle users(Dongles, DVAP dongles, ...)
so that dongle users will also be able to copy audio immediately after they connect.
Users asked for the these two new features.
--- Re-transmission of HEADER on every SYNC packet, so that repeaters that link can immediately copy the QSO
--- Authentication/Validation of users before they transmit.
Note: The above features were added to bring XRF closer to REF
Updated g2_link v2.85
This g2_link v2.85 allows you to link some or all of your local repeater (different) bands to the same reflector,
to different modules of that reflector.
With the multiple HEADER packets coming in from other programs, and filling up the log files,
to save space and time, and even bandwidth, set QSO_DETAILS=N in the g2_link.cfg
You do not need to see the activity in the g2_link.log file.
The activity will be seen in Dstar gateway log file(g2_ircddb.log)
and the Dstar repeater log(rptr.log, dvrptr.log, dvap_rptr.log, ...)
If you want to save more time and space, then set QSO_DETAILS=N in all configuration files:
g2_link.cfg, g2_ircddb.cfg and the Dstar repeater config files(rptr.cfg, dvrptr.cfg, dvap_rptr.cfg)
Updated the documentation file(README_ircDDB.txt) to include information on how to manage
the log files(using logrotate) created by the Dstar gateway g2_ircddb and its Dstar repeaters.
Thanks to Patrick for the research.
Added Dstar client (HOTSPOT) software r2g2_dcs for the DCS reflector(s).
You can use any of our Dstar repeaters with r2g2_dcs hotspot.
rptr for the GMSK adapter, dvrptr for the DV-RPTR modem, dvap_rptr for the DVAP dongle, snd_rptr for the sound card.
Major improvement on the Dstar protocol to handle Re-SYNCing on the network side.
Updated Dstar gateways g2_ircddb v3.06 and g2_ircddb_rp2c v3.06
Now any time your home network or any other network slows down or "freezes",
or even if there is network outage or any ISP connectivity problem,
our Dstar gateways(g2_ircddb, g2_ircddb_rp2c) will re-SYNC on the network side.
This takes care of all network timeouts from audio packets coming from any reflector(XRF/DCS, REF, ...)
and also Re-SYNCs with remote ICOM G2 or other gateways when RF users use callsign/zone routing.
Added option REGEN_HDR to g2_ircddb.cfg and g2_ircddb_rp2c.cfg
The STN idea breaks all ICOM and reflector rules and will not be supported any more.
Whoever came up with the STN idea, it was really bad.
Instead the XRF/DCS and x-Net technology run by our modified g2_ircddb server(MCS server) at each DCS reflector is clean, better
and does the routing in x-NET and DCS reflectors.
Added the package addon_linking_tool_with_DCS_for_ICOM_RP2C.zip
This is the add-on linking tool that does only the DCS linking/unlinking.
The other add-on linking tool addon_linking_tool_with_DCS_XRF_for_ICOM_RP2C.zip does both the DCS and XRF linking/unlinking.
There is also another add-on linking tool posted that does all types of reflectors.
All 3 add-on linking tools are for the ICOM G2 gateways that use the RP2C repeater hardware as a repeater.
All of them support DTMF tones.
The zip package addon_linking_tool_with_DCS_XRF_for_ICOM_RP2C.zip
for linking to XRF/DCS reflectors for the ICOM G2/RP2C has changed.
Changed the dtmf script g2_link_dtmf.sh to include DTMF tones 99 for requesting INFO on the status of the link.
Now it also understands DTMF tones for all remote modules A thru Z
For linking, six dtmf tones are used. The last two tones represent the remote module.
The first tone identifies the type of the reflectors: # for XRF reflectors, D for DCS reflector.
The next 3 tones identify the reflector node number.
The last two tones 01 thru 26 are translated to remote module A thru Z
Example: #02102 will link local module to reflector XRF021 B
Example: D00126 will link local module to reflector DCS001 Z
Example: 73 will unlink local module
Example: 99 will report link status of a local module
Note: You do not have to follow this format of using 6 dtmf tones for linking,
you can create your own dtmf tones shorter in length from 6 to 3 tones or even less
and make these tones do anything you want.
The readme.txt file has changed to include the new details
The Linux dtmf script proc_g2_ircddb_dtmfs.sh for our gateways(g2_ircddb) also changed to understand all modules A thru Z
The Windows version of the dtmf script procdtmf.bat (for the Windows gateways g2_ircddb) has also been updated.
Our G2 gateways (g2_ircddb) and our linking tool(g2_link) have been updated to support DCS links.
Updated Dstar repeaters: rptr v3.19, dvrptr v1.76, dvap_rptr v2.30
The new Dstar repeaters allow local RF users to use Emergency(EM), Break(BK) and EM+BK flags/settings when they make a radio call.
Also added option: INVALID_YRCALL_KEY
This new option is used as follows(example):
# To protect the repeater owners from bad STN programs out there
# and to also protect the repeater owners from RF users that abuse the STN stuff
# Reject values in YRCALL that start with STN
# If you want to allow the local RF users to subscribe to remote STN groups,
# then set it to XXX or something that is invalid like 123
INVALID_YRCALL_KEY=STN
2)
For the rptr/GMSK Dstar repeater software, we recommend these values in the config file rptr.cfg
For Satoshi gmsk adapters:
MAX_TRIES_WRITE=3
TX_DELAY=20 (higher if you get R2D2 in the first 1-2 seconds)
MAX_TRIES_WAIT_FOR_SPACE=20
DELAY_BETWEEN_RETRIES=5
PTT_THRESHOLD=3
For other gmsk adapters:
Configuration 1
MAX_TRIES_WRITE=3
TX_DELAY=400
MAX_TRIES_WAIT_FOR_SPACE=20
DELAY_BETWEEN_RETRIES=5
PTT_THRESHOLD=3
For other gmsk adapters:
Configuration 2
MAX_TRIES_WRITE=3
TX_DELAY=20 (higher if you get R2D2 in the first 1-2 seconds)
MAX_TRIES_WAIT_FOR_SPACE=70
DELAY_BETWEEN_RETRIES=5
PTT_THRESHOLD=3
If you see that your audio goes to the remote destination,
but it sounds garbled, then use this configuration
For other gmsk adapters:
Configuration 3
MAX_TRIES_WRITE=3
TX_DELAY=20 (higher if you get R2D2 in the first 1-2 seconds)
MAX_TRIES_WAIT_FOR_SPACE=20
DELAY_BETWEEN_RETRIES=20
PTT_THRESHOLD=3
3)
Added Dstar client programs for Linux and Windows(DstarHotSpotNodes r2g2).
These Dstar client programs follow the ICOM G2 protocol and connect to remote reflectors.
You can connect to either XRF/DCS reflectors or REF reflectors, but NOT at the same time, NO cross-connections are allowed.
For this reason, three different Dstar Client programs have been posted:
--- r2g2_x connects to XRF reflectors.
--- r2g2_dcs connects to DCS reflectors.
--- r2g2_p connects to REF reflectors.
This way cross connections from REF to XRF/DCS (or XRF/DCS to REF) are avoided.
You can use any of our Dstar repeaters for these HotSpotNode programs:
--- rptr (for the GMSK adapter)
--- snd_rptr (for the sound cards)
--- dvap_rptr (for the DVAP dongle)
--- dvrptr (for the DV-RPTR modems)
So, for example: The combination of programs "r2g2_x + dvrptr" builds a HotSpotNode using the DV-RPTR modem
Any of our Dstar repeaters can be used: rptr, snd_rptr, dvap_rptr, dvrptr
This way, you plug in a specific repeater and have a specific HotSpotNode for your repeater hardware/software
4)
MULTIPLE RX(receiver) repeaters and MULTIPLE TX(transmit) repeaters under one module/port(A,B,C)
We enhanced our MOD_CTRL software so that you do NOT need to use a DUPLEXER any more.
This requires 2 antennas, one for RF receive, the other for RF transmit.
You can also have one transmitter(TX) repeater with multiple receivers(RX) repeaters.
You can also designate any repeater to be either TX only or RX only or both TX and RX
For example, you can have 3 RF C modules, with one of them as TX and the others as RX
or all of them TX and RX or any combination of TX and RX.
This software works with any of our gateways, g2_ircddb, even for ICOM G2
You can use your home-brew repeater(rptr/GMSK, dvrptr/DV-RPTR, snd_rptr/Sound Card, dvap_rptr/DVAP) ,
instead of the RP2C, to work with the ICOM G2 gateway.
Send us a request for that software, specify which port(A,B,C) and which OS(Linux,Windows) you want to do this with.
5)
Released the Windows version of our sound card repeater snd_rptr v1.16 for Dstar
Both Linux and Windows versions of snd_rptr v1.16 are for ICOM G2-compatible gateways: g2_ircddb
Note: If your announcements(link,unlink,status) or the Echotest audio comes is broken, slow, or stuttering, or ...
you can correct it by configuring it correctly, read this: [Echotest and Announcement audio problems]
Note: Any program running on Windows that process audio in/out to/from the sound card,
may need to run in higher priority. So, we recommend that you try one the following start up options inside snd_rptr.bat:
/NORMAL
/HIGH
/REALTIME
/ABOVENORMAL
We suggest that you try the option /HIGH or /REALTIME if you get "slow" audio.
So, as an example, if we want to start the snd_rptr software in HIGH priority,
then the start line should be this:
start /HIGH /WAIT C:\snd_rptr\snd_rptr.exe C:\snd_rptr\ C:\snd_rptr\snd_rptr.log
of if you want to start the snd_rptr software in REALTIME priority,
then the start line should be this:
start /REALTIME /WAIT C:\snd_rptr\snd_rptr.exe C:\snd_rptr\ C:\snd_rptr\snd_rptr.log
Note: We use a batch file(BAT) to start the repeater software on Widnows. The repeater software on Windows is GUI
so instead of a BAT file, you can create a shortcut to start the repeater software.
6)
Dstar reflector dxrfd v2.75 released.
Use the new Dashboard tool: xrf_lh to see the additional modules D and E(echotest module) on the reflector dashboard
Maximum of 15 sedonds of recording time. It can be changed by the admin
Added source code for the Dashboard tool: xrf_lh.cpp
If your Dstar reflector does not listen on IP: 0.0.0.0 then change the value of CONNECT_TO inside xrf_lh.cpp and re-compile it
Updated help file: xrf_README.txt
7)
See this: [Multiple repeaters of the same band]
Our Dstar repeaters can be local or remote stations to g2_ircddb Dstar gateway.
Our Dstar repeaters can accept data from other repeaters over RF or from remote repeaters over IP.
This is used in cases where these remote repeaters do NOT have a gateway of their own.
As a matter of fact, you can have multiple repeater bands of the same MODULE.
Example: you can have 2 bands B(70cm) and 5 bands C(2m), local or remote locations.
Each g2_ircddb Dstar gateway can use thousands repeater installations as modules.
Some of these repeaters can have or NOT have Internet access.
All our "Dstar Gateways and Dstar repeaters" software(g2_ircddb, g2_ircddb_rp2c, rptr, dvap_rptr, dvrptr, snd_rptr, ...)
IDentifies the user in the MYCALL field in the Dstar stream.
All our Dstar repeater software(rptr, dvap_rptr, dvrptr, snd_rptr, ...) identifies the user over RF and over the Internet.
We comply with all Dstar rules when it comes to identifying.
Also, both RPT1 and RPT2 fields in our Dstar stream identify the gateway/repeater.
When our Dstar reflectors route the message to another gateway, that gateway receives
both the user in MYCALL field and the the name of the Gateway/repeater in RPT1 and RPT2
Official/correct implementation: g2_ircddb v3.06 Gateway for IRCddb routing network(or ICOM RP2C)
Download: g2 ircddb Dstar Gateway(Linux or Windows)
Help/install document
sample DASHBOARD
FREE STAR* site(Thanks to va3uv) for a CF/microdrive image(home-brew or RP2C) of g2_ircddb, or a CentOS ISO image of g2_ircddb, or
an automated script for installing g2_ircddb on an existing CentOS:
FREE STAR*
Two sites that describe how to install g2_ircddb on Compact flash cards(Alix,Voyage Linux,pcengines,...Debian OS mostly) and similar hardware:
Installing g2 ircddb Dstar Gateway on flash cards
Installing g2 ircddb Dstar Gateway on flash cards
Official/correct implementation: Dstar Reflector(XRF) v2.75 for all gateways(IRC or ICOM RP2C)
Our team developed/designed the Dstar XRF reflectors around 2008, there are invalid/bad copies out there, dxrfd v2.75 is the current release
Download: Dstar Reflector for all gateways(Linux or Windows)
Sample DSTAR Reflectors boards
Dstar Reflector XRF044 DASHBOARD
Dstar Reflector XRF021 DASHBOARD
Official/correct implementation: addon linking tool for both DCS linking and XRF linking for ICOM G2/RP2C gateways.
Download: DCS/XRF add-on linking tool
Official/correct implementation: Dstar Client programs/HotSpotNodes
Download: Dstar HotSpotNodes(Linux or Windows)
Official/correct implementation: Android gateway and Dstar repeater for Android mobile devices(tablets, smart phones, ...)
Download: Android g2ircddb gateway for Android mobile devices
Our implementation of the Dstar G2 Gateway is modular and simple in design to match the ICOM G2 gateway
Since the ICOM G2 Gateways are 3 parts: repeater(RP2C), gateway, and linking tools,
our implementation follows a similar design and it consists of 3 parts:
gateway --- g2_ircddb v3.06
repeater --- rptr v3.19(gmsk), dvap_rptr v2.30(DVAP), dvrptr v1.76(DV-RPTR), snd_rptr v1.16(sound card), ICOM RP2C
linking tool --- g2_link v2.83
irc database servers(our g2_ircddb gateways connect to these irc database servers):
North America: group2-irc.ircddb.net
Europe: group1-irc.ircddb.net
We have developed Callsign Servers around the world that have been installed in many countries(USA, UK, Canada, Italy, Germany, Holland, ...)
The idea is simple: Other "callsign servers" provide gateways that are with k5tit only.
Our Callsign Servers provide everything: k5it gateways + IRC gateways.
So, you can freely connect to our Callsign Servers if you want to download the FULL/COMPLETE list of gateways
for your dongle or DVAP dongle or any other program that you're using.
The host name of the computer that acts as a Callsign Server is: ve3tnk.homelinux.net
"Point" your DVTool, DVAP, .., or other client programs to download from ve3tnk.homelinux.net
Details are in the package get_list.zip
Note: If you're using g2_link as the linking tool, g2_link is special because it does not need to connect to any Callsign Server.
g2_link uses a flat file(gwys.txt) on your hard disk.
If you put inside the file gwys.txt, the hostnames of gateways
g2_link will convert the host name to an IP address, so that it does NOT have to connect to any Callsign Server.
Callsign servers return a list of gatewys with an IP address for each gateway.
Since you already have a host name for the remote gateways that you want to link to, then you can put the host names
inside the file gwys.txt, and you will never need to download anything from any Callsign Server.
But we also understand that some gateways have dynamic IP address, so in that case, you will need the list from the Callsign Server.
But 99.99% of our users link their gateways to reflectors and
reflectors have either static IP address that never changes(or rarely changes) or have a host name.
So, in that case too, connecting to a Callsign Server to download a fresh list of IP addresses, is not required.
In any case, g2_link does NOT need to connect to any Callsign Server at all.
Just put the IP addresses or the hostnames of all the reflectors, that you like to connect to, inside the file gwys.txt
and g2_link will be happy with that.
We understand that other gateway programs out there, have copied all our source code from g2_link.cpp and put that
into their gateway programs, so that their gateway programs can do the same thing as our g2_link software does.
But that is bad design, why ?
Because reflectors are NOT part of the Dstar protocol and linking to reflectors should not be done from inside the gateway.
It is also a bad design, because a gateway program should ONLY have 2 distinct parts to it, which are as follows:
--- Talking to other gateways because local RF user is making routing calls
--- Talking to its local repeater bands
That is exactly what the ICOM's design is all about
That is exactly what our Dstar gateway g2_ircddb has implemented so that we do not break the ICOM's rules
Actually the other gateways have copied all of our source code from our g2_ircddb.cpp gateway and g2_link.cpp to create their gateway programs
They have even copied our Dstar XRF reflector technology too.
They have even copied our gateway that uses the RP2C repeater hardware(g2_ircddb_rp2c)
Every single feature we add to our gateways, within a week, will be copied by these people out there
so they can have it in their gateways too.
A gateway should have a small "footprint". Our gateway design is a simple file(g2_ircddb or g2_ircddb_rp2c)
We designed a very modular gateway that is clean and simple and it only consists of a single source code file(g2_ircddb.cpp)
Creating a gateway that is made up of 1000 different files, that is a nightmare and impossible to maintain.
We also have software that works with the gateway and allows the gateway to have multiple modules of the same repeater band
Example:
The local gateway can have multiple B modules(440) and multiple C modules(2m) ... and so on
So, we can have a gateway with 2 B modules and 3 C modules and 5 A modules, all togther 10 modules, under the same gateway callsign
Or we can have one gateway with 4 B modules and only one C module
... and so one... the combinations are endless
The local modules(bands) of the gateway can also be located at different locations from the gateway computer.
You can have a local repeater band B and a remote(outside your home network) repeater band B, and our gateways will treat
both bands B as one band B.
This way, you can have ONLY one gateway with multiple repeaters(even on the same band module) local or remote repeaters all around
a large geographical space
Also in this way, you do not have to buy expensive microwave link equipment.
For the GMSK modem/adapter on Windows controlled by our rptr/GMSK Dstar rptr repeater software,
we include the LIBUSB dll file: libusb0.dll in our rptr_vxxx_Windows.zip
The file libusb0.dll was copied from the package libusb-win32-bin-1.2.5.0.zip which
we downloaded from: http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.5.0/
Inside that package, you will find the file libusb0_x86.dll, which we rename it libusb0.dll
and include it in our rptr_vxxx_Windows.zip
The file libusb0.dll that is included in our rptr_vxxx_Windows.zip must be placed
in the same directory where our Dstar repeater rptr vxxx will run from.
The web site http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases
is also recommended by Satoshi's web site: http://www.d-star.asia/libusb.html.en
It is also the site http://sourceforge.net/apps/trac/libusb-win32/wiki
that libusb drivers are submitted for Microsoft WHQL testing.
Do NOT install any other libusb packages or libusb drivers.
However, if you're using some gmsk adapter/modem that is not Satoshi,
then the libusb0.dll that is included in our rptr_vxxx_Windows.zip
might not recognize/detect your modem/adapter, so in that case
use only rptr_win_gui.exe from our rptr_vxxx_Windows.zip
and for LIBUSB driver(dll), use libusb0.dll that comes with your modem/adapter.
On linux, "detection" issues do not occur, because all gmsk adapters when installed on Linux
follow the LIBUSB standard driver which you install with "yum install ..." or "apt-get install ...",
but if you get the error: "Can not detect ...", then use the libusb0.dll that was created for your adapter
and do NOT use the libusb0.dll that is included inside our rptr_vxxx_Windows.zip
Some remote irc database servers take as much as 2 minutes to load their databases
so not much routing can be done if the remote irc database server is still loading.
What this means is that when you start/restart the gateway, the remote irc database server
may take as much as 2 minutes to be ready to respond to your requests for routing data.
The remote irc database server is finally ready when its irc status is 7
If the status of the remote irc database server is not 7, then requests for routing data
are not really handled by the remote irc database server, which means routing can not be done
The same thing happens when you lose the internet connection to the remote irc database server
Again, the remote irc database server goes into invalid status and will not respond to your
requests for routing data, until its status goes back up at 7
The g2_ircddb gateway will print the status of the remote irc database server
when it requests routing data, so the gateway owner will know exactly what is going on.
Also, the remote irc database server may not accept position information(last-heard)
from your local RF users, if the system clock is off.
For North America, a good set of NTP time servers would be this:
server 0.north-america.pool.ntp.org burst iburst
server 1.north-america.pool.ntp.org burst iburst
server 2.north-america.pool.ntp.org burst iburst
server 3.north-america.pool.ntp.org burst iburst
So, enter the above 4 lines in your ntp.conf file(For Linux: /etc/ntp.conf )
(replace the old lines)
Unless you have a Linux system that has a GPS time server, use the above 4 lines
Before ntpd starts for the very first time, it is a good idea, to execute:
ntpd -q
Note: The above command executes the ntpd program ONLY to set the correct system time
and it immediately exists after that. Wait until the above comand finishes executing and then
start the ntpd service with: service ntpd start
On some Linux systems, the command: "ntpd -q" is not recognized.
On such Linux systems, you will use the "obsolete" method, which is executing the command: ntpdate
to set the to set the correct system time, and then invoke: service ntpd start
Linux documentation for the "ntpd -q" command/option says this:
-q Exit the ntpd just after the first time the clock is set.
This behavior mimics that of the ntpdate program, which is to be retired.
Even with NTP used, we've seen the system clock drifting on some systems
and thereby your data are not posted on the LIVE site, because the LIVE site
works with timely data and will reject data from systems with "bad" system clock.
We've seen cases where the system date is just 10 seconds
into the future and the LIVE web site rejects the LAST-HEARD data.
If you run VMware or not, read http://wiki.centos.org/TipsAndTricks/VMWare_Server
especially the article http://kb.vmware.com/kb/1006427
Do not run Web servers.
Also anti-virus programs on Windows take too long to examine each packet
for possible viruses, so they steal CPU time from the gateway and the repeater.
VISIBILITY of your PRIVATE data on the INTERNET
Some users asked why they do NOT see their information on the LIVE web site
when they key up the local repeater
To see your data on the LIVE web site when you press PTT,
you must enable the MESSAGE text on your Dstar HT
We will keep this functionality for users that do NOT want to post
their private data on the LIVE web site.
This way, you do NOT have to tinker or mess with with that VIS_ON__ or VIS_OFF_ stuff
Another reason why your data may not show on the LIVE web site
is because your system clock is "off"
Have the NTP Linux service running
(or correct your Windows PC date, if using a Windows PC)
We've seen cases where the system date is just 10 seconds
into the future and the LIVE web site rejects the LAST-HEARD data.
So keep the correct date and time on your computer
where you run the Gateway.
For users that want to use "PACKET CAPTURE" to analyze/examine data
You have 3 choices:
Choice 1: Capture data at the repeater:
If the repeater is NOT the ICOM RP2C, you must capture all source repeater ports(A,B,C)
If the repeater is the ICOM RP2C, capture at the source repeater port 20000 ONLY
In both cases, set your capture software(tcpdump,windump,...) to capture data at source UDP port
Choice 2: Capture data at the local Gateway INTERNAL port:
Assuming that G2_INTERNAL_PORT=19000 in g2_ircddb.cfg, capture data at port 19000
In this case, set your capture software(tcpdump,windump,...) to capture data at dest UDP port 19000
Choice 3: Capture data as it goes from g2_ircddb gateway to g2_link
Assuming that TO_G2_LINK_PORT=18997 in g2_ircddb.cfg, capture data at port 18997
In this case, set your capture software(tcpdump,windump,...) to capture data at dest UDP port 18997
Tools for the gateway
dvtool_send sends a DVTool audio file and text to your G2 gateway external IP and port
dvtool_send_text sends only text to your G2 gateway external IP and port
(Both audio and/or text will eventually end up on your local repeater and play over local RF)
dvtool_send and dvtool_send_text are used mostly to identify your repeater/gateway as required by
the Amateur authorities governing the use of repeaters
In the US, FCC is the authority that governs the use of Amateur radio.
g2link_test sends a LINK or UNLINK or any other YRCALL command
to your G2 gateway internal IP and port
g2link_test emulates "actions" taken by the user's icom radio
g2link_test_audio sends audio from your repeater to external systems
The above tools are used mostly in scripts or for testing
Example for dvtool_send
(KJ4NHF is our gateway, do not use that)
Assuming that you have these in g2_ircddb.cfg
G2_EXTERNAL_IP=0.0.0.0
G2_EXTERNAL_PORT=40000
Send a dvtool audio file to your gateway
./dvtool_send 127.0.0.1 40000 some_dvtool_file "TEXT" KJ4NHF B 18
Examples for g2link_test
(KJ4NHF is our gateway, do not use that)
(KI4LKF is a personal callsign in our group, do NOT use that)
Assuming that you have these in g2_ircddb.cfg
G2_INTERNAL_IP=0.0.0.0
G2_INTERNAL_PORT=19000
_ is a SPACE
The last parameter on each line is the value of YRCALL.
You can use these YRCALL commands in your radio or you can send these commands with DTMF tones,
by adding the logic to your DTMF script(proc_g2_ircddb_dtmfs.sh or procdtmf.bat)
Store/record B_voicemail.dat
./g2link_test 127.0.0.1 19000 "TEXT" KJ4NHF B 18 1 KI4LKF "_ _ _ _ _ _ S0"
Recall/playback B_voicemail.dat
./g2link_test 127.0.0.1 19000 "TEXT" KJ4NHF B 18 1 KI4LKF "_ _ _ _ _ _ R0"
Clear/delete B_voicemail.dat
./g2link_test 127.0.0.1 19000 "TEXT" KJ4NHF B 18 1 KI4LKF "_ _ _ _ _ _ C0"
Make a CQCQCQ call for testing
./g2link_test 127.0.0.1 19000 "TEXT" KJ4NHF B 18 1 KI4LKF CQCQCQ
Link your local repeater module B to reflector XRF005 module A
./g2link_test 127.0.0.1 19000 "TEXT" KJ4NHF B 18 1 KI4LKF XRF005AL
Unlink your local repeater module B
./g2link_test 127.0.0.1 19000 "TEXT" KJ4NHF B 18 1 KI4LKF "_ _ _ _ _ _ _ U"
What is the link status on your local repeater module B ?
./g2link_test 127.0.0.1 19000 "TEXT" KJ4NHF B 18 1 KI4LKF "_ _ _ _ _ _ _ I"
ECHOTEST testing audio
./g2link_test 127.0.0.1 19000 "TEXT" KJ4NHF B 18 1 KI4LKF "_ _ _ _ _ _ _ E"
Execute script exec_1.sh(Linux) or exec_1.bat(Windows)
./g2link_test 127.0.0.1 19000 "TEXT" KJ4NHF B 18 1 KI4LKF "_ _ _ _ _ _ _ 1X"
Disable INBOUND connections from HotSpotNodes, dongles, ...
./g2link_test 127.0.0.1 19000 "TEXT" KJ4NHF B 18 1 KI4LKF "_ _ _ _ _ _ _ D0"
Enable INBOUND connections from HotSpotNodes, dongles, ...
./g2link_test 127.0.0.1 19000 "TEXT" KJ4NHF B 18 1 KI4LKF "_ _ _ _ _ _ _ D1"
The software is very small and compact(one small source code file: g2_ircddb.cpp),
written in C, but compiled with the g++(C++) compiler
to catch any programming errors and for correct type checking.
There are versions for Linux and Windows computers.
For Windows, the software is ready to execute
For Linux, a script is supplied that builds the executable easily
For each version(Linux or Windows), there are 2 different releases:
One release is for home-brew repeaters(rptr/GMSK, dvap_rptr/DVAP, dvrptr/DV-RPTR modem)
and another release is for repeaters that use the ICOM RP2C repeater hardware box.
If you want to run the g2_ircddb Gateway on ICOM RP2C repeater hardware then
download the ZIP package that has the keyword "rp2c" in the ZIP package name
g2_ircddb supports the following commands in YRCALL
Note: In the commands that folow, _ is a SPACE.
For Echotest/playback: This command is handled by g2_ircddb
YRCALL=_ _ _ _ _ _ _E
For Voice Mail: This command is handled by g2_ircddb
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. The dvtool 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
For inquiring the status of the link: This command is handled by the g2_link software.
YRCALL=_ _ _ _ _ _ _I
For unlinking: This command is handled by the g2_link software.
YRCALL=_ _ _ _ _ _ _U
For linking: The link command is handled by the g2_link software.
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
For executing scripts(Linux .sh or Windows .BAT):
This command is handled by the g2_link software.
YRCALL=_ _ _ _ _ _ nX
where n can be from 0-9 or A-Z
Example: YRCALL=_ _ _ _ _ _ 1X
Then the script exec_1.sh(Linux) or exec_1.BAT(Windows) will be executed
For disabling and enabling INBOUND HotSpot or Dongle connects:
This command is handled by the g2_link software.
To Disable: YRCALL=_ _ _ _ _ _ D0
To Enable: YRCALL=_ _ _ _ _ _ D1
Note: For routing commands, go here: [G2 routing]
VOICE ANNOUNCEMENTS
The latest release includes VOICE and TEXT announcements
There are 2 choices when announcing:
VOICE and TEXT announcements are enabled if the option ANNOUNCE=Y is set in the g2_link.cfg file
TEXT only announcements are enabled if the option RPTR_ACK=Y is set in the g2_link.cfg file
As an added benefit, when RPTR_ACK=Y is set, you receive a TEXT message when keying up
the local repeater
We suggest that you enable one or the other option, either ANNOUNCE=Y or RPTR_ACK=Y
Example:
ANNOUNCE=Y
RPTR_ACK=N
or
ANNOUNCE=N
RPTR_ACK=Y
Enabling both options just does not make much sense anyway.
Remember that there are 2 types of ACK's
One is generated by the repeater software, and another is generated by g2_link
So, enable ONLY one, not both
So, if you set RPTR_ACK=Y in g2_link.cfg, then set RPTR_ACK=N in the repeater
and if you set RPTR_ACK=N in g2_link.cfg, then set RPTR_ACK=Y in the repeater
When the announcements play back over RF, or when the Echotest audio plays back over RF,
if the audio sounds broken up, or comes in slow, or stuttering, do this:
For Echotest:
Change PLAY_DELAY option in g2_ircddb.cfg to a smaller number than 20
For announcements(Link, Unlink, ...):
Change DELAY_BETWEEN option in g2_link.cfg to a smaller number than 20
Note: On Windows PC's, PLAY_DELAY and DELAY_BETWEEN values are set as low as 15
because Windows OS switches slower between programs/tasks
On Linux boxes, PLAY_DELAY and DELAY_BETWEEN values can be set to 18, 19 or 20
There is also an option to set how long to wait before starting the playback, or the announcements
We use these options to wait a while so that we give time to the repeater to initialize itself
For example:
The EchoTest playback comes from the g2_ircddb. So g2_ircddb should give some time to the repeater
to let the repeater initialize itself properly before sending playback audio to it
This option is controlled by PLAY_WAIT in g2_ircddb.cfg
So If we set PLAY_WAIT=2 that means that g2_ircddb will wait 2 seconds before sending the recorded audio
to the repeater
Similar option is DELAY_BEFORE in g2_link.cfg
For example, if DELAY_BEFORE=2, that means that g2_link will wait 2 seconds,
to let the repeater initialize itself properly before sending an announcement to it
This option DELAY_BEFORE is also used by g2_link when it wants to send back to the repeater an ACK
Dstar routing
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
Notes:
ircddb Gateway software is a copy of our OpenG2 Gateway software with a small difference:
---> All data lookup requests are sent to the remote IRC database server,
instead of the local Postgres dstar_global database server.
©Copyright 1999-2008 - SourceForge, Inc., All Rights Reserved