[Lowfer] Re: Modes, signaling, and data recovery

Alberto di Bene [email protected]
Fri, 15 Feb 2002 13:25:24 +0100


"Dexter McIntyre, W4DEX" <[email protected]> wrote:

> Les Rayburn wrote:
>
> >
> > I'm actually kind of surprised that Alberto didn't choose to
> > expand on the work already done on WOLF rather than
> > trying to start from scratch with Jason.
> >
>
> Les,
>
> Even I can see that WOLF and JASON are completely different animals
> based on totally different decoding methods.  I seriously doubt that
> JASON was started from scratch.  I suspect most of the program is based
> on Spectran/Argo code.  Jason adds a text decoder.
>
> Dex

Les, Dex and the group,
   yes, Dex is perfectly right on this. Jason utilizes the kernel code of Argo
for doing spectral analysis. On top of this the encoder and the decoder
have been added. This was done in the sake of the minimum effort, but
it is not the optimal solution. In a forthcoming version, the spectral analysis
will be revised, with the consequence of the elimination of the 'Slow' mode.
With the new technique the CPU burden will be much less, so even slow
PCs could cope with it, with no need for a special low-gear mode.

Jim Moritz has explained (thanks Jim) much better of how I could have done
it, the differences between Wolf and Jason. I can add only this. When I was
thinking about the modulation scheme for the new program I had in mind to
write, my first thought was to use true m-ary FSK, maybe coherently
decoded. But this would have implied a linear PA stage in the TX.
The situation in EU is different from that in US. In US you can send BPSK
to a class C or D final stage, without worrying too much, given the 1W limit
you have. In EU, if you send BPSK (or m-ary FSK) to a class-D 1 kW PA,
without provisions for amplitude shaping, you will quickly become quite
unpopular among your fellow OMs...:-)
So, I had to settle for a modulation scheme that could be used with a class-D
switching Mosfet amplifier, almost the norm in EU. This, combined with
another requirement I had imposed to myself, i.e. that the program should be
useable by the vast majority of the OMs, who do not normally have access to
GPS, Rubidium or Caesium standards, made me choose a variant of the Steve's
IFK method, which satisfied those requirements.

Should a Jason version be produced for really weaksignal work, probably
one or more of the above restrictions should be lifted out. IMHO, just
lengthening the signalling duration would not buy enough S/N margin
to justify the added delay.
After all, Jason, as it is now, is quasi-real-time communication. Should the
timing lengthen more, then QRSS60 or Wolf would be better alternatives,
given their greater robustness in terms of S/N.

Hope to have clarified a little the rationale behind Jason's architecture.

73  Alberto  I2PHD