April 6, 2009
20:53
by: Dan

Communications Academy 2009

This past weekend, I was up in the Seattle area (again) for the 2009 Communications Academy conference.  This was my first time attending, and I found it to be quite good.  There was a lot of good information on various emergency communications topics and definitely a good concentration of knowledgeable folks.  I gave basically the same talk on D-RATS that I did at MicroHams a couple of weeks ago, but augmented with changes that have occurred since then.

Digital communications was a particularly prominent theme, which shouldn’t come as much of a surprise.  There was a lot of talk of D-STAR as well as P25.  I attended a talk the first morning comparing the two at a relatively low level, which I found quite informative.  The D-STAR stuff was all review, of course, but the P25 information was new to me.  In the afternoon of the second day I attended the “Digital Radio Possibilities for Amateur Radio” talk.  While there was no attempt to hide the fact that it was focused on P25, I felt that I had been lured into the room by the promise of a discussion (and perceived benefit) of interoperability between public safety P25 networks and potential amateur ones.  Unfortunately, it seemed to avoid that particular issue and promote P25 as the best digital voice standard for Amateur radio just because the public safety folks had chosen that route.  I was disappointed that the capabilities and benefits of D-STAR were completely ignored.

From what I learned in the various talks, I’m really not sure why P25 has much place in the amateur realm, at least any more than any other radio technology that can be pulled onto the amateur spectrum for experimentation.  The prices of used Phase-I gear are significantly higher than new D-STAR radios, and provide significantly less functionality.  The speaker also explained that Phase-II gear is almost categorically uninteresting to the amateur service, which seems to put a clear end date on production and availability of hardware.  Lots of people complain about D-STAR being a potentially dead-end technology with a high price of entry, given that there is only one manufacturer that could pull the plug and make the investment worthless.  That may happen, but with P25 there’s already a date for the funeral.

Finally, many P25 proponets in the amateur community seem to toss the word “interoperability” around quite a bit.  The only time that was addressed in any of the talks I heard this weekend was in the context of using a P25 radio to monitor public safety frequencies. Given such a silly argument, I still don’t know how interoperability is supposed to be a benefit of P25.  They can’t talk on our frequencies and we can’t talk on theirs. Does it matter if we use the same type of radios?

I certainly don’t think D-STAR is the perfect digital voice technology for amateur radio, but from what I learned this weekend, it’s definitely the best option at the moment.

Posted in Radio

March 23, 2009
21:33
by: Dan

Microhams 2009

This past Saturday, I presented at the Microhams 2009 Digital Communications conference.  I covered a basic demo of D-RATS functionality and showed the new 0.3.x UI I’m working on.  Response was quite good and the questions I received were refreshingly technical and well thought out.  Some new ideas came out of the discussions I had during and after the presentation, which I’m looking forward to working on.  Overall I think it was the most interesting conference I’ve been to in a while, with just about every presentation keeping me interested the entire time.

In case you don’t know, the Microhams group is closely related to Microsoft, and (as I understand it) was founded and is largely populated by Microsoft employees.  As such, the conference was held on the Microsoft corporate campus in Redmond, WA.  I thoroughly enjoyed taking my Linux machine up to the podium (which sported a large brass-colored Microsoft logo) and plugging it into the projector.  I got a couple of decent jabs at Microsoft worked into the material, and the audience was receptive to the fun.

As I was walking out to the parking area and waiting for Taylor to pick me up, I snapped the following shot of the posters that adorn the small-town-feel of the bit of the campus I was on:

 I was amused Smilie: :)

Posted in Miscellaneous

March 19, 2009
19:35
by: Dan

Expectations

I think that one of the hardest things to do as a programmer is anticipate the ways in which your product will be used.  If it’s not very powerful to start with, then it’s not likely that people will try to push the envelope of its capabilities.  However, if it’s above a certain level, users will attempt things that the creator didn’t anticipate.  Not knowing the details of the implementation, the users will expect to achieve a certain goal that exceeds capabilities.

I’m not very good at thinking outside the box in this way, and thus usually don’t come up with very creative test cases for my work.  It’s unfortunate, but I think that it is (in some cases) a common problem of being too close to the code.  I know what it’s supposed to do, I test to verify that it does that, but I have a hard time forcing myself to try to do something that wasn’t intended.  I need to work on that.

