PSKmail-0.1 (C)2005 Rein Couperus PA0R






What is PSKmail?

What can I do with PSKmail?

I use PSKmail wherever I am mobile (camper, boat) for some time and want to upload software patches and I have no connection to the internet. I also use it to get and send ham-related email, and download bulletins like weather warnings , navtex bulletins and propagation info.

The system is not fast, average throughput is 5 characters/second. This means ASCII TEXT only. It is also possible to send pictures etc. if you code them properly, but you can easily calculate yourself how much time it takes to send a 50 kByte picture (HINT: 50.000/300 minutes).

How does PSKmail work?

PSKmail uses a client/server architecture.

The server is connected to the internet, and uses standard protocols like POP3, SMTP and wget to handle the internet data. User ID's, passwords, ISP names are stored in a database on the server, which means users have to register before they can use the system.

Both client and server use the gMFSK program with the Soundcard of your computer to talk to the radio. You do NOT need a special controller like a PTC.






The protocol used at the link layer has been defined by Paul Schmidt, K9PS.

PSK63 was invented by Skip Teller, KH6TY to create an alternative to RTTY for contesting.

gMFSK has been written by Tomi Manninen OH2BNS. As gMFSK only supports keyboard-to-keyboard operation, it has to be changed slightly in order to allow operation in a server/client configuration.

The link layer protocol can be compared to Packet Radio. It is connection oriented, and there can be only 1 station connected at a time.

The protocol allows multi-stream connects in the future. At the moment that capability is not used, only the mailbox application (port 24) is active at the moment. In future also ftp/tty/telnet applications can be supported. Also the protocol version is fixed.

What is the difference between PACKET and PSKmail?

The main difference lies in the underlying layer1 protocol. Packet radio uses 300 Baud AFSK, PSKmail uses Phase Shift Keying with 100/63 Baud. PSK63 uses varicode encoding, resulting in 100 Baud for lower case characters and 63 Baud for upper case characters (CAPITALS).

The difference is in the BANDWIDTH... A 300 Bd Packet channel is 2.4 kHz wide, PSK63 does the job within 100 Hz !!!! A typical PR packet is 128 -256 bytes long, making it extremely vulnerable to knock-outs. PSKmail uses packets from 16 to 128 bytes, depending on band conditions.

That is a ratio of 5 cps/100Hz = 1:20 compared to 12cps/2400Hz = 1:200, a factor of 10 in favour of PSKmail !!

Why not use WINLINK2000? That is much faster!

The WINLINK2000 system is based on PACTOR PTC controllers. Most, if not all WINLINK2000 nodes now use PACTOR2 or PACTOR3. You can not work these modes without PAYING YOUR TRIBUTE TO SCS and MICROSOFT(TM). You can use their websites to work out how much you have to pay (the freeware Airmail program only works under Window$, and you must buy a PTC2e to run it).

Moreover the BANDWIDTH of a PACTOR3 system is in the order of 2400 Hz, a factor of 24 larger than PSK63!! The PACTOR3 systems can be considered commercial systems, and their users become more and more popular :) Again, you can work out the bandwidth efficiency yourself...

If you want to use WINLINK2000 anyway, DON'T read on....

In practise PSK63 is a lot faster than RTTY, and delivers the text (upper- and lowercase) unmutilated.

What is the difference to PSK31?

PSK31 is half the speed, and half the power. So PSK63 as a keyboard-to-keyboard protocol is twice fast as PSK31, and you have to run 10 Watts instead of 5 Watts. PSKmail puts protocol overhead on top of that. Depending on block size, protocol overhead is 50% (16-character blocks with 8 extra bytes), down to 6% (128-character blocks with 8 extra bytes). By the way, the average throughput of 5 cps was measured at 64-character blocks). As a frame normally contains 8 blocks, turnaround loss is much less important then the number of repeats.

The repeat strategy of PSKmail is to repeat only missing blocks. So if the client misses only the 3rd block out of a frame of 8, only block 3 has to be repeated.

Another difference with respect to PSK31 is that the frequency accuracy of the server is (2x) less crytical at PSK63. Also the path path phase error has less negative influence. In principle we could also use PSK31 as the underlying mode. I have had good connects with PSK31 when PSK63 failed. Theory and practise are in alignment here.... BTW, also MT63 or MFSK can be used. The problem with those modes is the turnaround time which is not suitable for arq operation. Unless you use MT63 with 2 kHz bandwdth, but then you are back at square 1. The arq system more than outperforms any FEC scheme...

How does PSK-arq work in theory?

