Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by klubnl.pl (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id wAD8Odiq032506 for ; Tue, 13 Nov 2018 09:24:45 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1gMTsy-0006S6-Ay for rs_out_1@blacksheep.org; Tue, 13 Nov 2018 08:17:24 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1gMTsl-0006Rv-7Y for rsgb_lf_group@blacksheep.org; Tue, 13 Nov 2018 08:17:11 +0000 Received: from rhcavuit03.kulnet.kuleuven.be ([2a02:2c40:0:c0::25:136]) by relay1.thorcom.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91_59-0488984) (envelope-from ) id 1gMTsj-00046C-CA for rsgb_lf_group@blacksheep.org; Tue, 13 Nov 2018 08:17:09 +0000 X-KULeuven-Envelope-From: rik.strobbe@kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 916F012000C.A410A X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by rhcavuit03.kulnet.kuleuven.be (Postfix) with ESMTP id 916F012000C for ; Tue, 13 Nov 2018 09:17:02 +0100 (CET) Received: from ICTS-S-EXMBX25.luna.kuleuven.be (icts-s-exmbx25.luna.kuleuven.be [10.112.11.60]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTPS id 8151040B5; Tue, 13 Nov 2018 09:17:02 +0100 (CET) Received: from ICTS-S-EXMBX27.luna.kuleuven.be (10.112.11.62) by ICTS-S-EXMBX25.luna.kuleuven.be (10.112.11.60) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 13 Nov 2018 09:17:01 +0100 Received: from ICTS-S-EXMBX27.luna.kuleuven.be ([fe80::291a:cc4f:6953:698a]) by ICTS-S-EXMBX27.luna.kuleuven.be ([fe80::291a:cc4f:6953:698a%25]) with mapi id 15.00.1395.000; Tue, 13 Nov 2018 09:17:02 +0100 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Rik Strobbe To: "rsgb_lf_group@blacksheep.org" , "600MRG@mailman.qth.net" <600MRG@mailman.qth.net> Thread-Topic: SlowJT9 v0.9.02: Decode simultaneous Thread-Index: AQHUetlkCr4ZhEQgOk+qCglSmtNeraVNVVfU Date: Tue, 13 Nov 2018 08:17:02 +0000 Message-ID: <1542097021988.39835@kuleuven.be> References: <1542060256183.45653@kuleuven.be>,<1670a157bca-1ec2-4867@webjas-vad028.srv.aolmail.net> In-Reply-To: <1670a157bca-1ec2-4867@webjas-vad028.srv.aolmail.net> Accept-Language: nl-BE, en-GB, en-US Content-Language: nl-BE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.112.50.1] MIME-Version: 1.0 X-Spam-Score: -0.7 (/) X-Spam-Report: Spam detection software, running on the system "relay1.thorcom.net", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hello Jim, all, my plan was that SlowJT9 will decode all JT9 submodes and show them on the same decoder window. The user can see for each decoding what the submode is (the M parameter in the decoder window will show 1, 2 or 5). If the user double-clicks on any call, SlowJT9 will change the TX submode to that of the received station (you double-clicked on) and you are ready for a QSO. [...] Content analysis details: (-0.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2a02:2c40:0:c0:0:0:25:136 listed in] [list.dnswl.org] -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message X-Scan-Signature: 539279ff7bff569d21f0b11e439ca5cc Subject: LF: Re: SlowJT9 v0.9.02: Decode simultaneous Content-Type: multipart/alternative; boundary="_000_154209702198839835kuleuvenbe_" 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_FONTCOLOR_UNKNOWN,HTML_MESSAGE 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 --_000_154209702198839835kuleuvenbe_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Jim, all, my plan was that SlowJT9 will decode all JT9 submodes and show them on the = same decoder window. The user can see for each decoding what the submode is= (the M parameter in the decoder window will show 1, 2 or 5). If the user d= ouble-clicks on any call, SlowJT9 will change the TX submode to that of the= received station (you double-clicked on) and you are ready for a QSO. No hastle with 2 or 3 instances ... But, as said before, this might be difficult with the initial JT9-2 and JT9= -5 transmission durations (49 sec for JT9-1, 109 sec for JT9-2 and 290 sec = for JT9-5) decoding for all submodes will happen at (almost) the same momen= t. On a moderate PC during the a single JT9 decoding the CPU usage peaks to= 40-50%. What will happen if 3 instances of the JT9 decoder are invoced at = the same time? An alternative would be to decode the 3 submodes one by one (in series). Bu= t I noticed that on a busy band one JT9 decoding can take several seconds, = so 3 decodings can take so much time that it exceeds the 10 seconds "respon= se time" (between the end of transmission an start of the next cycle), prev= enting the user from responding in time. With the current JT9-2 and JT9-5 transmission times in SlowJT9 (49 sec for= JT9-1, 98 sec for JT9-2 and 245 sec for JT9-5) there is alway at least 10 = seconds difference between any (JT9-1, JT9-2 or JT9-5) decoding, what shoul= d be no problem unless a very slow PC is used. So at this moment I am seeking advice about how to proceed. My aim to to cr= eate a tool that is useful for DX communication on 472kHz and 136kHz, so "y= our wish is my command" (but keep it realistic). 73, Rik ON7YD - OR7T ________________________________ Van: owner-rsgb_lf_group@blacksheep.org namens James Hollander Verzonden: maandag 12 november 2018 23:40 Aan: rsgb_lf_group@blacksheep.org; 600MRG@mailman.qth.net Onderwerp: LF: SlowJT9 v0.9.02: Decode simultaneous Rik, all, So, as I understand it, on some ordinary night a MF statio= n would/could run at least two software instances of JT9=97one instance set= to decode 2 minute slow JT9, and the other instance decoding 1 minute JT9 = concurrently. The 1st s/w instance is set for slow JT9. If the station you want to cal= l or have respond to a CQ is low-SNR like a QRP, transcontinental, or trans= oceanic station, then you activate your transmission using the slow JT9 sof= tware instance. If low-SNR stations comprise the only intended reception,= then slow JT9 is all you use and forget the 2nd s/w instance. You get de= ep-SNR receptions and QSOs that regular JT9 can=92t deliver. The 2nd s/w instance is set for regular JT9. Suppose the station you want t= o call or have respond to a CQ is likely above, say, the 50% decode probabi= lity, at least SNR -27 dB most of the time. Then you activate your transmis= sion on-the-fly instead with regular JT9 using that 2nd s/w instance. That= way, you either get a reply after 1 minute or have the chance to repeat yo= ur transmission. The nimble operator uses the 1st or 2nd s/w instance that=92s simultaneou= sly running as conditions and as sought-after stations warrant. No need to= change TX frequency. The DX may be on some other frequency than you, but = that=92s fine. You call them with slow JT9 or regular JT9 as you decide on= -the-fly without changing your frequency and they will see you on their PC = display if they can. Other stations may be running either slow JT9 or regular JT9 at any given t= ime, and that=92s fine too because you can receive them either way. You=92= ll see stations TXing slow JT9 on one decoder window and stations TXing reg= ular JT9 on the other decoder window. If a station sends slow JT9 for a whi= le and then regular JT9 for a while, you=92ll see that station go from one = decoder window to the other. If a station is already running regular JT9 diversity with two RX antennas = and two regular JT9 decoders connected to SDR sub-RXs, you just add two mor= e decoders for slow JT9 diversity as well. Depending on your PC, use a PC p= owerful enough to run the s/w instances concurrently. Feel free to clarify if I=92m missing anything important. Very interesting= ! 73, Jim H W5EST -----Original Message----- From: Rik Strobbe To: rsgb_lf_group ; rsgb_lf_group Sent: Mon, Nov 12, 2018 4:05 pm Subject: Re: LF: SlowJT9 v0.9.02 Hi Paul, it seems that we will have to make a choice: - either the old JT9-= 2 and JT9-5 standard and only decoding one mode at a time - or keeping the = current JT9-2 and JT9-5 parameters and keep the option open to decode all J= T9 submodes simultanious. I tend to go for the second option, but everyone = is welcome to convince me otherwise. 73, Rik ON7YD - OR7T _________________= _______________________ Van: owner-rsgb_lf_group@blacksheep.org > namens N1BUG > Verzonden: maandag 12 november 2018 22:43 Aan: rsgb_lf_group@blacksheep.= org; rsgb_lf_group@yahoogroups.co.uk Onderwerp: Re: LF: SlowJT9 v0.9.02 I= can confirm something similar. My CPU is running around 30% (it's a VERY b= usy system with many apps running). When SlowJT9 invokes the decoder I see = a short spike to 50%, sometimes as high as 55%. 73, Paul N1BUG On 11/12/18 = 4:13 PM, Rik Strobbe wrote: > I just had a look at the CPU usage of my comp= uter: > it is wobbeling between 2% and 5% but peaks to 40% if the JT9 decod= er is invoked. > I am afraid that invoking 3 instances of the JT9 decoder a= t (almost) the same time is not a good idea. > > 73, Rik ON7YD - OR7T --_000_154209702198839835kuleuvenbe_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Jim, all,


my plan was that SlowJT9 will decode all JT9 submodes and= show them on the same decoder window. The user can see for each decoding w= hat the submode is (the M parameter in the decoder window will show 1, 2 or= 5). If the user double-clicks on any call, SlowJT9 will change the TX submode to that of the received station (you double-cli= cked on) and you are ready for a QSO.

No hastle with 2 or 3 instances ...

But, as said before, this might be difficult with the initial JT9-2 and = JT9-5 transmission durations (49 sec for JT9-1, 109&nbs= p;sec for JT9-2 and 290 sec for JT9-5) decoding for all submodes = will happen at (almost) the same moment. On a moderate PC during the a single JT9 decoding the CPU usage peaks to 40-50%. What will h= appen if 3 instances of the JT9 decoder are invoced at the same time?

An alternative would be to decode the 3 submodes one by one (in series).= But I noticed that on a busy band one JT9 decoding can take several second= s, so 3 decodings can take so much time that it exceeds the 10 seconds &quo= t;response time" (between the end of transmission an start of the next cycle), preventing the user from respond= ing in time.


With the current JT9-2 and JT9-5 transmission times in SlowJT9  (49= sec for JT9-1, 98 sec for JT9-2 and 245 sec for JT9-5) there is alway at l= east 10 seconds difference between any (JT9-1, JT9-2 or JT9-5) decoding, wh= at should be no problem unless a very slow PC is used.


So at this moment I am seeking advice about how to proceed. My aim = to to create a tool that is useful for DX communication on 472kHz and = 136kHz, so "your wish is my command" (but keep it realistic).


73, Rik  ON7YD - OR7T


Van: owner-rsgb_lf_group@bl= acksheep.org <owner-rsgb_lf_group@blacksheep.org> namens James Hollan= der <mrsocion@aol.com>
Verzonden: maandag 12 november 2018 23:40
Aan: rsgb_lf_group@blacksheep.org; 600MRG@mailman.qth.net
Onderwerp: LF: SlowJT9 v0.9.02: Decode simultaneous
 
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:8pt">
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt">Rik, all,    &nb= sp;   So, as I understand it, on some ordinary night a MF station would/co= uld run at least two software instances of JT9=97one instance set to decode= 2 minute slow JT9, and the other instance decoding 1 minute JT9 concurrent= ly. 
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt"> 
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt">The 1st  s/w instance is set for slow JT9.   If the station you want to call or have respond to= a CQ is low-SNR like a QRP, transcontinental, or transoceanic station, the= n you activate your transmission using the slow JT9 software instance.   If low-SNR stations= comprise the only intended reception, then slow JT9 is all you use and for= get the 2nd s/w instance.   You get deep-SNR receptions and QSOs t= hat regular JT9 can=92t deliver.
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt"> 
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt">The 2nd s/w instance is set for regular JT= 9. Suppose the station you want to call or have respond to a CQ is likely above, say, the 50% decode probability, at least SNR -27 dB= most of the time. Then you activate your transmission on-the-fly inst= ead with regular JT9 using that 2nd s/w instance.  That way, you either get a reply after 1 minute or have the chance t= o repeat your transmission.
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt"> 
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt">The nimble operator uses the 1st  or 2nd  s/w instance that=92s simultaneously running as conditions and as sought= -after stations warrant.  No need to change TX frequency.  The DX= may be on some other frequency than you, but that=92s fine.  You call them with slow JT9 or regular JT9 as you decide o= n-the-fly without changing your frequency and they will see you on their PC= display if they can. 
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt"> 
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt">Other stations may be running either slow JT9 or regu= lar JT9 at any given time, and that=92s fine too because you can receive them either way.  You=92ll see st= ations TXing slow JT9 on one decoder window and stations TXing regular JT9 = on the other decoder window. If a station sends slow JT9 for a while and th= en regular JT9 for a while, you=92ll see that station go from one decoder window to the other.
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt"> 
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt">If a station is already running regular JT9 diversity= with two RX antennas and two regular JT9 decoders connected to SDR sub-RXs, you just add two more decoders for slow JT9 diversity as w= ell. Depending on your PC, use a PC powerful enough to run the s/w instance= s concurrently. 
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt"> 
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt">Feel free to clarify if I=92m missing anything import= ant.  Very interesting!  73, Jim H  W5EST
<= span style=3D"color:black; font-family:"Arial","sans-serif&q= uot;; font-size:10pt"> 
 
---= --Original Message-----
From: Rik Strobbe <rik.strobbe@kuleuven.be>
To: rsgb_lf_group <rsgb_lf_group@blacksheep.org>; rsgb_lf_group <r= sgb_lf_group@yahoogroups.co.uk>
Sent: Mon, Nov 12, 2018 4:05 pm
Subject: Re: LF: SlowJT9 v0.9.02

Hi Paul, it seems that we will have to make a choice: - either the old JT9-= 2 and JT9-5 standard and only decoding one mode at a time - or keeping the = current JT9-2 and JT9-5 parameters and keep the option open to decode all J= T9 submodes simultanious. I tend to go for the second option, but everyone is welcome to convince me otherw= ise. 73, Rik ON7YD - OR7T ________________________________________ Van: own= er-rsgb_l= f_group@blacksheep.org <owner-rsgb_lf_group@blacksheep.org> namens N1BUG <paul@= n1bug.com> Verzonden: maandag 12 november 2018 22:43 Aan: rsgb_lf_g= roup@blacksheep.org; rsgb_l= f_group@yahoogroups.co.uk Onderwerp: Re: LF: SlowJT9 v0.9.02 I can conf= irm something similar. My CPU is running around 30% (it's a VERY busy syste= m with many apps running). When SlowJT9 invokes the decoder I see a short spike to 50%, sometimes as high as 55%. = 73, Paul N1BUG On 11/12/18 4:13 PM, Rik Strobbe wrote: > I just had a lo= ok at the CPU usage of my computer: > it is wobbeling between 2% and 5% = but peaks to 40% if the JT9 decoder is invoked. > I am afraid that invoking 3 instances of the JT9 decoder at = (almost) the same time is not a good idea. > > 73, Rik ON7YD - OR7T
--_000_154209702198839835kuleuvenbe_--