However, in the case of D-RATS at least, I have a healthy contingent of people constantly working to break stuff.  They don’t realize that they’re trying (well, some do), but without a manual, box, or guide telling them what is in and out of scope, they tend to push on it until it breaks.  This has, undoubtedly, led to some of the better features and more robustness than I would have been able to accomplish alone.

A good example of this came about recently when one of my users told me that his map in D-RATS was getting slower and slower.  I had just added a few significant performance enhancements to the map code, so I wasn’t sure if I had broken something in the process or what.  After seeing one of his error messages, I asked him to send me his overlay files.  The overlays are a function I added that allow users to put static points on the map of things that don’t move, which are overlaid with the actual radio stations that the map is intended to track.  I have about ten such points on my map, and it’s quite useful.  He sent me his overlays and I put them on my system and brought up the map to see if I could reproduce the performance issues he was experiencing.  Here is what I saw:

Clearly, he had a different level of functionality in mind than I did.  The phrase “pushing the envelope” applies quite well here.  This, of course, led me to do quite a bit of work on the map code around the bits that draw the overlays.  Hopefully this will improve things quite a bit.

Bravo, Dave.  Bravo.

Posted in Codemonkeying Tagged

March 4, 2009
21:22
by: Dan

A change for me at work

When I started full-time with IBM, I was working on the Open Virtualization team, specifically on some core bits of the Xen hypervisor.  I really enjoyed that work, as it was close to what I wanted to be doing.  I enjoy the low-level stuff a lot, but team plans took me back and forth between that and higher-level things.  Recently, I had a long streak of very high level work with the libvirt-cim project.  It was nice to propose, implement, and lead something so large, especially given its relative success.  However, lately I have been itching to move back to something lower down in the stack.

Given the recent economic climate, not many people are getting a chance to change jobs or be picky about what they work on.  I was lucky enough to have the opportunity to move to one of the kernel teams in the LTC recently, so I jumped at the chance.  I have actually been working on the new team since the beginning of the year, but this week my transition was finally recognized as official in the company org charts.  Not wanting to put the cart before the horse, I waited until something concrete showed up in writing before I announced it to the world.

So, I say goodbye to the libvirt-cim project and the people working on it with me and hello to the LTC checkpoint/restart team.  I’ll be (and have recently been) working on checkpoint and restart support of running tasks in the Linux kernel.  It’s a challenging project that I’m excited to work on, with plenty of opportunities for learning.  Plenty.

Posted in News

February 27, 2009
18:09
by: Dan

KD7RFI D-STAR Repeater on the air!

This past weekend I met three other hams at the Synopsys site in Hillsboro to install our group’s D-STAR repeater.  We have had the components of this stack for a while now and have been testing it at a low-level site (my house).  Late last year, a member of our group approached the Synopsys facilities supervisor about potentially locating some or all of our D-STAR repeater equipment on their roof.  They graciously agreed and we closed on that this weekend.

We installed a Comet GP-98 antenna on a ten-foot pole with a very short run of 9913 coax through the wall into the roof stairwell enclosure.  Inside, we put a 7′ fully-enclosed rack cabinet with our D-STAR repeater controller, UHF RF module, and our UHF duplexer cans from TX/RX Systems.  We got everything installed and set out to test things to make sure they worked properly.

Initially, we were getting almost no power output from the repeater past the duplexer, but full output into a dummy load.  Not looking to prolong the installation day too far, we decided to tune up and install a small mobile notch duplexer that I happened to have with me so that we could at least get the machine on the air and then go home and diagnose the issue with the large duplexer offline.  Performance with the notch was not good at all, and I was worried that there were other issues at play.  Anything but the strongest signals into the repeater were seriously garbled and absolutely no data traffic was making it through the unit.

At home, we were able to determine that while the duplexer cans were tuned perfectly for our transmit frequency, they were presenting a relatively high SWR to the repeater PA, which caused it to scale back its power dramatically (from about 20W to 2.5W or so).  We retuned the duplexer a bit to give an additional 1db of loss but with very low SWR.  I tested it on a ground-level repeater module and confirmed that it was putting out reasonable power again.