PSK_arq cuts the text into blocks of 16 – 128 characters, depending on band conditions. Small blocks when there is a lot of QRM or QRN, large blocks when the signal is steady and the channel is clear. The blocks are numbered and they all get a sequence number from 0 to 63. They also get a CRC16 number so the receiver can see if the block has been received ok. The transmitter sends 8 blocks in a frame. The receiver checks every block against its CRC checksum and tells the transmitter with a short status block which text blocks were damaged. These will be prepended to the next frame, so the receiver gets another chance. This goes on until the text has been received 100%.

How does it work in practise?

I have a test server running on 10.148 kHz, at PI4TUE in Eindhoven. The distance of 20 km gives me a 95% reliable ground wave connection. Powers used at both ends is 10 Watts. The server uses a dipole, the test client is operated from my camper, and uses a fishing rod antenna (sort of an inverted L). 95% reliable means 1 out of 20 blocks has to be repeated, which means hardly any delay. In fact, it works a lot better than PACTOR 1 with my MFJ 1268 controller !! And we use only 100Hz bandwidth!!

I have tried the system from Le Havre in France, a distance of 422 km from the server. It worked 30% of the time, but the f0F2 MUF was only 4 MHz, and the server should have been on 3.5 Mhz instead of 10.148 Mhz to provide reliable NVIS connection!! At first I did not understand what was happening here. 1000 km was a piece of cake, 150 km impossible. I am studying the f0F2 charts regularly now. Even as I am writing this (13:30 GMT) , the f0F2 MUF is 10 MHz in 1 spot only on the globe: in the middle of the SAHARA desert. In Eindhoven, at the server location it remains below 5 MHz during 24 hrs!

I am already using gMFSK, do I need a new version?

Yes, you need a special version of gMFSK. That is because gMFSK only supports keyboard to keyboard operation. For use with PSKmail gMFSK must:

For the client:

For the server:

I hope this functionality will be built into gMFSK eventually (whatsay Tomi?), for now you need to install the special version (which also allows you the normal operation you are used to...).

What about the mail database?







PSKmail does NOT use a centralized mail database like WINLINK2000. Instead PSKmail can use any ISP POP account and sends your outgoing mail via SMTP to a trusted relay. That means the only Data Base necessary is a USER DATABASE. The user database is no more than a list of ISP's, user-id's and passwords per registered user. As the Database sits on the internet side of the gateway no passwords are visible on the RF connection.

So the principle is decentralized mail database, centralized user data. This concept also allows easy implementation of other services like weather, navtex, propagation bulletins. I also implemented a simple APRS solution.

APRS?

Yes, APRS update via PSKmail is only 1 click away (use the POS. button).





Can I help?

At the moment the system is in beta test. The client and server software has been uploaded to this website . There is no documentation other than INSTALL for client and server. The user database handler is ready, and is contained in the server archive.

If you want to deploy a server for testing, please contact PA0R@EUDXF.ORG. Or even better, figure it out for yourself and tell me what problems you had (->documentation!).

If you want to test the PI4TUE server on 10.148 MHz, please register at PA0R@EUDXF.ORG (need to know your ISP, user_id and password for POP; Call and passwd for posit@findu.com.

Why 30 meters?

30 meters is a good band for testing, being quiet even during weekends (no contests). The only problem is PACTOR stations who do not listen before they connect their servers, but most of the time the 100 Hz bandwidth wins. It is good for ground wave communications. It is not good for NVIS communications. That would need a station on 3.5 MHz at this point in the solar cycle.

What next?

PSKmail is not finished, but ready for testing. There are still a few things missing in the protocol. (reject block, stream id, ports other than 24). I am building this system for my own use, for propagation experiments and for use with the locals. The software has been released under GPL. I will also try to put it on a (Morphix) live CD so I can use it for log upload during Dxpeditions, and the INSTALL for the client is easy. I will not deploy an global network like WINLINK2000. There may be others who may want to do that, it will be extremely easy. The system also has potential use for ARES and especially mobile applications (only 10 Watts needed for a working NVIS system). It would be nice though to have a few (manned) servers available some 1000 km from Eindhoven for use with mobile stations. With 3 servers we could cover Europe. If you are interested, please contact the author.

The software can be downloaded at:

http://sharon.esrac.ele.tue.nl/pub/linux/ham/pskmail/ (archives).

Acknowledgements:

The protocol specification was written by Paul Schmidt, K9PS.

PSK63 was invented by Skip Teller, KH6TY

gMFSK, the best linux program for digital modes was written by Tomi Manninen, OH2BNS.

Contacts

Bug reports and comments to: Rein at Couperus.com, PA0R at EUDXF.ORG

There is now a WIKI at http://pskmail/wikispaces.org



Last change: PA0R 10/August/2005