Hold those thoughts for the ARRL Prize. But yes there is lots of thought about narrow moodes, 500 Hz and less and wider modes...3.5 KHz and perhaps 5-6 KHz.
The ARRL has proposed a 3.5 KHz bandwidth limit for wide bandwidth modes but I think the FCC wants to limit it to less than 3 KHz (maybe only 2.5 KHz) as the widedest bandwidth in the current SSB/SlowScan TV bands. Walt/K5YFW KV9U wrote: > > > Why do some modems use more "rectangular" waveforms instead of what > appears to be the optimum waveform for HF modems? Or are there downsides > to raised cosine waveforms? > > In terms of bandwidth, it seems to me that for most uses, a 500 Hz > bandwidth is a wise choice. This seems to be a good tradeoff in width vs > potential throughput for keyboard modes and even some higher speed data > modes like Pactor 2 can do under better conditions. Also, 500 Hz filters > have been commonly available for CW. With more rigs using DSP filters, I > admit that it is less of an issue to tailor make it to one particular > width. > > How about a two tone, DPSK scheme with 50 (maybe even 25?), and also 100 > and 200 baud rates? Even if you would initially require manual adjustment. > > Then we also should have a mode that can run in a voice channel, > probably 2.4 to at most 2.7 KHz width. How about an 8 tone DBPSK and > maybe switchable (manually at first) to higher PSK rates? > All of these modes could have similar timing for ARQ. How about 0.5 > seconds pause between transmissions and awaiting an ACK or NAK or > control signal? With right control signals you could change the length > of time for the packet burst. But for starters, maybe just a simple > packet size. > > 73, > > Rick, KV9U > > Walt DuBose wrote: > > >One solution suggested to me was that each tone be individually > shaped/filtered > >before transmitting and then each tone have an individual brick wall > filter > >before it is decoded. > > > >I believe that there is not going to be one mode or mode configuration > that > >works well on 3-30 MHz...we will probably have several sets of > configurations or > >perhaps even one optimum configuration for each band or set of > conditions. The > >more options you have that you can adjust of the fly or that can be used > >adaptively the better off the mode will be. > > > >Someone (perhaps all) needs to keep technical notes on what modes work > best on > >what band. > > > >Also, we need to come to an agreement on what mazimum bandwidth and user > >throughput we want as well as how robust and how sensitive we want the > mode to > >be. My personal belief is that we go for 500 Hz wandwidth, 400-800 WPM > user > >throughput 99.9% error free and work down below a 0 dB SNR (0 to -5 > dB) on a > >poor CCIR channel. > > > >Put your thinking caps on and make your wish list. > > > >73 & CLU, > > > >Walt/K5YFW > > > >KV9U wrote: > > > > > >>Some of us did try Chip modes when Nino first came out with them, but > >>they did not seem to perform as well as existing modes. > >> > >>I really implore to our treasured programmers to see if they can come up > >>with some modes that can compete with Pactor modes. Especially some ARQ > >>modes that can work on MS OS. > >> > >>We know from Pactor 2, that a raised cosine shaped pulse is likely a > >>very good basic waveform. Then for the most robust mode, a two tone > >>DBPSK modulation is used and as the conditions improve, the modulation > >>changes to DQPSK and then with further improvements to 8-DPSK and even > >>16-DPSK for maximum throughput when conditions are very good. This is > >>what enables Pactor 2 to send about 700 bits per second at the peak > >>speed and do it in only a 500 Hz wide span. > >> > >>We know this can be done at the higher speeds under good conditions with > >>sound card modes since SCAMP was even faster than P2, although a much > >>wider signal. The problem with SCAMP was that it had no fallback > position. > >> > >>Pactor 3 is runs an occupied bandwidth of about 2.4 kHz, but raw speed > >>is over 2700 bps. Instead of 2 tones, P3 uses up to 18, separated by 120 > >>Hz and modulated at 100 baud DBPSK or DQPSK. > >> > >>SCS has some fairly detailed data on Pactor 3 at: > >> > >>http://www.scs- ptc.com/download /PACTOR-III- Protocol. pdf > >><http://www.scs- ptc.com/download /PACTOR-III- Protocol. pdf > <http://www.scs-ptc.com/download/PACTOR-III-Protocol.pdf>> > >> > >>I wish someone could explain why we can not have a sound card mode that > >>is roughly the same as Pactor 2 at least. Even if there was no ARQ at > first. > >> > >>And how different is Pactor 3, than what the SSTV hams are using > >>everyday? Aren't they using OFDM with QAM? If you recall what Tom Rink > >>said back in 1995 on the TAPR HF SIG: > >> > >>"As mentioned in the introduction, PACTOR-II uses a two-tone DPSK > modulation > >>system. Due to the raised cosine pulse shaping, the maximum required > >>bandwidth > >>is only around 450 Hz at minus 50 dB. ASK, which was also tested in the > >>early > >>stage, provided poorer results in weak conditions compared with a higher > >>DPSK > >>modulation, as different amplitude levels are more difficult to > >>distinguish in > >>noisy channels than more phase levels. Additionally, ASK increases > the Crest > >>Factor of the signal. For these reasons, it is not used in the final > >>PACTOR-II > >>protocol. Basic information on these items can also be found in the > >>first part > >>of this series." > >> > >>Although not ASK, doesn't QAM employ amplitude changes as part of the > >>modulation scheme? > >> > >>What happens if you use a multitone DPSK? It seems to a non-engineering > >>person like myself, that a lot of what P2 and P3 are made up of are > >>really a series of PSK100 or PSK200 tones (carriers). > >>Isn't Q15X25 a similar modulation scheme? It even runs at 83.33 baud > >>rather than a minimum of 100 baud such as P2. > >> > >>Why did it not work as well as P modes? > >> > >>Or is it because it has no coding such as Reed-Solomon block coding or > >>Viterbi convolutional coding? > >> > >>73, > >> > >>Rick, KV9U > >> > >> > >