On Wednesday, I returned to the Synopsys site to reinstall the better duplexer and do a little bit of testing.  With a wattmeter, I was able to confirm that the repeater was putting out a reasonable amount of power after the duplexer.  After calling on the air for testers, it was immediately apparant that it was performing significantly better with the cans than the notch filter.  More testing that day and the day after was extremely positive.  Mobile stations were getting into the repeater quite well, and almost all fixed stations could hit it easily at 5W, even with a handheld on a rubber duck.  Wednesday night, I was able to have a QSO *and* transmit GPS position reports clearly from PDX Airport some 18 miles east.  Thursday morning, another station was able to get into the repeater easily while mobile from the intersection of Highway 6 and Highway 8, about 20 miles west.  Quite impressive for a repeater that is only six stories off the ground and putting out about 15 watts after losses!

The machine is KD7RFI_B on 440.550+MHz.  There is no gateway on it (and we’re not sure if we will try to install one at this site or not) at the moment.  If you’re within range, jump on and say hi!

Posted in Radio

February 15, 2009
15:25
by: Dan

Using Py2App with GTK

In order to present D-RATS as a nice and neat App package on MacOS X, I have been using Py2App.  When it works, this utility generates a App package that contains everything D-RATS needs aside from the base operating system to run.  To do this, I install MacPorts and then build a full Python 2.5 stack with things like pygtk, libxml2, libxslt, etc.  When I run Py2App, it captures all of the necessary libraries and support files from the MacPorts installation and relocates them into the App package to form a nice, neat, and easy-to-run package for Mac users.

Each time I set out to create this environment, I was presented with the same problem.  Since it took me several attempts spanning many months to figure out the proper way to solve it, I decided to document it here so that there would be a single place that explained how to get out of this particular jam.

The problem was that when running Py2App, I would inevitably get the following error message:

ValueError: New Mach-O header is too large to relocate

In order to figure out what it was complaining about, I would type print self in the debugger, which would show me the path of the library it was trying to relocate.  I think that the first one I would aways hit with this problem was  libpangoxft-1.0.0.dylib.  After hacking up a solution, I believe there were a couple more in the stack that I needed that would present the same problem.

It turns out that the problem is one of space.  When the dynamic libraries for MacPorts are created, they encode the full path of the library into the header, which is something like /opt/local/lib/libpangoxft-1.0.0.2203.1.dylib.  When Py2App goes to relocate the library into the package, it needs to change this to a relative path which points to its location in the package relative to some other object.   It would appear that if the length of the original string is shorter than the one it needs to become in the package, the relocation logic used by Py2App is stuck and thus dies with the above error message.

The Py2App author indicates that the only solution to the problem is to re-link the library with an option that will instruct the linker to create the maximum amount of space for the library name in the header, despite what is requires at link time.  This ensures that the relocated library path name will fit in the space allocated.  It turns out that in addition to the prescribed option, the -Xlinker option is also required to make some component in the chain obey the request to pad the header.  This bit took me quite a while to figure out.

I figured that the safest (and easiest to reproduce) option would be to convince MacPorts to build everything with this option instead of trying to insert it into the build environment of only the affected libraries.  To do this, I modified the port command’s library file where the default configure options are held.  For me, this was /opt/local/share/macports/Tcl/port1.0/portconfigure.tcl.  I edited the line starting with default configure.ldflags to look like this:

default configure.ldflags   {"-L${prefix}/lib -Xlinker -headerpad_max_install_names"}

After doing that on a fresh install of MacPorts, I proceeded to build the required stack.  In the end, Py2App agreed to relocate everything into the app package and it worked well.

Since I’ve got this going, I will point out an additional issue that I ran into in the whole process, which took some actual work to figure out.

The problem was with the pango configuration files.  These normally live in /etc/pango, or /opt/local/etc/pango in the MacPorts installation.  These must be in place in the App package or the pango library will not properly render fonts.  Moreover, the configuration files must properly point to the relocated objects within the package.

In order to capture the act of copying and modifying the pango configuration scripts, I wrote the following script which can be run after the App build is complete:

#!/bin/bash

