Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-md02.r1000.mx.aol.com (Internet Inbound) with ESMTP id C4DDB38000086; Sun, 18 Mar 2012 17:39:40 -0400 (EDT) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1S9Nnt-0005qM-TC for rs_out_1@blacksheep.org; Sun, 18 Mar 2012 21:38:17 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1S9Nns-0005qD-R1 for rsgb_lf_group@blacksheep.org; Sun, 18 Mar 2012 21:38:16 +0000 Received: from imr-ma03.mx.aol.com ([64.12.206.41]) by relay1.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1S9Nnp-0002cJ-UG for rsgb_lf_group@blacksheep.org; Sun, 18 Mar 2012 21:38:16 +0000 Received: from mtaout-mb06.r1000.mx.aol.com (mtaout-mb06.r1000.mx.aol.com [172.29.41.70]) by imr-ma03.mx.aol.com (8.14.1/8.14.1) with ESMTP id q2ILc8NN006793 for ; Sun, 18 Mar 2012 17:38:08 -0400 Received: from White (nrbg-4dbe6192.pool.mediaWays.net [77.190.97.146]) by mtaout-mb06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPA id 2D70EE0000D8 for ; Sun, 18 Mar 2012 17:38:05 -0400 (EDT) Message-ID: <257167E694A247BA8C5161831D6BFD92@White> From: "Markus Vester" To: References: <4F647735.3372.5358BB@mike.dennison.ntlworld.com> Date: Sun, 18 Mar 2012 22:38:02 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 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= X-AOL-SCOLL-SCORE: 0:2:517134272:93952408 X-AOL-SCOLL-URL_COUNT: 0 X-Spam-Score: 0.0 (/) X-Spam-Report: autolearn=disabled,HTML_MESSAGE=0.001 Subject: Re: LF: Opera will QRM 137k QRSS Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CD0557.C7200330" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_20_30,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.63 X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:522720768:93952408 X-AOL-SCOLL-URL_COUNT: 0 X-AOL-SCOLL-AUTHENTICATION: mail_rly_antispam_dkim-m238.2 ; domain : mx.aol.com DKIM : pass x-aol-sid: 3039ac1d60564f66561c281b X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none Dies ist eine mehrteilige Nachricht im MIME-Format. ------=_NextPart_000_000F_01CD0557.C7200330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mike,=20 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?=20 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?=20 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.=20 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.=20 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)=20 =20 From: Mike Dennison=20 Sent: Saturday, March 17, 2012 12:36 PM To: rsgb_lf_group@blacksheep.org=20 Subject: LF: Opera will QRM 137k QRSS Some of you may have missed my last post on this subject because it=20 had 'Opera' in the title and you thought it didn't concern you. But=20 it does. The Opera data mode evolves almost daily and is still in its Beta=20 stage. It recommends operating frequencies, and indeed won't work=20 outside these frequencies without mis-using it. The early versions=20 recommended 137.3 to 137.5kHz for Opera 8 and 137.5 to 137.6kHz for=20 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=20 recommended 137.4 to 137.6 for this activity. It then moved Op8=20 beacons to 137.6-137.8kHz. My last post on this subject protested in=20 strong terms at this flagrant disregard for long-standing=20 bandplanning. In particular it would have caused interference to the=20 137.777kHz America-Europe DX watering hole. I have been away for a week and have downloaded Opera version 1.3.9=20 (I did say it evolved daily) and this has improved the bandplanning,=20 probably thanks to some members of this group who are closer to the=20 Opera team than I am.The threat to the DX wateringhole has gone but=20 the encroachment on the QRSS window is still there. The new frequencies are: 137.5 to 137.6kHz for Op32 and 137.6 to=20 137.7kHz for Op8. The 'QSO mode' seems to have been dropped on this=20 band. This still means that Opera 8 beacons will occupy the area between=20 137.65 and 137.70 which has for many years been used for QRSS 3 and=20 10 QSOs, including the centre frequency (137.70) itself.=20 Whilst Opera may be regarded as machine generated/read QRSS and=20 therefore a good bedfellow for QRSS, it uses a different (non-Morse)=20 coding. Therefore an Opera user will not be able to read QRSS (and=20 won't even know it is there it if he turns off the resource-hungry=20 waterfall display) and the QRSS user will struggle to read what he=20 thinks is a weak QRSS station, but will in fact be Opera. =20 It could be argued that QRSS operators could use 137.70 to 136.75kHz,=20 but this disregards the substantial QRM from DCF39 sidebands which=20 affect all of western Europe, especially Germany. In any case, why=20 should they have to halve the available slot? However, much more to the point, bandplanning on this band has been=20 the subject of considerable discussion on this group right from the=20 very start, and has evolved to suit all concerned. By contrast, the=20 Opera team appear to have made arbitrary decisions based perhaps on a=20 poll of a handful of keen Opera fans without any consultation with=20 users of other, long-standing modes. When Opera first came out, I was accused of old-fashioned thinking=20 when I referrred to local adjacent channel QRM. If Opera is so=20 frequency-efficient, why does it need 200Hz when QRSS3/10 has got by=20 with 80-100Hz for years? Lastly, I am not anti-Opera. Until a week ago I used it every day, on=20 both modes and regard it as a useful tool. But it must be compatible=20 with users of other, well-established, modes. Does anyone else feel as angry I do about a software writer dictating=20 our bandplans?=20 Mike, G3XDV =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------=_NextPart_000_000F_01CD0557.C7200330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mike,
 
