Testing the AX.25 CL for DTN2

I received an email suggesting that I might like to test the AX.25 Connected Mode Convergence Layer for the DTN2 reference implementation, as some tweaks had been made to it upstream.

I updated the DTN2 source code on the two Linux machines that I use for testing the AXCM-CL with and rebuilt it.  The shack PC (upstairs) is hooked up to an FT-817 transceiver using an SCS Tracker/DSP-TNC.  The FT-817 uses it's rubber duck antenna and operates at the lowest power setting. Meanwhile, downstairs, my Lenovo laptop is hooked up to a Kenwood D72 (a hand-held radio with a built in TNC), also operating at its lowest transmitter power setting and using a short stubby dual-band antenna.

For monitoring the traffic, I decided to use my USRP & WBX daughter-board combo, using the Software Defined Radio program gqrx to demodulate the narrow-band FM signals and decode the 1200 baud AX.25.  This also runs on my Lenovo laptop downstairs, leaving me free to avoid entering the messy shack.

Here's a screen-shot of some AX.25 shifting a 35kB adif format log file on 70cm using the dtncp utility.

I pushed the adif file from the laptop to the machine upstairs and then onto the node at delaytolerant.net by means of a TCP convergence layer connection, where it was received by the dtncpd utility.  I confirmed that the md5sum of the file payload matched that determined at the sender manually.

Here's the result of probing the test network using dtntraceroute to a wildcard address:

darren@len:~/dtnrf$ dtntraceroute -e 3000 -w 6000 dtn://*/ping
source_eid [dtn://g0hww-6.dtn/traceroute.14414]
using default replyto
dtn_register succeeded, regid 25
dtn://g0hww-6.dtn/traceroute.14414: sent at Fri Feb 15 16:44:07 2013 UTC
dtn://g0hww-6.dtn/ping: echo reply at Fri Feb 15 16:44:07 2013 UTC (342 ms rtt)
dtn://g0hww-6.dtn: delivered at Fri Feb 15 16:44:07 2013 UTC (386 ms rtt)
dtn://g0hww-6.dtn: forwarded at Fri Feb 15 16:45:42 2013 UTC (95138 ms rtt)
dtn://g0hww-7.dtn: received at Fri Feb 15 16:45:33 2013 UTC (97749 ms rtt)
dtn://g0hww-7.dtn/ping: echo reply at Fri Feb 15 16:45:33 2013 UTC (99882 ms rtt)
dtn://g0hww-7.dtn: delivered at Fri Feb 15 16:45:33 2013 UTC (106687 ms rtt)
dtn://g0hww-7.dtn: forwarded at Fri Feb 15 16:45:33 2013 UTC (113715 ms rtt)
dtn://hambone.delaytolerant.net: received at Fri Feb 15 16:45:34 2013 UTC (116127 ms rtt)
dtn://hambone.delaytolerant.net/ping: echo reply at Fri Feb 15 16:45:34 2013 UTC (118282 ms rtt)
dtn://hambone.delaytolerant.net: delivered at Fri Feb 15 16:45:34 2013 UTC (125148 ms rtt)
dtn://g0hww-7.dtn: received at Fri Feb 15 16:45:39 2013 UTC (135215 ms rtt)
dtn://hambone.delaytolerant.net: forwarded at Fri Feb 15 16:45:39 2013 UTC (142659 ms rtt)

This overlapped with the file transfer using dtncp, resulting in some head of line blocking and an RTT of about 2 minutes.

No testing of the DTN would be complete without firing up what might be called a killer app for this specific domain, my awful dtnchat application, available here.

It looks like the screenshot below (which is the nicest view, the Preferences tab is even worse).  It does work though. It uses wxPython and the DTN2 Python bindings.

  
This is me talking to myself through the DTN over AX.25. The hideous notification at the bottom is probably due to it coming via a remote X session over SSH, along with the application instance on the right.

First night of the shadow-beacon experiment.

I've submitted the first nights logs for the shadow beacon experiment. I was initially confused about the desired format but on careful reading of the FAQ, it became apparent that 'arbitrary' formats are acceptable, so went for a filtered dataset from the aprx-rf.log file that showed only receptions from my satgate, G0HWW-4 containing the string RS0ISS. The full logs, with time stamps are here.

At first I didn't notice anything unusual, and then I realised that there were two digipeaters active.  The first clue was in a beacon from Nigel, G4DCQ:

G4DCQ-2>CQ,RS0ISS-4*::G4HBI    : Both Radio's running - RS0ISS & dash 4

 I wasn't really sure what Nigel meant, but then I noticed subsequent messages were being relayed by different digipeaters and some were coming via 3 hops:

G4DCQ-8>CQ,RS0ISS-4*,RS0ISS:=5255.81N\00117.76EL..JO02PW..g4dcq@yahoo.co.uk
G4DCQ-8>CQ,RS0ISS-4*,RS0ISS*:=5255.81N\00117.76EL..JO02PW..g4dcq@yahoo.co.uk
IK3ZGB-2>CQ,RS0ISS*:=4542.75N/01142.00E`73' Via ISS de Cris {UISS53}
IK3ZGB-2>CQ,RS0ISS-4*:=4542.75N/01142.00E`73' Via ISS de Cris {UISS53}
G4DCQ-8>CQ,RS0ISS-4*,RS0ISS::G4HBI    : Double Digi
G4DCQ-8>CQ,RS0ISS-4*,RS0ISS*::G4HBI    : Double Digi

If you look at the telemetry report for G0HWW-4 you can see an increase in activity the day before the experiment started, and another increase for the first day.  If you are viewing this page some time in the future, look for telemetry for the week starting 2013-01-28.

Update: Some time ago I received a QSL card.

AX.25 in the DTN2 Reference Implementation

As of August 2011, the AX.25 Connected Mode Convergence Layer is included in the DTN2 reference implementation version 2.8.0.

See dtnrg.org

KISSed off with the TM-D7E!

Over the past year or so, I've been implementing an AX.25 Connected Mode Convergence Layer for the DTN2 reference implementation of the Delay Tolerant Networking Research Group's Bundling Protocol.

Since I first posted in the Linux Hams mailing list about these efforts last April, I've been in contact with John, EI7IG, who's recently been trying out this code and has succeeded in sending bundles through the ether at 1200bps on 2m.

It works, but it doesn't work properly. There are two persistent bugs that I've so far been unable to sort out. Still, we've managed to string together a veritable hodge-podge of devices, using three different convergence layers (AX.25, Bluetooth and TCP) and have even had DtnMail running across this "het-net".

I've been getting jealous though, of John's success. You see, I've been testing the AX.25 Convergence Layer using an old PK-232 TNC running in KISS mode, with a loop-back cable. This morning, I decided to send my own bundles through my own ether. By this I mean the ether in my house. All I needed was an AX.25 connection from my MacBook Pro through my TH-D7E in my living room via one of the radios in the shack to my Ubuntu box upstairs.

The complicated bit in all of this is that I needed to use KISS mode on the D7. Now I've heard that KISS on the D7 is frightful, so I decided to google around and discover how bad it really is. I found posts that discussed the different revisions of the D7 and the bugs they manifested. I concluded that if I reduced the AX.25 window to one, and stuck to 1200bps link rate, I should be OK.

I decided to leave my TM-D700A and PK-232 out of the test setup, so I configured soundmodem to run on the Ubuntu box in the shack and hooked it up through the Tigertronics Signalink to my FT-817 with its rubber duck antenna. This meant that I could run a low power AX.25 link over 2m or 70cm to the D7 downstairs.

So I set up a Gutsy Gibbon virtual machine under VmWare Fusion on my MacBook Pro, installed libax25 and all the bits, installed the build tools, the mercurial source code management system, cloned the repository from my Ubuntu box with the experimental AX.25 code, built the code and sat down to test out the link.

With the D7 in Packet mode, it worked fine. With my D700 temporarily taken from APRS duties and pushed into service as a mailbox, the D7 connected happily. However, when I put the D7 into KISS mode and attempted to repeat the exercise with the call program, the D7 ignored all received packets and forwarded nothing over the serial link into the host's KISS implementation. Now, this was unexpected. I googled and googled and found no references to a problem with a D7 that wouldn't receive anything in KISS mode. I reset the D7 to factory defaults and tried again. I rebooted the Ubuntu VM. I monitored the link between the D7 and the D700 with the FT-817 and its soundmodem interface. Sure enough, the D7 was transmitting the SABM's and the D700 was replying with UAs, but the D7 steadfastly refused to pass anything on up via its KISS mode interface, even though I could hear the sound of healthy packets emanating from its loudspeaker. With the D7 out of KISS mode, APRS and connections to the D700's mailbox work fine, but KISS receive is as dead as a dodo.

Now, I don't expect anyone to actually comment here, but if anyone posts any suggestions as to what I could try next, or points out the obvious futility of my efforts, then I'll be grateful. Meanwhile, I'll be trying to come up with another cunning plan to get some sort of KISS mode link connection that's more interesting than a cable with some wires twisted together without having to dismantle the shack completely.