Return-Path: X-Spam-DCC: paranoid 1233; Body=2 Fuz1=2 Fuz2=2 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on lipkowski.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL, HTML_50_60,HTML_MESSAGE autolearn=no version=3.1.3 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by paranoid.lipkowski.org (8.13.7/8.13.7) with ESMTP id t4LJ4EOY000812 for ; Thu, 21 May 2015 21:04:14 +0200 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1YvVic-0005VC-0t for rs_out_1@blacksheep.org; Thu, 21 May 2015 20:01:22 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1YvVib-0005V3-Hz for rsgb_lf_group@blacksheep.org; Thu, 21 May 2015 20:01:21 +0100 Received: from smtpout3.wanadoo.co.uk ([80.12.242.59] helo=smtpout.wanadoo.co.uk) by relay1.thorcom.net with esmtp (Exim 4.85) (envelope-from ) id 1YvViZ-0001bC-3N for rsgb_lf_group@blacksheep.org; Thu, 21 May 2015 20:01:20 +0100 Received: from AGB ([95.150.81.4]) by mwinf5d44 with ME id Wj1J1q00305bScF03j1J7q; Thu, 21 May 2015 21:01:18 +0200 X-ME-Helo: AGB X-ME-Date: Thu, 21 May 2015 21:01:18 +0200 X-ME-IP: 95.150.81.4 Message-ID: <8E30521610A841009722787864E41B59@AGB> From: "Graham" To: References: <555CCC21.4060901@gmx.com><555CE435.7050502@freenet.de><55B8DA6A-5317-410B-8F43-A4EC035F14A2@gmx.com><555CF143.9090403@freenet.de><7E7DFBB4D102A04DB5ADC88D66628A4A23548558@ICTS-S-MBX1.luna.kuleuven.be> In-Reply-To: Date: Thu, 21 May 2015 20:01:17 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Scan-Signature: 92ba6d1cfea07ba208a9963ff95bc212 Subject: Re: LF: MF 630m: False Decode or Real? Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01D09400.E659F3B0" X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Scanned-By: MIMEDefang 2.56 on 10.1.3.10 Status: O X-Status: X-Keywords: X-UID: 3208 This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01D09400.E659F3B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HOWEVER, I don't see the various deep search solutions in Opera = including any unknowns in this sense. The time stamp is meant to act = as that item of unknown,information, but is not being actually = transmitted. Instead it has be correlated by external means, which = isn't quite the same in terms of strength of coding Im confused - that's the whole point of the system ? the data = has its own time code and dynamic attempts time sync=20 G,=20 From: Andy Talbot=20 Sent: Thursday, May 21, 2015 9:05 AM To: rsgb_lf_group@blacksheep.org=20 Subject: Re: LF: MF 630m: False Decode or Real? I disagree that the copying of callsigns is important if they are known = in advance. Such would be the case in real organised Dx attempts and = scheds It is just a waste of valuable QSO time / bandwidth to exchange = already-known information. =20 Why not regard the exchange of some unknown token as validating a = genuine QSO?=20 Like a digit or two, or a single letter. it could be a signal report, although a classic type of report does = itself include a lot of known information in its structure and may not = be robust enough All a-priori information can quite happily be exchanged by any other = route Just because an IARU Handbook specifies something doesn't make it common = sense - those rules / guidance or whatever were written by people who = assume voice and the hand sent pulsed stuff is what everyone uses. Use = for Contest rules, fair enough. But real experimenters use their common = sense HOWEVER, I don't see the various deep search solutions in Opera = including any unknowns in this sense. The time stamp is meant to act = as that item of unknown,information, but is not being actually = transmitted. Instead it has be correlated by external means, which = isn't quite the same in terms of strength of coding Discuss Andy G4JNT Andy G4JNT On 21 May 2015 at 07:47, Rik Strobbe = wrote: Hello Wolf, well said. From the IARU R1 VHF managers handbook: A valid contact is one where both operators have copied both = callsigns, the report and an unambiguous confirmation. However no = recourse should be made during the contact to obtain the required = information, change of frequency, antenna direction, etc. via other = methods such as the Internet, DX Cluster, talk-back on another band, = telephone etc. Similar statements are found in other documents such as contest and = award rules. 73, Rik ON7YD - OR7T -------------------------------------------------------------------------= ----- Van: owner-rsgb_lf_group@blacksheep.org = [owner-rsgb_lf_group@blacksheep.org] namens wolf_dl4yhf = [dl4yhf@freenet.de] Verzonden: woensdag 20 mei 2015 22:40 Aan: rsgb_lf_group@blacksheep.org Onderwerp: Re: LF: MF 630m: False Decode or Real? Hi Jochen, I think the discussion about Opera's own 'deep search' mode (or = whatever=20 the proper name is) was done here (or on "the other" reflector) over a = year ago, and the main problem I see is that the 'real time web-based=20 exchange' of currently active stations means fooling oneself. Consider this: You know there are only four possible callsigns which=20 have been transmitting, so in reality the software only has to decide=20 for a TWO BIT number. Much easier than "really" decoding the entire=20 number of message bits in an Opera message. In my very personal point of view, this 'real time web exchange of=20 stations (calls) which are currently transmitting' should not be used = at=20 all. For comparison, Markus' (DF6NM's) own deep search uses a quite large=20 table which is *static*, which means that his decoder has no chance to = play unfair (because it doesn't know who's currently active or not), = and=20 it also doesn't know what others receive (over the internet). What I=20 don't know is how many stations are currently in that list, and thus = how=20 many bits the algorithm effectively has to "decode" (well, it doesn't=20 really decode, it also makes a best guess from a limited number of = list=20 entries to chose from). All the additional data which look as if they were "decoded" (eg = "VK3ELV=20 ... 140w + Top loaded L 18m vert 80m horz") have been taken from a=20 database (***including the callsign***), not radio .. the only real=20 information is the '- 37 dB' report, and the two question marks which = imho may as well have been ten or twenty (considering the season and = the=20 distance). Well just my two pence of wisdom. I don't use Opera and don't think I=20 ever will. Cheers, Wolf . Am 20.05.2015 22:03, schrieb J. Althoff: > Hi Wolf, > > You are not disappointing me at all. I put this issue under = discussion myself. > > Please share your opinion about this to this topic to us in detail. = Maybe I missed > A discussion about this before, but I am very interested in = arguments about this > Topic. > > Thanks, Jochen > > > -=3D DF1VB =3D- > -=3D KH2MM =3D- > Jochen Althoff > df1vb@gmx.de > +491712020206 > > >> Am 20.05.2015 um 21:44 schrieb wolf_dl4yhf : >> >> Sorry to dissapoint you but .. no, no, no, and again, no. >> >> 73, >> Wolf >> >> Am 20.05.2015 20:02, schrieb Jochen Althoff: >>> Just popped up at my RX: >>> >>> 17:52 477 VK3ELV de DF1VB/3 Op8 Deep Search ?? 16348 km -37 dB = in Dortmund with 140w + Top loaded L 18m vert 80m horz >>> >>> Any comments welcome >>> >>> 73, Jochen >> > > ------=_NextPart_000_00A7_01D09400.E659F3B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
 
