Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: RE: OPERA and QRS

To: [email protected]
Subject: Re: LF: RE: OPERA and QRS
From: qrss <[email protected]>
Date: Wed, 01 Feb 2012 14:27:55 +0000
In-reply-to: <BF4A524700075746A6467658DFC7102CB0B68CCD71@ICTS-S-EXC2-CA.luna.kuleuven.be>
References: <[email protected]> <BF4A524700075746A6467658DFC7102CB0B68CCD6D@ICTS-S-EXC2-CA.luna.kuleuven.be>,<[email protected]> <BF4A524700075746A6467658DFC7102CB0B68CCD71@ICTS-S-EXC2-CA.luna.kuleuven.be>
Reply-to: [email protected]
Sender: [email protected]
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

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: [email protected] [[email protected]] 
namens qrss [[email protected]]
Verzonden: woensdag 1 februari 2012 14:06
Aan: [email protected]
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: [email protected] [[email protected]] 
namens qrss [[email protected]]
Verzonden: woensdag 1 februari 2012 11:20
Aan: [email protected]
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




<Prev in Thread] Current Thread [Next in Thread>