make_pango_modules() {
        local src=$1
        local dst=$2
        local sf=${src}/etc/pango/pango.modules
        local df=${dst}/etc/pango/pango.modules

        cat $sf | sed ‘s//opt/.*/lib/../Resources/’ > $df
}

make_pango_rc() {
        local src=$1
        local dst=$2
        local sf=${src}/etc/pango/pangorc
        local df=${dst}/etc/pango/pangorc

        cat $sf | sed ‘s//opt/.*/etc/./etc/’ > $df
}

make_pangox_aliases() {
        local src=$1
        local dst=$2

        cp ${src}/etc/pango/pangox.aliases ${dst}/etc/pango
}

usage() {
        echo ‘Usage: make_pango.sh [PATH_TO_MACPORTS] [PATH_TO_APP]’
        echo ‘Example:’
        echo ‘  make_pango.sh /opt/local dist/d-rats.app’
}

if [ -z “$1” ]; then
        usage
        exit 1
fi

if [ -z “$2” ]; then
        usage
        exit 1
fi

base=$1
app=”$2/Contents/Resources”

mkdir -p ${app}/etc/pango

make_pango_modules $base $app
make_pango_rc $base $app
make_pangox_aliases $base $app

By running this script with something like:

./make_pango.sh /opt/local dist/myprogram.app

You’ll get a properly configured pango environment.

Posted in Codemonkeying Tagged

February 5, 2009
20:57
by: Dan

Running strerror() from the shell

Reasonably often, I have a need to convert an errno variable to its string error message right at the shell.  This seems to come up relatively often in kernel development, but occasionally elsewhere.  Where I can, I usually just go for a printf(“Error: %mn”Smilie: ;) or printf(“Error: %sn”, strerror(foo)) directly in the debug statement I’m adding.  However, %m doesn’t work in the kernel and occasionally I either want or have to avoid recompiling something that just prints the integer value.  Chasing the header file chain to figure out what a given error code is can be time consuming and silly, but I’ve done it.

Recently, I’ve been trying to notice when I do stupid things repetitively and take the time to write a helper script or shell alias to prevent wasting effort the next time I need to do a particular task.  I have a collection of shell aliases, but I also keep a ~/bin directory with helper scripts for things that fit that mold better.  To solve my errno issue, I wrote the following today and stored it in ~/bin/perror:

#!/usr/bin/python

import os
import sys

for i in sys.argv[1:]:
    i = abs(int(i))

    print “%3i: %s” % (i, os.strerror(i))

It could probably be done smaller in a shell alias that calls perl or something, but oh well.  This is pretty handy so I can quickly get a couple of values:

% perror 111 22
111: Connection refused
 22: Invalid argument

I’ve already used it several times today, so it was definitely worth the 2 minutes it took to codify it.

Posted in Codemonkeying

February 3, 2009
00:34
by: Dan

A CI-V interface box for my IC-718

This weekend, I met some local ham geek types at a restaurant for breakfast.  The group is really focused on QRP, but they asked me to come and show them D-RATS.  They’re mostly hardware-focused, and probably more interested in the world below 30MHz than anything else (thus making D-STAR relatively low on their list of interests).  Either way, I’m not one to turn down a chance to geek out with smart people, especially at breakfast.

While I was there, Jason NT7S pulled out his EeePC running Linux and fldigi, which I also run.  I noticed that his screen was displaying the rig frequency and proceeded to ask him if he had a CI-V interface for his radio.  Later, I learned that this is the default layout in the newer version of fldigi (to which I have since upgraded), but his answer was “yes” anyway.  In fact, he too has an ICOM IC-718 and like me, doesn’t like buying cables and interface hardware for insanely inflated prices.  He mentioned that he was using a homebrew interface circuit and pointed me to it.  I had seen this particular site before, but gained new motivation knowing a living, breathing person who had successfully used it.

This afternoon, I set out to prototype the circuit on a breadboard and was tickled when I got it working.  I quickly transferred all of the components to a small perfboard mounted in a project box and ended up with this:

 

 

 

 

