NE-FL D-STAR System

The Journal of the North East Florida D-Star Repeater Network

Archive for June 13th, 2010

Daytona D-Star Gateway is OPERATIONAL..!!

Jun 13

Posted by mikelee in D-Star Repeaters | No Comments

Thanks to the efforts of Charlie (AA5QJ) and Robin (AA4RC), the new Daytona Beach D-Star Gateway is now operational and performing well. We started the installation of the computer, router and ClearWire wireless modem at about 14:00 today and finished at about 16:15.

Charlie and I worked most of yesterday afternoon, starting with learning how to install the CentOS operating system, as well as the Gateway software and updates. After which  Charlie did the actual install on the  hardware destined for Daytona Beach. In all, it took about 4 hours yesterday.

Today’s installation of the gateway at the Halifax Hospital was a relative breeze, compared to the back-breaking work “The Team” did last week.

We’ll let our neighbors in Daytona “play” with the gateway for a few days before we start linking it full-time to the NEFL D-Star Network.

Have fun..!!

D-Star Gateway Internet Requirements

Jun 13

Posted by mikelee in D-Star Repeaters | 3 Comments

A number of you have asked what the internet bandwidth requirements are for typical D-Star Gateway systems – and you’ve found that sometimes I gave a rather vague answer. It’s not because I don’t want anybody to know (quite the contrary), but because “it depends” (on a lot of factors) is truly the right answer.. LOL..!!

For example, if the Gateway is linked to another repeater with no other sources of input/output, it could be as low as 30-50Kbps. But if you throw in 3-5 DV Dongles and/or DVAP’s, you could take that UPLINK traffic to well beyond 100Kbps (since the Gateway has to transmit to the remote repeater AND to each of the DV Dongles/DVAP’s simultaneously). This is why we’ve elected to have our own REFLECTOR(s), so that multiple repeaters and DV Dongles/DVAPS would connect to the reflector and not the repeater’s own gateway. This SUBSTANTIALLY reduces the need for a very-high-speed UPLINK on the gateway and allows us to use technologies like DSL or equivalent.

Aside from the Internet bandwidth, D-Star gateways also require the exclusive use of certain “ports” on TCP and UDP. These ports allow for “connections” to occur – some ports are for signaling and handshake, while other ports are for the actual uplink and downlink audio (digitized, of course). Herein lies the problem in most Gateway setups – “opening” the ports on the respective router(s) so that the Gateway has EXCLUSIVE use. We call that process “Port Forwarding”, something that IT Managers detest doing due to potential security breaches. The process is quite easy, if you know what you’re doing – but I suppose that’s the case with everything in life – the right tools and the right knowledge at the right time is always the right combination….

The screen shot below shows the different ports that need to be forward, or “opened” on routers in order to make D-Star Gateways fully functional:

When Gateway administrators connect a new gateway machine to the internet, one of the first things they do is to run a script created by Robin (AA4RC) which tests the “open-ness” of the above ports. The script (run in Linux, so it is Command-Line) is called IPPortTestClient.bin and it’s results are shown below – in this case, the test is a success, which indicates:

  • the gateway machine is connected to the internet (interface cable is connected)
  • the firewall on the gateway machine is either disabled, or OPEN for the required ports
  • the router is connected to the internet (DSL, other)
  • the router has the required OPEN ports and that the required ports are forwarded to the gateway machine (exclusive use)

    Normally, configuring the router and testing for Port Forwarding is the most frustrating part of setting-up a D-Star Gateway. Once you learn it, it’s a piece of cake – so if you’re doing it for the first time and having difficulty, ASK FOR HELP. We are starting to build a cadre of volunteers who will be trained to set-up, maintain and troubleshoot various problems with the repeaters. Let us know if you’d like to be part of that team (if you haven’t already).

    Dplus Report – A God-Send to Net Control

    Jun 13

    Posted by mikelee in NET Operations | No Comments

    Another great Gateway utility from Ken Attkinson in Birmingham, Alabama…!! We will be installing dplusreport in the very near future and enabling  Net Control Stations to use this feature. Stay tuned for more details when installation and enablement are complete.
    ‘dplusreport’ runs on the D•STAR gateway and provides a formatted display of information derived from the dplus.log file on the system.  This is designed as a tool for a Net Control Station (NCS) that is running a D•STAR net – either locally or with linked systems.  The first major portion of the display includes information regarding:
    • Current (near real time) status of the links established to any or all of the D•STAR modules on the system.  Indication is provided as to the call sign and module of the far end.
    • Current (near real time) status of any direct dongle connections to the system is provided.  This includes only dongles directly linked to this particular D•STAR system.
    The second major portion of the display provides a sorted list of the repeaters which are participating in the net.  If any user keys up and enters the system through a remote system, the repeater and list of users are included in the display.
    The repeater and user display can be ‘aged’ which is useful for a long running net (e.g. a real weather event).  If the user call sign is displayed in ‘white’ then they have keyed within the previous 30 minutes.  If it is ‘yellow’, the last key•up was 31 to 45 minutes ago.  If the call is in ‘red’ then it has been 46 to 60 minutes since the last key•up by that station.   Once it has been over 60 minutes, then the call sign is removed from the display.  The idea is that if the call turns yellow or red, the NCS can call the station to determine if they are still monitoring the net or whether they have left the net.
    The third major portion of the display formats a log entry for each station key•up.  The time is displayed and the four calls (MyCall, RPT1, RPT2, and URCall).   Also, the 20 user message is displayed as the Name and QTH are frequently indicated in that message.   There are some basic edits done on the user programming and errors are indicated if an obvious problem exists in the four call signs (e.g. URCALL is set to something illogical).
    In the sorted list of repeaters and user call signs, with each key-up, the user call sign is underlined.   The underlining remains until the user enters ‘CTRL-Z’ on their terminal to clear all underlining.   The idea here is that as the NCS is calling for quick-key check-ins from a specific geographic area, the NCS can depress ‘CTRL-Z’.   Then as people quick-key, their calls are underlined and the NCS knows who to acknowledge as checked•in.   This feature should significantly reduce the amount of pencil and paper work required by the NCS.
    The program, dplusreport, does NOT require root level permissions as it does not perform any actions on the gateway.  It only reads the dplus.log and displays relevant information. When a permitted user logs into the gateway system, the users should “stretch” their display window to provide 80 columns and as many rows as possible in the window.   I run it with my window sized to 80 columns by 60 rows. However, this will generally be limited by the font size chosen on the display.