Hello Eric, Paul,
as Paul says the original JT9-2 and JT9-5 symbol lenghts are probably optimized
for "good use" of the 2 minute and 5 minute cycle.
JT9(-1) has a exact symbol length of 6912/12000 = 0.576 . For 85 symobls this
makes a transmission length of 48,96s (starts at 1 second after the full
minute, stops at 50 seconds after the full minute).
If the symbol length for JT9-2 is exactly 1.28 s (15360/12000 ?) the
transmission will take 108.8s or 1m48.8s.
Assuming a JT9-2 transmission started at 1s after any even minute it will stop
50 seconds after every odd minute, exactly (within a few tenths of a second) at
the same time as a JT9(-1) transmission end.
For JT9-5 and a symbol length of 3.41s a transmission wil take 289.85s or
4m49.85s. Thus it will end at almost the same moment as a JT9(-1) transmission
and every second time at the same moment as a JT9-1 and JT9-2 transmission.
In all 3 cases there is about 10s "response time", what makes sense.
Instead of using a scaling factor 2 and 5 (as for now) it is possible to use
non-integer scaling factors of +/- 2.2 (for JT9-2) and +/- 5.9 (for JT9-5). It
will just make the averaging a bit more complicating, but that shoudn't be a
real problem.
I am more worried about my plan to allow SlowJT9 to decode JT9(-1), JT9-2 and
JT9-5 (seconded by Paul), as in that case up to 3 decodes will have to happen
at the same time.
So unless there is a good reason to fall back to the original symbol lengths I
am not so keen to do that.
73, Rik ON7YD - OR7T
________________________________________
Van: [email protected] <[email protected]>
namens N1BUG <[email protected]>
Verzonden: maandag 12 november 2018 21:12
Aan: [email protected]; [email protected]
Onderwerp: Re: LF: SlowJT9 v0.9.02
Eric brings up a good point. Forget what I said the other day about
beaconing with a U3S to be received by SlowJT9. I believe that won't
work because the U3S uses the original JT9-2, -5, -10, -30 symbol
lengths which are different.
Probably (a guess) in the original, symbol lengths were chosen to
fill as much of the period as possible while leaving enough time at
the end for decoding. I would further guess there were specific
decoders for each submode, or one decoder whose parameters could be
modified for the current submode.
73,
Paul N1BUG
On 11/12/18 2:47 PM, Rik Strobbe wrote:
> Hello Eric,
>
>
> yes, a scale factor of 2 and 5 is used.
>
> I hadn't any information about the old JT9-2 and JT9-5 modes and
> those scale factors seemed the most straightforward to me and
> make the conversion to JT9 easy.
>
>
> 73, Rik ON7YD - OR7T
>
>
>
> ________________________________ Van:
> [email protected]
> <[email protected]> namens Eric NO3M
> <[email protected]> Verzonden: maandag 12 november 2018 19:03 Aan:
> [email protected]; [email protected]
> Onderwerp: Re: LF: SlowJT9 v0.9.02
>
> Rik
>
> SlowJT9 won't run in Wine in Linux, nothing particularly useful
> was output on the command-line. I tried using an old version of
> WSJTX (0.95 r 3278) but seems there is some protocol
> incompatibility.
>
> The original JT9 submodes specs give:
>
> Symbol Length:
>
> JT9-1 0.58s JT9-2 1.28s JT9-5 3.41s
>
> Is your program using a 2x and 5x scale factor for JT9-2 and
> JT9-5 respectively? If that is the case, the symbol lengths will
> be different than the original specs and old versions of WSJTX
> will not be compatible.
>
> 73 Eric NO3M
>
>
> On 11/12/18 10:59 AM, Rik Strobbe wrote:
>
> I just uploaded a new beta version of SlowJT9:
>
>
> v0.9.02 [12 Nov 2018] Bug fixes: - Non fatal bug that that
> corrupted the cycle calculation fixed. Changes: - Calculation of
> the report (dB) corrected for JT9-2 and JT9-5. - Beta version
> message changed (ignore option added).
>
> 73, Rik ON7YD - OR7T ?
|
