> KV9U <[EMAIL PROTECTED]> wrote: > I tried to find more information on the specifications but > did not find any. I would not consider this mode to be legal on > amateur radio frequencies until it has an easy to access > specification as required by the FCC. This really should be > detailed on the ARRL web site along with > the many other digital specs, don't you think? > > 73, > > Rick, KV9U
Hi Rick, ALE, and the MIL-STD and FED standards it is generally associated with, are some of the few digital systems hams are using that already have extensive documentation specs published by US Government itself... this certainly meets the description disclosure requirements of USA's FCC for digital transmissions :) Some of the pertinent parts of the ALE description are in one of the articles on the HFLINK.COM website. The basic system is 8FSK at 125 symbols/second (125baud) with a 375bps data rate. ALE AMD The normal "universal" texting method used with ALE 8FSK is called AMD (Automatic Message Display). AMD is a basic feature in every HF transceiver that has ALE embedded. The text message scrolls on the transceiver's front panel display. AMD is also part of PCALE, and it displays on the screen. AMD is for short message texting, similar to SMS on cellular mobile phones. AMD is known in government comms lingo an "orderwire" message. 8FSK ARQ It is more efficient to sent longer text messages and binary or text by 8FSK ARQ instead of AMD. PCALE has several additional keyboarding and file transfer methods to choose from that use the basic 8FSK standard (with or without ARQ). The 8FSK formats most commonly used by hams are "DTM with ARQ" and "DBM with ARQ". PCALE interoperates seamlessly with ATM, DBM, and DTM. You can use any of these 8FSK formats at any time, or switch between them during the QSO. The ARQ functions in user-selectable time frames (such as 5, 10, or 30 second data block lengths) with user-selectable number of repeats. The operator can adjust the timing and repeats to meet conditions, and the receive decoding system in PCALE is flexible, to accept any timing that is being transmitted by the other station. You can also send one-way texting messages or files, such as might be used in a net or a QST. It is quite a clever and efficient system, especially using the excellent implementation that Charles G4GUO has developed in PCALE (and Steve N2CKH in MARS-ALE). Why no ALE in most ham digital software? Considering how widespread ALE has become among HF users in the world, to the point that it is the defacto standard now for HF comms, does it seem a bit odd that most mainstream ham digital software doesn't include basic ALE? There are many obscure and little-used modes included in some ham software, yet they don't include the most popular basic ALE calling functionality. Are most ham software authors afraid of ALE? I've often wondered if the NIH factor (Not Invented Here) is part of the reason for ham software authors' slowness to include the ALE-associated digital formats. But, considering that it is rather difficult to understand the complex government documentation for the "overhead" of the ALE protocol, it is understandable that most authors of ham software haven't tried to implement it yet. Basic ALE functions could be included in mainstream ham software. Only a small part of that ALE documentation protocol is actually necessary for ham use, so it would not be quite so difficult to include a small subset of the basic ALE calling and texting that hams use most often. It would still be useful, even if channel scanning was excluded. Bonnie VR2/KQ6XA /
