Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: 8269.9 kHz EbNaut 27/12/17 - decoding ethics?

To: [email protected]
Subject: Re: LF: 8269.9 kHz EbNaut 27/12/17 - decoding ethics?
From: DK7FC <[email protected]>
Date: Sat, 30 Dec 2017 15:17:26 +0100
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1514643447; bh=OA/u0scD3v514c8k6axTgXO9+9snLixj06z9DvFF/uU=; h=Date:From:To:Subject:From; b=W/eIIZVX4ZFPc70D8eABbp2exBGxMpGnxYDAminaT9Pf0NY7axwiZ0r74cUkzypQY pa9TTIMzC3oBm3KWHIvFfeg8c0cyyP2IT85buwo3OXt2+KffNFcta8jrPtp9agi3VY GFWVK0/mM6jRsSudRPZirIwDHOS0SBlRknS9ANbQBvTpVw3DCQCNBs5gF6b+WLlPKP OnT5DymSW1FwX4qmS9sZsiisP3DLvUCFLpKpflkW9W3QUjBkJbabbptUF/aKrioNF/ NNaD8SnADl3GwREZ5vaERGmthUfcqWWgGl/4yGhfx6jbGOhAspKMdzS9wa0ivhmaf5 Fty58CPMTLBkg==
In-reply-to: <[email protected]>
References: <[email protected]>
Reply-to: [email protected]
Sender: [email protected]
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
I think, in the end the RX station operator and the TX station operator must decide for himselfe if he is happy when obtaining a decode with the help from others.

Ideally, there is a message announcement (mode | start time | crc | N characters | frequency | daily repetition yes or no and when (failed)) and the RX station that tries to receive and get a result at some time. Then it can make a statement, "I have received the message, it is 'XYZ'". Then the TX station operator answers "No, sorry" or "Yes, i confirm, congrats!". This is the game.

Stacking: The RX operator can see how strong the noise has been on the individual days. This is selfe generated information, collected without the help of others. Of course it is valid to apply a weighting of the individual days into the stacked file.

But for example: In my recent 3 char transmission, the 27th (december) has lead to a negative contribution in the develepment of the Eb/N0 in the stacked files. But this is only known when knowing the message. So if i analyse Alex' files and tell him, "Don't use the 27th in your stack, it makes things worse", and if this leads to a successful decode, it would not be a valid decode, in my opinion!

Another example: If i would decode a message from Dex, but only with the information from Paul, that i have to adjust the phase of the 2nd day by -120 deg and the phase of the 3rd day by +90 deg, then this decode would not feel valid for me. It wouldn't feel like my decode somehow.

73, Stefan


Am 30.12.2017 12:51, schrieb Markus Vester:
> So, do ethics accept a decode claim if it is necessary to use published information about the transmit phase to facilitate stacking?

Clearly yes. As you say, information from B describes a property of  A's transmitter (e.g. the accurate frequency), which is not related to message content.

> And what about using information published from other sites about the strength and success of the transmission?

Obviously yes, if it's related tro transmitter itself (e.g low tx antenna current, aborted transmissions etc. during certain nights).

In my opinion, this should also extended to propagation-related information (e.g. the phase change between A and B due to transversing the Atlantic). That is more or less equivalent to using other available data for propagation estimates (like Navy-MSK magnitude and phase, electron content, solar data), which is "legal".

> Pushing this further, once the message is published, the repeats can be selected for stacking based on their cross-correlation.

Accorduing to the "guideline", neither B or C may make use of the actual noise instance at receiver C to preselect C's data, because that could bias the noise statistics at C towards a decode. So the knowledge of A's message and C's noise should not be combined. Clearly, C may not apply knowledge of the message to make correlations with his own noise, and use them to weight or preselect his data. 

On the other hand, in my opinion correlation results from B (based on propagation A-B and noise at B) could "legally" be used for stacking by C. This implicitly assumes that noise instances at B or C are uncorrelated, so applying B's weights at C won't bias C's noise towards the correct message.

