Hi Murray, Gareth,
> There are a number of problems with using MT63 in the way you suggest.
> First, much of the value of MT63 (the wonderful Walsh/Hadamard error
> correction) will not be directly useful, as the latency involved in the way
> it is implemented will involve serious channel inefficiency.
Actually the Walsh/Hadamard code doesn't cause very much latency as the
block length is fairly short. Much of the power of MT63 comes from the
very long interleaver and that also causes the huge latency. (afaik)
> Secondly, MT63 is not well supported (or indeed understood) by us mere
> mortals, and the author, SP9VRC (where are you Pawel?) has been quiet of
> late. Development would therefore be largely from scratch.
Yes, this is true. Although Pawel does answer private email (about a month
ago I had a question to him), I suspect he is a very busy man. It might be
impossible to get any real support to developing anything new.
And it is also true that Pawel probably is the only one who really knows
how MT63 works. I think I know Q15X25 pretty much thoroughly and MT63 has
much similarity. But still it's not the same...
> However, there is another even better solution, and I'm surprised you have
> not already come across it and embraced it completely. This mode is Q15X25,
> also known as NEWQPSK, and it also uses multi-carrier QPSK and a
> Walsh/Hadamard FEC system. This mode, also dreamed up by SP9VRC, was
> designed from the start for ARQ applications. It is better understood than
> MT63 and has been tested (extensively?) on real HF links using datalink
> protocols. It has a lot of similarity to MT63, but is faster, has three
> levels of FEC and is much more suited to ARQ operation.
Yes, in Q15X25 there is a tune/sync preamble that enables quick
synchronization to the incoming packet, pretty essential for an ARQ
protocol. Also the interleaver is shorter which saves on the latency
(actually on a packet based system I think it's more appropriate to talk
about overhead ie. wasted transmitted symbols).
I have also done some further work on the basis of Q15X25, namely
developing a better framing system that allows experimenting with stronger
FEC and a different type of interleaver (with no overhead). Related to
this, Arnau Sanchez has been involved in a project that uses Q15X25 as the
modem in an HF email system (non-hamradio). We have excanged ideas and
code and the last time I heard from Arnau he had introduced Turbo codes to
my modified Q15X25 modem and had gotten positive results about that. A
while ago Arnau mentioned about the project on debian-hams list:
It's been a while since I last heard from Arnau so I don't know the status
of that project. Unfortunately I have not been able to contribute to this
project as much as I would have liked.
> Probably the best person to contact for advice and assistance would be Tomi
> OH2BNS oh2bns@... (hello Tomi) who has a fully working solution for
> this mode and sound card which operates under LINUX. Tomi recently released
> a new version, which I'm sure you could find on the net.
It's included in Thomas Sailer's soundmodem:
And just for the sake of clarity, none of the above mentioned "new"
developments have been released yet. Soundmodem contains the "standard"
> There is also the original SP9VRC version for Motorola EVM DSP module, but
> no Windows version that I know of. If you'd like to develop a version for
> WINDOWS and sound card, I am sure there would be many takers!
Actually there is a win32 version. Tom's soundmodem can be used with
FlexNet32 on windows. Also the next version of MixW will have Q15X25.
Tomi Manninen Internet: oh2bns@...
OH2BNS AX.25: oh2bns@...
KP20ME04 Amprnet: oh2bns@...