Due to other commitments I have been unable to develop and maintain XRF400 since mid 2015. I kept the reflector coasting for almost a year however due to lack of use and community interest I came to the conclusion that it is time to move on: XRF400 is officially retired as of 16 March 2016.
Summer means travel, and this year I will be in Russia until Fri 31 July. I packed my IC-7100 in the suitcase and I hope today I will be able to find a pole for a temporary wire antenna on 10-15-20 metres (I’ll leave 40 and 80 for another day) to operate either from a fixed base or portable. All going well I should be able to operate as RA/M0ZZM and somehow advertise my presence on a DX cluster.
One thing I’d like to do is experiment with direct D-STAR contact in HF, this will have to be on 10 metres (I was thinking of the 29.4 MHz region) as it is the only band allowing the 6 KHz bandwidth required to operate. So if you are also looking forward to test D-STAR under propagation conditions, my QTH locator will be around KO82, which is approximately 400 Km south of Moscow or about 2000 Km distance from central and southern Europe.
If you wish to schedule a QSO, please add a comment to this post.
If you have been playing with a Raspberry Pi and the usual SD cards, chances are that you also found yourself unable to reconvert your SD card back to Windows for normal use. When you try to reformat the card in Windows, you will most likely get to a point where you have only one primary partition with all the rest of the space on the card free, but you are unable to expand the partition to cover the whole available space. You will have something like 50 to 100 MB space in your FAT32 partition and many GB space that can’t be utilised.
Well, your frustration is over. Here is how to proceed to repartition your card as you wish – in Windows. No extra tools or software is required. In the below explanation, when you see [square brackets] you don’t need to type the brackets, just the content.
Before you proceed, the usual disclaimer: I tried this on my system and it worked well, however you do this at your risk and peril and if anything happens to your computer or your card while following these instructions, I am not responsible for it.
STEP 1: insert the SD card in your reader so that the computer can recognise it, then open a command prompt and type [diskpart]. You will be taken to a window where the prompt says DISKPART> or something similar.
STEP 2: display the list of volumes by typing [list disk]. You will see a list of disks, probably something like Disk 0 and Disk 1, with the capacity in GB for each disk.
STEP 3: select the relevant volume. In my case, Disk 0 was the computer’s HDD, Disk 1 was the SD card. I recognised it because the capacity in GB matched that of the card and I had no other storage devices connected to the system other than my HDD, which I also could recognise the same way (by looking at the capacity in GB). If you are still not sure, try to run [diskpart] and [list disk] without the SD card in the slot, and then again with the card; you should notice the difference and be able to identify the correct volume. Back to business, to select the correct volume, assuming (once again, check carefully your system first when you try on your computer!) that the SD card is Disk 1, type [select disk 1].
STEP 4: clean the unit by typing [clean]. Make sure you selected the right disk when you type this, as this will clear all your partition table!
STEP 5: create a new partition by typing [create partition primary] and format it by typing [format fs=fat32 quick]. This will quick-format your partition as FAT32.
STEP 6: type [assign] and your card will immediately become ready to use.
A new Yahoo! group has been created to find and discuss ways of developing dxrfd, the software supporting the XRF reflector. The people participating to the group have already redesigned the XRF reflector dashboard, giving it a new and fresh appearance. This is the link to the group in case anyone is interested and wishes to join.
As part of my effort to help a friend to configure and setup a system comprising of two D-STAR RF modules under one gateway (all running G4KLX software), I created this schematic layout of the system, assuming two different scenarios.
In the first scenario all the elements of the system are located within an internal private network operating within a NAT environment. In the second case, the gateway and one RF module are inside the private network and then there is a second RF module remotely located. All IP addresses are just examples, you will need to adapt the settings to your circumstances but the principle is correct and will allow you to get your system working.
Here is the file, I hop it helps. Please remember to quote the source if you intend to redistribute.
Having recently developed an interest in how reflectors work, I soon realised that the best way of coming to understand how these vital pieces of D-STAR pieces of infrastructure work and interact with the rest of the network was to build my own. The software I used is called dxrfd and is available on the web. The below article is more an overview than a detailed installation guide. One reason of this choice is that I will not be able to maintain this page updated with all the changes that developers around the world will be making over time. All the installation instructions are included in a README file that is normally included in the package and those who wish to try this experience will be able to install it by following those installation guidelines.
It makes sense to revisit a few points regarding D-STAR.
Let’s start by restating that D-STAR is a digital radio communication mode that needs no infrastructure to work, a D-STAR radio works out of the box both in FM and DV modes, with no need of repeaters, hotspots, reflectors, or anything else. I recently heard someone saying that D-STAR is like Skype with a radio – this is simply incorrect and if you know what your radio can do you can make good use of it and it has nothing to do with Skype et similia. So, similarly to FM, if you have someone else tuned on your same frequency and press the PTT button, you can talk to this person and hear their reply. The added infrastructure is used to enhance the possibilities of communication within VHF and UHF (or any other) bands by overcoming the range limitations typically encountered at these frequencies.
The first step to increase this range is to add a repeater in the area, so stations that are normally unable to communicate with one another can use the advantage of the favourable positions where normally repeaters are located within a given area – same as with FM analogue radio.
The second step to this is to add a gateway to an access point, which could be a repeater as discussed above. As nowadays repeaters are likely to be managed by a computer (with small board units such as the Raspberry Pi being very popular) with a repeater controlling programme running on it, the gateway can be, and in most cases is, another little programme which runs on the same machine. If you are new to this and you think all this sounds like rocket science, let me reassure you: it isn’t and once you understand your way around you will be able to setup your hardware relatively easily – sure some skills are required but this is true for almost everything.
People tend to believe that a gateway needs to be connected to a network to make contact with other entities in the D-STAR wider infrastructure; this is simply incorrect. Over the years there has been a lot of development in the D-STAR world, with open source repeater/hotspot and gateway software being created with open and flexible communication in mind. The most popular open source software allows a system to be setup with a collection of internet addresses of many of the thousands of repeaters and hotspots located all over the world. Since a gateway is able to connect directly another gateway or reflector by just having its address, nothing other than an internet connection and the correct address is needed to make contact with other users linked to one of them.
Enter the XRF reflector. It consists of a small server programme that requires little space and resources to run on a Linux platform. It accepts linking connections on port 30001 (DExtra protocol) and also allows DV dongle and other software clients connections through port 20001 (DPlus protocol). As explained above, XRF reflectors can run outside a network and don’t need to propagate their IP addresses through a network; all it’s needed is the reflector’s address in the DExtra – NOT DPlus – list of reflectors added to a gateway.
Building an XRF reflector consists of having an available Linux machine connected to the internet via a good broadband connection and into installing dxrfd on this machine. The system cannot be the same where you also run a gateway, I don’t know why this is the case but it is clearly stated in the instructions. It also needs a separate IP address otherwise there will be a reflector port conflict with the DExtra protocol activities running on the gateway – this could in fact be the reason why the reflector cannot run on the same machine where the gateway is running at the same time.
Once installed and configured, the reflector accepts connections from all the entities linked to it, one at a time, and redistributes to all of them at the same time. This process can run five times simultaneously as the XRF reflector offers five independent modules. In simple words it acts as a cyber repeater, if there is such definition. The difference is that input and output are data streams rather than RF carriers, with the RF conversion happening remotely.
An XRF reflector can also be enhanced by adding a dashboard page that can then be made available on the web. The dashboard will list all the ongoing reflector’s links and QSO activities.
This is how XRF400 was created. The system is now live, it can be enabled by adding the reflector’s address to the DExtra list of your gateway and then linked by using XRF400xL in your radio’s UR field (where ‘x’ is any letter between A and E).
As in subject, PipeMSG, a DVRPTR board manufacturing company located in Germany, will cease its operations at the end of 2014 as it is being dissolved.
If you are in the D-STAR arena you can still obtain DVRPTR-V1 boards through dvrptr.net, another manufacturer in Canada. I used the services of this company, as did some of my friends, and they provided very good service and support.