Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by mtain-mh03.r1000.mx.aol.com (Internet Inbound) with ESMTP id C209938000088; Sat, 8 Sep 2012 19:28:43 -0400 (EDT) Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1TAURL-0002JD-Mm for rs_out_1@blacksheep.org; Sun, 09 Sep 2012 00:27:51 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1TAURL-0002J4-1Q for rsgb_lf_group@blacksheep.org; Sun, 09 Sep 2012 00:27:51 +0100 Received: from smtpout2.wanadoo.co.uk ([80.12.242.42] helo=smtpout.wanadoo.co.uk) by relay1.thorcom.net with esmtp (Exim 4.77) (envelope-from ) id 1TAURI-0006vn-AJ for rsgb_lf_group@blacksheep.org; Sun, 09 Sep 2012 00:27:49 +0100 Received: from AGB ([2.26.45.146]) by mwinf5d22 with ME id wnTm1j00739DqMu03nTmjm; Sun, 09 Sep 2012 01:27:47 +0200 Message-ID: <8ECCED9ECECD4C2DBCB2EE7A5944FC0B@AGB> From: "Graham" To: References: <50493001.4050202@iup.uni-heidelberg.de> <16BEB82EDFAD4E4FB0A34C8BABAA6AE1@AGB> <504A14AD.2070403@iup.uni-heidelberg.de> <00ca01cd8ded$85328aa0$1502a8c0@Clemens04> <673F2A3B35F24CF894C1077CE36E2AEA@White> <75B3865F8CAA40E098D45E95C70DDE26@White> In-Reply-To: <75B3865F8CAA40E098D45E95C70DDE26@White> Date: Sun, 9 Sep 2012 00:27:46 +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-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "relay1.thorcom.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Yes the Op system is included in the new vhf beacons . so a direct frequency error indication would be advantageous .. this is something that needs to be looked at , I know from the trial versions , audio frequency to mHz was displayed , the dual pass bands are to reduce the level of false decodes , which for a free running , single pass system are very low , the original shared pass band required higher cpu loading , which for some reason was seen as a detrimental aspect . [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.12.242.42 listed in list.dnswl.org] 0.0 T_OBFU_GIF_ATTACH BODY: GIF attachment with generic MIME type 0.0 HTML_MESSAGE BODY: HTML included in message X-Scan-Signature: b266e01efe570cc7cc73d9fd75b218c3 Subject: Re: LF: Dial frequency - or better not? Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_00D6_01CD8E21.EF668230" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_30_40,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.63 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-aol-global-disposition: G X-AOL-VSS-INFO: 5400.1158/83768 X-AOL-VSS-CODE: clean x-aol-sid: 3039ac1d60d7504bd4ab0b09 X-AOL-IP: 195.171.43.25 X-AOL-SPF: domain : blacksheep.org SPF : none This is a multi-part message in MIME format. ------=_NextPart_000_00D6_01CD8E21.EF668230 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00D7_01CD8E21.EF668230" ------=_NextPart_001_00D7_01CD8E21.EF668230 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Yes the Op system is included in the new vhf beacons . so a = direct frequency error indication would be advantageous .. this is = something that needs to be looked at , I know from the trial = versions , audio frequency to mHz was displayed , the dual pass = bands are to reduce the level of false decodes , which for a = free running , single pass system are very low , the original = shared pass band required higher cpu loading , which for some = reason was seen as a detrimental aspect . =20 The dual pass bands would further complicate matters if a simple = bfo off set was defined=20 The option was considered to use web time locking to reduce the cpu = loading, but that would of placed limitations on its use , the = last Russian field party being a good example of the decision, = the Ros data mode is also free running and independent of time = considerations.=20 Under normal usage , the exact frequency is of no concern other = than it falls within the decoder pass band and complies with the = drift/jitter constraints , in fact non of the dsp processing of = Jos=E9's software requires soundcard alignment , locking etc , for = normal amateur equipment , 1 Hz accuracy could be some what = questionable ? 73 -G. From: Markus Vester=20 Sent: Saturday, September 08, 2012 10:46 PM To: rsgb_lf_group@blacksheep.org=20 Cc: rsgb_lf_group@yahoogroups.co.uk=20 Subject: LF: Dial frequency - or better not? Graham, > This all started with WSPR=20 yes I know... but let me suggest two points you might consider adopting = in future Op versions:=20 With WSPR v2, there is a "BFO" setting allowing to configure the RX = audio frequency range. The TX frequency can be edited as well. For = example, my LO is fixed on 135.5 kHz, and the default 1500 Hz centered = band would be useless here. When WSPR has found a signal, it adds the measured audio frequency to = the selected LO, and reports the QRG with 1 Hz accuracy in each spot. Best 73, Markus (DF6NM) From: Graham=20 Sent: Saturday, September 08, 2012 10:06 PM To: rsgb_lf_group@blacksheep.org=20 Subject: Re: LF: LF/MF night and weekend This all started with WSPR , 'we' had to introduce the the idea = of ' Dial set usb' or half the LF/MF Rx stations where off = frequency , as the mode expected a normal ssb /tx/rx ..then = came the PIC coders and things soon got out of hand .as we had = work out offsets . now cw operators are using 'semi-data' and we = start all over again .. In normal use , Op anti-collision system ( 2.5 Hz space) places the = carrier in the lowest s/n slot , as determined in the last 2 = seconds before the Tx is keyed , so the frequency will change = from each over ..=20 We are all appliance operators now .. , 'Appliance of Science' ! G.. From: Markus Vester=20 Sent: Saturday, September 08, 2012 8:43 PM To: rsgb_lf_group@blacksheep.org=20 Subject: Re: LF: LF/MF night and weekend Clemens, Stefan is actually transmitting on 478.70 kHz... I would generally prefer exchanging real RF frequencies rather than a = "dial frequency" setting, which I find more confusing than helpful. It = would also be nice if the web reports would mention the precise receive = frequency. After all, we wanna be real radio amateurs and not black box = users (aka appliance operators ;-). Best 73 and good luck, Markus (DF6NM) From: Clemens Paul=20 Sent: Saturday, September 08, 2012 8:12 PM To: rsgb_lf_group@blacksheep.org=20 Subject: Re: LF: LF/MF night and weekend >I just started my TX in OP4 mode on 477 kHz dial. Will run in until = sunday evening Stefan, wouldn't it be better to choose a slightly different qrg to avoid = interfering with the carrier of the 'RP' NDB beacon (which is BTW masking your signal here)? Perhaps 500Hz up or down would be fine. 73 Clemens DL4RAJ ... ------=_NextPart_001_00D7_01CD8E21.EF668230 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable
Yes  the  Op system is  included in the  = new  vhf=20 beacons  . so  a direct   frequency error =20 indication  would be  advantageous .. this is  something=20 that  needs  to  be looked at , I know  from = the =20 trial  versions  , audio  frequency  to  =20 mHz  was displayed , the  dual  pass  bands are=20 to   reduce the  level  of false  decodes  = ,=20 which  for a  free  running  , single  = pass =20 system are very  low , the  original  shared  = pass =20 band  required  higher  cpu loading , which for  = some =20 reason was  seen as a  detrimental  aspect . 
 
