Ref below. In that case if your referring to packet via a tnc,
I concede yes its just as error free as Pactor or any other mode
useing a TNC. Useing a sound card only with soundcard software
however sounds very implausable to me!!!
Joe



************************************************** **
* Ham KH6JF AARS/MARS ABM6JF QCWA WW2 VET WD RADIO *
************************************************** **


On Mon, 15 Mar 2004, Charles Brabham wrote:


"Joseph Fenn" wrote in message
va.net...
IMHO none of the sound card tools fulfill the requirement of
arq (formerly known as automatic error correction now known
and CRC checking). Hence they are not used where msg integrity
is the prime consideration from origin to destination and the
msg passes thru many gateways and channels to reach its final
destination point.
Joe ABM6JF/KH6JF
MBO (sysop) for AB6USA PBBS

Packet and Q15x25 mode have error correction, though not arq. Either of
these will send data error-free, and Q15x25 has impressive throughput.
Q15x25 uses psk streams, proving that psk can be utilized with effective
error-correction. It's not arq though.

Charles, N5PVL

Joseph Fenn wrote on 15/03/2004 23:20:

Ref below. In that case if your referring to packet via a tnc,
I concede yes its just as error free as Pactor or any other mode
useing a TNC. Useing a sound card only with soundcard software
however sounds very implausable to me!!!

Packet with a sound card uses exactly the same protocol as packet with a
TNC - AX25. Therefore it uses a CRC exactly the same as packet with a TNC.

--
Roger Barker, G4IDE -
For UI-View go to - http://www.UI-View.com
For WinPack go to - http://www.peaksys.co.uk

Joseph Fenn wrote on 15/03/2004 23:20:

Ref below. In that case if your referring to packet via a tnc,
I concede yes its just as error free as Pactor or any other mode
useing a TNC. Useing a sound card only with soundcard software
however sounds very implausable to me!!!

Packet with a sound card uses exactly the same protocol as packet with a
TNC - AX25. Therefore it uses a CRC exactly the same as packet with a TNC.

--
Roger Barker, G4IDE -
For UI-View go to - http://www.UI-View.com
For WinPack go to - http://www.peaksys.co.uk

"Joseph Fenn" wrote in message
va.net...
Ref below. In that case if your referring to packet via a tnc,
I concede yes its just as error free as Pactor or any other mode
useing a TNC. Useing a sound card only with soundcard software
however sounds very implausable to me!!!
Joe

I have operated a VHF port on my packet BBS that was soundcard-based, back
when I used the Win95 version of FlexNet. The DOS version of FlexNet will do
it too. That soundcard handled the VHF needs of a BBS, a DX cluster, and my
personal keyboard, all at once. It never failed, and never gave any trouble
in a year's operation. I finally shut it down when I upgraded to a better
computer running a more modern OS. The software was intended for Win95 and
would not work with Win98SE, so that was that.

On HF, it's a different story. There are numerous HF soundcard modes, but
none of them are intended or designed to be used in conjunction with BBS or
any other kind of server software at all. It's all end-user stuff.

The only soundcard mode I have gotten to work with packet BBS software on HF
is Q15x25 (Newqpsk) mode. I set it up and operated a Q15x25 BBS on HF for 24
hours on 20 meters, to check for function. Of course, there was nobody to
connect to the BBS, but I had already done on-the-air testing of Q15x25 on
HF so I knew that it "worked". After a day, I shut it down and went back to
HF packet, where there were other stations to communicate with. No matter
how advanced the mode; If you have no-one to connect with, you're not going
to move much data.

Q15x25 mode uses 15 psk streams @ 88 baud to get an effective 2500 baud
throughput. Despite sounding funny, and being 15 psk streams wide, Q15x25
mode works exactly like packet. What I did was to create a Packet/Q15x25
gateway (Using Flex32) and digi'd through that gateway to HF from my BBS.
The packet BBS "talked" to the gateway over a 19.2kb fulldup serial link.
( The whole mess was a two-computer setup.)

So, as far as operating a server on HF goes, I think it's fair to say that
the soundcard modes are currently pretty close to being worthless. Q15x25
has potential, but I don't notice anybody getting in a big rush to utilize
it. That makes it worthless, too. I'm not trying to be negative or critical
here, but that's just how it is at this point. - And tomorrow may be another
story.

My idea for a killer HF digital mode over a soundcard has no name, but would
involve a half-dozen or so psk streams (same overall bandwidth as packet),
with all but one stream transmitting in multicast mode. One PSK stream is
for a control/chat channel while the others send the multicast data stream,
slightly staggered in time so that each of the four redundant data streams
provide error-correction ala' multicast protocol. ( The same data is
transmitted on five psk streams, each one progressively delayed so that the
streams provide "fills" for data lost to static crashes, poor propagation,
etc. on the first stream, second stream, etc. etc...) The data gets five
chances to make it through. I would have an option of using the control/chat
channel as another redundant data stream, making it six.

This mode works like the low-power, constant boost ION engines that NASA has
on some of their satellites. Despite it's low data rate (300 baud on HF) it
still moves an impressive amount of data because it's constantly on the job,
not operating in fits and starts like packet or the arq modes. Constant
boost. At 300 baud, a multicast data stream can move around 5 megabytes a
data per day. (5 MB / Day) which is pretty impressive when combined with
on-the-fly error correction.

Another great feature of this mode is that it is a connectionless mode like
APRS... Anybody with an HF receiver and a computer can decode the multicasts
and receive the data. One server station can send data to an unlimited
number of receiving stations simultaneously, instead of just one. When you
combine this feature with the 5 MB/day throughput, what you have is a killer
HF data mode that will make just about anything else on HF look very, very
slow. - And I am not leaving PACTOR III out of that comparasin, neither am I
blowing smoke out of my shorts or trying to feed anybody any "farina". This
is for real. - And it will do it within the same amount of bandwidth that a
packet QSO takes up.

Programmers: Take note! Contact me for details, protocol info, etc. Here's
a good chance to make a name for yourself in the amateur community.

Charles Brabham, N5PVL
Director: USPacket.Net
http://www.uspacket.net

"Joseph Fenn" wrote in message
va.net...
Ref below. In that case if your referring to packet via a tnc,
I concede yes its just as error free as Pactor or any other mode
useing a TNC. Useing a sound card only with soundcard software
however sounds very implausable to me!!!
Joe

I have operated a VHF port on my packet BBS that was soundcard-based, back
when I used the Win95 version of FlexNet. The DOS version of FlexNet will do
it too. That soundcard handled the VHF needs of a BBS, a DX cluster, and my
personal keyboard, all at once. It never failed, and never gave any trouble
in a year's operation. I finally shut it down when I upgraded to a better
computer running a more modern OS. The software was intended for Win95 and
would not work with Win98SE, so that was that.

On HF, it's a different story. There are numerous HF soundcard modes, but
none of them are intended or designed to be used in conjunction with BBS or
any other kind of server software at all. It's all end-user stuff.

The only soundcard mode I have gotten to work with packet BBS software on HF
is Q15x25 (Newqpsk) mode. I set it up and operated a Q15x25 BBS on HF for 24
hours on 20 meters, to check for function. Of course, there was nobody to
connect to the BBS, but I had already done on-the-air testing of Q15x25 on
HF so I knew that it "worked". After a day, I shut it down and went back to
HF packet, where there were other stations to communicate with. No matter
how advanced the mode; If you have no-one to connect with, you're not going
to move much data.

Q15x25 mode uses 15 psk streams @ 88 baud to get an effective 2500 baud
throughput. Despite sounding funny, and being 15 psk streams wide, Q15x25
mode works exactly like packet. What I did was to create a Packet/Q15x25
gateway (Using Flex32) and digi'd through that gateway to HF from my BBS.
The packet BBS "talked" to the gateway over a 19.2kb fulldup serial link.
( The whole mess was a two-computer setup.)

So, as far as operating a server on HF goes, I think it's fair to say that
the soundcard modes are currently pretty close to being worthless. Q15x25
has potential, but I don't notice anybody getting in a big rush to utilize
it. That makes it worthless, too. I'm not trying to be negative or critical
here, but that's just how it is at this point. - And tomorrow may be another
story.

My idea for a killer HF digital mode over a soundcard has no name, but would
involve a half-dozen or so psk streams (same overall bandwidth as packet),
with all but one stream transmitting in multicast mode. One PSK stream is
for a control/chat channel while the others send the multicast data stream,
slightly staggered in time so that each of the four redundant data streams
provide error-correction ala' multicast protocol. ( The same data is
transmitted on five psk streams, each one progressively delayed so that the
streams provide "fills" for data lost to static crashes, poor propagation,
etc. on the first stream, second stream, etc. etc...) The data gets five
chances to make it through. I would have an option of using the control/chat
channel as another redundant data stream, making it six.

This mode works like the low-power, constant boost ION engines that NASA has
on some of their satellites. Despite it's low data rate (300 baud on HF) it
still moves an impressive amount of data because it's constantly on the job,
not operating in fits and starts like packet or the arq modes. Constant
boost. At 300 baud, a multicast data stream can move around 5 megabytes a
data per day. (5 MB / Day) which is pretty impressive when combined with
on-the-fly error correction.

Another great feature of this mode is that it is a connectionless mode like
APRS... Anybody with an HF receiver and a computer can decode the multicasts
and receive the data. One server station can send data to an unlimited
number of receiving stations simultaneously, instead of just one. When you
combine this feature with the 5 MB/day throughput, what you have is a killer
HF data mode that will make just about anything else on HF look very, very
slow. - And I am not leaving PACTOR III out of that comparasin, neither am I
blowing smoke out of my shorts or trying to feed anybody any "farina". This
is for real. - And it will do it within the same amount of bandwidth that a
packet QSO takes up.

Programmers: Take note! Contact me for details, protocol info, etc. Here's
a good chance to make a name for yourself in the amateur community.

Charles Brabham, N5PVL
Director: USPacket.Net
http://www.uspacket.net

"Charles Brabham" wrote

No matter
how advanced the mode; If you have no-one to connect with, you're not going
to move much data.

Once we get the FCC to write restrictive rules, it's very hard to remove them.
The only unattended mode allowed is packet using 2FSK, and if you can't run
unattended, why bother. Thus the stagnation and apathy in digital radio relay.
Meanwhile psk31 and others are very popular as the attended mode.

Until we get rules that allow experimentation, ham radio will always be about the
white man with the most money and power, rather than any other feature/future.

"Charles Brabham" wrote

No matter
how advanced the mode; If you have no-one to connect with, you're not going
to move much data.

Once we get the FCC to write restrictive rules, it's very hard to remove them.
The only unattended mode allowed is packet using 2FSK, and if you can't run
unattended, why bother. Thus the stagnation and apathy in digital radio relay.
Meanwhile psk31 and others are very popular as the attended mode.

Until we get rules that allow experimentation, ham radio will always be about the
white man with the most money and power, rather than any other feature/future.

"D. Strang" wrote in message
news:eaD5c.25251$m4.19987@okepread03...
"Charles Brabham" wrote

No matter
how advanced the mode; If you have no-one to connect with, you're not
going
to move much data.

Once we get the FCC to write restrictive rules, it's very hard to remove
them.
The only unattended mode allowed is packet using 2FSK,

Actually, that is not so. There are and have been unattended digital station
operating modes besides packet for quite some time. In fact, unattended RTTY
and AMTOR mailboxes predate packet. Currently, there are dozens of
unattended PACTOR and CLOVER stations.

I would say "Before you disparage the hobby, try getting your facts
straight." but I realize that very few ham-bashers have any interest in the
facts. - They just want to pee on everybody's party, miserable souls that
they are.

Charles Brabham, N5PVL
Director: USPacket.Net
http://www.uspacket.net

"D. Strang" wrote in message
news:eaD5c.25251$m4.19987@okepread03...
"Charles Brabham" wrote

No matter
how advanced the mode; If you have no-one to connect with, you're not
going
to move much data.

Once we get the FCC to write restrictive rules, it's very hard to remove
them.
The only unattended mode allowed is packet using 2FSK,

Actually, that is not so. There are and have been unattended digital station
operating modes besides packet for quite some time. In fact, unattended RTTY
and AMTOR mailboxes predate packet. Currently, there are dozens of
unattended PACTOR and CLOVER stations.

I would say "Before you disparage the hobby, try getting your facts
straight." but I realize that very few ham-bashers have any interest in the
facts. - They just want to pee on everybody's party, miserable souls that
they are.

Charles Brabham, N5PVL
Director: USPacket.Net
http://www.uspacket.net