Message-ID: <4F294BEB.6070107@talktalk.net>
Date: Wed, 01 Feb 2012 14:27:55 +0000
From: qrss <qrss@talktalk.net>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <4F2911FC.3020709@talktalk.net> <BF4A524700075746A6467658DFC7102CB0B68CCD6D@ICTS-S-EXC2-CA.luna.kuleuven.be>,<4F2938EB.8010504@talktalk.net> <BF4A524700075746A6467658DFC7102CB0B68CCD71@ICTS-S-EXC2-CA.luna.kuleuven.be>
In-Reply-To: <BF4A524700075746A6467658DFC7102CB0B68CCD71@ICTS-S-EXC2-CA.luna.kuleuven.be>
Subject: Re: LF: RE: OPERA and QRS
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d60d64f2954b405d2
X-AOL-IP: 195.171.43.25
X-AOL-SPF: domain : blacksheep.org SPF : none


Hello Rik

Thanks again for your thoughts.  I don't usually disagree much with what 
you say.:-)
Your extreme example of 20WPM for 4mins is totally unfair to Morse, due 
to exactly the same reason, you changed the bit rate, it could be used 
as an argument that the bit rate must stay the same in any comparison.

I do see the argument for
> let each mode use it best capabilities to transmit a given message in a given timeframe.
It is what we all thought was right / fair automatically.

73 Eddie

On 01/02/2012 13:40, Rik Strobbe wrote:
> Hello Eddy,
>
> Opera (and WSPR) are using the best way to improve SNR, in their case FEC.
> For QRSS using a shorter dotlength and repeating the message (what is in fact and kind of FEC) is probably not the best way. Increasing dotlength is.
> To give an extreme example: would repeating a callsign at 20WPM during 4 minutes ever be competitive to Opera4 or QRSS3. Certainly not, because this method is no good in improving SNR.
> So "fair" to me sounds: let each mode use it best capabilities to transmit a given message in a given timeframe.
>
> About PA7RIS / YQ0YQY: the last is a worst case example for QRSS. Opera needs the same time to transmit a 6 character call, that is a choise the designer made. CW (and thus QRSS) took another option.
>
> Comparing Opera4 with QRSS1 maybe an interesting test in a "men against machine" competition, but rather meaningless in real world. And without any doubt it will be in favour of Opera, as this is in advantage of FEC (used by Opera, nut used by QRSS).
> The other way around: could an Opera version without any FEC and 3 sec. bitlength compete with QRSS3. I doubt it.
>
> 73, Rik  ON7YD / OR7T
>
>
> ________________________________________
> Van: owner-rsgb_lf_group@blacksheep.org [owner-rsgb_lf_group@blacksheep.org] namens qrss [qrss@talktalk.net]
> Verzonden: woensdag 1 februari 2012 14:06
> Aan: rsgb_lf_group@blacksheep.org
> Onderwerp: Re: LF: RE: OPERA and QRS
>
> Hello Rik
>
> I am glad you used the word fair, I have been trying to avoid it. my
> first though when viewing my TX sending QRS3, then OPERA was, and is
> every time I look,  this is not fair.
>
> Yes digital modes are allowed FEC, as Andy says QRS is allowed the brain
> which is far more powerful than the computer, surely it is unfair to ask
> for longer bit time to compensate for repetition, let QRS be repeated  4
> times at QRS1.024. No need in my test transmission though I
> think.......unless someone would like it.
>
> The PA7RIS idea sounds OK but again would not be fair as the full
> capability of OPERA would not be used so favouring QRS. Only YQ0YQY will
> do, oh no, now every one knows the code call.
>
> 73 Eddie
>
>
> On 01/02/2012 10:52, Rik Strobbe wrote:
>> Hello Eddy,
>>
>> comparing Opera and QRSS with identical bit lengths seems not correct to me as Opera uses "ticks" (such as Forward Error Correction) to improve SNR.
>> Assuming a simple 8 bit character set it takes only 48 bits to transmit a 6 character call. With clever coding (as used in WSPR) it is even possible to fit a 6 character call into 28 bits. But each Opera transmission contains 240 bits.
>> So if Opera is allowed to use FEC in order to improve, QRSS should be allowed to increase dotlength for the same reason.
>> Same transmission duration seems far more fair than same bit/dot length.
>> But then the dot length would have to differ for every call, so maybe we should agree on an "average call" to determine the QRSS dot length. A traditional method to determine CW speed is the PARIS method (PARIS includes exactly 50 dots, including the word spacing), inserting an average length number (7) would give us the nice call PA7RIS, that contains 66 dots, including the word spacing. As Opera transmits only a single word (call) the word spacing is not used, so it can be ommted also in QRSS what leads to a (convenient) number of 60 dots.
>> Opera4 takes 246 seconds, so the QRSS speed to compare with should be 246/60 = 4(.096) seconds dot lenght.
>>
>> 73, Rik  ON7YD - OR7T
>>
>> ________________________________________
>> Van: owner-rsgb_lf_group@blacksheep.org [owner-rsgb_lf_group@blacksheep.org] namens qrss [qrss@talktalk.net]
>> Verzonden: woensdag 1 februari 2012 11:20
>> Aan: rsgb_lf_group@blacksheep.org
>> Onderwerp: LF: OPERA and QRS
>>
>> We all seem to have agreed to compare OPERA with a QRS speed which takes
>> the same time to send a call sign, correct or not?
>> A QRS beacon can send the call continuously all day and successive
>> periods are often used to establish the information.
>>
>> How about comparing like for like in the timing of Data Bits, OPERA uses
>> digital techniques and no doubt repeats the data in  the 4 minute period
>> of OP4. In this case we would need to be comparing it with QRS1 or
>> QRS1.025 if you like.
>>
>> I feed a coding session coming on.
>>
>> 73 Eddie G3ZJO
>>