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.