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.4 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL, 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 t4LGTdnb000411 for ; Thu, 21 May 2015 18:29:39 +0200 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1YvTJK-00050J-JK for rs_out_1@blacksheep.org; Thu, 21 May 2015 17:27:06 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1YvTJK-000508-4d for rsgb_lf_group@blacksheep.org; Thu, 21 May 2015 17:27:06 +0100 Received: from smtpout2.wanadoo.co.uk ([80.12.242.42] helo=smtpout.wanadoo.co.uk) by relay1.thorcom.net with esmtp (Exim 4.85) (envelope-from ) id 1YvTJH-00017D-Qj for rsgb_lf_group@blacksheep.org; Thu, 21 May 2015 17:27:05 +0100 Received: from AGB ([95.150.81.4]) by mwinf5d20 with ME id WgT21q00o05bScF03gT2Sz; Thu, 21 May 2015 18:27:03 +0200 X-ME-Helo: AGB X-ME-Date: Thu, 21 May 2015 18:27:03 +0200 X-ME-IP: 95.150.81.4 Message-ID: <7E12FF358ED44E7BA8BB7AC55261F708@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: <7E7DFBB4D102A04DB5ADC88D66628A4A23548558@ICTS-S-MBX1.luna.kuleuven.be> Date: Thu, 21 May 2015 17:27:02 +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: b90e415b040d4fc83939a5944c1a560a Subject: Re: LF: MF 630m: False Decode or Real? Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01D093EB.59AD9490" 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: 3204 This is a multi-part message in MIME format. ------=_NextPart_000_0062_01D093EB.59AD9490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes I agree very well sad , can talk the talk, but would appears to = have problems walking the walk . It actually bears no resemblance to how the system work's or = shows insight to the difference between a correlation system and = a data transmission system=20 Im not quite sure , how a correlation process is supposed to = identify a 'bit' of data or decode anything as it matches = patterns and has nothing to do with the encoding and decoding = of data and is purely a time based system=20 But gives perhaps, a insight into the working of other popular = systems , which may , then not be quite as intelligent as made out = to be ? the web was full of comments round the need for a call = list in a data mode ... correlation is not limited to a single = on/off carrier , non spread spectrum mfsk systems may also be = so inspected .only needs the coding template and expected call = list . but thats another story=20 As for the qso definition , what ever , other non plain text = systems , also fall into the same category . The main thing is its free and complies with the part-97 bandwidth = expectations =20 73-G, From: Rik Strobbe=20 Sent: Thursday, May 21, 2015 7:47 AM To: rsgb_lf_group@blacksheep.org=20 Subject: RE: LF: MF 630m: False Decode or Real? 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 = the proper name is) was done here (or on "the other" reflector) over a=20 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 = 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=20 play unfair (because it doesn't know who's currently active or not), and = 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 = 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 = ... 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=20 imho may as well have been ten or twenty (considering the season and the = 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_0062_01D093EB.59AD9490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes I agree  very well  sad , can talk the talk, = but =20 would  appears to  have problems   walking  = the =20 walk .
 
It   actually  bears no  resemblance  to  = how=20 the  system  work's or shows insight  to  the =20 difference between a correlation  system   and  = a =20 data  transmission  system
 
Im not quite  sure  , how  a  correlation  = process  is  supposed to  identify  a  = 'bit' =20 of  data or  decode  anything  as  it =20 matches  patterns  and has  nothing  to  = do =20 with  the encoding   and  decoding  of  = data  and=20 is  purely a  time  based   system
 
But gives  perhaps,   a  insight into the =20 working  of  other  popular  systems , which may ,=20 then  not  be  quite  as  intelligent as  = made out=20 to  be ? the  web was full  of comments  round  = the  need  for  a  call  list  in = a  =20 data  mode  ...  correlation is not  limited to = a =20 single  on/off  carrier , non   spread  spectrum=20  mfsk  systems  may also  be  so  = inspected=20 .only  needs  the  coding  template  and =20 expected  call  list . but thats  another  story =
 
As for the qso  definition , what  ever ,  = other =20 non  plain text  systems  , also  fall into  = the =20 same  category .
 
The main thing is  its free  and  complies with = the =20 part-97  bandwidth  expectations   
 
73-G,
 
 

Sent: Thursday, May 21, 2015 7:47 AM
To: rsgb_lf_group@blacksheep.org= =20
Subject: RE: LF: MF 630m: False Decode or = Real?

Hello Wolf,

 

well said.

From the IARU R1 VHF=20 managers handbook:

 

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

 

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

 

73, Rik  ON7YD - OR7T

 

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

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

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

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

Cheers,
  =20 Wolf .










Am 20.05.2015=20 22:03, schrieb J. = Althoff:
> Hi=20 Wolf,
>
> You are not disappointing me at = all. I=20 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=20 I am very interested in arguments about this
> = Topic.
>
>=20 Thanks, Jochen
>
>
>    =20 -=3D DF1VB=20 =3D-
>    -=3D KH2MM =3D-
>   Jochen Althoff
>   df1vb@gmx.de
> +491712020206
>
>
>> = Am=20 20.05.2015 um 21:44 schrieb wolf_dl4yhf <dl4yhf@freenet.de>:
>>
>> Sorry = to dissapoint you but .. no, no, no, and again, = no.
>>
>>=20 73,
>>   Wolf
>>
>> Am 20.05.2015=20 20:02, schrieb Jochen Althoff:
>>> Just popped up=20 at my RX:
>>>
>>> = 17:52   =20 477 VK3ELV de DF1VB/3 Op8 Deep Search ?? 16348 km = -37 dB=20 in Dortmund with 140w + Top loaded=20 L 18m vert 80m horz
>>>
>>> Any comments welcome
>>>
>>> 73, Jochen
>>
>
>


= ------=_NextPart_000_0062_01D093EB.59AD9490--