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 wAAGxBVE011022 for ; Sat, 10 Nov 2018 17:59:19 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1gLWXl-00026y-5N for rs_out_1@blacksheep.org; Sat, 10 Nov 2018 16:55:33 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1gLWXf-00026p-Pr for rsgb_lf_group@blacksheep.org; Sat, 10 Nov 2018 16:55:27 +0000 Received: from rhcavuit01.kulnet.kuleuven.be ([2a02:2c40:0:c0::25:129]) by relay1.thorcom.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91_59-0488984) (envelope-from ) id 1gLWXe-0005Qi-1a for rsgb_lf_group@blacksheep.org; Sat, 10 Nov 2018 16:55:26 +0000 X-KULeuven-Envelope-From: rik.strobbe@kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 6760A120331.A53A1 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 rhcavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 6760A120331 for ; Sat, 10 Nov 2018 17:55:22 +0100 (CET) Received: from ICTS-S-EXMBX20.luna.kuleuven.be (icts-s-exmbx20.luna.kuleuven.be [10.112.11.55]) (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 57BF240B6 for ; Sat, 10 Nov 2018 17:55:22 +0100 (CET) Received: from ICTS-S-EXMBX27.luna.kuleuven.be (10.112.11.62) by ICTS-S-EXMBX20.luna.kuleuven.be (10.112.11.55) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 10 Nov 2018 17:55:21 +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; Sat, 10 Nov 2018 17:55:22 +0100 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Rik Strobbe To: "rsgb_lf_group@blacksheep.org" Thread-Topic: LF: SlowJT9: 1st QSO and 2nd bug found Thread-Index: AQHUeQukLGEK2DvfMkGBgLnEnJ0c1aVJNZsL Date: Sat, 10 Nov 2018 16:55:22 +0000 Message-ID: <1541868852867.84353@kuleuven.be> References: <1320399704.180352.1541864234370.ref@mail.yahoo.com>,<1320399704.180352.1541864234370@mail.yahoo.com> In-Reply-To: <1320399704.180352.1541864234370@mail.yahoo.com> 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 Markus, For 1: extending the audio frequency range is possible, limitation is the fmax of 5kHz of the JT9 decoder. As a result the maximum audio frequency is 2.5kHz for JT9-2 and 1kHz for JT9-5. But even for this there is a workaroud possible by including pre-mixing of the incoming audio before sending it to the JT9 decoder. [...] 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:129 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: 80e63e173fa93b7854d61e1697120204 Subject: Re: LF: SlowJT9: 1st QSO and 2nd bug found Content-Type: multipart/alternative; boundary="_000_154186885286784353kuleuvenbe_" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=HTML_MESSAGE,LINES_OF_YELLING, LINES_OF_YELLING_2,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_154186885286784353kuleuvenbe_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Markus, For 1: extending the audio frequency range is possible, limitation is the fmax of = 5kHz of the JT9 decoder. As a result the maximum audio frequency is 2.5kHz = for JT9-2 and 1kHz for JT9-5. But even for this there is a workaroud possib= le by including pre-mixing of the incoming audio before sending it to the J= T9 decoder. But before doing all this I just want to be sure that it is worth the effor= t: - Do JT9-2 and JT9-5 "in the real world" (with ionoshepric instabilies, dri= fting transmitter and receivers) have a significant advantage over JT9? - Is there sufficient interest of the LF/MF community to use thse modes? For 2: One of the advantages of JT9-2 is that you have 20 seconds time to type the= free text (of maximum 13 characters). For JT9-5 you even have 50 seconds ;= -) But is should be possible to allow a "late start". It would just mean that = the first symbols of the codes message are skiped at the cost of S/N loss. = I think this is a better option that transmitting the entire codes message = some seconds late (what probably would lead to a fail to decode). But as for 1, I would like to wait with this until I am sure that SlowJT9 i= s of any use. 3. I haven't had any crash so far, but it is better to be safe than sorry. = Maybe I can add a "don't show this message again" option. 73, Rik ON7YD - OR7T ________________________________ Van: owner-rsgb_lf_group@blacksheep.org namens Markus Vester Verzonden: zaterdag 10 november 2018 16:37 Aan: rsgb_lf_group@blacksheep.org Onderwerp: Re: LF: SlowJT9: 1st QSO and 2nd bug found Hi Rik, thanks for the great work on this nice piece of software! Comments / questions from this end: 1. My LF equipment has a fixed 135.5 kHz LO, so audio will need to be aroun= d 1800 Hz or so. Such TX and RX frequencies can apparently be be set (albei= t red), but the clickable spectrogram range ends hard at 1400 Hz. Would it = be possible to allow a user defined spectrogram shift? The alternative is e= xternal frequency conversion using SpecLab and virtual cables, but I'd rath= er avoid that due to extra latencies. 2. In the past I often found myself just missing the start of the next tran= smit slot (particularly when entering free text). Is it possible to start a= transmission a few seconds late into the timeslot, or even change the mess= age on the fly? I think the SNR penalty of loosing a few symbols at the beg= inning may not be too severe. 3. The software seems to be fairly stable. Clicking the "save any work done= on this computer" disclamer may not be necessary on every startup. Best 73, Markus (DF6NM) -----Urspr=FCngliche Mitteilung----- Von: Rik Strobbe An: rsgb_lf_group@blacksheep.org ; rsgb_lf_gr= oup@yahoogroups.co.uk Verschickt: Fr, 9. Nov. 2018 23:27 Betreff: LF: SlowJT9: 1st QSO and 2nd bug found Dear all, I just completed a JT9-2 QSO with Marco, DD7PC: 2141 -11 0.1 1104 2 OR7T DD7PC JN49 2145 -10 0.1 1106 2 OR7T DD7PC JN49 2153 -16 0.0 1105 2 OR7T DD7PC R-13 2157 -12 0.0 1105 2 OR7T DD7PC 73 2201 -16 0.1 1106 2 UFB RIK During this QSO I discovered a 2nd bug: As can be seen above the time (UTC) is given at odd minutes (eg. Marco's 21= :40 - 21-42 transmission is reported 2141). This because the time is taken = at the moment of decode. For JT9(-1) this is not an issue, because decoding is in the same minute as= the start of transmission, but for JT9-2 and JT9-5 it is because it result= s in a wrong calculation of the cycle (1st or 2nd). As the wrong cycle is g= iven SlowJT9 will transmit in at the same cycle as the station you received= , very inconvenient! I will fix this big after the weekend (sorry, to many other obligations on = Saturday and Sunday). For the time being the workaround is rather easy: if you get a decode you w= ant to reply to (by double clicking on the call) just change the cycle manu= ally (click once on the "TX 1st cycle" checkbox). The good thing is you hav= e plenty of time to do so as there are 20 seconds between the end of a tran= smission and the start of the next cycle. To end with a positive note: during Marco's 2152-2154 transmission there wa= s very deep QSB and his signal dissapeared from the waterfall display for a= lmost 1 minute. But despite that still a good decode, just some dB weaker. 73, Rik ON7YD - OR7T --_000_154186885286784353kuleuvenbe_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Markus,


