From: "Mike Dennison" <mike.dennison@ntlworld.com>
To: rsgb_lf_group@blacksheep.org
Date: Sat, 17 Mar 2012 11:36:21 -0000
MIME-Version: 1.0
Message-ID: <4F647735.3372.5358BB@mike.dennison.ntlworld.com>
Content-description: Mail message body
Subject: LF: Opera will QRM 137k QRSS
Content-type: text/plain; charset=US-ASCII
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: 3039ac1d408e4f6477953f0f
X-AOL-IP: 195.171.43.25
X-AOL-SPF: domain : blacksheep.org SPF : none


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
==========