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:
> [email protected]
> <[email protected]> namens Andy Talbot
> <[email protected]> Verzonden: woensdag 21 november 2018
> 17:11 Aan: [email protected] CC:
> [email protected]; 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
> <[email protected]<mailto:[email protected]>> 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
|