The  dual  pass  bands = would  further =20 complicate  matters  if a  simple bfo off  set  = was  defined
 
The option was  considered to  use  web time  = locking=20 to  reduce the cpu  loading, but  that  = would =20 of  placed  limitations  on its use , the last =20 Russian  field  party  being  a  good = example  of=20 the  decision, the  Ros  data mode is also  free=20 running  and  independent of time  considerations.
 
Under normal  usage  , the  exact frequency  is = of no=20 concern  other  than  it falls  within  = the =20 decoder pass  band and complies with the  = drift/jitter =20 constraints ,  in fact non of   the  dsp  = processing=20 of  Jos=E9's software  requires soundcard = alignment  ,=20 locking    etc , for  normal  amateur =  equipment =20 , 1 Hz  accuracy  could be  some what  = questionable =20 ?
 
73 -G.
 
 
 
 

From: Markus Vester
Sent: Saturday, September 08, 2012 10:46 PM
To: rsgb_lf_group@blacksheep.org= =20
Cc: rsgb_lf_group@yahoogroups= .co.uk=20
Subject: LF: Dial frequency - or better = not?

Graham,
 
> This  all  started  with  WSPR 
 
yes I know... but let me = suggest two points=20 you might consider adopting in future Op versions: =
 
With WSPR v2, there is a = "BFO" setting=20 allowing to configure the RX audio frequency range. The TX = frequency=20 can be edited as well. For example, my LO is fixed on 135.5 kHz, = and=20 the default 1500 Hz centered band would be useless = here.
 