For 1:

extending the audio frequency range is possible, limitation is the fmax = of 5kHz of the JT9 decoder. As a result the maximum audio frequency is 2.5k= Hz for JT9-2 and 1kHz for JT9-5. But even for this there is a workarou= d possible by including pre-mixing of the incoming audio before sending it to the JT9 decoder.

But before doing all this I just want to be sure that it is worth the ef= fort: 

- Do JT9-2 and JT9-5 "in the real world" (with ionoshepric ins= tabilies, drifting transmitter and receivers) have a significant advantage = over JT9?

- Is there sufficient interest of the LF/MF community to use thse m= odes?


For 2:

One of the advantages of JT9-2 is that you have 20 seconds time to type = the free text (of maximum 13 characters). For JT9-5 you even have 50 second= s ;-)

But is should be possible to allow a "late start". It would ju= st mean that the first symbols of the codes message are skiped at the = cost of S/N loss. I think this is a better option that transmitting the ent= ire codes message some seconds late (what probably would lead to a fail to decode).

But as for 1, I would like to wait with this until I am sure that SlowJT= 9 is of any use.


3. I haven't had any crash so far, but it is better to be safe than = ;sorry. Maybe I can add a "don't show this message again" option.=


73, Rik  ON7YD - OR7T

Van: owner-rsgb_lf_group@bl= acksheep.org <owner-rsgb_lf_group@blacksheep.org> namens Markus Veste= r <markusvester@aol.com>
Verzonden: zaterdag 10 november 2018 16:37
Aan: rsgb_lf_group@blacksheep.org
Onderwerp: Re: LF: SlowJT9: 1st QSO and 2nd bug found
 