HOWEVER,   I don't see the various deep search = solutions=20 in Opera including any unknowns in this = sense.    The=20 time stamp is meant to act as that item of unknown,information, =  but=20 is not being actually transmitted.  Instead it has  = be=20 correlated by external means, which isn't quite the same in terms = of=20 strength of coding
 
 
Im confused  -  that's  the  whole  = point  of=20 the  system ?    the  data   has its=20 own  time  code and  dynamic  attempts  = time  sync=20
 
G,
 

From: Andy Talbot
Sent: Thursday, May 21, 2015 9:05 AM
To: rsgb_lf_group@blacksheep.org= =20
Subject: Re: LF: MF 630m: False Decode or = Real?

I disagree that the copying of callsigns is important if they are = known in=20 advance.  Such would be the case in real organised Dx attempts and=20 scheds
It is just a waste of valuable QSO time / bandwidth to exchange=20 already-known information.  

Why not regard the exchange of some unknown token as = validating a=20 genuine QSO?
Like a digit  or two,  or a single letter.
it could be a signal report, although a classic type of report = does=20 itself include a lot of known information in its structure and may not = be robust=20 enough

All a-priori information can quite happily be exchanged by any = other=20 route
Just because an IARU Handbook specifies something doesn't make it = common=20 sense - those rules / guidance or whatever  were written by people = who=20 assume voice and the hand sent pulsed stuff is what everyone = uses.  =20 Use for Contest rules, fair enough.  But real experimenters use = their=20 common sense

HOWEVER,   I don't see the various deep search solutions = in Opera=20 including any unknowns in this sense.    The time stamp = is meant=20 to act as that item of unknown,information,  but is not being = actually=20 transmitted.  Instead it has  be correlated by external = means,=20 which isn't quite the same in terms of strength of coding

Discuss

Andy  G4JNT

Andy  G4JNT


