Topband: QSB surfing

[Tree]

Last night - I had a "QSB surf" QSO with OE3GCU.  This type of QSO uses 
a protocol that is similar to a moonbounce QSO.  Many people use it without
thinking about it - but I thought I would document it here for those who 
might not have been exposed to it.

Many times - DX signals here have QSB on them.  Often, stations like the 
JW's will be totally in the noise for minutes - then peak up for 30 seconds
with 579 signals.  During these peak times - it is possible that you are in
the spotlight and have an advantage over other stations calling.

It is important to make the QSO quickly during the peak.  It is also 
important to understand what is going on when the peak isn't there and
make sure you are "doing the right thing".

You can hear the QSB effect and a QSO made during it with this recording:

http://www.sm2cew.com/audio/bu2aq_5_090121.WAV

There is a very simple flow to a QSO made this way.  I will use RA4LW and
N6TR as callsigns in this example to illustrate how it works:

1. RA4LW calls CQs.  If he is aware there are people calling and trying to
QSB surf - he will call short CQs.  Nothing is more frustrating than hearing
a station fade out when they are calling a long CQ.  It was an opportunity
wasted.

2. N6TR calls RA4LW.  At this point, one of three things might happen:
  - RA4LW responds and N6TR hears the response.
  - RA4LW responds and N6TR does not hear the response due to QSB
  - RA4LW does not respond and CQs again.

It is important for N6TR to hear for sure that RA4LW came back to him before
moving on.  If N6TR hears RA4LW sending something - but isn't sure he came 
back - he should assume he was not heard - and the QSO stays in state #2.
When RA4LW is done sending - he should simply send his call again.  

3. If N6TR hears his call coming back - then he knows we are moving forward
with the QSO.  The next step is to see if he can get a report from RA4LW.
  - If N6TR hears the report - then move to state 4.
  - If N6TR does not hear the report - you are in a very critical point in
the QSO.  You know RA4LW has heard you and come back to you - but you did
not get your report.

At this point - I believe the best thing to do is NOTHING.  Just sit there
with you head on the table concentrating on the noise.  From RA4LW's 
perspective - he will think you didn't hear him come back and he will 
again send your call and the report - which is pretty much exactly what
you want him to do.  If he does this quickly - over and over - the QSB
will eventually peak - and you will get the report - and conditions should
be best for him to hear your report coming back.

Having someone trying to be helpful by sending "K" to you when RA4LW is
done sending is not very useful at this point.  Chances are - if you tried
to send something, RA4LW will not hear it.

4. When you hear the report coming back - you should send the report back 
without much delay or sending other information.  If you know he got your
call correct - don't bother sending it again.  If you think he got your
call wrong - send your call ONLY again and make him send it right before
going on.  The reason for this - is that once you send an RST - and it is
copied on the other end - the QSO is going to "complete" without any 
control on your part.  If you hold back sending a report - the other station
will keep trying to complete the QSO and might get the idea that he has
your callsign wrong and he needs to fix it.

The beauty about just sending your call again if he has your call wrong is
that he can't tell the difference between having your call wrong or that 
you just can't hear him come back.  In both cases - you want him to do the
same thing - send your call and the report again.  

An example:

RA4LW: CQ DX RA4LW RA4LW DX
N6TR: N6TR N6TR
RA4LW: N6TW N6TW 559 559
N6TR: N6TR N6TR
RA4LW: N6TR N6TR 559 559
N6TR: R 579 57
RA4LW: 73 TU
N6TR: TU EE
RA4LW: EE QRZ RA4LW DX

See how "the right thing" happened when the RST was not sent?  If you send
an RST and there was QSB when you sent your call again - this is what might
happen:

RA4LW: CQ DX RA4LW RA4LW DX
N6TR: N6TR N6TR
RA4LW: N6TW N6TW 559 559
N6TR: N6TR N6TR 579 579
RA4LW: (something QSB) 73 TU
N6TR: TU EE
RA4LW: EE QRZ RA4LW DX

Okay - what call does RA4LW have in his log?

5. When you hear RA4LW has your report - the QSO is over.  However, for extra
credit - the last exchange shown the above example is useful.  What is going
on there comes from something I learned from the JAs that operate the KCJ CW
contest.  Their QSOs sound a lot like this:

JA1ABC: CQ KCJ JA1ABC
JA2XYZ: JA2XYZ
JA1ABC: JA2XYZ 599
JA2XYZ: 599
JA1ABC: QSL TU EE
JA2XYZ: EE

now - maybe a new station calls JA1ABC - or JA1ABC calls CQ.

In the sound file above, you can hear BU2AQ do this with G3FPQ sending "73 TU" 
and hearing the response come back.  This really puts the icing on the cake 
for the QSO and both parties walk away knowing it took place.  

Using short cuts to this process will often lead to situations where one
party might not be 100 percent sure that the QSO took place.  

Here is a recording of such a case - where the QSO did not take place.  I
was guilty of pushing the QSO furthur than I should have - and ended up
being disappointed later when I found out I wasn't in the log:

http://www.kkn.net/~tree/160/3b7cQSO.mp3

I thought I heard enough of my call coming back that he had it.  He came
back with N6TA - and I thought there was no way he didn't know it was 
N6TR - I sent a report and lost control of the QSO.  When I heard him
CQing again - I thought he had finished the QSO with me.  

If I had just repeated my call - and not sent an RST - I would have known
that he wasn't done with the QSO - since I hadn't sent him and RST yet.
In that case - hearing him CQ again would have just meant he wasn't hearing
me very well.

This really isn't as complicated as it sounds.  Hopefully it makes sense.
If not - please feel free to ask me questions about it.

73 Tree N6TR
Boring, OR