Re: [digitalradio] RE:Packet radio with sound card

[Jose A. Amador]

Rick,

You have a point. I did not stop to think about the possibility of 
"multicast fills".

73,

Jose, CO2JA

--

Rick W wrote:

> Hi Jose,
> 
> The advantage of using manual ARQ fills after the transmission of the 
> data, is that it can be used as a one to many transmission. If any 
> stations did not receive the data perfectly, they can send a request to 
> repair defective portions. This is not possible with a handshaking type 
> connection. Ideally, you would be able to do it either way.
> 
> The main advantage of Pactor, Clover II and Gtor were the ability to 
> make some changes in the speed and modulation in order to more closely 
> match the path conditions. SCAMP could do this within a narrow limit, 
> but it was not capable of working down to the weak signal level that the 
> developer had expected, which was around zero dB SNR. Instead, it was 
> closer to perhaps ~ +8 dB and needed to have a slower (more robust) mode 
> to compete at all with Pactor.
> 
> It is hard to believe that 4 years have gone by since we started beta 
> testing SCAMP, but better something late than never. In the meantime, no 
> one else was able to come up with an adaptive mode suitable for amateur 
> use, so this could be the next big thing ...
> 
> 73,
> 
> Rick, KV9U
> 
> 
> Jose A. Amador wrote:
>> I can understand that procedure in sake of simplicity, but hardly an
>> efficient one. Obviously, ARQ should be automatic.
>>

VI Conferencia Internacional de Energía Renovable, Ahorro de Energía y 
Educación Energética
9 - 12 de Junio 2009, Palacio de las Convenciones
...Por una cultura energética sustentable
www.ciercuba.com 

Re: [digitalradio] RE:Packet radio with sound card

[Rick W]

Hi John,

Amtor was never that good. If you recall, it would start allowing 
erroneous data through when signals become weak enough. And when that 
happened, the signals were of what we would today call reasonably good 
signal strength for PSK31, MFSK16, etc.

Pactor was much better. I did not have similar problems with bad data. 
Clover II would not allow bad data to go through but it did not work 
that well into the noise either and was a huge disappointment to me as I 
liquidated all my equipment to buy the HAL P-38 card that was supposed 
to also do Pactor, which it never could work properly.

Pactor II and Pactor III are claimed to be much better than Pactor, 
however, like most digital hams, I won't ever be using them so it is a 
moot point.

If Winmor can work reasonably close to the expectations of the 
developer, it should perform as well as or even better than Pactor II, 
but it may need a wider footprint for similar speed. Unlike Pactor 
modes, Winmor will have three different bandwidth modes. It will be very 
interesting to see how they perform. It is not expected to reach the top 
speeds of Pactor III, but then again, how often does P3 reach the higher 
speeds via its wide bandwidth and more complex constellation? Not very 
often from what observers have seen. It is often operating at Speed 
Levels several steps down from the top level due to band conditions.

We don't know if there will be a peer to peer mode. If there is none, 
then it will primarily find limited use for e-mail. I know some think 
this is the most important thing to have. In my area, it would get 
rather infrequent use, but a connected mode, or better yet, a BBS system 
that could tie a group together would be the most useful. Unlike packet, 
it should be much more sensitive with weak signals and allow stations to 
connect, that currently can not when they use simplex phone. With a BBS 
it could also time shift so that more radio amateurs could participate 
since you would not be beholden to a specific net time.

In my Section, they actually have hams promoting the sending of e-mail 
to a central server as somehow participating in a net operation. And you 
don't even have to use RF, just use the internet! We need to completely 
turn around this kind of approach and move to a robust method of 
connecting hams through HF and VHF.

Imagine using a multimode/multiband transceiver, as many now have, to 
one simple interface and laptop and work with one basic system across HF 
and VHF.

73,

Rick, KV9U


John Becker, WØJAB wrote:
> Rick
> Correct me if I'm wrong. But reading between the lines of you post
> on this subject I feel you are saying -
>
> don't hold you breath for a sound card mode that will replace the
> ARQ modes such as Pactor  or  Amtor. 
>
>
> John, W0JAB
>
>
>   

Re: [digitalradio] RE:Packet radio with sound card

[John Becker, WØJAB]

Rick
Correct me if I'm wrong. But reading between the lines of you post
on this subject I feel you are saying -

don't hold you breath for a sound card mode that will replace the
ARQ modes such as Pactor  or  Amtor. 


John, W0JAB

Re: [digitalradio] RE:Packet radio with sound card

[Rick W]

Hi Jose,

The advantage of using manual ARQ fills after the transmission of the 
data, is that it can be used as a one to many transmission. If any 
stations did not receive the data perfectly, they can send a request to 
repair defective portions. This is not possible with a handshaking type 
connection. Ideally, you would be able to do it either way.

The main advantage of Pactor, Clover II and Gtor were the ability to 
make some changes in the speed and modulation in order to more closely 
match the path conditions. SCAMP could do this within a narrow limit, 
but it was not capable of working down to the weak signal level that the 
developer had expected, which was around zero dB SNR. Instead, it was 
closer to perhaps ~ +8 dB and needed to have a slower (more robust) mode 
to compete at all with Pactor.

It is hard to believe that 4 years have gone by since we started beta 
testing SCAMP, but better something late than never. In the meantime, no 
one else was able to come up with an adaptive mode suitable for amateur 
use, so this could be the next big thing ...

73,

Rick, KV9U


Jose A. Amador wrote:
>
> I can understand that procedure in sake of simplicity, but hardly an
> efficient one. Obviously, ARQ should be automatic.
>
>   

Re: [digitalradio] RE:Packet radio with sound card

[Jose A. Amador]

Rick W wrote:

> SCAMP had no problem at all with the switching times from the testing
> I did. As a former Amtor and Pactor user from years earlier, it
> proved to me that my concerns about switching were unwarranted.

Cold switching (no RF until contacts are closed, or opened while RF is
flowing) should be harmless.

My 600 W output homebrew linear can handle 40 wpm full break in using a
current driven, run of the mill Potter and Brumfield 12 V 3P2T relay.

But other replacement relays may be not as easy to find.

> Then along comes RFSM2400 with its frequent switching back and forth
> to maintain a link, even with no data flow, and you realize that
> computers can switch in a few tens of milliseconds, even with
> non-real time operating systems. Try toggling the PTT control with a
> typical multimode program and see how fast you can switch back and
> forth. It is not all that slow. I am skeptical about the "wear and
> tear" issue.

My first experiences with AMTOR were frightening... but proved harmless
to my gear.

> Many rigs have QSK capabilities to allow switching between TX and RX
> many times per second. Even at 60 wpm with CW! So twice per second
> for older technology such as Amtor would not be that difficult to
> handle and new technology with less than one cycle per a few seconds,
> hardly noticeable.
> 
> Although RFSM (MIL-STD 188-110A) can not be used in the HF RTTY/Data
>  U.S. bands due to the high baud rate, other MIL-STD parallel tone
> modems could, even though it is not something that common. One of the
> methods would be to use some of the SCAMP technology and leverage it
> with the newer non RFDT modulation of SSTV/data such as QAM

QAM is as far as you can go without losing appreciable robustness.

> and do it with on the fly ARQ instead of manually after the
> completion of the transmission as it is done now with most of these
> programs.

I can understand that procedure in sake of simplicity, but hardly an
efficient one. Obviously, ARQ should be automatic.

> From my understanding that is what Winmor effectively does, plus it 
> will have the necessary adaptive technology for ramping speeds up and
> down for conditions. This is something that any new, successful 
> messaging system MUST have to succeed.

That is what SCS boxes have done for a long time.

> The big question for the future is how open Winmor will be so that
> other adaptations can be made for BBS and peer to peer connections,
> particularly if you want something that can meet the needs of public
> service/emergency communication.

Some sort of input is necessary, as MultiPSK can be used as modem for
KISS streams. I have not enough details about Winmor to understand what
it packs and what it misses.

> E-mail can be helpful, but peer connections are vital, and BBS of
> great value in order to time shift.
> 
> If there was a BBS system that could use low/no cost sound card
> adaptive modes for HF and/or VHF, I think it would be popular.

I think likewise.

> I personally would be one of the first to support such a system. This
> is currently a large "hole" in what we need since the packet systems
> have mostly been discontinued. The key is to have at least a local
> BBS system that can work over a moderate distance of perhaps 30 to 50
> miles on VHF (or more) and up to a few hundred miles on HF.

...in order to regain what has been lost. BBS's here, beyond allowing
local contacts, also allowed to access the worldwide packet network,
which was a window to the ham world.

73,

Jose, CO2JA

Re: [digitalradio] RE:Packet radio with sound card

[Rick W]

SCAMP had no problem at all with the switching times from the testing I 
did. As a former Amtor and Pactor user from years earlier, it proved to 
me that my concerns about switching were unwarranted. Then along comes 
RFSM2400 with its frequent switching back and forth to maintain a link, 
even with no data flow, and you realize that computers can switch in a 
few tens of milliseconds, even with non-real time operating systems. Try 
toggling the PTT control with a typical multimode program and see how 
fast you can switch back and forth. It is not all that slow. I am 
skeptical about the "wear and tear" issue. Many rigs have QSK 
capabilities to allow switching between TX and RX many times per second. 
Even at 60 wpm with CW! So twice per second for older technology such as 
Amtor would not be that difficult to handle and new technology with less 
than one cycle per a few seconds, hardly noticeable.

Although RFSM (MIL-STD 188-110A) can not be used in the HF RTTY/Data 
U.S. bands due to the high baud rate, other MIL-STD parallel tone modems 
could, even though it is not something that common. One of the methods 
would be to use some of the SCAMP technology and leverage it with the 
newer non RFDT modulation of SSTV/data such as QAM and do it with on the 
fly ARQ instead of manually after the completion of the transmission as 
it is done now with most of these programs.

 From my understanding that is what Winmor effectively does, plus it 
will have the necessary adaptive technology for ramping speeds up and 
down for conditions. This is something that any new, successful 
messaging system MUST have to succeed. The big question for the future 
is how open Winmor will be so that other adaptations can be made for BBS 
and peer to peer connections, particularly if you want something that 
can meet the needs of public service/emergency communication.  E-mail 
can be helpful, but peer connections are vital, and BBS of great value 
in order to time shift.

If there was a BBS system that could use low/no cost sound card adaptive 
modes for HF and/or VHF, I think it would be popular. I personally would 
be one of the first to support such a system. This is currently a large 
"hole" in what we need since the packet systems have mostly been 
discontinued. The key is to have at least a local BBS system that can 
work over a moderate distance of perhaps 30 to 50 miles on VHF (or more) 
and up to a few hundred miles on HF.

73,

Rick, KV9U




José A. Amador wrote:
>
> Examples of tight timing and succesful implementation are P-II and 
> P-III, not only AMTOR, with its hair raising clicking
>
> I never tried SCAMP, which seemingly did well running under Windows. 
> Actually, I have entrenched on my mind what
> gave me good results, but certainly, that may not be the only way for 
> success, I have to admit.
>
> Examples of the success of tight timing are WSPR and WSJT, and  
> certainly, knowing WHEN to expect input  is a bonus.
> None of them generate such a high wear and tear. WHEN may be absolute, 
> like in WSJT, related to the UTC time scale,
> or relative, in some time measure after the last received packet.
>
> I have had little luck with RFSM8000,  because of  my perennial lack of 
> time in recent times and the little user mass it has generated.
>
> - - - 
>
> It was a way, which certainly, has been proven not to be the only one. 
> You cannot entirely disegard trends, that may vary in time.
>
> I was the sysop of three BBS's at a time, on MSDOS (even with Desqview 
> "multitasking"),  Linux and Windows (the last one was a quick hack and 
> an exercise in lazyness) and I liked BBS's.
>
> Forwarding over radio links, with all the freedoms it provides, and some 
> associated extra responsibilities too. But I fail to see the comeback of 
> the BBS's.
> Winlink may be useful, but it hardly substiututes the "packet" network 
> the way it operated in the 90's.
>
> I have very good memories of the Linux based systems I ran (node, FBB, 
> JNOS, DXNET), both were highly resilient and almost bulletproof. Uptime 
> was usually more than 30 days, and the PC's ran without battery backups. 
> I always used hardware TNC's, Kantronics and SCS.
>
> Pactor allowed 1 MB per day of forwarding on HF easily. Packet (300 
> baud) hardly ever exceeded 100 kb per day.
>
> 73,
>
> Jose, CO2JA
>
>
>
>
>
>
>
>
> 
>
> Announce your digital presence via our Interactive Sked Page at
> http://www.obriensweb.com/sked
>
>
>
> Yahoo! Groups Links
>
>
>
> 
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.9.19/1853 - Release Date: 12/17/2008 
> 8:31 AM
>
>   

Re: [digitalradio] RE:Packet radio with sound card

[José A. Amador]

Howard Brown escribió:

>  GM Jose,
>
>  There is one point in your post I would like to bring up. Where you
>  say:
>
>  >"Multitasking cannot handle tight ARQ timing windows.
>
>  >It is a pity that noone has come forward (as far as I know) a real
>  >time OS (RTL, for instance) with a proposal usable on an old PC as
>  >packet engine with a sound card as modem. The problem is not the PC
>  >itself, but the prevalent OS's."
>
>  Why not challenge the need for the tight timing windows?  This
>  creates more wear and tear and the radio but what real benefit does
>  it provide?  I believe that the NBEMS package and the RFSM8000
>  package prove that you can have effective ARQ without the fast
>  switching.

Examples of tight timing and succesful implementation are P-II and 
P-III, not only AMTOR, with its hair raising clicking

I never tried SCAMP, which seemingly did well running under Windows. 
Actually, I have entrenched on my mind what
gave me good results, but certainly, that may not be the only way for 
success, I have to admit.

Examples of the success of tight timing are WSPR and WSJT, and  
certainly, knowing WHEN to expect input  is a bonus.
None of them generate such a high wear and tear. WHEN may be absolute, 
like in WSJT, related to the UTC time scale,
or relative, in some time measure after the last received packet.

I have had little luck with RFSM8000,  because of  my perennial lack of 
time in recent times and the little user mass it has generated.

>  I would love to see Linux used more and not need to deal with Windows 
but still, the quick switching seems to be of little value.

It was a way, which certainly, has been proven not to be the only one. 
You cannot entirely disegard trends, that may vary in time.

I was the sysop of three BBS's at a time, on MSDOS (even with Desqview 
"multitasking"),  Linux and Windows (the last one was a quick hack and 
an exercise in lazyness) and I liked BBS's.

Forwarding over radio links, with all the freedoms it provides, and some 
associated extra responsibilities too. But I fail to see the comeback of 
the BBS's.
Winlink may be useful, but it hardly substiututes the "packet" network 
the way it operated in the 90's.

I have very good memories of the Linux based systems I ran (node, FBB, 
JNOS, DXNET), both were highly resilient and almost bulletproof. Uptime 
was usually more than 30 days, and the PC's ran without battery backups. 
I always used hardware TNC's, Kantronics and SCS.

Pactor allowed 1 MB per day of forwarding on HF easily. Packet (300 
baud) hardly ever exceeded 100 kb per day.

73,

Jose, CO2JA

Re: [digitalradio] RE:Packet radio with sound card

[Rick W]

The closer you are to the MUF with a path between two points often 
results in the most stable path. That is why HF packet worked well 
during peak times of the sunspot cycle where higher frequencies, 
especially 10 meters worked very well.

I have used fldigi on both Windoze and Linsux operating systems and also 
include flarq for ARQ testing. It seems a bit unwieldly to me and I have 
not had much success in getting others to try this function. As an alpha 
tester, I am very supportive and impressed with fldigi which is the only 
cross platform multi-mode digital program. It does not have any BBS 
features, but like you point out, if someone implemented these features 
into a local BBS system ...

73,

Rick, KV9U


Toby Burnett wrote:
> Rick , 
> Just on a side note, yep I have dabbled on HF packet, just connecting to
> european nodes etc. Never had much success, I'd have thought NVIS on 80m be
> quite good. 
> Anyway there are some promising HF sound card ARQ modes coming out at the
> moment, 
> Like psk mail and flarq for FL digi (even windoze version).  Surly some of
> these ARQ modes could be implemented into a local BBS system somehow.  Just
> thinking out loud. 
> Regards
> Merry Xmas everyone from Dark Winter Scotland.
>
> Toby MM0TOB
>   

Re: [digitalradio] RE:Packet radio with sound card

[Howard Brown]

GM Jose,

There is one point in your post I would like to bring up. Where you say:

"Multitasking cannot handle tight ARQ timing windows.

It is a pity that noone has come forward (as far as I know) a real time OS 
(RTL, for instance) with a proposal 
usable on an old PC as packet engine with a sound card as modem. The problem is 
not the PC itself, but the 
prevalent OS's."

Why not challenge the need for the tight timing windows?  This creates more 
wear and tear and the radio but what real benefit does it provide?  I believe 
that the NBEMS package and the RFSM8000 package prove that you can have 
effective ARQ without the fast switching.

I would love to see Linux used more and not need to deal with Windows but 
still, the quick switching seems to be of little value.

Howard K5HB




From: José A. Amador 
To: digitalradio@yahoogroups.com
Sent: Wednesday, December 17, 2008 10:16:32 AM
Subject: Re: [digitalradio] RE:Packet radio with sound card


Rick W escribió:
> Similarly, I have used Multipsk's packet modes on both HF and VHF with 
> success. With the advance of technology, I moved away from packet around 
> 15 years ago! It is just not robust enough for HF and can only go a 
> short distance on VHF, compared with newer modes
> 
I moved from HF 300 baud packet to Pactor (PTC-II) ten years ago. It 
meant a tenfold increase in forwarding thruput,
with ten times less power. About a hundredfold improvement. ..
> What seems like an unfulfilled need is a framework similar to packet, 
> with the ability to insert different modes as they are developed. You 
> would not have to keep inventing the wheel over and over.
> 
My feeling is that even when the modulation/signalli ng speed was quite 
less than optimal, the network worked.
(Runing a network costs, but there existed a will to keep it going. Life 
is more expensive nowadays)

The Achilles heel has been the radio channel access method.
> This would mostly have practical value for groups that want to set up a 
> BBS system. For example, I have monitored the packets on an 80 meter BBS 
> here in my state where most of the transmissions are retries. And this 
> is during the day under NVIS conditions. 
NVIS has the longest time spread of all ionospheric propagation modes. 
Even 300 baud can be too fast at times.
> A much more robust mode needs 
> to be used.  Then you would be able to send and receive direct or time 
> shifted messages. This is the one thing we can not do with any other 
> system, but there does not seem to be any interest in developing such a 
> system.
> 
It is EASIER with the Internet...as long as it is up.
> At this time, it is true that a slower baud rate packet system could be 
> used, such as the software 110 baud speed available in Multipsk. This is 
> why hardware packet TNC's are a poor choice for our advancing technology 
> and why almost no one uses them anymore. 
Rick, I do not agree with this. My feeling is that manufacturers took the easy 
way out 
with a stagnant product, and the market fell on its knees because of lack of 
innovation.
With a market scale vision, hams are not a profitable market.

SCS has the merit of distributing easily flashable firmware updates. Who else 
has done so?

Of course, with a CPU running a single task... ("Real men use hardware 
TNC's..." 8-) ) 

MultiPSK has the merit of being a working option at less than 300 baud. 

The sound card itself is not a panacea, when used in a multitasking (or quick 
task switching) OS. 
Multitasking cannot handle tight ARQ timing windows.

It is a pity that noone has come forward (as far as I know) a real time OS 
(RTL, for instance) with a proposal 
usable on an old PC as packet engine with a sound card as modem. The problem is 
not the PC itself, but the 
prevalent OS's. 

> You are locked into a mode 
> developed over 30 years ago with no FEC or ability to be adaptive for 
> conditions. And yet, I admit that if you want a BBS system today, what 
> other choices do you have?
>
> 73,
>
> Rick, KV9U
[snip]

Re: [digitalradio] RE:Packet radio with sound card

[Toby Burnett]

Rick , 
Just on a side note, yep I have dabbled on HF packet, just connecting to
european nodes etc. Never had much success, I'd have thought NVIS on 80m be
quite good. 
Anyway there are some promising HF sound card ARQ modes coming out at the
moment, 
Like psk mail and flarq for FL digi (even windoze version).  Surly some of
these ARQ modes could be implemented into a local BBS system somehow.  Just
thinking out loud. 
Regards
Merry Xmas everyone from Dark Winter Scotland.

Toby MM0TOB
 
---Original Message--- 
 
From: Rick W 
Date: 17/12/2008 14:59:31 
To: digitalradio@yahoogroups.com 
Subject: Re: [digitalradio] RE:Packet radio with sound card 
 
Similary, I have used Multipsk's packet modes on both HF and VHF with 
Success. With the advance of technology, I moved away from packet around 
15 years ago! It is just not robust enough for HF and can only go a 
Short distance on VHF, compared with newer modes 
 
What seems like an unfulfilled need is a framework similar to packet, 
With the ability to insert different modes as they are developed. You 
Would not have to keep inventing the wheel over and over. 
 
This would mostly have practical value for groups that want to set up a 
BBS system. For example, I have monitored the packets on an 80 meter BBS 
Here in my state where most of the transmissions are retries. And this 
Is during the day under NVIS conditions. A much more robust mode needs 
To be used. Then you would be able to send and receive direct or time 
Shifted messages. This is the one thing we can not do with any other 
System, but there does not seem to be any interest in developing such a 
System. 
 
At this time, it is true that a slower baud rate packet system could be 
Used, such as the software 110 baud speed available in Multipsk. This is 
Why hardware packet TNC's are a poor choice for our advancing technology 
And why almost no one uses them anymore. You are locked into a mode 
Developed over 30 years ago with no FEC or ability to be adaptive for 
Conditions. And yet, I admit that if you want a BBS system today, what 
Other choices do you have? 
 
73, 
 
Rick, KV9U 
 
Bev & Jerry Chambers wrote: 
> I have used MixW for packet, both on 2 meters and on HF and found it 
> to work fine. 
> 
> Jerry - W6LQR 
> 
> 
> __ 
> Plan ahead with a quick and convenient rental car. Click now. 
> <http://thirdpartyoffers.Juno
com/TGL2142/fc/PnY6rw2i4Kl14diV4YFfqj9NVa0ZLTLXxwC4c6Z897wGFONyq2THo/> 
> -- 
> 
> 
> No virus found in this incoming message. 
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.9.19/1853 - Release Date:
12/17/2008 8:31 AM 
> 
> 
 
 
 
 

Re: [digitalradio] RE:Packet radio with sound card

[José A. Amador]

Rick W escribió:
> Similarly, I have used Multipsk's packet modes on both HF and VHF with 
> success. With the advance of technology, I moved away from packet around 
> 15 years ago! It is just not robust enough for HF and can only go a 
> short distance on VHF, compared with newer modes
>   
I moved from HF 300 baud packet to Pactor (PTC-II) ten years ago. It 
meant a tenfold increase in forwarding thruput,
with ten times less power. About a hundredfold improvement...
> What seems like an unfulfilled need is a framework similar to packet, 
> with the ability to insert different modes as they are developed. You 
> would not have to keep inventing the wheel over and over.
>   
My feeling is that even when the modulation/signalling speed was quite 
less than optimal, the network worked.
(Runing a network costs, but there existed a will to keep it going. Life 
is more expensive nowadays)

The Achilles heel has been the radio channel access method.
> This would mostly have practical value for groups that want to set up a 
> BBS system. For example, I have monitored the packets on an 80 meter BBS 
> here in my state where most of the transmissions are retries. And this 
> is during the day under NVIS conditions. 
NVIS has the longest time spread of all ionospheric propagation modes. 
Even 300 baud can be too fast at times.
> A much more robust mode needs 
> to be used.  Then you would be able to send and receive direct or time 
> shifted messages. This is the one thing we can not do with any other 
> system, but there does not seem to be any interest in developing such a 
> system.
>   
It is EASIER with the Internet...as long as it is up.
> At this time, it is true that a slower baud rate packet system could be 
> used, such as the software 110 baud speed available in Multipsk. This is 
> why hardware packet TNC's are a poor choice for our advancing technology 
> and why almost no one uses them anymore. 
Rick, I do not agree with this. My feeling is that manufacturers took the easy 
way out 
with a stagnant product, and the market fell on its knees because of lack of 
innovation.
With a market scale vision, hams are not a profitable market.

SCS has the merit of distributing easily flashable firmware updates. Who else 
has done so?

Of course, with a CPU running a single task... ("Real men use hardware 
TNC's..." 8-) ) 

MultiPSK has the merit of being a working option at less than 300 baud. 

The sound card itself is not a panacea, when used in a multitasking (or quick 
task switching) OS. 
Multitasking cannot handle tight ARQ timing windows.

It is a pity that noone has come forward (as far as I know) a real time OS 
(RTL, for instance) with a proposal 
usable on an old PC as packet engine with a sound card as modem. The problem is 
not the PC itself, but the 
prevalent OS's. 


> You are locked into a mode 
> developed over 30 years ago with no FEC or ability to be adaptive for 
> conditions. And yet, I admit that if you want a BBS system today, what 
> other choices do you have?
>
> 73,
>
> Rick, KV9U
>
>
> Bev & Jerry Chambers wrote:
>   
>> I have used MixW for packet, both on 2 meters and on HF and found it 
>> to work fine.
>>  
>> Jerry - W6LQR
>>
>>
>> 

73,

Jose, CO2JA

Re: [digitalradio] RE:Packet radio with sound card (thanks to all)

[Russell Blair]

Thanks for your input, I do have MultiPSK and will look into as well I will 
look into MixW, Yes to your responces with all the other modes provided from 
other programs, However I am looking at Satelitte Packet 1200 , So tnx agn 73 
 
Russell


 
= 
IN GOD WE TRUST ! 
= 
Russell Blair (NC5O)
Skype-Russell.Blair
Hell Field #300
DRCC #55
30m Dig-group #693

--- On Wed, 12/17/08, Rick W  wrote:

From: Rick W 
Subject: Re: [digitalradio] RE:Packet radio with sound card
To: digitalradio@yahoogroups.com
Date: Wednesday, December 17, 2008, 8:58 AM






Similary, I have used Multipsk's packet modes on both HF and VHF with 
success. With the advance of technology, I moved away from packet around 
15 years ago! It is just not robust enough for HF and can only go a 
short distance on VHF, compared with newer modes

What seems like an unfulfilled need is a framework similar to packet, 
with the ability to insert different modes as they are developed. You 
would not have to keep inventing the wheel over and over.

This would mostly have practical value for groups that want to set up a 
BBS system. For example, I have monitored the packets on an 80 meter BBS 
here in my state where most of the transmissions are retries. And this 
is during the day under NVIS conditions. A much more robust mode needs 
to be used. Then you would be able to send and receive direct or time 
shifted messages. This is the one thing we can not do with any other 
system, but there does not seem to be any interest in developing such a 
system.

At this time, it is true that a slower baud rate packet system could be 
used, such as the software 110 baud speed available in Multipsk. This is 
why hardware packet TNC's are a poor choice for our advancing technology 
and why almost no one uses them anymore. You are locked into a mode 
developed over 30 years ago with no FEC or ability to be adaptive for 
conditions. And yet, I admit that if you want a BBS system today, what 
other choices do you have?

73,

Rick, KV9U

Bev & Jerry Chambers wrote:
> I have used MixW for packet, both on 2 meters and on HF and found it 
> to work fine.
> 
> Jerry - W6LQR
> 
>
>  _ _ _ _ _ _
> Plan ahead with a quick and convenient rental car. Click now. 
> <http://thirdpartyof fers.juno. com/TGL2142/ fc/PnY6rw2i4Kl14 
> diV4YFfqj9NVa0ZL TLXxwC4c6Z897wGF ONyq2THo/>
>  - - - - - -
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg. com 
> Version: 8.0.176 / Virus Database: 270.9.19/1853 - Release Date: 12/17/2008 
> 8:31 AM
>
> 

 














  

Re: [digitalradio] RE:Packet radio with sound card

[Rick W]

Similary, I have used Multipsk's packet modes on both HF and VHF with 
success. With the advance of technology, I moved away from packet around 
15 years ago! It is just not robust enough for HF and can only go a 
short distance on VHF, compared with newer modes

What seems like an unfulfilled need is a framework similar to packet, 
with the ability to insert different modes as they are developed. You 
would not have to keep inventing the wheel over and over.

This would mostly have practical value for groups that want to set up a 
BBS system. For example, I have monitored the packets on an 80 meter BBS 
here in my state where most of the transmissions are retries. And this 
is during the day under NVIS conditions. A much more robust mode needs 
to be used.  Then you would be able to send and receive direct or time 
shifted messages. This is the one thing we can not do with any other 
system, but there does not seem to be any interest in developing such a 
system.

At this time, it is true that a slower baud rate packet system could be 
used, such as the software 110 baud speed available in Multipsk. This is 
why hardware packet TNC's are a poor choice for our advancing technology 
and why almost no one uses them anymore. You are locked into a mode 
developed over 30 years ago with no FEC or ability to be adaptive for 
conditions. And yet, I admit that if you want a BBS system today, what 
other choices do you have?

73,

Rick, KV9U


Bev & Jerry Chambers wrote:
> I have used MixW for packet, both on 2 meters and on HF and found it 
> to work fine.
>  
> Jerry - W6LQR
> 
>
> 
> Plan ahead with a quick and convenient rental car. Click now. 
> 
> 
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.9.19/1853 - Release Date: 12/17/2008 
> 8:31 AM
>
>