On 21 May 2015 at 07:47, Rik Strobbe <Rik.Strobbe@fys.kuleuven.be> wrote:

Hello Wolf,

 

well said.

From the IARU R1 = VHF=20 managers handbook:

 

A valid contact=20 is one where both operators=20 have copied both callsigns, the = report=20 and an unambiguous=20 = confirmation. However no=  recourse should be=20 made during the contact to obtain=20 the required information, change of=20 frequency, antenna direction, etc.=20 via other methods such as the=20 Internet, DX=20 Cluster, talk-back on another=20 band, telephone etc.

 

Similar statements are found=20 in other documents such=20 as contest and award rules.

 

73, Rik  ON7YD - = OR7T

 

Van: owner-rsgb_lf_group@blacksheep.org = [owner-rsgb_lf_group@blacksheep.org] namens&nb= sp;wolf_dl4yhf=20 [dl4yhf@freenet.de]
Verzonden:=  woensdag=20 20 mei 2015 22:40
Aan: = rsgb_lf_group@blacksheep.org
Onderwerp= :=20 Re: LF: MF=20 = 630m: False Decode or=20 Real?

Hi Jochen,

I think=20 the discussion about Opera's own=20 'deep search' mode (or whatever
the = proper name=20 is) was done here (or on = "the=20 other" reflector) over a 
year ago, and=20 the main problem I see = is that=20 the 'real time web-based
exchange'=20 of currently active=20 stations means fooling=20 = oneself.
Consider this: You = ;know there=20 = are only four possible callsigns=  which=20
have been transmitting, so = in reality the=20 software only has = to decide 
for=20 a TWO BIT=20 number. Much easier than=20 "really" decoding=20 the entire 
number of message bits=20 in an Opera=20 = message.

In my very personal = point=20 of view, this 'real time web exchange of =
stations=20 (calls) which are currently=20 = transmitting' should not be&nb= sp;used=20 at
all.
For comparison, Markus'=20 (DF6NM's) own deep=20 search uses=20 = a quite large 
table which= =20 is=20 = *static*, which means that his=20 decoder has no chance to 
play = unfair=20 = (because it doesn't know = who's currently active or=20 not),=20 = and 
it also doesn't know<= /A> what others receive=20 (over the internet). What = I 
don't know=20 is how many stations are currently = in that list,=20 and thus how 
many bits=20 the algorithm effectively has to = "decode"=20 = (well, it doesn't 
really=20 decode, it also makes a=20 best guess from=20 a limited number of = list 
entries=20 to chose from).

All = the additional=20 data which look=20 as if they were "decoded"=20 (eg "VK3ELV
... 140w +=20 Top loaded=20 = L 18m vert 80m=20 horz") have been taken from a
database=20 (***including the callsign***), not = radio ..=20 = the only real 
information  = is the=20 '- 37 dB' report, and=20 = the two question marks which<= /A> 
imho may=20 as well have been ten or twenty=20 (considering the season and the=20 =
distance).

Well just my&= nbsp;two pence=20 of wisdom. I don't use Opera=20 and don't think I
ever=20 will.

Cheers,
   Wolf=20 .










Am 20.05.2015=20 22:03, schrieb J.=20 Althoff:
> Hi=20 Wolf,
>
> You=20 are not disappointing me at all. I=20 put this issue under discussion=20 = myself.
>
> Please share = your opinion about this=20 to this topic to us in = detail. Maybe I=20 missed
>=20 A discussion about this=20 before, but=20 I am very interested=20 in arguments about this
>=20 Topic.
>
> Thanks,=20 Jochen
>
>
>    =20 -=3D DF1VB =3D-
>   =20 -=3D KH2MM = =3D-
>   Jochen=20 Althoff
>   df1vb@gmx.de
> +491712020206
>
>
>> = Am=20 20.05.2015 um=20 21:44 schrieb wolf_dl4yhf=20 <dl4yhf@freenet.de>:
>>
>> = Sorry=20 to dissapoint you but .. = no,=20 no, no, and again, no.
>>
>>=20 73,
>>   Wolf
>>
>> Am 20.05.2015 = 20:02, schrieb Jochen=20 Althoff:
>>> Just popped up=20 at my RX:
>>>
>>>=20 17:52    477 VK3ELV de=20 DF1VB/3 Op8 Deep Search = ?? 16348=20 km -37 dB = in Dortmund with 140w +=20 Top loaded=20 = L 18m vert 80m=20 = horz
>>>
>>> Any c= omments=20 welcome
>>>
>>> 73,=20 = Jochen
>>
>
>


=

------=_NextPart_000_00A7_01D09400.E659F3B0--