Loading ...
Sorry, an error occurred while loading the content.
 

Re: [MT63] Looking to use MT63 as a datalink layer

Expand Messages
  • Greenman Family
    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)
    Message 1 of 3 , Jul 23, 2002
      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. While you could
      develop something in its place, it wouldn't be MT63, and it would be a lot
      of work.

      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.

      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.

      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.

      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!

      73,

      Murray ZL1BPU
    • Tomi Manninen OH2BNS
      Hi Murray, Gareth, ... 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
      Message 2 of 3 , Jul 23, 2002
        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:

        http://lists.debian.org/debian-hams/2002/debian-hams-200203/msg00007.html

        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:

        http://www.baycom.org/~tom/ham/soundmodem/

        And just for the sake of clarity, none of the above mentioned "new"
        developments have been released yet. Soundmodem contains the "standard"
        Q15X25 modem.

        > 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@...
      Your message has been successfully submitted and would be delivered to recipients shortly.