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

Looking to use MT63 as a datalink layer

Expand Messages
  • m5kvk
    Hi With some others in the UK, I am considering the merits of various data modes for use as a data link layer in an HF emergency comms network for use in the
    Message 1 of 3 , Jul 22, 2002
      Hi
      With some others in the UK, I am considering the merits of various
      data modes for use as a data link layer in an HF emergency comms
      network for use in the UK. We have just been allocated some space on
      5MHz for experimentation and I hope to apply for a variation to my
      license to permit me to operate on one of the spot frequencies we
      have been allocated.
      The idea would be to perform some extended practical experiments to
      assess the suitablity of various modes under changing conditions.
      MT63 is an obvious candidate. However, to proceed I need to create an
      MT63 datalink engine, probably with a sockets interface on top that I
      can drive from a variety of upper layer engines. I will also look to
      do the same for other modes.
      Does anybody have any experience of using MT63, or any of the other
      modes, in this way? If so, would they be willing to share their
      experiences?
      Also, can anybody point me at a suitable code base I can use as a
      starting point.
      Responses relating to MT63 could be posted here, but anything related
      to other modes should be email'd directly to me as
      mailto:m5kvk@...
      73!

      Gareth - M5KVK
    • 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 2 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 3 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.