Hello Patrick, The "problem" with PAX/PAX2 is that they do not have the full ASCII character set and they are very slow.
The timing of Windows/Linux is not so bad that you could not have a moderate sized window. After all the SCAMP mode showed this can be done and it had a NAK/ACK time of 0.6 seconds or something close to that. While not a synchronous ARQ mode, it sure acted like it when I did the beta testing. The feeling you got is very similar to what it was like when we first started using Amtor:) The success of this kind of mode seems to be the use of pipelining the last packet and the processing being done in the background. It seem to me that this is the best way to develop a serious ARQ sound card mode that can work with existing computer abilities. If it also had adaptive ability to meet the challenges of the RF conditions at the moment, you would have a huge winner. 73, Rick, KV9U Patrick Lindecker wrote: >Hello Rick, > > > >>Yes, I was afraid of the long frames. >> >> >Yes, at 100 bauds, no more than 50 bytes... > > > >>And when you get done, it seems it would be better to use an existing >>mode or new mode for an ARQ mode for sound card digital. >> >> >With the same frames, in APRS for example (on in Unproto), compare the 100 >bauds Packet with Pax/Pax2. I think in Pax APRS will be very much better (I >hope so!) because Pax is an Olivia clone (so much more robust than Packet). > > > >>What do you think about all this talk about very high baud rate digital sound >>card >programs? >> >> >I think all this is very confused...It needs precise specifications for >programmers on a precise mode. >In the principle, why not very high baud rate, but remember that more or less, >when you double the baud rate, you double the bandwidth (or and if you keep >the same bandwidth you divise by 2 the euclidian distance between symbols), >and, so, you increase the minimum S/N of 3 dB... >The way to win dB on the minimum S/N is: >*on the correction coding, which can give a gain according to the coding >(Convolutional coding and Reed Solomon were the best but now "turbo-codes" >approach the Shannon limit). >* to decrease the number of bits by character (about 5 bits/character in >PSK63F (Nino IZ8BLY) which is the best auto-synchronized coding but 4 >bits/character would be ideal...). > >If you multiply the number of carriers, you decrease drastically the average >power/peak power ratio. > >Note: under Windows only an asynchronosous ARQ mode is possible (as Pax) not a >synchronous ARQ mode (as Pactor), unfortunatly... > >73 >Patrick > > > > Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org Other areas of interest: The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/ DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion) Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