Now, I can use another serial port to interface with the 718, which gives me control over the settings from the software, as well as a live frequencyin my logs.  I’m looking forward to the next contest so I can try it out.  Before then, I may add an external LED (there is one surface-mounted on the board already) to indicate operation, a panel-mount jack instead of the pigtail, and an additional transistor to key the radio from the RTS signal.  As it stands now, I’d still need to use my RigRunner box to key the radio, and thus two serial ports.  Unfortunately, the 718 doesn’t allow you to key the radio with CI-V, but adding some additional components to my box will make it possible to cut it down to a single serial port by using the RTS line.

Posted in Radio

January 25, 2009
08:57
by: Dan

A year ago today…

A year ago today (January 25th, 200Smilie: 8), I released the first beta version of D-RATS.  It was version 0.1.1 and was posted for early testing with my local ARES group.  I had been working on the code for about a week at that time and had just gotten enough working (about 1,900 lines of code) that I felt it was worth testing.  Soon after that, I released 0.1.2, which I considered the first non-beta version.  Interestingly enough, the screenshot at the top of the D-RATS page is still of version 0.1.2…I should probably update that soon!

Anyway, 0.1.1 was interesting because it represented a lot of firsts.  It was my first GUI Python program, and the first time I had used PyGTK.  It was my first attempt at a Windows application (well, since Visual Basic back in middle school) and certainly my first time trying to package a Python program with Py2EXE.  It was also my first attempt at implementing the XMODEM protocol, which I thought was how I would do file transfers over the radio.  Since then, it has become obvious that XMODEM (and variants) won’t work because the radio is not 8-bit safe.

Now a year (and 30 releases) later, D-RATS has grown much larger than I had ever imagined (about 16,500 lines) and does things I never anticipated when I started.  Who knows where we’ll be on January 25th, 2010!

Posted in Radio

December 19, 2008
07:39
by: Dan

Outpost on Linux with WINE

I recently decided to play around with packet radio while I had some time off of work for the holidays.  I just wanted something to get my feet wet with, not knowing if it would be something I really wanted to get into.  So, I ended up with a pair of Kantronics KPC-2s for the right price of $25 total.  Interestingly, these are from the mid-eighties and the manual describes how to interface to computers like the VIC-20, C64, Apple II, etc.  Even though I have a working VIC-20 up in the attic, I decided I’d go forward with my modern PC.

The local group uses Outpost to connect to packet BBSes for message exchange.  Even though this is a Windows app, I decided to play nice and do what I could to set myself up to use it.  I immediately tried running it under KVM, passing my serial port through.  It worked just fine, which meant I had a reasonable solution at the very least.  However, this is less than ideal because it requires me to run a full copy of Windows, and it requires me to dedicate a serial port to KVM whenever it’s booted (since KVM doesn’t let go of it while running).

So, I went down the path of running Outpost under WINE.  The program installed fine and seemed to run normally.  However, it refused to speak to the serial port properly.  I could see that it was opening the port, and I could even send commands to the TNC but no serial data would flow back to Outpost.  Running under CrossoverOffice and regular WINE, I’d get the following errors:

fixme:comm:set_queue_size insize 1024 outsize 512 unimplemented stub
fixme:comm:GetCommProperties (0x80 0x32f514 )

Some diggging seemed to reveal that this may be related to my use of a USB-to-serial adapter, although I’m not sure how.  Since it’s not likely I’ll be increasing the number of machines in my possession that have real serial ports, I figured this was mostly the end of the road for using Outpost under WINE to access the serial port.  I’m not a Windows programmer, so I wouldn’t know much about how to even bring it up with the Outpost folks.

Not to be defeated, I decided to try another approach.  Outpost has the ability to connect to a BBS over telnet directly, without using a TNC.  Since networking under WINE usually works quite well, I decided to try to work up a proxy.  I ended up with a small C program that opens the serial port and listens on a socket.  When it receives a socket connection, it instructs the TNC to call the BBS and proxies the traffic until a disconnect occurs.  The result is that I can use Outpost directly in WINE, talking to my proxy program running natively in Linux.

It’s a total hack, but it works, and it also means that you can remote your TNC and radio from the machine you run Outpost on, which can be kinda handy.  If you’re interested, you can grab the source here.  Note that you should configure Outpost to send no password, and set the username equal to the BBS you want to connect to.  The proxy will read the login and use that callsign in the connect command to the TNC.

Posted in Radio