To: rsgb_lf_group@blacksheep.org
Cc: "600MRG@mailman.qth.net" <600MRG@mailman.qth.net>,
        rsgb_lf_group <rsgb_lf_group@yahoogroups.co.uk>
References: <1541712573053.31739@kuleuven.be>
 <1542362144885.30626@kuleuven.be> <1542721669174.9290@kuleuven.be>
 <CAA8k23RktZzwjGcy2MNhKY0X4zbRZ8X3T3fZURWs+iZM=mxcTw@mail.gmail.com>
 <1542724318123.33202@kuleuven.be>
 <CAA8k23Q9yTDFND2EOnZxRh8upOgZ9wf_LX9kuuQm6TTz1WKT-Q@mail.gmail.com>
 <CAA8k23RAZqT9JwNa-mKsWeWwx7ZDGaMrcdGt0XmH1gZkhwQ8-g@mail.gmail.com>
 <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>
 <CAA8k23QsejC64uFD8CUDF-8fohMGfLNnE9nRdUgaQxUYHN1sMQ@mail.gmail.com>
 <1542819051896.23883@kuleuven.be>
From: N1BUG <paul@n1bug.com>
Openpgp: preference=signencrypt
Autocrypt: addr=paul@n1bug.com; prefer-encrypt=mutual; keydata=
 xsFNBFqj1+0BEACggWlaH8oG/AiXSUG3CeQwZ1NrVEP4U7YsA9N9XEffjCDEsnTjHF2BJSgS
 2AicyomkmTGvghEHxrNFfFw07jwgJl97ae/VtNxpERPSE98mb4sPOMpJbwddioMazMDXwhKA
 wpg5fse+Ru8OrIT04KK919xL/pZuAP6pY6d2kVoizjJOfS71pHpiU6N6q3d9cl+w7d2LKhAE
 a3A1ZgDquPvn0WQlrN8K5D66xVrwTRhf1b5H4Ozl8/mMJzCeLG1ZIsDB3Pu2flwE81P8dCJA
 y1azwgY8pTEshVk4em/se9uRiZaDJr/qUSCf6hrV7AGa8g1jpAQDmdGpDNYMqyDqXen4jNi1
 8kNFVu1BMl2vjaI8skw/YPxIxlk/0ROHYhN6SuoDq1mt4AW4FryNa7k3A8dM8Bt7udBoTv0i
 uw4j9R/bmh2vl/QaHRUhDco0xn2z6geWvXkKqha++vzXDrEKUuqgB85SDZPs5W/phs9p0pz1
 xA61d1gn8FQJtpou5dQuAucqMo8eKQY5LUcbC+MH5pebH+M2wIuDCBmFPJHQDSPNepeaxJ4o
 G/HU1hrpzlgLiTTSKR8DcwtMQwYywnCTlm8MgL4jXuPzoGyKDMYyKIjC51G+3AAOJ6oXJAGR
 g0ehhCPtmnCGBaRlUIoUSpbgc4B+onqFKZmDiVm9CRNJhKIWrQARAQABzRZOMUJVRyA8cGF1
 bEBuMWJ1Zy5jb20+wsF9BBMBCAAnBQJao9ftAhsjBQkJZgGABQsJCAcCBhUICQoLAgQWAgMB
 Ah4BAheAAAoJECRS/J8srRGjPBsQAIh+Haz9gqrQJ0OlMI5xmQ0A5nsVWcatWF/Ea4mucNjL
 4n4jmW+Z4Ukn3OVss55chWwrOVMRNWU2d2zRc92ZF7yJhLCoJFV870bZfxNYwdJ3GEBLIu6/
 anmQYX0oXFx8UBsx5K6egNqbeflPA7zrLiQkWrz6JApECdiA1rHDjyJdS7PDxBCG9cKgr/5b
 r4Rn/JlUl9pRPnxlSwHXsV+J6JtFYtWI69MWIVD7Y7OY1wO9+684uOnzeDANzeIwpBDcSm6p
 0D5u0b1hfPl2TD0ozVs6P0NvxkMbimXUhRR1QD0FvydyxmZTLAo+XZDGR8GqWYrYrauoRZ1h
 3m23+bNT2T4AuoFnWekpsZu+sxIf0LKPtEZCa51O65jZ810ROpXg9Lx71gEoQD+kbjO69+kq
 9r7wjytDq/jyhpOGrGYV6kgcQrISY86t9YvkA9Of2HDzZLih3GwecW6fkeV1AO5w4RteE9nL
 zIs2siGw2YqavF6LpTH71Db7cUYyZWn5hkKpwfpLNnPEuqgZACovpH1WUHx+KMqqIL4rMVCH
 GcSLqnH2KF4cEDb6OeTbwuLfpGlN+I3j24eQnB2uz5rDa7/IBjsClLl8S/wdDTP8IikBGixX
 06v3k06tk/OF4UsfJ0cY/ASGP5+kjT4ASMZAIikwVMpKi5A5be77vecKNYlJQ2a6zsFNBFqj
 1+0BEACaujZXo3F17v7QTnub4DjjYvm+nr8J0uU5pPc1UMEz9eWjmtmITm15fx1hPKNtVW+I
 VlT+DG+ShNnYmO2M4CFBoc7PwkAOc70aDxfHz20kotvj1HhXG7oBiqPkN3TK4C7qWV1HUEPA
 V960qPdhsoCqmtkvNwj39w1T0ZR5qwwaqDogs9UwBib7zseQ3OXHG32xYYCMcxM35hgXGkkz
 R7wFL4ZnAPOeFb8LnWtZcrGpwXdsYkXuCxm+A+u9KlFY+w3ZCzZt1F9Ie+/PSZnFIUtbXt2i
 mfc+VkRwOLz5BDAeWuDL09TN81+gbrR3kXlymDcCbuduO/yHOQK085qzE3LuImdy+JNb7oDf
 1C/hvpRvtB02vVy33rzIXT8644SJzFY/mw/W39/BgHKCoL1FrBbfgf0UoIFw5M752i7jQwmv
 j5yFfnVAXIPpCuusMwWMGVpZcGV7QxJxh0HBEhYgOo9v3zKwzNIPm9V/LA67u/rj4a/MlCE0
 mpd6IHaePE1vXDaboPZHZdhAziru5/Jd7KQI0k+HmM/HRANPRNDZ4UeBpgj9PzS6hDN5GHlZ
 fRUbI8JAg9wSaQtEn0bjyaR7lw0yngZTvvjT1Qqt5zGwm1IAall2STes5xK0aS7p+UJJMVbf
 ydZ5VOnocvUkwYxbiqoyuVtGxi4tpWW9CRstYXMkAwARAQABwsFlBBgBCAAPBQJao9ftAhsM
 BQkJZgGAAAoJECRS/J8srRGjTDMP/18q7uhac/naxoFsOqhgXIlvaPgu6GX7s/QOh+bcSV1F
 y50lxo51P/C95H2TVME/CtCjk2xWQcNjWtXloMEsZpl7T3qWgJHvyZYkDtgh3M6UNY+zb08U
 K9E2+rR0AZ6zdMKio7Z1xA9BtbUpSZpvy2NgjoYVqo35NllUWMZJq0u+88PvE5WeCIqLipNI
 EZmUcG9UwolQbPkrRc42ReL+bFbuXGXDA5GbQ0RudXbugI8iUwaw3ftaKElIZtuHW0hw1VrU
 9tVHsxKyEoKgNNT1hr+dgRmvCHmA87Pi4R5cMV0ZkLVOYfPX1motedag7HmSNPi2PkYLts4z
 kyvPEJe2IvaPvjvK1ShRWWgje3uytrhfwyjUZcIuA76RWEfBbwT2Mbrn9O7LvrYtbTiTlsLo
 Zdk2uocuefBvPd2oI7mTn5eLy/VDy2JVnlb9vpZZhriXI4KtCcP6mYyuPxlxqj/30Kn1fU5b
 C4EpnKy6hW1CHM42DbwzT+ChjBpFbX9bfwT4qn6d42+T4mN5wkmfnBRHfcn8Wf1ezRSK3Ome
 Esa3ZDssj23CZHe11uec6Ln14qoB7JyRT9qM3Q99tzvAlmWFM3GrSsG94g4JponQjQWHmr8B
 eMYezwJHzSI7zWElJpzs/OuohstTYfYTy16FygUOEinc1K4ywjEklgRpXRtjKvqc
