Hi Rick, At 09:58 AM 6/20/2007, you wrote: >I doesn't sound like this mode would require much change in software, >but if you have a rig with some kind of unchangeable firmware, I can see >where AQC would not work. If we ever did get ALE placed in amateur rigs, >it would be wise to have it in a flash eeprom form that can be updated >with new technology.
AQC-ALE blows away NORMAL ALE in many ways, but I doubt it will filter down to the affordable commercial or Amateur Radio grade ALE radios any time soon. Judging by the job done to date by ICOM and Yaesu/Vertex in their attempts to bring about ALE transceivers, I will just stick with the software modem/controller approach myself. I doubt you will see the true Amateur Radio grade transceiver provided with an ALE modem/controller option, you never know though? >ALE is very unlikely to have a large following with radio amateurs >because we don't tend to operate by calling specific stations, but I can >see the potential for certain kinds of net operation. Even better would >be some kind of store and forward or at least BBS type system to shift >away from real time interfacing that we typically must do with nets. In >fact, the main reason that I reduced my activity with NTS nets was not >only the lack of traffic, but the requirement to meet at a specific time >and day, which was not acceptable to me. There are many facets of the Amateur Radio Service for which ALE is the best choice in my opinion. Personally I do not want to see all Amateurs cluttering up the ALE channels in full multi-channel ALE operations with daily banter as they do via other modes, that would actually be counter productive, it would be like everyone using PACTOR x on the WL2K PBMO channels. However the use of ALE in daily Amateur Radio activities is valuable in a number of ways, training in support of ECOM application, HF e-mail, linking with a buddy without a schedule or just grabbing their station to leave them a message, calling DX and moving off to another channel for a PCSDM ARQ QSO, propagation studies from monitoring ALE soundings and the list goes. >I realize that part of the attraction of nets is the human social >function and machine connections are not the same thing and that is >probably why other BBS systems did not stay in the forefront over the >years. AQC-ALE for nets has a feature called "Meet Me", you really need to experience it, an NCS station on a schedule or not ( say an Emergency ) can fire up a linking call and send Broadcast traffic to all stations linked ( attended or not ) and lets say the channel first linked on now has really bad interference or the band is changing, the NCS station can fire off "Meet Me" and steer all linked stations to automatically QSY to another channel on that band or another band if needed while maintaining the linked state of all stations, of course all stations must be fully computer controlled. This a great feature for nets, in MARS our nets are multi-mode, fully Voice/Digital, in Amateur Radio must rules prohibit that around the world, but even in the U.S., if you were running a Voice net, this is just a form of signaling where is permitted under Part 97, thus at the start of a voice net the NCS can fire off the net linking call and all stations can be configured with a long enough timeout to cover the duration of the net or no time out and during the course of the net when taking Voice check-in's the NCS can continue to so to link in more new net members and at any time when needed just steer the net to another channel that is not in use automatically, this is great for moving a net when members can not copy the NCS due to propo or interference as that AQC-ALE data usually cuts through, even if the human ear can't hear on it on clear channel ! >If I understand your comments, you are saying that it is only a >theoretical thing that we could run Amtor/Pactor/ and other high speed >switching protocols with existing Operating Systems. Amtor is a bigger timing challenge, I don't think that one will fly under MS-Windows taking all into consideration, PACTOR I is less so, GTOR is even less of a timing challenge. > I guess I look at >all of this as to what can we do with what we have in place now and are >likely to have in place for the foreseeable future and any kind of RTOS >seems unlikely. Well there is always the idea of an RTOS on a powerful enough PIC processor based modem where its all designed and made open, there is OpenRTOS and it runs on a few PIC's and other processors for those who want an inexpensive hardware Modem/TNC approach. I know of one PIC based Packet TNC, actually I think there are two? But to date the PIC MCU's are not powerful enough, that's not rule out other devices though, I can't wait until one of the FPGA manufacturers come out with less than $10 devices in single quantities with guts and free development toolset's, don't know if I will live long enough to see that though. > The main development of new, and yet practical >technology has come from Patrick's FAE mode. FAE ARQ is a great protocol in my opinion, every Amateur wants to use their PCSDM and have an ARQ protocol should start using it, other tools authors should start adding it to their list of supported protocols. >As I often point out, we have the pieces already developed, to wit: > >- very high speed modes that work with very good signals (> 10 dB S/N) >and modest baud rates that are legal here in the U.S. >- software frameworks such as Multipsk and possibly DM780 that handle >the rig control through an auxiliary program such as DXLab Commander and >Ham Radio Deluxe >- no longer having a need for fast switching due to being able to >pipeline data into a background thread to be processed while a new >packet is incoming >- busy frequency detection Tradeoffs my friend, just as in all forms of life, you can ask for but can't expect to get everything you want. >The main missing piece is being able to automatically switch between a >suite of modes and negotiate the best mode for the current conditions. There are a number of fully adaptive data link protocols, some partially adaptive, in a speed sense both PACTOR I and GTOR are speed adaptive, the new PACTOR x and DLP's use with MIL-STD-188-110x are fully adaptive on both ends for speed and interleaver and more, until you see your PCSDM system where here my RX sucks due to channel conditions, but your RX is fine and thus my side tells yours to slow down the data rate and your side tells mine to speed up, after starting at 600bps and then automatically changing to 300/1200bps on the overs or whatever, you have not really experienced adaptive HF digital operation, what I just described is an aspect of MIL-STD-188-110x using just old FS-1052 ARQ which we use in MARS via MARS-ALE with a 2Khz BW and is found in PC-ALE ( but only at the standard 3Khz BW). >I'm still very skeptical of the utility of very high baud rate single >tone modems for moderate to weak signals that are well below the MUF, >but I am keeping an open mind on this and keep looking for some real >world testing results that would compare various modes. The earlier >document I mentioned suggests to me that these modes may not work well >below 10 dB S/N and that is often what we radio amateurs must work with. For traffic networks the speed is really nice to have, especially during an ECOM event. Perhaps at some future WRC the powers to be will formulate two frequencies on each Amateur Band that are clear channels for only high speed HF data network links, not where users get on, but just back end routing channels, that way the users via other frequencies can use various speed ARQ protocols when accessing networks, but those reserved high speed channels can carry the radio-to-radio ( we can't live on just radio-to-Internet alone) flow. As to other uses of high speed data modes, well keyboard to keyboard use is rather stupid as most Amateur's can't even type fast enough and good enough to use 100-200 baud or even less mode, I am told by users all the time that the ACK/NAK diddling of the radios puts pressure on them to type faster and they can't, but for pre-canned message traffic and file attachments the speed is needed, although I would like to see full STANAG 5066 or other aspects of 3G ALE systems come to Amateur Radio, I do not see the need for full blown systems for web page browsing and the like, just e-mail, file attachments and FTP will suffice for Amateur Radio needs. >Lately, there have been more comments about HF e-mail and ALE. What is >currently available other than PSKmail for Linux OS that permits anyone >to set up servers to route the traffic into the internet? HFlinkNet/Winlink 2000 interfacing is rolling out, visit HFlink.org or the HFlinkNet Yahoo forum for details, any ALE system capable of sending/receiving the ALE AMD protocol, which is all ALE systems will be able to send single line or multi-line messages via WL2K interfacing, this was developed in support of MARS and is now coming to Amateur Radio. /s/ Steve, N2CKH >73, > >Rick, KV9U > > > > > >Steve Hajducek wrote: > > GM Rick, > > > > Alternate Link Call (AQC) ALE is basically 2G Plus ALE in that its an > > advanced 8FSK form of ALE where most all of the un-necessary overhead > > of ALE has been removed and new capabilities have been added, to > > include a PSK burst mode. The linking time to setup is must faster > > with AQC-ALE and the ability to achieve a linked state in the face of > > poor channel conditions is hugely improved. > > > > Remember this, ALE is the great facilitator of follow on traffic, be > > it data or voice ( analog or digital) or remote signaling for command > > and control and where the data may be of any format and not just 8FSK > > ALE or other MIL-STD protocols, there are no limitations to what > > follows after the ALE Link Quality Analysis (LQA) has been used to > > select the best channel from those provided to work with. > > > > GTOR and PACTOR I are a challenge within the frame work on an event > > driven OS to implement, if you take control of the OS and limit the > > interrupts to a point of which the application is in control of > > environment, which would for the most part preclude the multi-tasking > > 3rd party application aspect of the OS to point where only the > > digital communications application is running, then it even these > > fast timing ACK/NAK protocols would work, even AMTOR ARQ which is > > even a worst case than PACTOR I timing. As to the new PACTOR x and > > CLOVER modes, they do not have the same short turn around timing, > > PACTOR III is basically modeled after the newer Military waveforms > > which run on the MIL-STD-188-110x modem. > > > > The work that Patrick has done with FAE ARQ to date is the best > > example of an FSK ARQ protocol for Amateur Radio designed for the PC > > Sound Device Modem (PCSDM) in my opinion, it provides the best > > aspects of the MIL-STD ALE DBM ARQ protocol ( developed from the > > MIL-STD's which Kantronics also worked up GTOR from) and PAX/PAX2 > > into a new protocol that I find to be perfect for Amateur Radio at > > keyboard to keyboard, file transfer and HF e-mail needs. What the > > Amateur Radio Service will see come along on the PCSDM in the way of > > a high speed PSK modem waveform that provides all the desired > > features and is legal in all countries for use is yet to be seen. Its > > obvious to me that the MIL-STD-188-110x modem with one of a number of > > DLP waveforms are contenders, timing is not an issue as far as the OS > > is concerned and the speed is certainly there, just as fast and even > > faster and as and more robust than is PACTOR III which the ham world > > uses as the yard stick for some reason, tailoring down of the PSK > > carrier and symbol rate for less than 3Khz signal BW is doable, some > > hardware modems support it and I did in MARS-ALE, but its still to > > much under current FCC rules for Amateur Radio here in the U.S., so > > stay tuned for more developments to come is what I say and for now > > embrace the legal FSK ARQ waveforms on the PCSDM. > > > > /s/ Steve, N2CKH > > > > > > >Announce your digital presence via our Interactive Sked Page at >http://www.obriensweb.com/drsked/drsked.php > >Yahoo! Groups Links > > >
