DStar – Lost Opportunity

It struck me a few days ago that the abysmal data transfer rate of DStar DV (at best 900bps) didn’t have to be as bad as it is. This stems from the observation that most computer initiated data transmissions have no voice traffic in parallel.

It would have only take a single bit in the header to indicate that the packet was 100% data and the 3/4 of the payload that is reserved for voice could have been used instead for data when voice wasn’t required. Instead, we transmit data with 3/4 of the payload wasted.

Too late now, I guess.

D-Star, hmm.

My local radio club has put together a D-Star repeater and my role in it has been to set up the gateway computer. The gateway software is proprietary to Icom (no source code) and installs fairly easily as long as you do everything exactly as the poorly translated documentation specifies.

The documentation recommends CentOS 5.1, although I used 5.8. I used the 32-bit version as the administrators of the US Root Trust server, which manages the linking between hundreds of repeaters together over the Internet caution against the 64-bit version, and although I’ve usually managed to get most things to work on 64-bit CentOS, there was no reason to swim upstream on this project. I’ve also heard cautions about CentOS version 6 (now up to at least 6.2). I imagine the main problem is the tightening down of SELinux, but again, not worth the aggravation.

US Trust also has documentation “Joining the Network6″ which clearly explains what is necessary. I didn’t have much trouble getting it to work, although the last step of registration was delayed, I think, by a typo in one of the conf files.

The most curious part of the installation is that the Icom script installs a whole bunch of open source software packages (like Apache httpd, Tomcat, Postgres, etc.) from source. I suppose it is a way to control which version is installed.

The system worked as advertised, although at this moment it is down because the laptop which the (prototype) gateway is running on is prone to crashing every now and then with a hardware related kernel panic. It being the weekend of the Dayton Hamvention, I can’t get at it to reset it. Hopefully we’ll find a suitable server to run it on soon.

It’s a fairly small setup, with just 2 repeater modules and a controller. We’ve connected to the REF001C reflector, which is apparently the busiest of them all, but never saw more than 5% CPU utilization even on a 5 yr vintage laptop. So CPU performance doesn’t seem to be required. The memory utilization started around 500MB, but crept up to 900MB over a week or so of operation. I’ve heard there’s a memory leak somewhere in the software but no confirmation yet.

So what do I think of D-Star? It’s OK I guess. I’m not sure I’ll be buying a D-Star radio. The linking is pretty straightforward, and as it’s embedded into the signal can be supported by many memory slots in a radio like the ID-880h. The fundamental D-Star linking method, which is “connectionless” in that every transmission in both directions has to identify the path, seems less popular than the more traditional linking method of creating a nailed-up connection.

The low-speed data transmission capability is really slow. In combination with D-Rats a small email takes a couple of minutes to transfer. A PDF or other large document would take a very long time indeed. Technologies like HSMM-MESH seem more promising for usable data networking.

I was also shocked when setting up an ID-880h borrowed from the club that the speaker is in the body of the radio, not the front panel and the microphone also plugs into it. It seems pointless to separate the front panel from the radio by 12 ‘ but have a 3′ microphone cable attachment. You can buy extensions and external speakers, of course, but why not have the panel handle everything with one attachment cable? It’s not a D-Star thing though, the Yaesu FT-857 has the same setup.

So I’m not sure what radio is going to end up in my new Highlander. The D-Star options are very limited, either a plain dual-bander (70cm, 2m), a 1.2GHz (the Icom ID-1) only radio, or a very expensive all band base station radio.

Time Passes

I’m working on so much right now. Asterisk at work, plus my all my other jobs, A D-Star gateway computer for the radio club, along with configuring a Cisco router to work with it, which drove me a little crazy for a while. Got a dive trip coming up too (see my other blog at deepstop.wordpress.com).

The D-Star gateway goes well so far. I’m waiting for the second Ethernet interface to arrive before testing, and the internet access to arrive at the test site, but everything else seems to fit into place.

Meanwhile, I’ve bought a Columbus USB GPS to talk to D-Rats. I like D-Rats in part because it’s written in Python, which I’m starting to get better at. I like to have access to the source and I’ve read through the code that talks to the D-Star radio (or Internet, or KISS TNC). The club has also given me a D-Star radio for testing, but no interface cable, so I’m going to buy the parts this week to make one (just a 9 pin D-Sub to a mini TRS with no electronic components).

Back to you soon.

73,

Chris

 

The Linux Ham Guide to Setting up a Modern Radio Station

Using the Linux operating system for amateur radio can be both rewarding and frustrating. The rewarding part is that you will be part of a community that values sharing with others over profit and experimentation over appliance operation, not to mention having access to a lot of free stuff. The frustration comes when you can’t run something because it’s Windows-only and closed-source – and there’s some clever closed-source software out there. To be free, in both senses of the word, sacrifices are necessary. If, however, enough hams take up the challenge, the entire hobby will benefit, and so, I believe, will the industry that supports it.