Message-ID: <ec58adc1-a48b-0f1a-33e2-6a3f6e2ff730@n1bug.com>
Date: Thu, 22 Nov 2018 07:01:18 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <1542819051896.23883@kuleuven.be>
Content-Language: en-US
Subject: Re: LF: SlowJT9 averaging (in conversion to JT9-1)
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

Hello Rik, all,

It's the same for me. I know 2200m is mostly a engineers and
experimenters band, but I came as a ham radio operator looking for
challenging DX QSOs. Maybe I don't quite belong there, but I'm not
going to give up easily! :-)

I am convinced that JT9-2 (and maybe JT9-5?) can be useful for such
QSOs on 630m, if real on air performance lives up to theory. On
2200m I can convinced JT9-10 or even something slower can be used to
good advantage, again if real world performance meets theory. Recent
WSPR-15 results clearly show the advantage of very slow "similar" modes.

As I was once a programmer (sorry, long time ago in the MS-DOS
days!) I understand very well about doing things the best way for
you. I also understand it's much more difficult to stay with the
original slow JT9 timings. Maybe in the end you have to go with
integer values, that's understandable.

However I don't completely agree with Andy about backward
compatibility being unimportant. Sorry Andy. Let me try to explain why.

We have seen the advantage of very slow modes (eg. WSPR-15). But as
a general idea, we also know the slower it is, the better our
frequency stability must be to run it. For some of us hams who came
here looking for exciting QSOs, this is a problem. In my own
situation I should be OK in receive even down to JT9-10. But for
normal transmitting methods, I expect to have some problems with
JT9-10 and probably even JT9-5. It seems there is not much I can do
about that.

