Data (RTTY/PSK) contesting – The anatomy of an ideal QSO

I like contesting.  I like data contesting and I operate a lot in data contests.  I don’t generally have the time to dedicate to making a winning entry although for the big events, I’ll try and make a good score and aim to finish high up in the table.  I’ve done well enough though and hold the current G record in the single op 15m high power section of CQ WPX RTTY.

I’m going to detail how I think the ideal contest QSO should be.  This is my opinion, there’s no right or wrong here but this is how I’d like it to be.

The example here is of a RTTY contest QSO but the format for a PSK contest QSO is pretty similar, I mention PSK specifically towards the end of this post.

The most important thing (in my opinion) is to make sure there’s no ambiguity in the info you send.  That means sending it THREE times.  If you send your callsign once then there’s a chance that one character may get corrupted.  I won’t know it’s wrong and if you don’t correct me then I’ll log it wrong. If you correct me, it’s wasting time.  If you send it twice and one character is corrupted in one instance, I won’t know which is correct and I’ll ask for a repeat.  This wastes time.  If you send it three times and one character is corrupted then I have two other instances which are correct and can work out which is the right version.  The chances against the same character corrupting in two of the instances are minimal so sending your callsign three times is the best way.

I think that each period of transmission should be headed by one or two characters to allow the other stations software to lock and ensure nothing is missed.  I personally send a CR/LF followed by a space at the start of each transmission.  At the end of your transmission, DO NOT include a CR/LF but do include a space before you switch back to receive.  There are reasons for each of these.

Lots of software allows the operator to double click on the callsign and it’s recorded automatically.  It’s really frustrating to move the mouse over a callsign on the screen and double click just as the other station transmits a CR/LF and the screen scrolls so you miss the callsign.  By not sending CR/LF at the end of your macro you stop this happening.

I end all of my transmissions with a space.  The reason for this is that when a signal drops, the receiving station will be running unsquelched and the chances of picking up a random character on the end is very high when that happens.  Those extra characters can cause confusion and force repeats.

So my initial CQ call is this:


[TEST] is completely optional.  Some contest organisers specify what the CQ call should be.  The majority of the time, I won’t include it, sometimes I will.  For the CQ WPX contests, I’ll call CQ WPX.

The CQ at the end is for anyone who might be tuning past and who has missed the start of the transmission.  They won’t know if I’m calling CQ or working someone.

The perfect reply, bearing in mind all the above would be this:


That’s good.  Vlad has sent my callsign so I know he’s calling me and then he’s identified himself three times.  Some argue that he doesn’t need to send my callsign because I already know what it is.  This is true but I’ve had UBN reports where I’ve looked back at the saved transcript and although it looks like the station was calling me, he was actually working someone else on the same frequency.  It’s rare but it does happen so it doesn’t hurt to give the callsign of the station you’re calling.

He’s got my callsign, I’ve got his so I reply.  This contest is serial numbers and I’ve been busy so my reply is as follows:

“<CR/LF> UT3ABC 599 437 437 437 UT3ABC ”

I’ve started off with CR/LF and a space again, given his callsign then the signal report, followed by the important part of the exchange, the serial number which I’ve repeated three times for reasons as described above.  I’ve finished off with his callsign.  Notice that I’ve not repeated my callsign, he’s already got it and doesn’t need it again.  However if he got it wrong when he called me, I would send the correction now.  I use the other stations callsign twice, it shows him that I’ve received it and logged it correctly.  If I’ve got it wrong, now is the time for him to correct me.

In my opinion, his perfect reply would be:

“<CR/LF> G6NHU 599 034 034 034 [xxxxx] ”

My callsign again, it’s like a final check, the signal report just once because the report is always 599 and then the exchange three times.  [xxxxx] is optional, it doesn’t need to be there but if it is, it can be either my callsign or his, I don’t care. Then the space before the end of transmission to finish.

I finish with a simple reply:


His callsign, TU for thank you followed by my callsign and a CQ.  The TU acknowledges his exchange then I identify and go straight back to a CQ.  As soon as he sees the TU, Vlad will be tuning away.

I don’t want to see someone send my serial number back to me, I don’t want you to say “Hi Keith” (because you’ve mined my name from, I don’t care about 73 GL at the end and I don’t want a row of ……. or RYs to start the transmission.  A contest exchange should be short and to the point.

If it’s a RTTY contest, I don’t want you to send 5NN as a report because that shows an ignorance of how RTTY works and more importantly, it wastes time.  Unlike CW, it takes longer to send 5NN than it does to send 599!   There are a limited number of characters that make up the RTTY Baudot code and switching from letters to numbers forces an extra character.  When someone sends 5NN they’re actually sending <FIGURES SHIFT>5<LETTERS SHIFT>NN instead of just <FIGURES SHIFT>599.  It’s wasting time and achieves nothing.

I’m all prepared if someone asks me for a repeat and I suggest everyone has a similar macro key set.  If I send “NR NR” then I don’t want your entire exchange again, all I want is your serial number.  Set up a macro which repeats just that a few times: “<CR/LF> 437 437 437 437 437 437 “.  Note again the usual CR/LF and space at the front and trailing space at the end.

If it’s a PSK contest, send as much info as possible in lower case.  It’s quicker to send lower case than capitals due to the way characters are formed.  PSK uses a varicode system where more commonly used characters are shorter than less common ones, for example an ‘e’ is encoded as ’11’ but an ‘E’ is ‘1110111’ and so takes much longer to send.

All my contest macros are tuned around the procedure and the exchange I’ve detailed above and I think I’ve got them pretty much spot on.  If you don’t agree with me or have other things to suggest, I’d love to hear from you using the comment form below this post.


Add a Comment
  1. Nice entry – Makes a lot of sense. I changed a few of my macros to reflect some of your musings. I’m seeing a lot of “sensible” macros but have spotted 1 or 2 Russians using 5NN *gulp*.

    The space and carriage-return is a good one – My PZTLog software offers a double-click and omits various symbols so it can pick out a Callsign, Locator, Name etc but I’ve also seen a fair amount of 599-001 599-001 which is fine if a) you like another character and b) your software can separate the fields!

  2. Never thought about tuning the macros, but you’re right. The faster you can send, you can make some more QSOs in the same time. I’ll check my own macro’s next time before contesting PSK. 73, Bas

  3. What you say makes a lot of sense to me! Even though I’m quite new to data modes your explanation of how and why are not just informative but make a huge amount of common sense. When I get home tonight I think I’ll be editing some of my macros 😉


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.