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 wALGv2jb002433 for ; Wed, 21 Nov 2018 17:57:08 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1gPVjg-0006y8-P0 for rs_out_1@blacksheep.org; Wed, 21 Nov 2018 16:52:20 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1gPVjd-0006xv-QL for rsgb_lf_group@blacksheep.org; Wed, 21 Nov 2018 16:52:17 +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 1gPVjb-0002eB-R3 for rsgb_lf_group@blacksheep.org; Wed, 21 Nov 2018 16:52:16 +0000 X-KULeuven-Envelope-From: rik.strobbe@kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 4743912000D.A510B 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 4743912000D for ; Wed, 21 Nov 2018 17:52:04 +0100 (CET) Received: from ICTS-S-EXMBX23.luna.kuleuven.be (icts-s-exmbx23.luna.kuleuven.be [10.112.11.58]) (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 2F09A40B5; Wed, 21 Nov 2018 17:52:04 +0100 (CET) Received: from ICTS-S-EXMBX27.luna.kuleuven.be (10.112.11.62) by ICTS-S-EXMBX23.luna.kuleuven.be (10.112.11.58) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 21 Nov 2018 17:52:04 +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; Wed, 21 Nov 2018 17:52:04 +0100 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Rik Strobbe To: "rsgb_lf_group@blacksheep.org" CC: "600MRG@mailman.qth.net" <600MRG@mailman.qth.net>, rsgb_lf_group Thread-Topic: LF: SlowJT9 averaging (in conversion to JT9-1) Thread-Index: AQHUga9TasBswUSc5Uyy0LTDQ9ucTaVaVbqAgAAWJPI= Date: Wed, 21 Nov 2018 16:52:04 +0000 Message-ID: <1542819051896.23883@kuleuven.be> References: <1541712573053.31739@kuleuven.be> <1542362144885.30626@kuleuven.be> <1542721669174.9290@kuleuven.be> <1542724318123.33202@kuleuven.be> <4c469b8e-72ca-08f9-f8f6-a382109537b5@n1bug.com> <1542728224113.91361@kuleuven.be> <8c07075d-4453-5362-1697-4abc779a8ae0@n1bug.com> <1542813050896.24684@kuleuven.be> <1542815371548.82873@kuleuven.be>, In-Reply-To: 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: -2.3 (--) 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 Andy, no I am not sure it is THE best way, it is just MY best way. Adapting the WSJT-X JT9 decoder might be a better option. Content analysis details: (-2.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [2a02:2c40:0:c0:0:0:25:136 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message X-Scan-Signature: 84ab60ecdd4473835b39687102047368 Subject: Re: LF: SlowJT9 averaging (in conversion to JT9-1) Content-Type: multipart/alternative; boundary="_000_154281905189623883kuleuvenbe_" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE, TO_ADDRESS_EQ_REAL 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_154281905189623883kuleuvenbe_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ?Hello Andy, no I am not sure it is THE best way, it is just MY best way. Adapting the WSJT-X JT9 decoder might be a better option. Creating a nice interface is within my range but I am not sure I am capable= of changing the WSJT-X JT9 decoder (agree, there is only one way to find o= ut about that ...). Basicaly I was looking for a fast way to get JT9-2 and eventually JT9-5 and= JT9-10 rolling again, as I am convinced that these modes (certainly JT9-2)= can contribute to more long distance QSO's (I plead guilty to be one of th= ese old school hams that still want to make QSO's, the further the better). And as far as I understand, in theory "speeding up" (with averaging) to JT9= -1 should get the same result as adapting the decoder software. But suggestions to do it another (preferable better) way are welcome. And if someone feels the itch to adapt the JT9 decoder (or write an own dec= oder) I will be happy to implement that in SlowJT9. 73, Rik ON7YD - OR7T ________________________________ Van: owner-rsgb_lf_group@blacksheep.org namens Andy Talbot Verzonden: woensdag 21 november 2018 17:11 Aan: rsgb_lf_group@blacksheep.org CC: 600MRG@mailman.qth.net; rsgb_lf_group Onderwerp: Re: LF: SlowJT9 averaging (in conversion to JT9-1) Rik Are you sure you are going about this the best way? If you want to stay w= ith the original JT9-slow values, then wouldn't it be better to go to the W= SJT repository and find the original source code. Or dive inside the deco= ding software and change the numbers, instead of speeding things up and ave= raging ALTERNATIVELY, if you wish to stay with the speeded up version and the late= st decoder, then go back to your original idea of integer ratios. Forget = backwards compatibility. After all, no one is likely to be using the old W= SJT-X 1 suite with these modes so there is no need for backwards compatibil= ity. You can start with a fresh and the simpler approach The only thing I suggest is that you change the name of the mode slightly. = Stay with JT9 for the normal one, but instead of JT9-2 and JT9-5 call it = , say JT9-R2 and JT9-R4 (R for Rik :-) That way no one can think it is b= ackwards compatible. Andy www.g4jnt.com On Wed, 21 Nov 2018 at 15:53, Rik Strobbe > wrote: For those interested: in order to get JT9-2, JT9-5 and JT9-10 signals decoded with a JT9 decoder = (from the WSJT-X suite), the JT9-2, JT9-5, JT9-10 audio is "speeded up" to = JT9-1. During the process the signal is also averaged (otherwise ther would= be no S/N improvement). In the initial versions of SlowJT9 the ratios were integer values: 2 for JT= 9-2 anf 5 for JT9-5, making averaging very simple. In SlowJT9 v0.9.10 however the original parameters for JT9-2, JT9-5 and JT9= -10 are used, resulting in some non-integer conversion rates: 2.2222 (15360= /6912) for JT9-2 and 5.9259 (40960/6912) for JT9-5. So, how to average with for example each 2.2222 incoming samples are conver= ted to 1 outgoing sample? Not finding relevant information about this on the web, I did it quite stra= igh forward: Assuming I1, I2, I3, I4, ... are the incoming JT9-2 samples and O1, O2, O3,= O4, ... are the outgoing JT9(-1) samples O1 =3D (I1+I2+0.222*I3)/2.222 O2 =3D (0.778*I3+I4+0.444*I5)/2.222 O3 =3D (0.556*I5+I6+0.667*I7)/2.222 O4 =3D (0.333*I7+I8+0.889*I9)/2.222 and so on. I am by no means sure that this is the best way to average for non-integer = conversion rates (it was just the best I could think of), so any suggestion= to do this better is welcome. 73, Rik ON7YD - OR7T --_000_154281905189623883kuleuvenbe_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

​Hello Andy,


no I am not sure it is THE best way, it is just MY best way.

Adapting the WSJT-X JT9 decoder might be a better option.

Creating a nice interface is w= ithin my range but I am not sure I am capable of changing the W= SJT-X JT9 decoder (agree, there is only one way to find out about that ...).

Basicaly I was looking for a fast way to get JT9-2 and eventually J= T9-5 and JT9-10 rolling again, as I am convinced that these modes (certainl= y JT9-2) can contribute to more long distance QSO's (I plead guilty to be&n= bsp;one of these old school hams that still want to make QSO's, the further the better).

And as far as I understand, in theory "speeding up" (with aver= aging) to JT9-1 should get the same result as adapting the decoder sof= tware.

 

But suggestions to do it another (prefe= rable better) way are welcome. 

And if someone feels the itch to adapt = the JT9 decoder (or write an own decoder) I will be happy to implement that= in SlowJT9.


73, Rik  ON7YD - OR7T



Van: owner-rsgb_lf_group@bl= acksheep.org <owner-rsgb_lf_group@blacksheep.org> namens Andy Talbot = <andy.g4jnt@gmail.com>
Verzonden: woensdag 21 november 2018 17:11
Aan: rsgb_lf_group@blacksheep.org
CC: 600MRG@mailman.qth.net; rsgb_lf_group
Onderwerp: Re: LF: SlowJT9 averaging (in conversion to JT9-1)
 
Rik

Are you sure you are going about this the best way?   If you want= to stay with the original JT9-slow values, then wouldn't it be better to g= o to the WSJT repository and find the original source code.   Or = dive inside the decoding software and change the numbers, instead of speeding things up and averaging

ALTERNATIVELY, if you wish to stay with the speeded up version and the late= st decoder, then go back to your original idea of integer ratios.  &nb= sp;Forget backwards compatibility.  After all, no one is likely to be = using the old WSJT-X 1 suite with these modes so there is no need for backwards compatibility.   You can start wi= th a fresh and the simpler approach

The only thing I suggest is that you change the name of the mode slightly.&= nbsp;  Stay with JT9 for the normal one, but instead of JT9-2 and JT9-= 5 call it , say JT9-R2 and JT9-R4   (R for Rik :-)  That way= no one can think it is backwards compatible.





On Wed, 21 Nov 2018 at 15:53, Rik Strobbe <rik.strobbe@kuleuven.be> wrote:

For those interested:


in order to get JT9-2, JT9-5 and JT9-10 signals decoded with a JT9 decod= er (from the WSJT-X suite), the JT9-2, JT9-5, JT9-10 audio is "sp= eeded up" to JT9-1. During the process the signal is also averaged (ot= herwise ther would be no S/N improvement).

In the initial versions of SlowJT9 the ratios were integer values: 2 for= JT9-2 anf 5 for JT9-5, making averaging very simple.

In SlowJT9 v0.9.10 however the original parameters for JT9-2, JT9-5 and = JT9-10 are used, resulting in some non-integer conversion rates: = 2.2222 (15360/6912) for JT9-2 and 5.9259 (40960/6912) for JT9-5.

So, how to average with for example each 2.2222 incoming samples are con= verted to 1 outgoing sample?

Not finding relevant information about this on the web, I did it qu= ite straigh forward:

Assuming I1, I2, I3, I4, ... are the incoming JT9-2 = samples and O1, O2, O3, O4, ... are the outgoing JT9(-1) samples

O1 =3D (I1+I2+0.222*I3)/2.222

O2 =3D (0.778*I3+I4+0.444*I5)/2.222

O3 =3D (0.556*I5+I6+0.667*I7)/2.222

O4 =3D (0.333*I7+I8+0.889*I9)/2.222

and so on.

I am by no means sure that this is the best way to average for non-= integer conversion rates (it was just the best I could think= of), so any suggestion to do this better is welcome.


73, Rik  ON7YD - OR7T



--_000_154281905189623883kuleuvenbe_--