But maybe there is another way. I have a QRP Labs Ultimate 3S which
is very stable and capable of transmitting the original slow JT9
down to 30 minutes. Can it be used for QSOs? There are some problems
around how to quickly change messages and it can only send free text
messages. But one 630m ham has worked out a way to use it for JT9-1
QSOs and has written about this recently. Clearly this can work for
the slower submodes too. But it only works if the receiving software
can decode the original slow JT9 timing.

This is why I said "selfishly I prefer the original slow JT9 baud
rates". That would leave open the possibility to adapt methods for
use of a U3S in QSOs. It might be the only way I can use JT9-5 and
JT9-10 for some dream QSOs on 2200m.

Someone suggested maybe the U3S firmware can be changed in the
future to support new integer value slow JT9 scaling. That's true of
course, but I do not expect that could happen any time soon. The
developer is extremely busy, having his hands full with a new
project and some health issues.

Whatever you decide, whatever direction you need to take with this,
I will continue to explore ways of testing and using SlowJT9 for
exciting ham radio QSOs!

73,
Paul N1BUG


On 11/21/18 11:52 AM, Rik Strobbe wrote:
> ?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 out 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 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
> 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 decoder) I will be happy to implement that in SlowJT9.
> 
> 
> 73, Rik  ON7YD - OR7T
> 
> 
> 
> ________________________________ Van:
> owner-rsgb_lf_group@blacksheep.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 go 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 latest 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 WSJT-X 1 suite with these modes
> so there is no need for backwards compatibility.   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 backwards compatible.
> 
> 
> 
> Andy www.g4jnt.com<http://www.g4jnt.com>
> 
> 
> 
> On Wed, 21 Nov 2018 at 15:53, Rik Strobbe
> <rik.strobbe@kuleuven.be<mailto:rik.strobbe@kuleuven.be>> 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 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 converted to 1 outgoing sample?
> 
> Not finding relevant information about this on the web, I did it
> quite 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 = (I1+I2+0.222*I3)/2.222
> 
> O2 = (0.778*I3+I4+0.444*I5)/2.222
> 
> O3 = (0.556*I5+I6+0.667*I7)/2.222
> 
> O4 = (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