I basically support your point of=20 view.
 
In my opinion, automatic frequency = selection to=20 what Opera (or any other software) thinks is a clear frequency does not = make=20 much sense on LF. A good human operator would make a careful = decision=20 involving many aspects. For example, he would = surely avoid a=20 known intercontinental beacon frequency (sic!), even if his = receiver=20 cannot currently detect this signal. Or possibly avoid a = Japanese=20 Loran line... For weak signal detections, a posteriori knowledge of your = exact=20 frequency and timing is extremely helpful - what do you do if = your=20 signal has been visible but not decodible, and you can't even tell = what QRG=20 your software has randomly chosen? 
 
Of course you can still select your = frequency=20 manually if you use Opera to key an external oscillator instead of=20 connecting the audio to an upconverter. But why would you want to enter = the=20 traditional QRSS band, where people like me like to stare into the = noise, trying=20 to decipher bits of human readable code? 
 
Why the need for more spectrum anyway? = Opera may=20 not be overly sensitive, but as Mike has pointed out, it's single = frequency and=20 thus as bandwidth efficient as QRSS. It certainly could put tens of = stations=20 into say just 50 Hz. If you really want to let Opera go DX, it would be = better=20 to adopt something like the TA / Eu split band scheme, and = define two=20 narrow slots with a large gap inbetween.
 
Regarding DCF39 sidebands, the = situation has=20 worsened here since the advent of their new "dirty" transistor = transmitter. The density of FSK telegrams has increased over the years. = In that=20 respect it would be attractive to center QRSS even lower, and = make use=20 of the spectral gap around 137635 Hz. 
 
BTW If you google for "ros anti = jamming" or=20 similar you may find a past history, where Jose's suggestions for = HF band=20 usage were at least "not undisputed". I would rather not have this kind = of=20 hackling in our narrow and difficult LF band. 
 
That's just my five cents' - I admit it = may be a=20 bit biased, because I didn't like the unclosed coding in the first = place.=20 And I just haven't been convinced of the advantage of using = Opera=20 rather than QRSS/DFCW (human readable), WSPR or MFSK (faster and more=20 sensitive), Wolf, etc...
 
Flames invited ;-)
 
Best 73,
Markus (DF6NM) 
 

Sent: Saturday, March 17, 2012 12:36 PM
To: rsgb_lf_group@blacksheep.org= =20
Subject: LF: Opera will QRM 137k QRSS

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

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

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

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

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

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

Whilst Opera may be regarded as machine generated/read QRSS and=20
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=20 even know it is there it if he turns off the resource-hungry =
waterfall=20 display) and the QRSS user will struggle to read what he
thinks is a = weak=20 QRSS station, but will in fact be Opera. 

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

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

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

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

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

Mike,=20 G3XDV
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


------=_NextPart_000_000F_01CD0557.C7200330--