15 February 2013

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.

No comments: