Re: [digitalradio] Olivia

[Rick W]

Hi John,

WINMOR is an open protocol, therefore it is up to the developers as to 
what they want to use it for. I personally prefer open protocols because 
of this, but far be it for me to tell others how they can or can not use 
a given protocol.

The current developers have designed the protocol to compete with Pactor 
modes. Preliminary information says that it will outperform Pactor, and 
be fairly competitive with Pactor 2, although at a much wider bandwidth, 
similar to Pactor 3.

Unlike Pactor, WINMOR will have the ability to work within 200 Hz, 500 
Hz, and ~ 2000 Hz bandwidths so that it can be used within the IARU band 
plans.

And unlike Pactor 2 and 3, the modes are not including PSK100. We know 
that PSK modes are susceptible to ionospheric instabilities, 
particularly if they do not have training pulses. If you have looked at 
the very interesting mode specifications, WINMOR may have some of this 
newer technology.

I have never seen any tests from SCS as to how much ISI/multipath or 
Doppler the Pactor modes can tolerate, but I suspect not very much. (Dr. 
Rink claimed some years ago that it could handle most paths well enough 
with their DSP, but I suspect that there are cases where the signal 
strengths are good but Pactor can not work and yet other modes can.

As it progresses over the years, there is no reason that WINMOR can not 
be constantly improved. Unlike a proprietary lock in with a 
hardware/firmware system, it would be possible to update to newer modes 
just by downloading new free software. In fact, I would expect that to 
happen.

While I don't see hams using it for casual chatting, but it could be 
done similar to how we used to use Amtor and even Pactor in the "old 
days," HI.

What I would like to see is the ability to have a superior ARQ sound 
card mode that can scale speed up or down to meet conditions and do this 
automatically without user intervention. Since one of my interests is 
pubic service, if peer to peer connections were designed into the 
software, you would be able to connect to another station under varying 
conditions and communicate directly from keyboard and send files as 
needed. Ability to connect to an e-mail server may be useful, however 
the first two needs must be met to be of value for local and regional 
digital communication. And that is something we don't have available to 
us at the moment.

73,

Rick, KV9U

John Becker, WØJAB wrote:
> Rick
> I feel you think that winmor was intended to be a chat mode.
> It was not and is not nor a replacement for pactor.
>
> John
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
>
> Announce your digital presence via our Interactive Sked Pages at
> http://www.obriensweb.com/sked
>
> Recommended digital mode software:  Winwarbler, FLDIGI, DM780, or Multipsk
> Logging Software:  DXKeeper or Ham Radio Deluxe.
>
>
>
> Yahoo! Groups Links
>
>
>
> 
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.0.238 / Virus Database: 270.12.10/2088 - Release Date: 04/30/09 
> 06:01:00
>
>   

[digitalradio] 10 meter Es now

[Tony]

All,

Sporadic-E opening on 10 meters towards the south as of 23:20z. Few 
Caribbean stations on the band...

KP3FT beacon loud and clear on 28222.5

Tony -K2MO 

Re: [digitalradio] Olivia

[John Becker, WØJAB]

Rick
I feel you think that winmor was intended to be a chat mode.
It was not and is not nor a replacement for pactor.

John

Re: [digitalradio] Olivia

[Sholto Fisher]

I've found the 1000Hz 8 tone waveform to be very good also. Nice 
throughput and still plenty sensitive enough for many conditions.

Had a nice chat to KC5CAY in 8 tone Contestia today and that worked very 
well, if a little fast.

I have the radio on 14072.5 USB if anyone wants to experiment with any 
of these modes. If possible enable your RS ID.

K7TMG

Tony wrote:
> 
> 
> 
> Rick,
>  
>  > It is easy to determine the BW, but not so easy for the  number of 
> tones.
>  
> The RSID would come in handy for this, but I don't feel it's 
> difficult to determine the number of tones. The 500Hz mode seems to be 
> the standard and it's rare to see anyone using more than 16 tones. C 
> licking through 8, 4 and 2 tones will usually find the correct 
> combination quickly.
>  
>  > operators who have slower keyboarding skills have told me that 
> they find that the 19 or 29
>  > wpm of Olivia 500/16 and 500/8 to be a good fit.
>  
> I agree - the 500/8 mode strikes a good balance between speed and 
> throughput under most conditions. I asked Simon to include 500/8 as one 
> of the point-n-click modes in DM780.
>  
>  > the faster Olivia modes may not work as well as other modes, 
> particularly MFSK16 which is > also much faster (~ 40 wpm)
>  
> True - c utting the number of Olivia tones will cause a slight degrease 
> in the robust quality of the mode in exchange for speed. But there are 
> times when this will not effect throughput, i.e., moderate to good 
> signal quality / stability.
>  
> Re: Winmore
>  
> I'm not so sure that this mode can compete with robust MFSK modes like 
> Olivia. As you say, it wasn't intended to be used as a chat mode so it 
> seems we might be mixing apples and oranges by trying to compare the two.
>  
> Thanks for the comments Rick...
>  
> Tony -K2MO
> 
>  
>  
> 
>  
>  
>  
>  
> - Original Message -
> From: "Rick W" < mrf...@frontiernet. net  >
> To: < digitalradio@ yahoogroups. com 
>  >
> Sent: Thursday, April 30, 2009 9:40 AM
> Subject: Re: [digitalradio] Olivia
> 
>  >I think that the reasons that we tend to gravitate toward a given Olivia
>  > speed/bandwidth:
>  >
>  > - need a "standard" to find others on the air. It is easy to determine
>  > the BW, but not so easy for the number of tones.
>  > - if you use a non-standard speed to start with, you will have a
>  > difficult time finding anyone at all (speaking from experience, HI)
>  > - once you make contact, switching to different speeds/modes is not
>  > always that easy to do with some operators
>  > - it is probably best to start off with a robust subset of a mode and go
>  > faster if you need to do this, with the plan to return to the robust
>  > mode if faster ones don't work, but it can be a bit awkward
>  > - operators who have slower keyboarding skills have told me that they
>  > find that the 19 or 29 wpm of Olivia 500/16 and 500/8 to be a good fit
>  > - I can see where the slower modes of Olivia can be useful for really
>  > difficult conditions such as short DX type contacts or for critical
>  > public service messaging, but for casual use, the faster Olivia modes
>  > may not work as well as other modes, particularly MFSK16 which is also
>  > much faster (~ 40 wpm)
>  >
>  > Also, it is possible that eventually someone might be willing to come up
>  > with a program that will use a protocol that can adapt to conditions.
>  > Simon mentioned WINMOR which is the only possible protocol that can .
>  > This is the serious shortcoming of sound card modes thus far since
>  > nothing currently available can automatically scale speed and robustness
>  > to meet conditions. The closest thing we had for a short time was SCAMP
>  > and the ratio of speeds was fairly limited due to not being very robust
>  > at the slowest speed. But WINMOR should help a great deal in moving the
>  > bar higher. But from what I can tell, the WINMOR program from the
>  > developer is not intended to be used peer to peer, only for e-mail. That
>  > won't help most of us who are primarily interested in public
>  > service/emergency communication between operators at various locations.
>  >
>  > As some have found out the hard way, you don't design service/emergency
>  > communications to be sent via e-mail since you make a very dangerous
>  > assumption that the internet will be operational.
>  >
>  > At this time, the only options we have for ARQ keyboarding and messaging
>  > are packet and FAE modes but as technology advances maybe that one
>  > person will be able to develop the killer app for public service?
>  >
>  > Imagine if a program like PSKmail, which has peer to peer capability
>  > (not yet available for MS Windows), switched to an adaptable mode such
>  > as WINMOR.
>  >
>  > 73,
>  >
>  > Rick, KV9U
>  >
>  >
>  >
>  > Tony wrote:
>  >>
>  >>
>  >> All,
>  >> 
>  >> I'm not sure why, but it seems that most of us tend to stick with the
>  >> slowe

Re: [digitalradio] Olivia

[Tony]

Rick,

> It is easy to determine the BW, but not so easy for the number of tones.

The RSID would come in handy for this, but I don't feel it's difficult to 
determine the number of tones. The 500Hz mode seems to be the standard and it's 
rare to see anyone using more than 16 tones. Clicking through 8, 4 and 2 tones 
will usually find the correct combination quickly.

> operators who have slower keyboarding skills have told me that they find that 
> the 19 or 29
> wpm of Olivia 500/16 and 500/8 to be a good fit. 

I agree - the 500/8 mode strikes a good balance between speed and throughput 
under most conditions. I asked Simon to include 500/8 as one of the 
point-n-click modes in DM780. 

> the faster Olivia modes may not work as well as other modes, particularly 
> MFSK16 which is > also much faster (~ 40 wpm)

True - cutting the number of Olivia tones will cause a slight degrease in the 
robust quality of the mode in exchange for speed. But there are times when this 
will not effect throughput, i.e., moderate to good signal quality / stability.

Re: Winmore

I'm not so sure that this mode can compete with robust MFSK modes like Olivia. 
As you say, it wasn't intended to be used as a chat mode so it seems we might 
be mixing apples and oranges by trying to compare the two. 

Thanks for the comments Rick... 

Tony -K2MO










- Original Message - 
From: "Rick W" 
To: 
Sent: Thursday, April 30, 2009 9:40 AM
Subject: Re: [digitalradio] Olivia


>I think that the reasons that we tend to gravitate toward a given Olivia 
> speed/bandwidth:
> 
> - need a "standard" to find others on the air. It is easy to determine 
> the BW, but not so easy for the number of tones.
> - if you use a non-standard speed to start with, you will have a 
> difficult time finding anyone at all (speaking from experience, HI)
> - once you make contact, switching to different speeds/modes is not 
> always that easy to do with some operators
> - it is probably best to start off with a robust subset of a mode and go 
> faster if you need to do this, with the plan to return to the robust 
> mode if faster ones don't work, but it can be a bit awkward
> - operators who have slower keyboarding skills have told me that they 
> find that the 19 or 29 wpm of Olivia 500/16 and 500/8 to be a good fit
> - I can see where the slower modes of Olivia can be useful for really 
> difficult conditions such as short DX type contacts or for critical 
> public service messaging, but for casual use, the faster Olivia modes 
> may not work as well as other modes, particularly MFSK16 which is also 
> much faster (~ 40 wpm)
> 
> Also, it is possible that eventually someone might be willing to come up 
> with a program that will use a protocol that can adapt to conditions. 
> Simon mentioned WINMOR which is the only possible protocol that can . 
> This is the serious shortcoming of sound card modes thus far since 
> nothing currently available can automatically scale speed and robustness 
> to meet conditions. The closest thing we had for a short time was SCAMP 
> and the ratio of speeds was fairly limited due to not being very robust 
> at the slowest speed. But WINMOR should help a great deal in moving the 
> bar higher. But from what I can tell, the WINMOR program from the 
> developer is not intended to be used peer to peer, only for e-mail. That 
> won't help most of us who are primarily interested in public 
> service/emergency communication between operators at various locations.
> 
> As some have found out the hard way, you don't design service/emergency 
> communications to be sent via e-mail since you make a very dangerous 
> assumption that the internet will be operational.
> 
> At this time, the only options we have for ARQ keyboarding and messaging 
> are packet and FAE modes but as technology advances maybe that one 
> person will be able to develop the killer app for public service?
> 
> Imagine if a program like PSKmail, which has peer to peer capability 
> (not yet available for MS Windows), switched to an adaptable mode such 
> as WINMOR.
> 
> 73,
> 
> Rick, KV9U
> 
> 
> 
> Tony wrote:
>>
>>
>> All,
>>  
>> I'm not sure why, but it seems that most of us tend to stick with the 
>> slower versions of Olivia
>> even when conditions allow for much faster throughput. The more robust 
>> tone-bandwidth combinations seem overkill when the path is stable so 
>> why go slow?
>>  
>> I sometimes test the waters by reducing the number of tones 
>> (regardless of bandwidth) to speed things up. One can always increase 
>> the tones again if conditions change for the worse.
>>  
>> It would be a neat to see some kind of "throughput sensing" where the 
>> speed of the mode changed to suit conditions automatically.
>>  
>> Maybe an RSID-like preamble that automatically switched the other 
>> stations software to the best mode based on the last over.
>>  
>> Tony -K2MO
>>
>>
>> 
>> 

Re: [digitalradio] The next big thing - Using Swarm Intelligence

[Simon (HB9DRV)]

- Original Message - 
From: "David" 
>
> We can design it as a community.
>

There are a couple of Ham Radio community projects I follow which have 
collapsed or at least stopped moving forwards simply because they are 
community projects where the problems with self-elected experts / community 
leaders annoy the other members.

There is no doubt that the Ham community has some outstanding engineers - 
N8VB, W1JT and G3PLX to name three - and their results are very much the 
result of their work with assistance from someone else as needed.

On the other hand I use free community software such a DotNetNuke where 
community collaboration has really worked and one-man software such a 
FileZilla.

Simon Brown, HB9DRV
www.ham-radio-deluxe.com 

Re: [digitalradio] The next big thing - Using Swarm Intelligence

[Simon (HB9DRV)]

Look at the WINMOR specs and coding - at the moment this may be the 
solution.

Simon Brown, HB9DRV
www.ham-radio-deluxe.com

- Original Message - 
From: "David" 
>
> Where am I going with this? Why do we have to wait for someone to invent 
> the better mouse trap?  We can design it as a community. Perhaps its time 
> for us as a community to develop the specifications for this "next big 
> thing." and send it out to the ether for programmers and technologist to 
> build.
> 

RE: [digitalradio] The next big thing - Using Swarm Intelligence

[Dave AA6YQ]

The approach you're suggesting is referred to as "crowdsourcing", not "swarm
intelligence".

http://en.wikipedia.org/wiki/Swarm_intelligence

http://en.wikipedia.org/wiki/Crowdsourcing

We have been using a form of crowdsourcing to drive the development of DXLab
for the last 9 years. It works well.

 73,

  Dave, AA6YQ


-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of David
Sent: Thursday, April 30, 2009 11:21 AM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] The next big thing - Using Swarm Intelligence





Excuse the newbie's lack of knowledge, but...

Rapid expansion followed by slow consolidation. This is the way of business
and technology. What we have been seeing over the last decade or so is the
rapid expansion (diversity) of digital communications schemas. Eventually,
market forces will prune the tree and only a few major branches will be
left. Some minor branches will survive as museum pieces used by a small
"collector-antique" community. Alternatively, a new digital mode that will
either be superior to all others, or will dominate others, as to create a
barrir to entry in the market. For example, when Windows and MAC took over
the personal computer OS market.

Where am I going with this? Why do we have to wait for someone to invent the
better mouse trap? We can design it as a community. Perhaps its time for us
as a community to develop the specifications for this "next big thing." and
send it out to the ether for programmers and technologist to build.

Specifications:

1. Simple and easy to hook-up for the average computer user. Ideally only
requires software, cables, and the Ham's existing transceiver.
2. Inexpensive
3. Open source code and documentation
4. Excellent documentation within source code and within manuals
5. Able scan beacon's and make suggestions for the best mode of operation
given the users frequency.
6. Consists of a set of communications protocals and methods to enable it to
determine the best format to use given bandwidth, power, band noise,
information density, etc.
7. Uses low-bandwidth low baud rates for initial contact and then quickly
shifts through machine-to-machine communication to establish the best
connection using the best communications schema given the conditions.
8. Can repair bits.
9. Uses standardized tokens to send and recieve often used letters, words,
or phrases between machines.
10. Can send any combination of text, images, and speech within the same
transmission given enough bandwidth.
11. Can enable the connection of many different Hams in one call working at
the same time.
12. Can interface with standard logging software.

Well here are the first dozen from an inexperienced newbie that believes in
Swarm Intelligence. Perhaps if we all write a solid Specifications document
we could next pool money and create a prize to the group that can create the
first robust solution for us. Well enough of my soapboxing.

73

Re: [digitalradio] Re: Olivia

[Rick W]

Jim,

I agree with you completely about Clover II. Some years back, when I 
would call CQ, I would sometimes get a connection with Ray Petit, W7GHM, 
(the inventor of CCW, Clover and Clover II), but with our distance and 
dipole antennas, could rarely do much more than trade the path 
information, HI.

Clover II just did not have a robust enough mode, which was somewhat 
surprising since the base modulation was 4 PSK31 tones. At the time the 
Winlink system used both Clover II and Pactor (some Amtor until that was 
phased out), but when they switched over to the Winlink 2000 internet 
based e-mail system, they dropped Clover II support so that really 
decreased use of the mode.

WINMOR is an openly published protocol (perhaps not quite finalized yet) 
that anyone will be able to develop if they have the ability and 
interest to do so. This means it could be used in existing programs or 
even in a new program that would insure ARQ and adaptability for peer to 
peer communication. 

This is vital for those of us who have a serious interest in public 
service/emergency communications. We primarily need the ability to 
connect to other stations on a peer to peer basis, but having e-mail 
access to the internet can also be useful, assuming the internet is 
working where you need to move traffic.

Based on the protocols for WINMOR, I wonder if it will sometimes be more 
robust than Pactor modes of which the most robust, even with P3 is 2 
PSK100 tones separated by about 700 Hz. I have never seen any published 
information on the tolerance for ISI and Doppler and I suspect it may 
not be all that much based upon Tony's results with various modes.

73,

Rick, KV9U

jhaynesatalumni wrote:
> --- In digitalradio@yahoogroups.com, "Simon \(HB9DRV\)"  
> wrote:
>   
>> Would not WINMOR be an option here?
>>
>> 
> Well, except that WINMOR seems to be single-mindedly a message
> passing mode.  I wish there was some layering so that the modulation
> means and the error correcting means and the message passing were
> separable.  Of course adapting to varying conditions means some
> communication down through the layers, changing the modulation
> scheme when error control indicates that is needed.
>
> CLOVER had that kind of operation - trouble is that it (amateur
> version) seems to lack the ability to go downhill when conditions
> worsen - it's aggressive enough about going uphill when conditions
> permit.  Times I have used it, it would invariably get stuck
> trying to send long blocks that never made it through, when shorter
> blocks probably would have been successful.
>
> Jim W6JVE
>
>   

[digitalradio] NZ4O Daily LF/MF/HF/6M Frequency Radiowave Propagation Forecast #2009-13

[nz4o]

The NZ4O Daily LF/MF/HF/6M Frequency Radiowave Propagation Forecast #2009-13 
has been published on Thursday 04/30/2009 at 1500 UTC, valid  UTC 
Saturday 05/02/2009 through 2359 UTC Friday 05/08/2009 at 
http://www.kn4lf.com/kn4lf6.htm .

73 & GUD DX,
Thomas F. Giella, NZ4O
Lakeland, FL, USA
n...@arrl.net

NZ4O Daily Solar Space Weather & Geomagnetic Data Archive:
http://www.kn4lf.com/kn4lf5.htm
NZ4O Daily LF/MF/HF/6M Frequency Radiowave Propagation Forecast & Archive:
http://www.kn4lf.com/kn4lf6.htm
NZ4O 160 Meter Radio Propagation Theory Notes:
http://www.kn4lf.com/kn4lf8.htm
NZ4O LF/MF/HF/VHF Frequency Radiowave Propagation Email Reflector:
http://lists.contesting.com/mailman/listinfo/spaceweather
NZ4O Harmful Man Induced Climate Change (Global Warming) Refuted:
http://www.kn4lf.com/globalwarminglie.htm
 

[digitalradio] Solar Cycle 23 Sunspot Group Re-emerges

[nz4o]

Posted Thursday April 30, 2009 at http://www.kn4lf.com/kn4lf5.htm and 
http://www.kn4lf.com/kn4lf72.htm .

On Thursday solar cycle 23 sunspot group S740 re-emerged near S08W64. Today 
NOAA/SWPC assigned it #10116. Solar cycle 23 is now 13 years long from first 
spot to present one, an extension of the already record long solar cycle!!!

Besides space plasma physics I also have education in paleoclimatology, 
meteorology and oceanography. Having said that I am becoming seriously 
concerned that we are really headed for a second "Dalton Minimum" and it's 
attendant global cooling for a period of 20-30 years.

Another "Dalton Minimum" will put quite a strain on resources such as food 
and petroleum.

73 & GUD DX,
Thomas F. Giella, NZ4O
Lakeland, FL, USA
n...@tampabay.rr.com
eList Owner/Moderator

LF/MF/HF/VHF/UHF Frequency Radiowave Propagation Email Reflector: 
http://lists.contesting.com/mailman/listinfo/spaceweather
NZ4O Daily Solar Space Weather & Geomagnetic Data Archive: 
http://www.kn4lf.com/kn4lf5.htm
NZ4O Daily LF/MF/HF/6M Frequency Radiowave Propagation Forecast & Archive: 
http://www.kn4lf.com/kn4lf6.htm
NZ4O 160 Meter Radio Propagation Theory Notes: 
http://www.kn4lf.com/kn4lf8.htm

[digitalradio] Re: Olivia

[jhaynesatalumni]

--- In digitalradio@yahoogroups.com, "Simon \(HB9DRV\)"  wrote:
>
> Would not WINMOR be an option here?
> 
Well, except that WINMOR seems to be single-mindedly a message
passing mode.  I wish there was some layering so that the modulation
means and the error correcting means and the message passing were
separable.  Of course adapting to varying conditions means some
communication down through the layers, changing the modulation
scheme when error control indicates that is needed.

CLOVER had that kind of operation - trouble is that it (amateur
version) seems to lack the ability to go downhill when conditions
worsen - it's aggressive enough about going uphill when conditions
permit.  Times I have used it, it would invariably get stuck
trying to send long blocks that never made it through, when shorter
blocks probably would have been successful.

Jim W6JVE

[digitalradio] The next big thing - Using Swarm Intelligence

[David]

Excuse the newbie's lack of knowledge, but...

Rapid expansion followed by slow consolidation.  This is the way of business 
and technology.  What we have been seeing over the last decade or so is the 
rapid expansion (diversity) of digital communications schemas.  Eventually, 
market forces will prune the tree and only a few major branches will be left.  
Some minor branches will survive as museum pieces used by a small 
"collector-antique" community.   Alternatively, a new digital mode that will 
either be superior to all others, or will dominate others, as to create a 
barrir to entry in the market. For example, when Windows and MAC took over the 
personal computer OS market. 

Where am I going with this? Why do we have to wait for someone to invent the 
better mouse trap?  We can design it as a community. Perhaps its time for us as 
a community to develop the specifications for this "next big thing." and send 
it out to the ether for programmers and technologist to build.

Specifications:

1.  Simple and easy to hook-up for the average computer user.  Ideally only 
requires software, cables, and the Ham's existing transceiver. 
2.  Inexpensive
3.  Open source code and documentation
4.  Excellent documentation within source code and within manuals
5.  Able scan beacon's and make suggestions for the best mode of operation 
given the users frequency.
6.  Consists of a set of communications protocals and methods to enable it to 
determine the best format to use given bandwidth, power, band noise, 
information density, etc.
7.  Uses low-bandwidth low baud rates for initial contact and then quickly 
shifts through machine-to-machine communication to establish the best 
connection using the best communications schema given the conditions.
8.  Can repair bits.
9.  Uses standardized tokens to send and recieve often used letters, words, or 
phrases between machines.
10. Can send any combination of text, images, and speech within the same 
transmission given enough bandwidth.
11. Can enable the connection of many different Hams in one call working at the 
same time.
12. Can interface with standard logging software.

Well here are the first dozen from an inexperienced newbie that believes in 
Swarm Intelligence.  Perhaps if we all write a solid Specifications document we 
could next pool money and create a prize to the group that can create the first 
robust solution for us.  Well enough of my soapboxing.

73
  

Re: [digitalradio] Olivia

[Rick W]

I think that the reasons that we tend to gravitate toward a given Olivia 
speed/bandwidth:

- need a "standard" to find others on the air. It is easy to determine 
the BW, but not so easy for the number of tones.
- if you use a non-standard speed to start with, you will have a 
difficult time finding anyone at all (speaking from experience, HI)
- once you make contact, switching to different speeds/modes is not 
always that easy to do with some operators
- it is probably best to start off with a robust subset of a mode and go 
faster if you need to do this, with the plan to return to the robust 
mode if faster ones don't work, but it can be a bit awkward
- operators who have slower keyboarding skills have told me that they 
find that the 19 or 29 wpm of Olivia 500/16 and 500/8 to be a good fit
- I can see where the slower modes of Olivia can be useful for really 
difficult conditions such as short DX type contacts or for critical 
public service messaging, but for casual use, the faster Olivia modes 
may not work as well as other modes, particularly MFSK16 which is also 
much faster (~ 40 wpm)

Also, it is possible that eventually someone might be willing to come up 
with a program that will use a protocol that can adapt to conditions. 
Simon mentioned WINMOR which is the only possible protocol that can . 
This is the serious shortcoming of sound card modes thus far since 
nothing currently available can automatically scale speed and robustness 
to meet conditions. The closest thing we had for a short time was SCAMP 
and the ratio of speeds was fairly limited due to not being very robust 
at the slowest speed. But WINMOR should help a great deal in moving the 
bar higher. But from what I can tell, the WINMOR program from the 
developer is not intended to be used peer to peer, only for e-mail. That 
won't help most of us who are primarily interested in public 
service/emergency communication between operators at various locations.

As some have found out the hard way, you don't design service/emergency 
communications to be sent via e-mail since you make a very dangerous 
assumption that the internet will be operational.

At this time, the only options we have for ARQ keyboarding and messaging 
are packet and FAE modes but as technology advances maybe that one 
person will be able to develop the killer app for public service?

Imagine if a program like PSKmail, which has peer to peer capability 
(not yet available for MS Windows), switched to an adaptable mode such 
as WINMOR.

73,

Rick, KV9U



Tony wrote:
>
>
> All,
>  
> I'm not sure why, but it seems that most of us tend to stick with the 
> slower versions of Olivia
> even when conditions allow for much faster throughput. The more robust 
> tone-bandwidth combinations seem overkill when the path is stable so 
> why go slow?
>  
> I sometimes test the waters by reducing the number of tones 
> (regardless of bandwidth) to speed things up. One can always increase 
> the tones again if conditions change for the worse.
>  
> It would be a neat to see some kind of "throughput sensing" where the 
> speed of the mode changed to suit conditions automatically.
>  
> Maybe an RSID-like preamble that automatically switched the other 
> stations software to the best mode based on the last over.
>  
> Tony -K2MO
>
>
> 
> 
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.0.238 / Virus Database: 270.12.8/2086 - Release Date: 04/29/09 
> 06:37:00
>
>   

Re: [digitalradio] Olivia

[Simon (HB9DRV)]

Would not WINMOR be an option here?

Simon Brown, HB9DRV
www.ham-radio-deluxe.com
  - Original Message - 
  From: Tony 


  It would be a neat to see some kind of "throughput sensing" where the speed 
of the mode changed to suit conditions automatically.