MIME-Version: 1.0
In-Reply-To: <1325950521.75721.YahooMailNeo@web87305.mail.ird.yahoo.com>
References: <1325950521.75721.YahooMailNeo@web87305.mail.ird.yahoo.com>
Date: Sat, 7 Jan 2012 15:36:42 +0000
Message-ID: <CAA8k23StLJ2Je1_f9_HmxLGafia8dnu2ivDgBQHpUkuWNCHgHg@mail.gmail.com>
From: Andy Talbot <andy.g4jnt@gmail.com>
To: rsgb_lf_group@blacksheep.org
Subject: LF: First stages of Opera Decoding
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
X-AOL-SCOLL-URL_COUNT: 0  
X-AOL-SCOLL-AUTHENTICATION: mail_rly_antispam_dkim-d002.1 ; domain : gmail.com DKIM : fail  
x-aol-sid: 3039ac1dc1484f0866d33512
X-AOL-IP: 195.171.43.25
X-AOL-SPF: domain : blacksheep.org SPF : none


For those who would like to try to work out how the=A0Opera waveform is
coded, I've generated a file with the bit patterns for some
systematically made up callsigns in an attempt to see how these are
turned into the=A0Tx sequence.

http://www.g4jnt.com/Download/Raw_Opera_Coding.txt

(if you read it with the URL underlining in place, the gaps in the
file name are underscores, not spaces)

These were all generated using Op2 mode, but testing yesterday showed
that at least for the first 50 or so symbols, all the speed varients
transmit the same data pattern.=A0=A0 The leading two - second framing
pulse is ignored, but therafter each symbol is represented by a 0 for
carrier off, and 1 for carrier on.

You can see that it appears to be a di-symbol code structure, always
consisting of either a 01 or 10 transition - Manchester coding in
other words - so duty cycle is always 50% and it is therefore self
clocking.

There are 220 symbols in each frame and there=A0can be a=A0maximum of 1
data bit per two symbols. Each frame begins 01 and ends on a double;
between those the data varies, so this leaves at most 118 bits for the
content.

A selection of made-up callsigns were tried, and the results listed in
a sort of Gray code order, where only one or perhaps =A0two bits of the
originating ASCII are changed each time.

Only the callsign appears to be coded;=A0=A0altering the=A0locator , name o=
r
QTH make no change to the bit pattern sent.

Haven't tried studying the format yet, it has taken most of the day to
make the interface for extracting 0 /1 text=A0from the wobbling COM line
and actually recording the results.=A0 Initially I forgot data was
available on a com port, and made up an opamp rectifier arrangement
before the bell went ding !=A0=A0=A0 However, a first cursory examination
does show there is some systematic changes, at least at the beginning,
so it is not convolutionally coded at least.=A0 taht woudl have been
difficult to sort out.

The actual conversion was made using a PIC to detect a transistion and
measure subsequent delays before teh next transition.=A0 The measured
results being output in ASCII text as 1, 0 or (cr] for the extended
lead in symbol. The 1 / 0 text was captured to a file.=A0=A0 It was easier
for me to programme a PIC to do the job than it would have been to
just wrap-round the COM signal and use VB or C to measure the gaps.

More made up callsigns will be added as needed.

Andy
G4JNT