While the Pactor 2 and 3 modes are quite good, they do use a constant 
100 baud signaling rate. SCS indicated a number of years ago that their 
tests showed that with what at that time, they considered strong DSP, 
the desire for improved data throughput and  I think resistance to 
Doppler, the 100 baud speed was a good compromise. However, under some 
circumstances, primarily severe ISI multipath, there are going to be 
times that these modes simply do not work and some sound card modes may 
work, albeit at very slow speeds.

SCS also claimed that they could work down to around -15 dB SNR or so, 
but others have pointed out that there really is not much, if any 
throughput at that point, but it can maintain the link. Reminds me how 
frustrated I used to be with Clover II. I would be connecting to Ray, 
W7GHM, the inventor of Clover and Clover II (and CCW), but we would have 
very little throughput between his island in Washington state an my QTH 
in SW Wisconsin:(

The reason that Pactor 2 and 3 modes work so well overall, is the 
ability to scale. No one has had either the desire or ability to design 
a new sound card mode with this adaptive ability except on a limited 
basis with the SCAMP protocol developed by KN6KB, who is also the 
developer of WINMOR. But as I always say, it only takes one person. And 
maybe others will now be willing to help develop the open protocol for 
other uses that we need. Especially because it will have a very narrow 
200 Hz mode as well as 500 and wider modes. This has tremendous potential.

As QST showed some time back, even a low end sound card does quite well 
with sound card modes. Maybe it could be shown that a more sophisticated 
sound card protocol needs a superior sound card but WINMOR is been 
tested with the Tigertronics Signalink USB which has one of the lower 
quality sound cards with a relatively poor SNR and low frequency noise 
products that you likely won't find on a built-in card. A modest ~ $30 
sound card such as the Creative Soundblaster Audigy SE might have at 
least a magnitude or even several magnitudes better SNR.

The test that I perform, (and all digital hams really should) is to 
monitor my own signal with a nearby receiver and determine whether there 
is any noticeable rise in background noise when you key the sound card 
with no signal. With the aforementioned Audigy SE, I can not hear 
anything. With my SL-USB it is of course another story:( Even so, the 
SL-USB has its place, in my view, for ease of use and particularly for 
emergency situations where you want to keep things as simply as possible.

The problem with the proprietary SCS products is that 99.9% of hams will 
never have such a modem so you can obviously not expect P2 and P3 to 
communicate with very many other hams. Its main forte is for e-mail to 
get to the internet via HF distances using Winlink 2000. Although rarely 
needed, some hams who travel might find it convenient. If I was an RV or 
blue water mariner, I would give serious consideration to buying this 
kind of product. For casual ham use it has minimal value since the whole 
point is to contact other hams who have similar technology and almost 
none have it and they don't use it for keyboard contacts as (believe it 
or not) we used to do with Amtor, Pactor, and Clover II.

As Jim points out, Pactor could be run on DOS based computers (K6STI and 
a later version of BMKMulti with some basic interface such as a AEA 
CP-1, etc.), but some claimed the capabilities were not as good. I have 
a friend who likes old stuff and scrounging and he runs Pactor with some 
kind of DOS set up for MARS. With Pactor 2 and 3, this is not possible 
due to licensing issues, even if the computer could handle the timing.

WINMOR should perform better than Pactor and may be competitive with P2 
in terms of speed although I am not sure about robustness. And to do 
that it will have to be as wide as some of the widest P3 speed levels, 
so it is perhaps not a totally fair comparison since P2 is ~ 500 Hz.

I think there are more than a few of us who are excited about the 
direction things seem to be going.

73,

Rick, KV9U






jhaynesatalumni wrote:
>
> I would say that adapting to changing band conditions and utilizing
> FEC as much as possible are not inherent limitations of sound card
> modems, but are simply artifacts of the higher-level protocols.
> There's the modulation scheme layer, and the encoding layer where
> the FEC is applied, and then an adaptive layer that comes in 
> where the sender gets feedback from the receiver that things are
> not going very well and something else should be tried.  Now this
> layer may call for a change down in the modulation scheme layer,
> to use something more robust and slower when things are not going
> well, and to hop up to something faster and less robust when
> conditions permit.
>
> I think you're right too about the quality of sound cards.  What we
> get with onboard sound or with the low-priced add-in boards is the
> lowest grade the consumer will accept.  You can't blame the
> manufacturer for providing that when the consumer will accept such
> junk - I mean if all you are going to use it for is to listen to
> loud, intentionally-distorted rock music then you aren't going to
> care much about signal to noise ratio or linearity.
>
> You can find some sound card evaluations on the web; and some have
> been discussed on this group.  There are really good ones, but
> then the prices are up there with the dedicated DSP engines like
> the SCS modems.  The challenge is to find one that is good enough -
> and considering all the noise and crud of the HF channel maybe it
> doesn't have to be very good to be good enough.
>
> The big win for sound card modems is that everybody has one already,
> and that lots of people are writing software that can use them,
> so lots of experimentation is going on.  We've already got dozens
> of digital soundcard modes that nobody uses because they have not
> attracted enough attention or shown enough superiority over others
> to make people want to use them.
>   
>   
>>     
>
> What we are talking about here are products that have their own
> DSP processor and memory and A/D/A conversion, and you can
> download the firmware that runs the DSP from a PC.  The advantage
> seems to be that the DSP processor is not getting interrupted by 
> all the other activity that is going on in the PC; and the receiver
> can maintain synchronism with the transmitter over a long period
> of time.  This is presumably important for some modulation and coding
> schemes - they can spend as much time as they want getting
> synchronized initially, and then they don't need to spend much
> effort to stay synchronized afterward.
>
> The problem we all realize is that there is no single DSP engine
> out there that we have all agreed to use and therefore people have
> an incentive to write software for; so it remains a niche activity.
> I recall this is where PSK was before the sound card software was
> developed - it ran on a dedicated DSP engine and so few people had
> them that there was little incentive for others to get them.
>
> If the SCS products were (are?) open to third-party development,
> so that others might write PSK or MFSK or Olivia modems to run
> on them, perhaps we would all buy them and quit using the sound
> cards.  I don't think it's realistic to expect SCS or any other
> vendor to spend their own money to add popular modes to their
> products, esp. when the sound card versions are out there for free.
> There once was the HAL PCI-4K DSP modem developed for Clover but
> later adapted to run RTTY and Pactor-I.  Clover was once used
> for message-passing systems as well as for conversational operation.
> I don't know how relatively good or bad it was as a modulation
> scheme compared to some of the others.  It seemed to me that a
> main drawback could have been remedied - it seemed to get stuck
> trying to send a long block when conditions were too poor and
> for some reason it could not fall back to sending short blocks
> which might get through.
>
> There also once was the K6STI RITTY software that was designed
> to run under DOS and for a while could run Pactor-I as well as
> RTTY.  This leads me to wonder if a suitable DSP engine could
> be made from a PC and a sound card but not running a general
> purpose operating system.  Maybe FreeDOS is a candidate for
> the operating system, or maybe we just need a single-minded
> loader that can load and run a single PC program and communicate
> with another PC over Ethernet or USB or even RS-232.  The
> other PC running a conventional OS would handle the higher-levels
> of protocol and the user interface.
>
> Jim W6JVE
>
>
>
>   

Reply via email to