Hi Mike,
I agree with you.
The band plan for LF is well known and such an efficient mode should
focus on the band below 137.6 kHz. I saw opera (?) traces on my grabber
as well and didn't know who it was. That could be iritating to others
who struggle to identify a QRSS call out of the noise.
I would vote to extend the digimode band rather to 137.4 instead, if 200
Hz aren't sufficient for those super efficient QRSS and CW replacement
modes.
73, Stefan/DK7FC
Am 17.03.2012 12:36, schrieb Mike Dennison:
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
==========
|
