User Tools

Site Tools



The ircDDB-Network is a amateur radio network for exchanging routing information. There are several amateur radio systems that are able to reach individual ham radio operators, due to the use of unique callsigns around the world. These systems need to be fed with the latest data where ham radio operators are reachable. For example, ICOM introduced the first radios with digital voice (D-Star) on the amateur radio market, which are capable of addressing QSO partners directly (call sign routing). The ircDDB-Network provides a solution to distribute the essential routing information across its entire network.


In our opinion, from the users point of view, the really new exciting thing about digital voice on ham radio is the ability to address QSO partners directly (call sign routing). It is a shame that ICOM's software implementation to exchange D-Star routing information doesn't work satisfactorily. The current situation makes call sign routing an annoying game of chance, due to delayed synchronisation intervals of routing information, as well as several bugs that we found in the ICOM software. There is even a lack of transparency for the user to discover routing problems. Both problems must be resolved in order to become accepted by the users. Our plan is to provide a solution for these problems.

Moreover, we like to collaborate with other developers around the world. To make this possible, we will publish our documentation and source code under open licenses. Despite the D-Star RF-protocol, the network-protocol introduced by ICOM has never been published. Our network protocol will be well documented, allowing developers to integrate the protocol into their software. We want to make it clear that operating a large network doesn't conflict with the idea of Open Source. The most prominent example is the internet, which is based on a complete open protocol suite. We want to provide a smooth path to allow D-Star to move forward without interfering with existing networks.


The ircDDB-Network

The idea is to reduce the needed data to be exchanged for a working call sign routing to a minimum. This set of data contains for D-Star one table with “Call sign + Module” and one table with “Gateway + Internet-IP-address”. The ircDDB-Network provides this data to all its clients making them able to route digital voice to the correct destination.

The exchange of data is done using the Internet Relay Chat technology (IRC). A network of distributed IRC servers can handle thousands of users without any problem.

