Hi Rick, RTTY is dead in MARS in my opinion as to being useful, but still allowed in all three MARS programs as far as I know, CW was vanquished some years ago now, prior to my return to MARS. There are 3 MARS as you know and to date, there are different approaches in all three and many commonalities regarding HF digital communications. I was NMCM in the 80's until '91 and I have been Army MARS since 2003, I had to bow out for a number years as career and TDY travel got in the way. Almost since returning to MARS, I have been involved with the more to ALE within MARS.
In NMCM these days its mostly MT-63 and PACTOR I, where FEC is used a lot as programs such as MultiPSK and MixW support a connection between the TNC user and the PC Sound Device Modem user. This is also true for Army MARS. In NMCM the BBS system is MDS on DOS and is PACTOR I. For both Army and Air Force MARS, WL2K PBMO's with AirMail as the client is being used and 95%+ of the users are PACTOR I based, Army MARS has shutdown their older MSYS and Winlink Classic BBS systems just this month and currently has all their eggs in the WL2K basket. Air Force MARS retains its MSYS and Winlink Classic for radio-to-radio BBS capability as does NMCM with MDS, and NMCM does not allow the use of WL2K. As to Air Force MARS attended digital communications, I am not sure just what the story is outside of my direct activities, I know MT-63 is also getting heavy use, along with PACTOR. Basically MARS makes use of all digital modes that are commonly used by both Amateur Radio, Commercial and the U.S. Military to some extent, but PACTOR I and MT-63 currently rule, my opinion obviously, others in MARS may disagree. In my direct activities, members of all three MARS programs are working jointly in the use of ALE where a Tri-Service ALE network operates 24/7 where MARS-ALE is the ALE tool set for most users and is the ALE LQA front end for the existing and developing MARS Traffic System. At present we have MARS-ALE via Telnet communicating with back end servers, one is for network activity reporting automation and the other is the BBSlink server. Any MARS-ALE based station can use the report automation tool for feed the view from their station perspective (its the MARS-ALE/BBS 24/7 perspective that will always be fed) when on-the-air, on a selected period of all channel acty via Internet e-mail to one or more end points for display, analysis and reporting in near-real time, there is an SQLdbase being developed and host of reporting tools, at present one such feed is to a closed Yahoo forum such as this one ( http://groups.yahoo.com/group/MARS-ALE-SITREP/ ) where all that data exposes all the network acty as to Soundings, linking calls, what stations were linked one on one or one on many etc., and network diagrams and other reporting can be derived, our reporting tools are not all in place yet and manual processing has really become difficult as the acty has increased. The BBSlink sever at present supports WINLINK.ORG and MARSALE.ORG ( a new development that uses standard SMTP/POP3 client and webmail when not on HF) on the back end where only Air Force and Army MARS can use WL2K. This is a very new development that has only just entered wider testing. Any supported MARS-ALE ARQ protocol, including the use of Tactical AMD messages can be used to send and receive e-mail ( AMD is painful on incoming e-mails if more than one line !) and not just PACTOR x, MARS-ALE supports a number of ARQ protocols on the PCSDM and provides external TNC/Modem support. The next addition to the BBSlink server with be WA8DED emulation so that MDS, MSYS and Winlink Classic will see MARS-ALE as just a TNC on another port, at that time NMCM and Air Force MARS will have a full radio-to-radio and Internet HF e-mail solution as BBSlink will at one site all combinations. My MARS-ALE/BBS which is running at the moment has accepted traffic today from stations where test message were send by the Remote ALE user during the connection using both WINLINK.ORG and MARSALE.ORG agents in separate messages sent, its just a matter of the addressing to tell BBSlink which agent to use, the same will be true of MDS/MSYS/Winlink Classic support when added, thus if Internet is completely down that BBS has a radio-to-radio path, the user still has a path to send their out going traffic. Our interface for all these BBS systems supports the Remote ALE user to list ( if desired) any incoming messages and chose which to read as during an ECOM event in the field, one does not want to reading waiting for a ton of incoming traffic if the order of business is just to send their outbound traffic, but one may be looking for a specific message or two inbound, this is not an option when using the normal WL2K PBMO interfaces. With MARS-ALE the use of AMD, DTM and DBM modes are automatically detected and if ARQ responded to in same, this is also true of the MIL-STD-188-110 Data Link Protocols. Thus even it one station is unattended, the Remote ALE user is in the drivers seat for protocol selection. For BBS operations only the AMD Handshake and ARQ protocols will be allowed, the FEC/BRD protocols are ignored by BBSlink. For the external TNC/Modem support, when talking commercial units that provide PACTOR I ( and not MIL-STD and other exotic units selected by use of the GENERIC interface) I coded PACTOR I as the default protocol. Thus any Remote ALE user can be assured that at ALE link, if the station they are linking with is MARS-ALE based ( which all MARS-ALE/BBS stations are) and have an external TNC/Modem, it will be in PACTOR I as that is the startup mode and the default reset mode at each ALE link clear or time out. A Remote ALE user can send an AMD Orderwire message to determine if the station has and external TNC/Modem and what make it is to determine if they have like capabilities, such as a KAM with GTOR in common. Then if desired, they can send another AMD Orderwire to select GTOR and then establish a GTOR link to send their traffic, its that easy. In time additional PCSDM protocols may be added, we are looking at a number of things in that regard which make sense to the MARS mission, they must be adaptive protocols, bi-directional and transport protocol layer support being a plus, all must offer speed and robustness. The MARS-ALE development team is looking at the prospect of a fully adaptive MT-63 ARQ protocol, which means automated support for MT-63 FEC interleaver and speed ( we would be adding more options) detection as well, as is done with FS-1052, which would be backward compatible with standard single speed MT-63. We consider MT-63 to be a tailored FSK derivative of FS-1052 BRD for intents and purposes, FS-1052 FSK is detailed in the FED-STD but not implemented in MARS-ALE. The MARS mission is to move traffic in support of its customers, which means pre-written and checked messages in one form or another and not keyboard to keyboard messages on the fly. Originating station to relay station of this traffic as well as originating station directly into MARS Traffic System automation is the key aspect here as well as replies in many cases, keyboard to keyboard which is the primary Amateur Radio focus of communications is the minor focus of MARS communications, its on the bottom our or list, ahead of it is Broadcast of messages to all members of an NCS directed net actually. All MARS nets are however multi-mode, which means Voice/Data where data can be anything at the direction of the NCS and all MARS acty is channelized on 3Khz data/2.8Khz voice channels with a common center. Thus we need Voice Detection with our automated digital systems ( provided by ALE ) and we need the ability to break digital comms fast as needed to support priority Voice traffic ( the new ARQ FAE protocol implementation is a great example of that, as is ALE links and DBM ARQ as both have the bi-directional support and ARQ FAE stops diddling the channel the second there is not more data to send and goes to automatic standby unlike GTOR or PACTOR I were the link needs to be broken). So, that is my perspective and opinions on all things MARS and HF digital Rick, perhaps some would disagree and perhaps you may find it all interesting enough to come back into MARS operations? /s/ Steve, N2CKH/AAR2EY At 11:07 AM 2/25/2007, you wrote: >Steve, > >I got the impression that MARS was moving toward Winlink 2000 and >handling traffic primarily through the internet. > >How do you set up different methods of traffic handling to include the >different systems? Or do some members work one kind of mode and others >another kind of mode? > >As a former Navy MARS member back in the early 1960's and later in the >80's with AF MARS, we were mostly sending traffic with voice with some >feeds (often garbled) from RTTY. > >73, > >Rick, KV9U