Howecver theoretically the noise at B and C could be correlated, for example if the dominant noise source is a very localized thunderstorm, affecting both B and C. Then B has indirect access to noise at C, and application of B's correlation results could bias C's noise statistics. Depending on phase differences, this could increase or decrease the likelyhood of a correct decode at C. In practice, given the size and movement of thunderstorms acompared to the wavelength, I would not expect a large noise correlation between far-spaced receiver sites (unless for certain special geometries, e.g. all three stations and noise sources arranged in-line on the same great-circle). Thus in my opinion, the application of B's correlations at C should not be generally forbidden.

So like with many questions in ethics, the answers are not always purely black or white. I have to say I'm glad Ive become an engineer rather than a lawyer ;-)

Best 73,
Markus (DF6NM)

-----Ursprüngliche Mitteilung-----
Von: Paul Nicholson <[email protected]>
An: rsgb_lf_group <[email protected]>
Verschickt: Fr, 29. Dez 2017 19:29
Betreff: Re: LF: 8269.9 kHz EbNaut 27/12/17

Dex wrote:

> New message tonight [27th]

> 3 chars 16K21A CRC20
> 30 second symbols
> Start 22:30 UT

Decoding from 8269.9 Hz, 2017-12-XX_22:30,+27900
vtfilter -h bp,f=8270,w=3000
vtblank -a12 -d0 -t100
ebnaut -dp16K21A -r1 -S30 -k20 -N3 -PU -L500000 -v

Todmorden (6194 km)
-------------------

27/28 Eb/N0 +9.2 dB, S/N -22.9 dB/1Hz, phase -140.9 *Decoded*
28/29 Eb/N0 +5.4 dB, S/N -26.7 dB/1Hz, phase 108.7 *Decoded*

Bielefeld (6917.7 km)
---------------------

27/28 Eb/N0 -2.6 dB, S/N -34.7 dB/1Hz, phase 71.2;
28/29 Eb/N0 -2.3 dB, S/N -34.4 dB/1Hz, phase -45.2;

Fails to decode with stacking, Eb/N0 -5.0 dB due to
phase change.

Warsaw (7681.3 km)
------------------

27/28 Eb/N0 -7.4 dB, S/N -39.6 dB/1Hz, phase 143.3;
28/29 Eb/N0 -11.5 dB, S/N -43.7 dB/1Hz, phase 85.6;

Cumiana (7173.4 km)
-------------------

27/28 Eb/N0 +0.6 dB, S/N -31.6 dB/1Hz, phase 164.1 *Decoded*
28/29 Eb/N0 -2.1 dB, S/N -34.2 dB/1Hz, phase 63.2;

Hawley TX (1816.2 km)
---------------------

27/28 Eb/N0 7.8 dB, S/N -24.3 dB/1Hz, phase -86.3 *Decoded*
28/29 Eb/N0 1.3 dB, S/N -30.8 dB/1Hz, phase -163.5 *Decoded*

Forest VA (254.2 km)
--------------------

27/28 Eb/N0 21.2 dB, S/N -10.8 dB/1Hz, phase 115.9 *Decoded*
28/29 Eb/N0 20.4 dB, S/N -11.8 dB/1Hz, phase -14.0 *Decoded*

All the rx sites show a similar phase change between the two
nights, even Warsaw with the very weak signal.

So, do ethics accept a decode claim if it is necessary to use
published information about the transmit phase to facilitate
stacking?

One might argue that knowledge of the tx phase is no different
to knowing the tx frequency and start time. Such knowledge
does not bypass any propagation.

And what about using information published from other sites
about the strength and success of the transmission?

A problem with stacking is the number of permutations as the
number of repeats increases. Eg with four repeats, there are:

One run with all four;
Four runs with one repeat dropped;
Six runs with two repeats dropped;
Four runs with single repeats;

15 runs altogether and the operator is obliged to accept the
strongest looking decode out of all of them. Each of the
15 runs has the chance of throwing up a false decode which
will beat the correct decode. Therefore, knowledge that a
particular repeat performed poorly at other sites allows you
to drop that one with no cost in terms of false decodes.

Pushing this further, once the message is published, the
repeats can be selected for stacking based on their cross-
correlation. You might for example have 10 repeats and be
able to get a decode from the best 5, Without that knowledge
you would need 252 full runs of the decoder to go through all
permutations of 5 out of 10 repeats, surely enough to suffer
a stronger false decode.

--
Paul Nicholson
--

<Prev in Thread] Current Thread [Next in Thread>