Every gateway taking part on this network needs software being able to speak the IRC protocol with our IRC-Servers. For the US-Trust gateways we provide an IRC client. We call it the ircDDB-Add-On. For standalone systems we recommend to use the G4KLX ircDDB Gateway (Demo video:

The ircDDB-Add-On

Our Add-On software allows D-Star gateways being part of the US-Trust network while taking part on the ircDDB-Network without any interference. The Add-On ensures that the US-Trust network will not be disturbed in any way and makes only local changes on the system which is using the Add-On.

We decided to implement the IRC client in Java using RFC2812. The client is currently used to receive routing updates from the ircDDB-Network. To send routing updates, the dstarmonitor (DSM) is used on Icom based gateways and sends it's updates to a postgres server which interacts with the IRC servers. We decided to choose Java and DSM because these components are already mandatory on the US-Trust-Network and we try to add as less new software as we can.

Injected routing updates to the ircDDB-network are scanned for bad values on the server side before they are distributed on the IRC-channel to the clients. The client on the gateways will only send small updates to the local “dstar_global” database on a few fields (see documentation) if there is new routing information. It will not add any new entries which could cause “dsipsvd” (closed software daemon) to send wrong data to other trustservers. You can see this piece of software as an application interface for developers which takes care, that the other network will not be disturbed.

The client is Open Source and can be reviewed to make sure that nothing can go wrong.

Our work has been reviewed by the US-Trust-Network-Maintainers. The “ircDDB”-Add-On is accepted and may be installed on any Gateway of the US-Trust-network.

The G4KLX ircDDB Gateway

The ircDDB Team recommends to use the G4KLX software with homebrew solutions.

There is another gateway sofware from KI4LKF available in the Download section.


  • The ircDDB-Network is an intermediate step to a real open D-Star network without having the problem of a loss of connectivity. It combines the need for a stable network (US-Trust-Network) and other developments which can move D-Star forward. It should be accepted as an Add-On-application on all existing networks.
  • The ircDDB-Network provides a robust interface, which can't break the network, even if developers make something wrong. It should encourage more people to give D-Star development on the network side a try.
  • We want to get a high penetration allowing self-made D-Star gateways to communicate with many systems.
  • The ircDDB-Network is designed as a distributed network allowing it to run several servers in different countries. We want to find reliable partners to setup more servers around the globe.
  • We want to get a worldwide D-Star network with at least a functional call sign routing with a roaming time below five seconds.



  • Supports all current call sign routing enabled D-Star Networks
  • Provides the call sign routing feature to developers (might be useful for D-Star-Hotspots or DV-Dongle-Users)
  • Allows to attach gateways without US-Trust connectivity making the ircDDB-Network their default
  • Realtime roaming: Available for users between gateways and different modules
  • Dynamic IP support: Realtime update of gateways IP-address on DSL reconnect
  • Access control: Password protected logins for the gateway clients
  • Load balancing: Supports thousands of gateways/users (using multiple network servers)
  • Scalability: The network uses proven technology on distributed servers.
  • Visualisation: Provides MH-data to Visualisation Servers
  • Visualisation: Provide URCALL, RPT1, RPT2, MYCALL fields to Visualisation Servers


  • Runs on US-Trust gateways
  • Does not conflict with the US-Trust-Network
  • Uses only components which are mandatory on the US-Trust-Network
  • Will be installed as root, but will run as user “ircDDB” with user privilege
  • Easy Install Script available

Might be implemented if requested:

  • Intercept bad database entries which will cause the DNS-server not being able to start (e.g. pc_hostname = 'dg8ngn-' in “sync_mng”)
  • Cleanup the local database from expired entries
  • Securing the network by blocking access to UDP port 40000 for non ircDDB-Network-members




Digital Voice Data Flow in the D-Star Network

Please keep in mind that only the “ircDDB - standalone version” needs no user registration.

To communicate through a gateway being part of the US-Trust network both participating users need to be registered on the US-Trust network.

ircDDB - multihomed version (US-Trust)

The ircDDB - multihomed version is designed for US-Trust gateways running the ICOM G2 software. See for more information.

mandatory components:

  • ICOM software (dsgwd, dsipsvd, postgres, httpd) or G4ULF software
  • Java / DStarMonitor
  • ircDDB (multihomed version)


  • ICOM controller or DV-Adapter (G4ULF)

possible add-ons:

  • dplus
  • dextra_ng (under investigation & testing until approved)

data flow diagram (click twice for maximum zoom level):

Data flow example US-Trust

setup instructions for new installations and updates:

ircDDB - standalone version

The ircDDB - standalone version is designed for gateways which don't need or can not be connected with the US-Trust network.

The G4KLX gateway software and the G4KLX repeater software can run on localhost or on another machine within the LAN.

data flow diagram (click twice for maximum zoom level):

Data flow example G4KLX


gateway software:

  • G4KLX ircDDB Gateway

repeater software / hardware:

  • G4KLX “D-Star Repeater” (Soundcard) or G4KLX “GMSK Repeater” (USB DV Adapter) or ICOM Controller “RP2C”

Setup instructions


gateway software:

  • G4KLX ircDDB Gateway

repeater software / hardware:

  • G4KLX “D-Star Repeater” (Soundcard) or G4KLX “GMSK Repeater” (USB DV Adapter) or ICOM Controller “RP2C”

Setup instructions

Network policy

Testing network

There is a testing network from Armando, IK2XYP (ircDDB-Italia Team), available. If you want to test the ircDDB gateway software with your personal call sign instead of a repeater call sign you can use this network. The server is listening on the following machine: TCP port 9007.

Gateway Callsigns

Due to a technical limitation a user call sign can't be used as a gateway call sign. Therefore we need to take care which call signs we can register with the ircDDB network. Please help us to define simple rules for each country (press edit):

Country Syntax Regulations Online Check
Argentina FIXME
Australia VK#R$ Register of Radiocommunications Licences
Austria OE#X$
Belgium ON0$
Brazil PY#$,PP#$,PQ2$,PQ8$,PR7$,PR8$,PS7$,PS8$,PT#$,PU#$,PV8$,PW8$
Bulgaria LZ0$
Canada VE#$, VA#$ Amateur Radio Operator Certificates
Croatia 9A0D$
Czech Republic OK0$
Denmark OZ#RE$, OZ#DS$, OZ#DH$
France F#Z$ New French rules to come in October 2012 station répétitrices
Finland FIXME
Germany DB0$, DF0$, DM0$, DO0$ Vfg Nr. 34/2005 Bundesnetzagentur Amateurfunk-Rufzeichen
Greece SV#$, SW#$, SZ#$
Italy IR#$
Japan 7J#Y$, 7K#Y$, 7L#Y$, 7M#Y$, 7N#Y$, 8J#$, JA#Y$, JD1Y$, JE#Y$, JF#Y$, JG#Y$, JH#Y$, JI#Y$, JJ#Y$, JK#Y$, JL#Y$, JM#Y$, JN#Y$, JO#Y$, JP#Y$, JQ#Y$, JR#Y$, JS#Y$, 7J#Z$, 7K#Z$, 7L#Z$, 7M#Z$, 7N#Z$, JA#Z$, JD1Z$, JE#Z$, JF#Z$, JG#Z$, JH#Z$, JI#Z$, JJ#Z$, JK#Z$, JL#Z$, JM#Z$, JN#Z$, JO#Z$, JP#Z$, JQ#Z$, JR#Z$, JS#Z$
Netherlands PI1$ Onbemand frequentiegebruik Table
New Zealand ZL#$
Norway LD#$
Poland SR#$
Portugal CQ0D$, CQ1D$, CQ2D$
Romania YO#$
Slovenia S55$
Spain ED#$ Art.28 & Art.13.3
South Africa ZS#$, ZU9$
Sweden All SM ITU Prefixes allowed
Switzerland HB9$
United Kingdom GB3$, GB7$, MB6$
United States n.a. ARRL License Data Search FCC License Data Search

callsign = 4 to 6 characters, # = 1 number, $ = 1, 2 or 3 letters, n.a. = not available

Best guess ircDDB Team: cursive ← to be replaced by the community. Please edit or give feedback by email. Tnx

User Callsigns

^(([1-9][A-Z])|([A-Z][0-9])|([A-Z][A-Z][0-9]))[0-9A-Z]*[A-Z][ ]*[ A-RT-Z]$

The user callsign must have 3 to 7 characters.


Gateway Users

Tune to your next ircDDB enabled D-Star repeater and push PTT to make your call sign visible to the network. You are now reachable by call sign routing. Each time you change to another D-Star repeater or another RF module of the same D-Star repeater, you need to push PTT again. This information is saved within the network. You don't need to push PTT again.

Please make sure you're call sign and terminal is registered with the US-Trust network if you want to be reachable from US-trust based repeaters.

Gateway Operators

Despite the current existing networks the ircDDB-Network provides real access control by the use of usernames and passwords to authenticate gateways during the log-in process. We prepared a Gateway Registration section on our mainpage: Please make sure you use not a personal call sign for your gateway (see Network Policy).

If you want to test the ircDDB gateway software with your personal call sign you can use the testing network (see Network Policy).

Network Operators

There is currently no gateway available to exchange routing information between IRC based networks and other type of networks. This might change in future.





Sourcecode & Development

Check comments in the source code



  • Q: Why do we still need to be a registered user even when we do communicate between gateways taking part on the ircDDB-Network?
    A: We can't add new users to gateways running the ICOM software since the “dsipsvd”-process would send bad data to the Trust-Server of the network. So each time you will communicate from/to a gateway being part of the US-Trust-Network you need to ensure you and your QSO partner are registered on that network.
  • Q: Why can't I register on the ircDDB network with my personal call sign?
    A: We need to stay compatible with the ICOM G2 architecture. A repeater call sign can not be used as a user. See as a reference.
  • Q: How can I then login to DPlus with my gateway?
    A: DPlus connectivity only works for US trust gateways and registered users. This is for a basic authentication and security as long as nothing better is in place. However, there are methods for non-US-trust gateways. In ircDDBGateway you may enter a registered callsign for DPlus login, which is not the gateway callsign. There is a field in the DPlus configuration mask for this callsign. The gateway will log in to the network as a dongle user using that callsign.
  • Q: Why is my callsign shown in red color in ircDDB-live and the lists?
    A: Red color always means that the transmission was addressed from or to a callsign at a US trust gateway, where this callsign is not registered. It may occur in the source or destination field.
    Unfortunately the databases of the gateways are not all in sync, so you might see the callsign in red on one US trust gateway, in black on another. In that case one of the admins needs to resync the database with the trust server. A description how to do it can be found on the US trust info page.
    The registration information is supplied by the US trust gateway itself, it is not stored anywhere in the ircDDB system, we only make that information visible. On ircDDB-only gateways all callsigns and '*' will always be shown in black, there is no user registration. However, you should be registered in the US trust network to be able to use all gateways. The ircDDB gateway addon on Icom-G2 will not bypass the US trust registration.
  • Q: Why is my callsign not shown, only a group of '*' instead ?
    A: For privacy reasons you need to activate VISibility in the system once.
    Every time that you access ircDDB-live, the lastheard table or the log you may find a blue hint bar on your screen. Please klick on the link in that bar to get more information on the 'VIS-feature'.
  • Q: Why can't I use 'tactical callsigns' or any other names of my choice for starnet destinations?
    A: The ircDDB network does not allow to use callsigns which do not meet the ITU specifications.
    ircDDB does not use any user registration, there is no database for that. Basic address verification is based on pattern match against the international rules.
    'Tactical callsigns' would make an additional database for that kind of destinations necessary, which needs to be implemented to all network components. The data would have to be maintained, updated and distributed. We want to keep the administration effort as low as possible.
    The pattern “STN####” have been implemented in addition to the known international callsign specs. This may be used for internet-only destinations, which have no need for a legal callsign. Other destination addresses are not accepted by the network.
  • Q: Which STN-adresses are already in use?
    A: A list of STN-adresses can be found here:
    Please add new addresses there and help to keep it unique.
  • Q: How does the registration process for a new gateways work? How long does it take?
    A: Fill out the registration form on our website
    After submitting the registration information make sure that the page confirms the registration and does not return any error messages at the top of the page.
    Please use an email address which accepts the automatically generated emails from the registration system! Do not use an address which works with white-lists or make sure that 'register at' will be accepted!
    The registration system immediatly sends out a notification to local responsible admins and the ircDDB team. Currently we have more than 10 admins in different countries who do the approvals locally.
    Our goal is to approve a request within 24 hours. If all information are supplied correct this is done by a mouse click, in special cases it may take longer.
    We all have to do it in our free fime, every day. However, if you did not get any email within 2-3 days you should contact us.
    After the approval you will get an email with the login credentials for the gateway and the admin. The gateway callsign will also appear in the lists on the ircddb website in grey color.
    Without activation it will stay there for 60 days. After 30 days it will be marked, after 60 it will disappear. It will return on activation.
  • Q: Where can I check my ircDDB login password ?
    A: Only in the email notification from the registration server. Nowhere else!
    Ask your bank for a lost PIN, you won't get it.
    Please make sure to store the login credentials at a secure place. We do not store passwords in human readable form. The database and the login servers only keep a crypted hash.
    However, we have the chance to search copies of the notification emails in really urgent cases, but this is an effort which costs us a lot of time.
  • Q: How can I delete a gateway from the network ?
    A: Contact the admin team, you can not delete a gateway yourself. This is the same like with US trust gateways.
    Registered ircDDB gateways can not really be deleted but the admin team can make it invisible.
    We would very much prefer if the request would come from the person who registered the gateway, just to prevent that an unauthorized person asks to delete gateways from others.
    6 months after the last login to the network gateways will be set to invisable status automatically.
    An invisible gateway will become visible again as soon as it logs in to the ircDDB network next time.
projects/dstar/ircddb.txt · Last modified: 2017/03/15 23:19 by jann