When WSPR has found a = signal, it adds the=20 measured audio frequency to the selected LO, and reports the QRG = with 1 Hz=20 accuracy in each spot.
 
Best 73,
Markus (DF6NM)
 
 

From: Graham
Sent: Saturday, September 08, 2012 10:06 PM
Subject: Re: LF: LF/MF night and weekend

This  all  started  with  WSPR  , = 'we' =20 had  to introduce the  the  idea of  ' Dial = set =20 usb'  or  half the LF/MF  Rx  stations =20 where  off  frequency  , as the  mode =20 expected   a  normal   ssb /tx/rx  = ..then =20 came  the  PIC coders  and  things  soon  = got out=20 of  hand .as  we  had work out  offsets   . now  cw = operators =20 are  using  'semi-data'  and we start all  = over  again=20 ..
 
In normal  use , Op anti-collision  system  ( 2.5 Hz = space)  places the  carrier in the  lowest   = s/n =20 slot  , as  determined  in the  last  2 = seconds =20 before the  Tx  is  keyed , so the  frequency =20 will  change  from  each over ..
 
We are  all  appliance  operators now .. =  ,=20 'Appliance of  Science'  !
 
G..

From: Markus Vester
Sent: Saturday, September 08, 2012 8:43 PM
To: rsgb_lf_group@blacksheep.org= =20
Subject: Re: LF: LF/MF night and weekend

Clemens,
 
Stefan is actually transmitting on = 478.70=20 kHz...
 
I would generally = prefer exchanging real RF=20 frequencies rather than a "dial frequency" setting, which I find = more=20 confusing than helpful. It would also be nice if the web reports would = mention=20 the precise receive frequency. After all, we wanna be real radio = amateurs and=20 not black box users (aka appliance operators ;-).
 
Best 73 and good luck,
Markus (DF6NM)
 
Sent: Saturday, September 08, 2012 8:12 PM
Subject: Re: LF: LF/MF night and weekend

>I just started my TX in OP4 mode on 477 kHz dial. = Will=20 run in until sunday evening
 
Stefan,
 
wouldn't it be better to choose a slightly different qrg to = avoid=20 interfering with the carrier
of  the 'RP' NDB beacon (which is BTW masking your signal = here)?
Perhaps 500Hz up or down would be fine.
 
73
Clemens
DL4RAJ
 ...
------=_NextPart_001_00D7_01CD8E21.EF668230-- ------=_NextPart_000_00D6_01CD8E21.EF668230 Content-Type: application/octet-stream; name="Emoticon10.gif" Content-Transfer-Encoding: base64 Content-ID: <3F8CD0A02BEC4A03887FE8B6EE6D4FC0@AGB> R0lGODlhEwATALMPAPbw4Nm8W/XZSem3KtuvMvTjVvDHOeTKj7CLMdCbMO7JbqN/KbmfZp8/H1Mf DQAAACH5BAEAAA8ALAAAAAATABMAAASq8EkJjjJjqAOmf5VhCEUhiAT3AVfplicRdJRCvq6gy/Rh FIHFIuAiCAmGFOhXWDgcC5cTikmEStMo9rkQJSy3BQCgbY67ScYIe5aeMQPEwBUcwowLZGYx0OF0 gCIZBAgXgIeBggMJDAd9gAQJDZMJehkIDABIOpINlZ0JgwgdB0gGniKCkpcMFAGmqRmycZkTAK+z s4S1HhUJlQQDkQiYNB8gBwwIC5i8ExEAOw== ------=_NextPart_000_00D6_01CD8E21.EF668230--