[Lowfer] OP8 again tonite...

[Cliff Sojourner]

hi Eric,

On 2012-12-28 15:15, Eric Tichansky wrote:
> If I remember correctly, then number signifies the time in minutes to 
> complete one message, so yes, OP8 is about 4 times "slower" then WSPR.
>
> Opera is basically encoded QRSS; it uses CW elements, but the element 
> combinations (ie. characters) are not standard CW.  In fact, as far as 
> I am aware, the encoding is still not public knowledge, neither 
> explicitly published nor able to be observed in any source code should 
> someone wish to understand how it operates.

see below, forwarded message from the opera yahoo group.  personally I 
doubt the author really divined all that encoding just by looking, that 
shows tremendous skill in cryptography, and would be too much work!

> For amateur operation, this is somewhat questionable in my opinion, 
> perhaps not legally, but goes against the tradition and spirit of 
> amateur digital modes.  ROS modes probably are in the same category 
> (same author).

yes, agreed.  anyways now it is clear that WSJT is superior in many ways.

Cliff  K6CLS

>
> 73 - Eric NO3M, WG2XJM
>
> On 12/28/2012 17:50, Douglas D. Williams wrote:
>> Or am I not allowing OP8 enough time? Does it take longer for a 
>> successful
>> decode?

To: O_P_E_R_A_ at yahoogroups.com
From: Guido<threeme3 at gmail.com>
Date: Wed, 15 Feb 2012 17:05:57 +0100
Subject: [O_P_E_R_A_] Behind the scenes of OPERA - how does it work?

While Opera is in its experimental stages, the internal workings are hardly
known.

In order to address this mystery (and my personal curiosity) I have looking
in the Opera symbols construction (encoding) process by comparing the
output symbols for various callsign inputs. As it might have your interest
too what is happening behind the scenes, here are my findings so far with
Opera v1.1.9 to v1.2.8:

1. MESSAGE
First, a 51-bit message is constructed based on the operator's call-sign.
The message contains in sequence:
    bit 47-50: 4 unused bits (set to zero);
    bit 19-46: 28-bit packed integer holding a compressed instance of the
call-sign;
    bit 3-18: 16-bit check-sum of binary representation of bits 19-46 (this
is the check-sum of the packed callsign);
    bit 0-2: 3-bit check-sum of binary representation of bits 19-3 (this is
the check-sum of the packed call-sign and its checksum).

The 28-bit packed integer is constructed from the 6 callsign characters,
where the last digit in the prefix must be aligned to the 3rd position.
Each position is encoded in a certain radix and character encoding mapping:
    pos 1,   radix 37 with mapping [blank(0), A-Z(1-26), 0-9(27-37)];
    pos 2,   radix 36 with mapping [A-Z(0-25), 0-9(26-36)];
    pos 3,   radix 10 with mapping [0-9(0-9)];
    pos 4-6, radix 27 with mapping [blank(0), A-Z(1-26)].

The check-sums are based on a CRC with polynomial x^16 + x^15 + x^2 + 1
also known as CRC-16. Rationale for applying a 16 bits CRC is to be able to
block invalid messages on the receiver site while decoding a (error
corrected) message. Note that:
    a. check-sum is based on the binary representation in ASCII of the bits
specified (Rationale: should be not necessary, probably a practical reason
as the application can be based on string manipulations instead of binary
operations);
    b. a zero in the high- or low byte of the CRC result is replaced by
respectively 2B (hex) and 1B (hex), Rationale: should be not necessary,
unclear why this is done;
    c. the high- and the low bytes are swapped when put in the message where
for the 3-bit check-sum only the least significant bits are considered;

2. SCRAMBLING
Second, a 51-bit scrambled message is constructed by means of a XOR
operation with message and a pseudo-random noise vector 70ABF3680C8AB
(hex). Rationale for scrambling is to reduce repetitive zeros by ensuring
for enough transitions in the data independent on the end-users input,
preventing degraded hamming distances for zero code words, nevertheless for
the current code used it seems not to be necessary as the distance is
constant for k=3D3.

3. WALSH-HADAMARD CODE
Third, a Walsh-Hadamard code (k=3D3) is applied on the 51-bit message
resulting in a 119-bit message. With k=3D3 the Walsh-Hadamard code maps eve=
ry
3 bits of the message to a orthogonal codeword of length 2^(k-1) =3D 7 bits=
,
where the Hadamard code is obtained from an inverse 8th order Hadamard
matrix:
    000 0000000   001 1010101   010 0110011   011 1100110
    100 0001111   101 1011010   110 0111100   111 1101001
Rationale: Walsh-Hadamard code is an error-correcting code (block code)
that may be used on the receiver site for forward  error correction (FEC)
and error detection. Doing so, relaxes the signal requirements while
transmitting messages over very noise or unreliable (fading) channels,
approximating the Shannon capacity model.
With k=3D3, the minimum hamming distance of the code is 2^(k-1) =3D 4, with
this code a theoretical receiver can detect 2^(k-2)-1 =3D 1 error and corre=
ct
2^(k-3)-1 =3D 0 errors. The Walsh=96Hadamard code is a
locally decode-able code, which provides a way to recover parts of the
original message with high probability, while only looking at a small
fraction of the received word.  As an alternative to error-correction,
list-decoding may recover the original message on the receiver as long as
less than 1/2 of the bits in the received word have been corrupted.

4. INTERLEAVING
Fourth, the 119-bits message is block interleaved by writing the bits by
column in a 7-by-17 matrix and reading back by rows into the message.
Rationale: interleaving makes the block encoded message less vulnerable
against temporary decoding errors (fading, burst errors) by scattering of
the bits over the entire message (approximately written every 7 positions).

5. MANCHESTER ENCODING
Fifth, the 119-bits message is Manchester encoded (per IEEE802.3
convention) by encoding a 1-0 transition for a 0, and a 0-1 transition for
a 1, doubling the message length. Note that bit 238 and 239 are set to one
and that bit 0 is omitted, resulting in a 239-bit message. The binary
representation contains the symbols to be transmitted.

6. KEYING
Sixth, in the event of an transmission event, a frequency that is not
occupied is selected (that is the frequency that has the least energy just
before transmission), and each of the 239 symbols are transmitted by keying
the transmitter as CW on and off with a symbol rate of 0.256*n s/symbol,
where n is the integer of operation mode OPn that corresponds with the
Opera frequency recommendation:
OP32: 137.5-137.6 kHz
OP8: 137.7-137.5, 501.5-501.6, 1837.3-1837.5 kHz
OP4: 501.3-501.5, 1837.5-1837.9, 3576.3-3576.5, 5290.3-5290.5,
7039.3-7039.5, 10136.3-10136.5, 14066.3-14066.5 kHz
OP2: 3576.5-3576.9, 5290.5-5290.9, 7039.5-7039.9, 10136.5-10136.9,
14066.5-14066.9, 18106.3-18106.5, 21075.3-21075.5, 24926.3-24926.5,
28076.3-28076.5, 50701.3-50701.5, 70252.3-70252.5 kHz
OP1: 18106.5-18106.9, 21075.5-21075.9, 24926.5-24926.9, 28076.5-28076.9,
50701.5-50701.9, 70252.5-70525.9 kHz

On the decoder site, the inverse of above operations are done in reverse
order to retrieve the callsign of a received broadcast. An interesting
feature is to exploit the list-decoding potential of the Walsh-Hadamard
code in combination with the CRC check-sums in the message. With
list-decoding, a set of message possibilities is outputted and may be
evaluated for validity. This computation power with receiver gain.

73,
Guido
PE1NNZ