I’m starting down this path with almost nothing. I was first licensed in 1983 as VE3NRT, and have retained that call ever since. I soon obtained my 10 metre phone endorsement (after proving I’d operated a station for 6 months), then my Amateur Digital license (which required passing the Advanced theory test), then after a year of being licensed I got my Advanced ticket. The regs have changed since then and my Digital license is just a piece of paper now.

A couple of years later, the late Dr. David Toth, VE3GYQ recruited me into to write controller software for one of the London, Ontario repeater systems (VE3TTT and VE3SUE). It had a remote autopatch (to save having a business phone line) and links to Toronto repeaters. It was quite an undertaking, all written “down to the bare metal” in PDP-11 assembly language on a KXT-11 single board computer. It ran for several years without much attention. Dave moved to the US and I moved to Toronto and we didn’t see each other again except once when I visited him in the hospital in Detroit after he was diagnosed with the condition that led to his death.

During the eighties I operated both HF and VHF/UHF FM and logged a bunch of contacts but after moving to an apartment in downtown Toronto and then to a house in Aurora Ontario I set the hobby aside. In 2010 I decided it was time to start again and joined the York Region Amateur Radio Club and the local ARES (now EmComm) group. A year and a half later I was still working with just 2 metre and 70 cm portables and my old dual band mobile from the eighties which still works perfectly well.

In early 2012 I volunteered to work on the gateway computer (running Linux) for the D-Star project for the York Region Club, and this increased involvement has reinvigorated my interest in combining ham radio and Linux. Recently I’ve learned a lot about Linux and done some programming in Python, a language that I like a lot. At work we’ve converted most of the server environment to Linux, with the 1 remaining Windows Server running as a virtual machine under CentOS.

So a year after starting a blog on the subject I’m now ready to work in earnest to get some interesting things running, and put my thoughts and experiences down in writing for the benefit of others.

73,

Chris VE3NRT

P.S. I’m keeping all related posts in a Word Document (yes, not open source software) for posterity.

P.P.S. Wish me luck

Python Script to Reset Cisco 79XX SIP Phone

This works with the SIP image, tested on firmware 8.12, but should also work with earlier versions. I wrote this as part of a larger routine to support hot desking (allowing people to “log in” to a phone). The other functions of the routine (an Asterisk AGI script) rewrite the SIP configuration file, and do housekeeping and lookups in the database, which are specific to my environment so no really relevant for general use.

The code is quite simple (and probably could be made simpler by someone really good at Python).

import telnetlib
def PhoneReset(IP,pw):
    pwprompt="Password :"
    prompt="> "
    try:
        tn=telnetlib.Telnet(IP,23,10)
        try:
            tn.read_until(pwprompt,10) 
            tn.write(pw+'\r')
            tn.read_until(prompt,10)
            tn.write('reset\r')
        except:
           return False
        finally:
            tn.close()
    return True

The one thing here is you should be pretty sure you have the right phone, otherwise someone is going to get an unpleasant surprise. It is easy enough to add an extra argument to the function with the device name (SIPnnnnnnnnnnnn) and use it in front of the prompt variable which would make sure it timed out if the name was incorrect.

The phone also has to have privileged access enabled. The default password on these phone is cisco, but I always change it.

Finally you can see that I intercept errors and use a true/false return. I’m developing a tendency to use the Python exception mechanisms instead of this kind of thing. It saves lines of code.

A View to a Join

I found a tough nut to crack in Django the other day. In my Asterisk system there’s a bunch of tables as you’d expect to support various relationships between phone numbers, voicemail, devices and the like, but there’s also one PostgreSQL view. This is used so I can have a single view of the devices, even though there’s a separate table for SIP devices, because I’m using SIP realtime which requires it. The view was therefore a Union query that brought together selected fields from the sip table and what I ended up calling device_static.

Now Django database models make connections based on the existence of a primary to foreign key relationship, but PostgreSQL doesn’t support keys in views, so it wasn’t as straightforward to create a page that pulled data from a join between a table and this view as it would be between two tables. However, all I had to do was to add a “pretend” foreign key to the django models.py for the database in the table definition, and a “pretend” primary key to the view. So these keys exist in the django database model but not in the database itself.

But that doesn’t matter. Django still knows how to form a SELECT statement with the appropriate inner joins, and it all works great. One thing I had to do was to move the definition of the view in front of the table that referenced it as the primary key has to be declared before the foreign key.

Just discovered Django

I’ve been playing with Django lately. It is a web development framework based on Python that integrates several database management systems, including SQLite, MySQL, Oracle and PostgreSQL, as well as some others less formally, like SQL-Server, and some other ODBC compliant systems.

So far, I’ve developed a few rather clever (if I don’t say so myself) pages to access the database in our company Asterisk system. This required me to use two different PostgreSQL databases simultaneously on two different computers, integrate a style sheet, edit database models and various other things.

I must say, I’m very impressed with the quality of the software and the documentation. I’m sure I’ll be mentioning it more often. I actually coded a cgi script using psycopg and python to do something similar first, and found it quite tedious. Django really made it easy, and the learning curve so far has been reasonable because of the excellent tutorials in the documentation.