Henk, PA3GUO has made a video showing the ISS passing over his location while both transmitting through and decoding the APRS data being relayed through the ISS AX.25 repeater. The video is available here.
It seems that POLLUXs batteries have gone flat.
I posted before about using the Airmail through Wine on Linux to access the Winlink system. It’s fine, it works, but it is a lot of overhead. Recently, in a response to a question, Dana, KA1WPM posted to one of the Winlink email lists that I’m on about the existence of paclink-unix. Paclink-unix was started by Nick Castellano, N2QZ.
Now I had seen this mentioned before, but for whatever reason I never took the time to look at it. This time I took a closer look.
After downloading the source and having a quick browse, a few small modifications had to be made.
mime2wl.c I changed Nick’s call-sign to my own. The same had to be done in
in wl2k.c I changed
asprintf(&command, "%s -ba %s", SENDMAIL, emailaddress)
asprintf(&command, "%s -bm %s", SENDMAIL, emailaddress)
Next the configuration. After (very) briefly consulting the postfix docs. I came up with the following:
transport_maps = hash:/etc/postfix/transport
wl2k unix – n n – – pipe
flags=RXhu user=j0n argv=/usr/local/libexec/mail.wl2k
I mostly copied the maildrop line already in the configuration file. removing the ‘D’ in the flags and adding an ‘X’. I’ve not yet tested whether I need the ‘D’ or not.
X indicates ” Indicate that the external command performs final delivery. This flag affects the status reported in “success” DSN (delivery status notification) messages, and changes it from “relayed” into “delivered”.”
So anything destined @winlink.org now gets sent through the local transport.
That’s pretty much it for the moment.
If I need to send to any other domains through winlink I could add the following “catch-all” to the transports file.
And everything would go through it.
Testing it then I sent myself an email at winlink.org, and tried to collect it using the supplied tools.
j0n@ns1:~/src/paclink-unix-0.3$ sudo wl2kax25 EI7IG "EI8IG-10 v EI2WRC-4" 1200 60 ei7ig@localhost
wl2kax25: sid [WL2K-220.127.116.11-B2FIHM$] inboundsidcodes -B2FIHM$
>; EI8IG-10 V EI2WRC-4 DE EI7IG QTC 0
wl2kax25: proposal code C type E mid 6L9CAL8YBRST usize 274 csize 236 next (nil) path (null) ubuf (nil) cbuf (nil)
wl2kax25: sentcksum=79 proposalcksum=79
wl2kax25: 1 proposal received
wl2kax25: title: Testing Postfix
wl2kax25: offset: 0
wl2kax25: len 236
wl2kax25: calling sendmail for delivery
wl2kax25: delivery completed
wl2kax25 is like fetchmail. It connects out over a linux ax25 port (i.e. Radio) to a winlink node and retrieves it to be delivered to an email account of your choosing. In the above example, the winlink node is approximately 35km away, but not accessible directly. Consequently I used the EI2WRC-4 digital repeater (digipeater) to relay my packets.
For a ‘pre-alpha’ piece of software, it is working nicely for me, and it is good to have a Linux “Native” winlink client. Many thanks to Nick and Dana for their efforts.
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:
|Window Size||“Raw” AX25 (seconds)||DTN over AX25 (seconds)||Delta (seconds)|
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!