Hi Rick, The U.S. Declaration of Independence of late has become a popular MARS EXERCISE test message in testing MARS-ALE and with ALE DBM ARQ, that as the body of the message along with the standard MARS message header and tail takes just over 6 minutes if there are no ACK/NAK failures using a frame size of setting of 10 seconds of data which means less data is sent prior to an ACK/NAK, if you increase that from 10 to 100 the message will go some what faster as there are less ACK/NAK handshakes, however if their is a handshake failure due to a poor channel than a much longer frame needs to resent which would mean the message would take much longer than if a shorter frame was sent.
PC-ALE always requires and ALE link first, you can't just use DBM ARQ, however a ham program can be written to drop the ALE link and just implement DBM BRD and DBM ARQ, all the details are published in standards to do so. In MARS-ALE as soon as I have the time such will be the case as well. PC-ALE is configured as a data message tool where you type or paste a message and just send it. The interface is not a keyboard to keyboard interface per see as you need to go through menus to keep getting back to the point where you send the message. However in the most recent version there is a one lone data bar for sending a message in any mode, this provides for keyboard to keyboard without the changing focus, and DBM ARQ is bidirectional, thus technically both station can both be sending those one line messages at the same time and as fast as they can type, but the interface is really designed to buffer all this so that you can, I have testing the bidirectional aspect and it does work but you can't load it up, you can send a full message from both ends and watch the exchange where they will pop up on each stations display, the shortest message will usually finish first. The Military implementation of DBM ARQ seems to be all keyboard to keyboard buffered terminals with type ahead buffers triggered to send when x amount of data is ready by configuration parameter settings. I did recently add LISTEN mode to MARS-ALE which is like GTOR Monitor or PACTOR PLISTEN for DBM and DTM ( DTM is not deeply interleaved as is DBM) and its rather amazing how well one can monitor a DBM ARQ message when not in the link, yes you will get frame repeats when sent, but unless you loose sync on a poor channel you get the entire message and with far fewer repeats than you do when listening to PACTOR I by the way. By the way, data compression can be applied to DBM ARQ where mixed cased messages will benefit the same as GTOR and PACTOR do, thus you can more than double the throughput that I mentioned earlier, this will be in the next release of PC-ALE as a user selected option. When you leave PACTOR I, which for a PII or PIII modem is just used for the initial link and then a negotiation to a higher mode/data rate you start to move away from FSK, basically what SCS has done is to follow what the Military has been doing over the last 10+ years whereas PIII is pretty much the SCS version of Military waveform's that are used on the MIL-SDT-188-110 modem. Someone should really look at making a stand alone DBM ARQ terminal program and DBM ARQ BBS if an excellent FSK ARQ PCSDM based system is desired, the speed and robustness are all good and the protocol is all published and free to implement. I believe that I read on this forum that ALE Sounding and Decoding was added to MultiPSK for an experiment? That's not really something that has any usefulness in a program such as MuliPSK, however DBM ARQ would be just the thing. The turn around time after the sending station sends a DBM ARQ frame ( or block ) is seconds, not milliseconds, the receiving station should immediately respond, but in a few seconds if no response is heard or if the response is heard and is bad, the sending station sends the last frame again, if the receiving station gets a frame twice that match then one is tossed, when all is said and done if the message is complete you have success and if not you have a failed message. During the process if the number of retries set to send a frame is ever exceeded ( it resets on each successful frame) then you have a failed message. Lately with MARS-ALE we have been sending long messages on poor channels over short and long distances where DBM ARQ gets through and GTOR and PACTOR I at times fail, pretty amazing, here I am using a KAM Plus, KAM XL for both modes and also an SCS PTCII Pro at times, but mostly the KAM Plus on my 24/7 station. That 24/7 ALE station by the way is using the on-board AC'97 sound device and its a laptop PC, worst case when talking about good, low jitter, low noise PCSDM, PCI is much better and external PCSDM is the best, which I also have and use, but I always do most of my development work with worst case, obviously when switching over to the MIL-STD-188-110 PCSDM based modem that AC'97 limits the data rate, 600bps is usually the best, where as I can get 2400bps coded on a PCI based system and better with an external device. You want MIL-STD-188-141B for the latest standard, but '141A or even FS-1045 will provide all the needed details on DBM, just search the web. /s/ Steve, N2CKH At 08:57 PM 1/16/2007, you wrote: >Steve and group, > >The part of ALE that has this ARQ mode sounds pretty good. Is it fair to >say that the 8 tone modulation is actually closer to what Pactor 3 uses? >The speed is a bit fast for many HF conditions but it has FEC as well as >ARQ so like Pactor, is that why it tends to overcome some of the ISI issues? > >Can you just use the PC-ALE program and connect to another station for >an ARQ transfer of data or even a keyboard connection? > >If this mode is this good, what is the possibility of adapting it for a >high speed digital sound card mode and have it incorporated into the >multimode sound card programs? > >How can this mode handle ARQ with sound card/computer timing constraits? > >Some of us in the amateur digital community have been hoping for some >kind of ARQ sound card mode. Are we overlooking an already invented >sound card protocol as Bonnie had mentioned last summer, except that >ideally it would scale down in baud rate if conditions require it? > >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
