.



MT 63

Description:

By  encoding  the  data  to   transmit  (what  you   type  on  the keyboard) in a complex way,  using  64 different modulated tones, the  MT63  developer  Pawel Jalocha  SP9VRC has been able to  include a  large amount of extra  data in the transmission of each character,   so  that   the  receiving  equipment   can  work  out, without   any   doubt,   which  character   was   sent,   even   if  25%  of  the character  is obliterated.  This  technique  is  called Forward  Error  Correction.  Other modes use  FEC (for example AMTOR mode B uses a simple FEC technique), but MT63 has other advantages. Unlike most HF modes where a character can be lost or  changed into  something else by a single noise burst,  MT63 is inherently  very robust,  because each  character  is spread over many   tones   (to   avoid   interference   such  as   other   radio transmissions) and over several seconds (to avoid bursts of noise, such as  lightning).  On each tone,  the transmission  data rate is also   fairly   slow,   which    suits   the   nature   of   ionospheric disturbances.  Despite  the  low  data  rate, good  text  speed  is maintained because the text is sent on many tones at once.  The system runs at several different  speeds, which can be chosen to suit conditions,  but 100 WPM, much faster than you can type, is typical.

MT63  sounds unusual,  (it  sounds like a  roaring noise)  but  the performance is spectacular. There is no connection process, as in AMTOR, Packet or PACTOR.  Some users maintain that under poor propagation conditions (excessive fading) MT63 works better than either    PACTOR   II   or   Clover.    Under   good  conditions  the performance   advantages  are  less  obvious.   The  convenience advantages remain,  no matter how good the signal - the mode is suited to nets and random  QSOs,  as no link need be established. MT63  is  also  far  more  immune to  interference and  deliberate jamming  than any of the more  conventional modes.  Changeover from  transmit  to  receive and  vice-versa  is  slower  than  most modes.

There  are disadvantages to  MT63. First,  the mode is broad (see below) and quite  aggressive,  i.e. it  causes interference to other modes, but itself is little affected by other modes.  Also,  because of  the   delay  through  the   error   correction  and   interleaving processes,  it is not possible have quick turnaround  "slick"  QSOs. In otherwords, operation is clumsy.

Operation procdure:

  • CQ calls should be preferably made using 1 kHz long interleave. If possible, ID calls with Morse or voice ID. It is important to ID, as it is a sure way to educate other amateurs that the weird noises they are hearing is a genuine Amateur transmission. MT63 attracts more than it's share of attempted jammers!
  • Use an ID format such as "DE ZL1BPU 1K LONG" which identifies the protocol in use. The modes are almost impossible to tell apart. (The IZ8BLY software and the latest LINUX software ID automatically).
  • Choose a calling frequency clear of all other signals by at least 500 Hz. Make sure you are well away from adjacent SSB QSOs. Sure, SSB chaff will not affect your operation, but your noises will affect theirs seriously. You CAN operate right next to another MT63 QSO (e.g. one on 14.347, another on 14.348 MHz).
  • Use USB for all transmissions above 9 MHz, and LSB below (as for SSB).
  • When starting an over, particularly working DX, send a few lines of unimportant text to allow the receiving equipment time to sync. If conditions are poor it may take several attempts before sync is achieved.
  • Often, when working DX, the sync locks incorrectly, as evidenced by masses of garbled text, often with repeated characters. This is the time to RESYNC. It may take several attempts for proper lock to be achieved under really poor conditions.
  • When listening in to a QSO, or taking part in a net, using the EVM version, you will almost always need to force resync manually between transmissions.
  • MT63 for the EVM does have a transmit buffer - but you won't see it using Windows Terminal. With a split screen terminal program such as Pawel's Splittrm or a suitably adapted packet program, you will see what you type during receive. When the EVM goes to transmit, it sends the start message, followed by the buffered text, and finally anything new that you type. To use this feature it is best not to add text to the Windows Terminal F1 function key, or it will be added in the middle of the buffer - the ^T is processed immediately, but the rest of the text goes into the buffer.

 

References:

- http://www.qsl.net/zl1bpu/

  
 
     
 
 
 

Last modified:
20 apr 2002

© millennium
1999 - 2002
http://www.qsl.net / s57onw /