John’s Blog

I wrote in January that I had done some testing of Darren, G0HWW’s DTN over AX25 (also know as Packet Radio) Implementation. At the time we really only wanted to see if it worked. Since then I have been quite busy in my day job, and not had a chance to really do any more testing up until recently.

In the last few weeks had some free evenings and devoted it to testing the Darren’t DTN implementation against ‘raw’ AX25 connections with different AX25 window sizes from 1 – 7. I used a test file size of 9744 bytes (a NASA format keplerian element set that was handy) over at 1200bps AX25 link.

For the raw AX25 test, I connected from one node to another over and had the test file waiting for me in an email (using axmail). I recorded the wall clock time from when I pressed return until the command prompt was returned.

For the DTN test, I used the dtncp command to send the file and I started recording from when I pressed return on the command line. Obviously there is a problem there in that the AX25 test has to transmit the command before it can receive anything, whereas dtncp immediately starts transmitting, but as I only wanted to get a ‘feel’ for the figures, I think it will suffice. Several runs of each later (to get average figures) we have:

I’m not an AX25 expert by any stretch of the imagination, so we had several false starts trying to get working settings for the various timers that are part of the AX25 implementation. None of them were set to ‘optimum’ but really I just increased T1 and T2 in line with the Window parameter until it worked reliably.

Several things surprised us. Firstly, Darren’s implementation is not as bad, performance wise, as we thought it would be. At the moment, no effort been made to streamline the implementation but it is designed to be highly robust in the event of data transmission errors. Secondly, all data was transferred successfully on every occasion, always good . Also, on average, the overhead (if we ignore the window of 1 and window of 7), is between approximately 17% and 21%. The figures for the Window set to 1 (above) is a special case in that it forces an almost ’round-robin’ transmit cycle on the two participating stations. Setting it to 7 seemed to trigger a bug, but we don’t know where exactly. In fact the picture is much worse than that. 1 in every three runs took almost 5 minutes to complete as the two stations got completely out of sync AND it looks like Darren’s code (or the kernel) wasn’t honouring the window of 7. In reality though, it would be seldom that one would attempt to use a window size of 5-7 on a shared frequency due to the likelihood of being ‘trod on’ by another station.

All that said, it’s pretty reliable. If your are interested in giving it a try, email Darren, his details are at the bottom of this page, describing his implementation.

Now, back to writing QSL Cards. Shamefully, I’m several years behind.

Dissapointingly it has taken far to long to get back to this (see my earlier post), but recently Darren and I managed to be both online over the same few days to organise some testing. The infrastructure has changed slightly, in that the testing is now taking place through an AX25 Digipeater on a 1200bps Packet Channel, with the nodes being approximately 32Km distant from one another.

Both machines were Ubuntu 8.04, with kernel 2.6.17 on my end, 2.6.24 on the far end, latest ax25 utilities and tools.

My end was used to bring up the link every time (The far end has no /proc/ax25, so I can’t sent the ax25 parameters remotely, I’ve to change/rebuild the kernel afaik)

Through the digi we used the following settings when setting up the kiss ports. Txdelay of 150ms, paclen of 255, maxframe set to 1.

We quite quickly identified a problem with ‘chattyness’ (the locals got upset), and Darren did some re-work. Since then its performing much better, and the locals are much happier. I was away for a bit and Darren has updated the code some more, so more testing for me I think.

Given that I’m looking at this from an Emcomm/AREN point of view, I’m really pleased with how its progressed so far, and I think Darren may even be considering sending the code ‘upstream’.

./configure ; make; sudo make install

Almost 12 months ago Darren, G0HWW sent this post to the linux-hams mailing list. We exchanged some emails discussing how Delay Tolerant Networks (DTNs) could be used for Emergency Communications (being a classic store and forward network). In a DTN network, each sub-net or point-to-point link can operate over whatever stack is available, in this case it is AX25. In August Darren became aware of some work done in Helsinki University of Technology (under Joerg Ott) specifically a paper entitled Opportunistic Email Distribution and Access in Challenged Heterogeneous Environments. Joerg forwarded Darren their DTN Mail Proxy and we started experimenting with it.

Last weekend, we went a step further. Darren sent me on patches to the DTN2 reference implementation that implement an AX25 Convergence Layer. As I had a working 9600 baud AX25 connection we were eager to test it. After some patching, head scratching and recompiling we were able to successfully pass email from my Laptop over AX25 (439.850MHz) to my Linux server, then over the Internet to Darren’s server and on to his mailbox. All using the DTN bundling protocols. Very cool!