Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: Opera will QRM 137k QRSS

To: <[email protected]>
Subject: Re: LF: Opera will QRM 137k QRSS
From: "Markus Vester" <[email protected]>
Date: Sun, 18 Mar 2012 22:38:02 +0100
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1332106688; bh=jQeWqkXfd+qO/a+bsGiRFNgY6YFTbgOK6QiQbCklWzo=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=VDdy2eSDB4wAZkfldcGXrVm1MAGYl/qhff4qXlf5Hv39DJEhRVSQN7ZRsf7DmLQ6+ rifqRJsudy/m4Hcm51Zlc2/ihBgLdR/XzPcIELS7PMxzHVRZA6f3Fo+xqWFe/o0/Ic pGlapj1e6KQI7dUn4fjBKzbY1iWz6aA0VXHag/IM=
Importance: Normal
References: <[email protected]>
Reply-to: [email protected]
Sender: [email protected]
Hi Mike,
 
I basically support your point of view.
 
In my opinion, automatic frequency selection to what Opera (or any other software) thinks is a clear frequency does not make much sense on LF. A good human operator would make a careful decision involving many aspects. For example, he would surely avoid a known intercontinental beacon frequency (sic!), even if his receiver cannot currently detect this signal. Or possibly avoid a Japanese Loran line... For weak signal detections, a posteriori knowledge of your exact frequency and timing is extremely helpful - what do you do if your signal has been visible but not decodible, and you can't even tell what QRG your software has randomly chosen? 
 
Of course you can still select your frequency manually if you use Opera to key an external oscillator instead of connecting the audio to an upconverter. But why would you want to enter the traditional QRSS band, where people like me like to stare into the noise, trying to decipher bits of human readable code? 
 
Why the need for more spectrum anyway? Opera may not be overly sensitive, but as Mike has pointed out, it's single frequency and thus as bandwidth efficient as QRSS. It certainly could put tens of stations into say just 50 Hz. If you really want to let Opera go DX, it would be better to adopt something like the TA / Eu split band scheme, and define two narrow slots with a large gap inbetween.
 
Regarding DCF39 sidebands, the situation has worsened here since the advent of their new "dirty" transistor transmitter. The density of FSK telegrams has increased over the years. In that respect it would be attractive to center QRSS even lower, and make use of the spectral gap around 137635 Hz. 
 
BTW If you google for "ros anti jamming" or similar you may find a past history, where Jose's suggestions for HF band usage were at least "not undisputed". I would rather not have this kind of hackling in our narrow and difficult LF band. 
 
That's just my five cents' - I admit it may be a bit biased, because I didn't like the unclosed coding in the first place. And I just haven't been convinced of the advantage of using Opera rather than QRSS/DFCW (human readable), WSPR or MFSK (faster and more sensitive), Wolf, etc...
 
Flames invited ;-)
 
Best 73,
Markus (DF6NM) 
 

Sent: Saturday, March 17, 2012 12:36 PM
Subject: LF: Opera will QRM 137k QRSS

Some of you may have missed my last post on this subject because it
had 'Opera' in the title and you thought it didn't concern you. But
it does.

The Opera data mode evolves almost daily and is still in its Beta
stage. It recommends operating frequencies, and indeed won't work
outside these frequencies without mis-using it. The early versions
recommended 137.3 to 137.5kHz for Opera 8 and 137.5 to 137.6kHz for
the slower Opera 32, both beacon only. So far, so good.

Just over a week ago, version 1.3.3 introduced a new 'QSO mode' and
recommended 137.4 to 137.6 for this activity. It then moved Op8
beacons to 137.6-137.8kHz. My last post on this subject protested in
strong terms at this flagrant disregard for long-standing
bandplanning. In particular it would have caused interference to the
137.777kHz America-Europe DX watering hole.

I have been away for a week and have downloaded Opera version 1.3.9
(I did say it evolved daily) and this has improved the bandplanning,
probably thanks to some members of  this group who are closer to the
Opera team than I am.The threat to the DX wateringhole has gone but
the encroachment on the QRSS window is still there.

The new frequencies are: 137.5 to 137.6kHz for Op32 and 137.6 to
137.7kHz for Op8. The 'QSO mode' seems to have been dropped on this
band.

This still means that Opera 8 beacons will occupy the area between
137.65 and 137.70 which has for many years been used for QRSS 3 and
10 QSOs, including the centre frequency (137.70) itself.

Whilst Opera may be regarded as machine generated/read QRSS and
therefore a good bedfellow for QRSS, it uses a different (non-Morse)
coding. Therefore an Opera user will not be able to read QRSS (and
won't even know it is there it if he turns off the resource-hungry
waterfall display) and the QRSS user will struggle to read what he
thinks is a weak QRSS station, but will in fact be Opera. 

It could be argued that QRSS operators could use 137.70 to 136.75kHz,
but this disregards the substantial QRM from DCF39 sidebands which
affect all of western Europe, especially Germany. In any case, why
should they have to halve the available slot?

However, much more to the point, bandplanning on this band has been
the subject of considerable discussion on this group right from the
very start, and has evolved to suit all concerned. By contrast, the
Opera team appear to have made arbitrary decisions based perhaps on a
poll of a handful of keen Opera fans without any consultation with
users of other, long-standing modes.

When Opera first came out, I was accused of old-fashioned thinking
when I referrred to local adjacent channel QRM. If Opera is so
frequency-efficient, why does it need 200Hz when QRSS3/10 has got by
with 80-100Hz for years?

Lastly, I am not anti-Opera. Until a week ago I used it every day, on
both modes and regard it as a useful tool. But it must be compatible
with users of other, well-established, modes.

Does anyone else feel as angry I do about a software writer dictating
our bandplans?

Mike, G3XDV
==========


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