Content-Transfer-Encoding: 8bit
Message-ID: <5.1.0.14.0.20030321093918.01834d60@u0019445.kuleuven.be>
Date: Fri, 21 Mar 2003 10:08:10 +0100
To: rsgb_lf_group@blacksheep.org
From: "Rik Strobbe" <rik.strobbe@fys.kuleuven.ac.be>
In-reply-to: <5.1.0.14.0.20030320183946.0260e158@gemini.herts.ac.uk>
References: <196204469165.20030320181102@dx.ru>
MIME-Version: 1.0
Subject: Re: LF: Re: UA9 expedition and DX operating
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: <owner-rsgb_lf_group@blacksheep.org>
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

Hello group,

just some ideas regarding the optimalisation of QRS speed for long distance 
tests (skeds) :

1. DFCW will speed up things by a factor 3

2. For QRSS with rather long dotlengths (10-30 sec.) and using "full 
break-in" it should be possible to indicate when the other station can 
increase speed (or has to decrease). It could be agreed that sending a 
"dot" just above the TX frequency means "speed up" while sending a carrier 
just below means "speed down".
An example :
Assume a sked between M0BMU and UA9OC, both starting at 30 sec./dot. M0BMU 
transmitting on 137770.0Hz and UA9OC transmitting on 137772.0Hz. Next 
assume that M0BMU starts transmitting his own call. If UA9OC receives the 
"M0" at good strength he could transmit a 30 sec. dot on 137770.2Hz during 
the pause between the "0" and "B" (that pause takes 180 sec. at 30 sec/dot, 
so a 30 sec. dot fits in well) . M0BMU know that he can speed up to 10 
sec/dot (starting with the next character "B"). Now  M0BMU is transmitting 
at 10 sec/dot but later the QSO propagation is fainting, UA9OC can indicate 
that by sending a 30 sec. dot on 137769.8Hz so M0BMU knows that he has to 
go back to 30 sec/dot (the 30 sec. "indicator" just fits in a pause at 10 
sec/dot).
I know that the above sounds a bit complicated, but it would allow an 
optimal "use of propagation".

73, Rik  ON7YD


At 20:25 20/03/2003 +0000, you wrote:
>Dear Ed and friends, LF Group,
>
>Thanks for sending the report of your UA9 expedition. It was very exciting 
>to see the first LF signals from Asia. In spite of the problems, achieving 
>the first Asia - Europe QSOs and successfully being received in, and 
>receiving signals from, ZL means it was a great achievement; I look 
>forward to the next time!
>
>The UA9 - G propagation seems to be quite similar to what we experience 
>during the transatlantic tests - occasionally the propagation is 
>excellent, and a QSO is possible with quite fast speeds. But sometimes you 
>see no signals for several days, which is really frustrating, especially 
>if you are on an expedition. With the recent X-class solar flares, it is a 
>good thing you were in Siberia last week and not this week!
>
>As far as I know, there have only ever been a handful of successful QSOs 
>using QRSS30 before last week, so we are still all learning how to do 
>this. Operation with QRSS30 and longer dot lengths is difficult because it 
>takes such a long time, and there is always a danger that propagation will 
>disappear before the QSO is finished. So it is important to use a 
>procedure that uses the smallest number of characters. But at the same 
>time, there has to be at least the exchange of callsigns and signal 
>reports to make it into a "proper" QSO. A problem with inventing new 
>procedures is informing all the stations that the new procedure exists. It 
>is not easy for stations who do not have internet access, or do not speak 
>much English, so there is always going to be some confusion unless the 
>procedure is kept very simple. I think using procedure signals for sending 
>faster and slower might help sometimes, but the problem is that the QSO 
>has to start with both stations sending slowly to be sure they can copy 
>each other - so they can only speed up after the first 2 overs, by which 
>time more than 50% of the QSO is complete,and so not much time is saved. 
>If one station has a higher ERP than all the others, as Ed did, it would 
>make sense for that station to send faster. I guess about 1/3 the dot 
>duration would be right (3s/10s, 10s/30s etc) - even if faster sending was 
>possible for one station, it would not make much difference to the total 
>QSO time.
>
>It is quite common to see stations doubling with each other, which wastes 
>a lot of time at QRSS30. A good way to avoid that is to use break-in. 
>Rik's QRS software allows you to receive between characters and/or 
>elements, which enables you to see if you are doubling, or if you are on 
>the same frequency as someone else, which saves a lot of time. I guess it 
>would be quite easy to do this with other keying methods too.
>
>I agree with ZL2CA that there seems to be an optimum speed for DX QRSS 
>contacts. I suppose it varies depending on the particular path. Too short 
>a dot length, and the probability of the propagation ever being good 
>enough is very low. Too long a dot length, and the chances of a 
>propagation lift lasting long enough for a QSO are small. Also, the number 
>of stations operating makes a difference, since propagation varies for 
>each location. Now that we are getting more data from monitoring beacons, 
>DCF39 etc, it might be possible to analyse the signal strengths 
>statistically to work out the optimum dot length. Of course, the other 
>modes we have been testing such as Jason, Wolf and so on are an attempt to 
>make this balance more favorable - so some DX paths may have to wait until 
>these are better developed before QSOs are possible. However, for the time 
>being, QRSS (and DFCW) do have the advantage in that they are much simpler 
>to get working in the typical LF amateur station, which means more people 
>can put them into use, and increase the chances of successful contacts.
>
>Cheers, Jim Moritz
>73 de M0BMU
>