Hi Rik,

thanks for the great work on this nice piece of software!

Comments / questions from this end:

1. My LF equipment has a fixed 135.5 kHz LO, so audio will need to be = around 1800 Hz or so. Such TX and RX frequencies can apparently be be set (= albeit red), but the clickable spectrogram range ends hard at 140= 0 Hz. Would it be possible to allow a user defined spectrogram shift? The alternative is external frequency conversion using = SpecLab and virtual cables, but I'd rather avoid that due to extra lat= encies.

2. In the past I often found myself just missing the start of the next= transmit slot (particularly when entering free text). Is it possible to st= art a transmission a few seconds late into the timeslot, or even = change the message on the fly? I think the SNR penalty of loosing a few symbols at the beginning may not be too severe.
3. The software seems to be fairly stable. Clicking the "save any= work done on this computer" disclamer may not be necessary on every&n= bsp;startup.

Best 73,
Markus (DF6NM)



-----Urspr=FCngliche Mitteilung-----
Von: Rik Strobbe <rik.strobbe@kuleuven.be>
An: rsgb_lf_group@blacksheep.org <rsgb_lf_group@blacksheep.org>; rsgb= _lf_group@yahoogroups.co.uk <rsgb_lf_group@yahoogroups.co.uk>
Verschickt: Fr, 9. Nov. 2018 23:27
Betreff:  LF: SlowJT9: 1st QSO and 2nd bug found

Dear all,

I just completed a JT9-2 QSO with Marco, DD7PC:

2141 -11  0.1 1104 2  OR7T DD7PC JN49      &nbs= p;
2145 -10  0.1 1106 2  OR7T DD7PC JN49       <= br clear=3D"none"> 2153 -16  0.0 1105 2  OR7T DD7PC R-13       <= br clear=3D"none"> 2157 -12  0.0 1105 2  OR7T DD7PC 73        &n= bsp;
2201 -16  0.1 1106 2  UFB RIK

During this QSO I discovered a 2nd bug: 

As can be seen above the time (UTC) is given at odd minutes (eg. Marco's 21= :40 - 21-42 transmission is reported 2141). This because the time is taken = at the moment of decode. 

For JT9(-1) this is not an issue, because decoding is in the same minute as= the start of transmission, but for JT9-2 and JT9-5 it is because it result= s in a wrong calculation of the cycle (1st or 2nd). As the wrong cycle is g= iven SlowJT9 will transmit in at the same cycle as the station you received, very inconvenient!

I will fix this big after the weekend (sorry, to many other obligations on = Saturday and Sunday).

For the time being the workaround is rather easy: if you get a decode = you want to reply to (by double clicking on the call) just change the = cycle manually (click once on the "TX 1st cycle" checkbox). = The good thing is you have plenty of time to do so as there are 20 seconds between the end of a transmission and the start of the next= cycle. 

To end with a positive note: during Marco's 2152-2154 transmission there wa= s very deep QSB and his signal dissapeared from the waterfall display = for almost 1 minute. But despite that still a good decode, just some dB wea= ker.

73, Rik  ON7YD - OR7T


--_000_154186885286784353kuleuvenbe_--