The following text is from D-STAR.ca . Images are missing.
While the repeater modules look nice, there are always things that can be done to make them work better. :)
Of course, it should go without saying that if you undertake any of the modifications listed on this page, you do so at your own risk. Further, you will probably be voiding your ICOM warranty, so you're on your own.
While we will try to be as accurate as possible in the information we provide, there are no guarantees that it will work with your equipment. Something as simple as a manufacturing change may render this information inaccurate.
Under the Hood
There are some interesting things to notice when you peek under the hood of the repeater equipment.
This is a picture of the ID-RP2C (click for zoom):
image: rp2c_inside.jpg
Not really too much to see here. Below is the block diagram of how it works.
image: rp2c_block.jpg
Interesting to note is that the ASSIST ports (ID-RP2L 10GHz link) connect via a 10MB/s ATM connection using LVDS (low voltage differential serial).
There is a 16 Mbit x 8 Boot ROM (flash) (IC12), 32 Mbit x 16 Flash ROM (IC11), and 4 Mbit x 32 of SRAM (IC2, 3, 6, 7) on board.
Also of note is that J6 is an RS-232 interface directly connected to the CPU (IC5). The pinout of this connector appears to be:
Pin 1 - RTS
Pin 2 - TX Data
Pin 3 - RX Data
Pin 4 - CTS
Pin 5 - GND
Pin 6 - GND
Now, the IC-RP2D. This appears to be nothing more than perhaps an ID-1 in a rackmount case, presumably with some slightly different firmware.
image: rp2d_inside_t.jpg
image: rp2d_radio_inside_t.jpg
Some investigation will be required to see if the radio responds to other commands on the USB port (as defined in the ID-1 interface specification).
Since the RP2D can only operate half-duplex, it only needs an integrated transceiver.
On the other hand, the repeater modules that need to do duplex require separate transmit and receive units.
This is what the IC-RP2V looks like inside:
image: rp2v_inside.jpg
RSSI
It seems that the pinout of the RJ45 on the rear of all the repeaters is the same. The pinout of this connector is:
Pin 1 - TC (Transmit Clock)
Pin 2 - TD (Transmit Data)
Pin 3 - Ground
Pin 4 - TE (Transmit Enable)
Pin 5 - RE (Receive Enable)
Pin 6 - RSSI (Receive Signal Strength Indicator)
Pin 7 - RC (Receive Clock)
Pin 8 - RD (Receive Data)
Now, something that is immediately interesting about this is that all of the repeater modules have an RSSI signal that they send to the controller.
This RSSI signal comes pretty much directly from the receiver IC (MC3356 in the RP2D, or TA31136 in the RP2V). It is NOT used by the RP2C.
This signal is an analog voltage, that appears to be in the range of 1-4.5VDC (depending on signal level).
An RP-4000V was tested by applying a CW signal to the antenna connector, and measuring the corresponding RSSI voltage as the level was changed.
With no input, the RSSI voltage was 1.078VDC. The signal was swept from -128dBm to -60dBm in 4dBm steps (source was an IFR 1200S). The resulting data was graphed to produce the following:
image: rp4000v_rssi.jpg
You will notice that the curve is basically linear right up to about -72dBm, at which point the detector circuit obviously saturates (4.5VDC).
The receiver was also swept with a CW at both +/-12.5kHz from the operating frequency. As you can see, it takes a stronger level from the adjacent channel interference to cause the RSSI to rise, but it still affects the RSSI.
The actual selectivity of the receiver was not tested at this time.
Further tests on the other repeaters will be performed as the opportunity presents itself.
Discriminator Tap
While there isn't currently any test equipment on the market that can encode and decode D-STAR, there are some work arounds.
Right up to the modem chip, the RX radio is still an FM receiver. So, all the standard tests can be done to check the RF performance of the radio by utilizing the discriminator audio prior to the modem chip.
In the RP-4000V, this is relatively painless. If you remove the top cover of the RX radio, you will see the RX interface board. Near the middle of that board is the CMX589A modem chip. Right near that chip is a test pad labelled "DET". Yep, you guessed it, that's good old FM Detector audio.
image: rp4000v_pads2.jpg
If you look on the main board, right near the front, you'll see some more test pads, "MIN" which appears to also be detector audio, and "RSSI" which is the receive signal strength indicator pin.
image: rp4000v_pads1.jpg
RP-4000V Internal Jumpers
It has been reported by others, and confirmed also on our unit, ICOM in their infinite wisdom indeed used RG-58A/U for the jumper cables between the RX and TX units to the back of the chassis.
They probably could not have picked a worse cable for this application. It isn't the loss that is a problem (about 0.2dB), its the lack of shielding.
Put a 25W UHF radio right beside a sensitive receiver, and you're asking for desense when you use cable with only 95% braid (if you're lucky).
These are the factory installed jumpers:
image: rp4000v_rg58.jpg
In order to eliminate the RG-58, and improve the shielding, we replaced the factory jumpers with some semi-rigid coax jumpers instead. These jumpers happened to be surplus out of another application, and fit the bill. They are N(f) bulkhead on one end, and SMA(m) on the other. A high quality SMA(f)-N(m) adapter was used to attach to the radio.
The result:
image: rp4000v_semi.jpg
On a side note, these are obviously nothing more than modified mobiles that make up the repeater... if you've used a ham mobile in a high RF environment, you know how the front end is wide open like a barn door and will get hammered by strong adjacent channel interference.
Since there is so much room inside the chassis, you would be well advised to add a tuned RF preselector in front of the receiver to try and keep some of the "crap" out.
A surplus out of a Daniel's Electronics UHF receiver would work perfectly inside the chassis. We use an external Sinclair Laboratories receiver multi-coupler ahead of ours that contains a bandpass filter and pre-amp. It makes a BIG improvement.
Output Power
The RP-4000V was checked for its output power by applying 3.3V to the TE line on the RJ45 connector (you can find 3.3V on one of the accessory connectors inside the transmit radio).
On low power, the radio puts out 2.2W (seems low, should be 5W?).
On high power, it puts out 24.7W (on spec).
Input Current
The RP-4000V draws about 400mA idle (RX). During TX (low), it uses about 2A, and on TX (high), about 5A.
TX/RX LED
One of the biggest things that the repeater modules lack is an indication of whether the repeater is transmitting or receiving.
Instead, all you have on the front panel is a nice, green LED to tell you that the power is on.
However, all is not lost, it seems that ICOM did include all of the circuitry on board to give you a TX and RX LED, its just not brought out to the outside world.
This modification was first tested on the IC-RP2D 1.2GHz Digital Data repeater. It is confirmed to work with this unit. It has also been proven to work on the IC-RP2V 1.2GHz Digital Voice repeater. The difference on the IC-RP2V is you will need to pull the RX from one radio unit and TX from the other.
Open up the repeater to expose the radio unit. You will also need to open the top cover of the radio unit to expose the logic board.
On the logic board, near the front of the repeater, you should see three series of three through-hole plated vias.
The set of holes on the left are connected to the bias resistors of the TX/RX LED circuit.
image: rxtx_sch.jpg image: rxtx_brd.jpg
Note that the picture of the board layout is actually of the under side of the board, when you are looking down from the top, R114 (TX) is actually the LEFT hole, and R113 (RX) is the RIGHT hole.
Since the bias resistors and drivers are already installed, all you have to do is install some LED's!
Our prototype used a bi-color, common cathode LED. We connected the green anode to the RX line, and the red anode to the TX line.
This is a picture of our prototype in "proof of concept":
image: rxtx_led_t.jpg
Once we proved that it actually worked, it was time for a more permanent solution.
The factory power LED is pretty much an idiot light. As long as the fan is running on the back, there is power. We re-located the power LED from the top of its PC board to the bottom (you'll need to rotate it 180 degrees so the pinout is correct when you do this).
This freed up room behind the little frosted hole in the chassis to install our TX/RX LED without having to drill holes in the case.
Extend the LED with a nice piece of shielded wire, hot glue it in place, and you get this:
image: rxtx_mounted_t.jpg image: rxtx_wire_t.jpg
On the IC-RP2D it flickers nicely red and green as data is being moved. On the voice repeaters, you will usually find the bi-color LED will be amber/orange since both TX and RX will be active at the same time.
General Info
From: http://www.dstar.ca/setup.html
Most of the software utilities used to configure the repeater modules are pretty simple and straight forward. In most cases, all you can do is set the operating frequency. The RP2C is a little more involved, and it will be covered separately.
ID-RP2D
This repeater module has some unique configuration quirks that should be noted.
This repeater module only has one radio unit inside, since the Digital Data connection is half-duplex. As such, there is only one Service port on the front of the repeater.
Normally, you would think that you would set the repeater's transmitter frequency with the utility. Wrong. The main configuration setting in the utility is the RECEIVE frequency.
In most cases they are the same, since you will be operating on a simplex frequency.
However, also unique, is a setting for "Offset". This determines the transmit frequency of the repeater.
Operating the IC-RP2D on split frequencies may be required in circumstances where you may only have one antenna to use. This, of course, would require an external circulator and combiner/multi-coupler assembly.
ID-RP2C
The default IP address that the controller is on is 172.16.0.1.
The default password is PASSWORD (case sensitive).
If you are not using a gateway server, then you can tick the Local Server box. This will allow the IC-RP2D repeater to serve up the local internet connection to mobile users. You may want to consider something like Chillispot to manage user connectivity to your internet connection.
There are different configuration settings that correspond to the type of repeater modules connected to the controller. Probably the most common is "D,V,V,V". In this configuration, the controller expects the IC-RP2D to be on Port 1 of the controller. Remember this when you hook it up, IT DOES MATTER. You can connect the other repeater modules to any of the other ports, just make sure you get the assignments correct for the port name (A, B, C) to match local conventions.
The "standard" for assigning repeater ports in USA and Canada is:
Port A - 1.2GHz (both IC-RP2D Data and IC-RP2V Voice)
Port B - 450MHz IC-RP4000V
Port C - 144MHz IC-RP2000V
You will note that the configuration utility will have one of the enable check marks for the repeater ports grayed out so you cannot de-select it. Further, it will not let you change the assignment to something other than "A"... unless you have one of the other voice ports assigned as "A".
What this boils down to is you will always need to have a voice port assigned as "A", whether that repeater actually exists or not.
Just make sure that you actually connect the repeater modules to the controller on the ports that you have assigned. Looking at the back of the controller, the ports are numbered 1, 2, 3, 4 from left to right.
As mentioned above, port 4 will always be enabled, so you might want to put your VHF module on there.
User Radio Setup
Most of the important details on setting up your radio for D-STAR communications can be found in the user manual.
For configuring the callsign fields, a useful tool can be found here: http://www.dstarinfo.com/Calculator/DSTAR%20Web%20Calculator.aspx
ID-1 Data Radios
The ID-1 in DD mode acts like an ethernet bridge. That is, it does not have an IP address itself, that is programmed into the device(s) attached to the radio.
For communication WITHOUT an attached gateway, and the ID-RP2C configured in "server" mode, the settings to get on the internet would be:
Field Setting
URCALL: VE7RAG S
RPT1: VE7RAG A
RPT2: VE7RAG S
MYCALL: VE7BCB
In this mode, set your attached PC with the IP settings appropriate to the internet connection the controller is attached to.
For communication WITH an attached gateway, you must register with a gateway machine and get an assigned IP address (on the 10.0.0.0/8 net). The settings in the radio to get on the internet are:
Field Setting
URCALL: VE7RAG
RPT1: VE7RAG A
RPT2: VE7RAG G
MYCALL: VE7BCB
You will set the IP address in your PC to one of the ones registered to you. The default gateway is 10.0.0.1, and the default DNS server would be 10.0.0.1.
In both modes, make sure that the radio is in DD mode, and is set for RPS mode. Also make sure that TX Inhibit is turned off, to allow the radio to transmit when the computer wants to send data.
Note that because of the much higher data rate associated with DD communications, you need a much stronger signal in order for the DD mode to work. Somewhere on the order of 10-12dB more signal is required, compared to DV mode. So, while you may be able to talk to the DV machine just fine, it is no guarantee that you will be able to use the DD repeater. Yagi's are a good idea.
Now, some quirks about DD mode with a gateway...
You can use ANY 10.0.0.0/8 IP address that has been previously registered, it doesn't even have to have an inital or pcname attached to it.
The IP address does not have to match the registered MYCALL.
The implications of these quirks are still being studied.
About the "PC Name" you set in the Personal Information screen on the G2 server you registered on. This name cannot end in a "-", it has to be a valid letter or number. PC Names must also only contain letters and numbers, no other special or punctuation characters.
Why? The name you set in PC Name is actually used by the G2 system to create a unique hostname assigned to your IP address. When you register a PC Name, that actually gets expanded into PCNAME.dstar.local. In the internals of the G2 software, your call is used to figure out what gateway you are on so other users can contact you.
From: http://www.dstar.ca/interfacing.html
Repeater Modules
The repeater modules have two different types of interfaces, USB is used to set the operating frequencies, and then a proprietary interface is used as a communication bus between modules and the controller.
USB Interface
The USB interfaces use an FTDI USB to serial interface chip to communicate to the outside world.
The driver software and setup utilities are generally shipped on a CD included with the repeater module. The exception to this is the IC-RP2V and IC-RP2D. The drivers and utilities for these modules are on the CD that is shipped with the IC-RP2C controller.
Note that the "Service 1" and "Service 2" USB connectors on the ID-RP2C controller are only used to access the ID-RP2L 10GHz Link radios that would be connected to the "Assist 1" and "Assist 2" ports. The ID-RP2C is configured through the ethernet connector on the front (default address is 172.16.0.1/16).
In the Linux 2.6.17.13 kernel, the ID-1 already has USB support built in (if you compile support for FTDI serial converters). By inspecting the Windows .inf files for the serial drivers, we can find the rest of the PID's for the serial converters. The results are:
ICOM Vendor ID (VID) 0x0C26
ID-1 Product ID (PID) 0x0004
ID-RP2C Product ID (PID)
Service 1 (Assist 1) 0x0009
ID-RP2C Product ID (PID)
Service 2 (Assist 2) 0x000A
ID-RP2D Product ID (PID) 0x000B
ID-RP2V Service T Product ID (PID) 0x000C
ID-RP2V Service R Product ID (PID) 0x000D
ID-RP4000V Service T Product ID (PID) 0x0010
ID-RP4000V Service R Product ID (PID) 0x0011
ID-RP2000V Service T Product ID (PID) 0x0012
ID-RP2000V Service R Product ID (PID) 0x0013
These are the "typical" VID and PID's of the equipment. At least one other VID and PID is known to exist:
ICOM Vendor ID (VID) 0x0403
ID-RP2D Product ID (PID) 0x6001
You may find that if you add the following patches and re-compile, you will get USB support for these devices under Linux.
/usr/src/linux/drivers/usb/serial/ftdi.c
locate the variable definition for the ID1:
{ USB_DEVICE(ICOM_ID1_VID, ICOM_ID1_PID) },
then add:
{ USB_DEVICE(ICOM_ID1_VID, ICOM_RP2C1_PID) },
{ USB_DEVICE(ICOM_ID1_VID, ICOM_RP2C2_PID) },
{ USB_DEVICE(ICOM_ID1_VID, ICOM_RP2D_PID) },
{ USB_DEVICE(ICOM_ID1_VID2, ICOM_RP2D_PID2) },
{ USB_DEVICE(ICOM_ID1_VID, ICOM_RP2VT_PID) },
{ USB_DEVICE(ICOM_ID1_VID, ICOM_RP2VR_PID) },
{ USB_DEVICE(ICOM_ID1_VID, ICOM_RP4KVT_PID) },
{ USB_DEVICE(ICOM_ID1_VID, ICOM_RP4KVR_PID) },
{ USB_DEVICE(ICOM_ID1_VID, ICOM_RP2KVT_PID) },
{ USB_DEVICE(ICOM_ID1_VID, ICOM_RP2KVR_PID) },
/usr/src/linux/drivers/usb/serial/ftdi.h
locate the entries for the ID-1:
/*
* Icom ID-1 digital transceiver
*/
#define ICOM_ID1_VID 0x0C26
#define ICOM_ID1_PID 0x0004
then add:
#define ICOM_RP2C1_PID 0x0009
#define ICOM_RP2C2_PID 0x000A
#define ICOM_RP2D_PID 0x000B
#define ICOM_RP2VT_PID 0x000C
#define ICOM_RP2VR_PID 0x000D
#define ICOM_RP4KVT_PID 0x0010
#define ICOM_RP4KVR_PID 0x0011
#define ICOM_RP2KVT_PID 0x0012
#define ICOM_RP2KVR_PID 0x0013
#define ICOM_ID1_VID2 0x0403
#define ICOM_RP2D_PID2 0x6001
Is this useful? Perhaps not yet, but it might be easier to poke at the equipment using scripts under Linux to try and figure out how to put some hooks in for other programs.
It will also be interesting to see if there is any data on the USB connector of the voice repeaters during operation. Perhaps we can get the low-speed data out of the "R" port?
Bus Interface
All of the repeater modules connect to the ID-RP2C through a CAT-5 ethernet cable. This IS NOT an ethernet interface. The only ethernet interface is the one that is on the front of the ID-RP2C that connects to the Gateway computer.
It seems that the pinout of the RJ45 on the rear of all the repeaters is the same. The pinout of this connector is:
Pin 1 - TC (Transmit Clock)
Pin 2 - TD (Transmit Data)
Pin 3 - Ground
Pin 4 - TE (Transmit Enable)
Pin 5 - RE (Receive Enable)
Pin 6 - RSSI (Receive Signal Strength Indicator)
Pin 7 - RC (Receive Clock)
Pin 8 - RD (Receive Data)
Now, something that is immediately interesting about this is that all of the repeater modules have an RSSI signal that they send to the controller.
This RSSI signal comes pretty much directly from the receiver IC (MC3356 in the RP2D, or TA31136 in the RP2V). It is NOT used by the RP2C.
On the other hand, the repeater modules that need to do duplex require separate transmit and receive units.
From: http://www.dstar.ca/gateway.html
ICOM Gateway
Currently, the software from ICOM is the only available gateway interconnect software for the D-STAR system.
Gateway Software
Please obtain your copy of your gateway software from your authorized ICOM dealer.
Presently, the standard OS to install the Version 2 Gateway Software (G2) on is CentOS 5.1. You will want to download yourself some installation media (cd's or the dvd) from http://www.centos.org.
The installation manual for the G2 software is included on the disk from ICOM. Unfortunately, the English isn't written all that well, so it can be difficult to understand what they are saying. Usually if you refer to the pictures and boxes, you will be successful in getting the software installed.
Post Installation
In order to fix some issues identified with the roll-out of the G2 software, it is necessary to apply a few updates.
See http://dsyncg2.dstarusers.org/info/ for further information and instructions.
There, you will also find some of the add-on software that is installed on most gateways.
When you are ready to register your gateway on the US Trust server, you will need to contact the US Trust Server administration team by sending an email to trust-server-admins@dstarusers.org.
Important Commands
There are some important commands useful for checking status and trouble-shooting problems. These include:
service dstar_gw stop Stop the gateway software
service dstar_gw start Start the gateway software
service dstar_gw restart Restart the gateway software
service dstar_gw status Check the status of the gateway software
service dplus stop Stop the dplus software
service dplus start Start the dplus software
service dplus restart Restart the dplus software
service dplus status Check the status of the dplus software
service dsm stop Stop the DstarMonitor software
service dsm start Start the DstarMonitor software
service dsm restart Restart the DstarMonitor software
service dsm status Check the status of the DstarMonitor software
cat /var/named/chroot/var/named/dstar.local.db Peek inside the named database of all the current registered calls
Most of the software keeps log files as it runs, they can be found in /var/log. Use cat or tail to have a look at them. If you want to watch a log file in real time, do a tail -f filename (exit with ctrl-c).
Warning... the rest of this page contains modifications of the ICOM D-STAR Gateway Software. You CAN hose you system real quick if you do not know what you are doing. Proceed with caution. If you screw it up, don't blame me!
Fix Registration Page Re-direct
Out of the box, you are supposed to register users on the gateway system at https://my.domain.net/Dstar.do (note the https).
This is, of course, a secure web page.
Unfortunately, if you just go to the domain name, and forget the Dstar.do, you get an error (Apache tries to do a directory listing because there is no index file, and the permissions won't allow that).
To fix this error, and get people to the right place, a simple fix is to create a basic index.html file that re-directs them to the right place.
You need the following code:
<html>
<head>
<META HTTP-EQUIV="Refresh" Content="2; URL=Dstar.do">
</head>
<body>
Forwarding to login page...please wait.
</body>
</html>
Place it in a file called index.html in /opt/products/dstar/apache/securesite. Make sure it is readable by all chmod 644 index.html.
Now, when you go to the base URL of the G2 box, you should get re-directed to the login page after a couple of seconds.
This is the simplest way to do it. It does not rely on knowing any hostnames or anything else fancy. Pretty it up and do what you like... if you want.
Make G2 Email You
Again, out of the box, there is a "problem" with the G2 software in that there is no way to know if there are new registrations pending approval.
One would figure the box would notify someone, as it implies, when a new user registers... but it doesn't.
Go get the JavaMail (See Note) API from Sun (Originally http://web.archive.org/web/20090101112701/http://java.sun.com/products/javamail/downloads/index.html now Oracle). You have to do some clicking to actually get to the file, so download it somewhere conveniently, then transfer it to your G2 box.
Go get the JAF API from Sun (Originally http://web.archive.org/web/20090101112701/http://java.sun.com/javase/technologies/desktop/javabeans/glasgow/jaf.html now Oracle). Again, you have to do some clicking to actually get to the file, so download it somewhere conveniently, then transfer it to your G2 box.
Once you get both those files onto your G2 box, un-zip them.
From the JavaMail file, get the mail.jar file and copy it to /opt/products/dstar/tomcat/webapps/D-STAR/WEB-INF/lib, and from the JAF file, get the activation.jar file and copy it too into the same place.
These files enable you to actually be able to send email from Tomcat/Java.
Now, go to /opt/products/dstar/tomcat/webapps/D-STAR/WEB-INF/pages/register and you will see a couple of files. Back up the Complete.jsp file (cp Complete.jsp Complete.jsp.old is a good idea).
Open Complete.jsp in a text editor. At the very top of the file, paste in the following three lines above everything else:
<%@page import="java.util.*"%>
<%@page import="javax.mail.*"%>
<%@page import="javax.mail.internet.*"%>
Next, just above the <html:html> tag, paste the following:
<%
Properties props = new Properties();
props.put("mail.smtp.host", "localhost");
Session s = Session.getInstance(props, null);
MimeMessage message = new MimeMessage(s);
InternetAddress from = new InternetAddress("dstar@localhost");
message.setFrom(from);
InternetAddress to = new InternetAddress("dstar@localhost");
message.addRecipient(Message.RecipientType.TO, to);
message.setSubject("New D-STAR Registration");
message.setText("A new user has registered and is awaiting approval!");
Transport.send(message);
%>
Now, what will happen is that when new users register, they have to click "OK" in the "Are you sure?" box. If the registration passes without errors, the Complete.jsp file gets called. The code that you just pasted gets run when the page is called. It sends an email to "dstar@localhost", which is the dstar user on the G2 machine to let them know that someone has just registered and is pending approval.
Of course, you probably aren't going to check that mail, so you will want it to be forwarded somewhere else more convenient (or even to multiple admins).
That's easy, as the G2 box should have Sendmail running on it.
The reason we choose the dstar user and not root to send the notification to, is that root also gets mails from logwatch and other stuff that is running.
Open /etc/aliases in a text editor, go way down to the bottom of the file, and paste in the following:
# Who should we send D-STAR notifications to
dstar: you@your-isp.net
Save the file, then run the command newaliases to update the database. Finally, restart Sendmail with a service sendmail restart.
That's it, now when new registrations arrive, you will get an email notification!
If you want the easy way to do this, download this file to your G2 machine, and run the following commands:
tar -xzf email_mod.tar.gz
cd ./email_mod
sh ./email_mod
You can download this file directly to your G2 box with the command:
curl -O http://www.dstar.ca/scripts/email_mod.tar.gz