RE: [digitalradio] Re: on another note

[W5XR]

I'm asking. :)
 
Bob, W5XR.


  _  

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of jhaynesatalumni
Sent: Wednesday, February 25, 2009 8:26 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: on another note



--- In digitalradio@ 
yahoogroups.com, "Patrick Lindecker" 
wrote:

> A synchronous RTTY under Windows is possible with a standard symbol 
> synchronization (with or without a PLL which can be seen as the
"digital 
> flywheel"). However, the stop bit (1.5 symbols) complicates all as
it is not 
> an integer multiple of the symbol length.
> 
> Now, RTTY must be supposed to be asynchronous to be compatible with
all RTTY 
> apparatus and programs. Let's work on more modern modes...

I did some work earlier with "compatible synchronous RTTY" using
7.00 unit start-stop code, to make it easier to synchronize.
Even mechanical TTY machines can easily receive 7.00 unit code.
I built a transmitting converter that would send the 7.00 unit
code, and insert fill characters (LTRS or FIGS) if there was
no input character available when one was called for. Another
ham was working on the receiver - I don't know if he ever got it
working.

Then years later K6STI did his "digital flywheel" and he said it
didn't matter that the character length was not an integral
multiple of the bit length so long as the character length was
constant. Which required transmitting "diddle".

But I fully agree about more modern modes. Last night I was copying
a couple of RTTY stations, pretty good copy except for QSB, and
one of them was using 1KW and the other using 500W. And back in
the glory days of RTTY we were all trying to run that kind of power.
I have a big TMC kilowatt transmitter gathering dust out with all
the TTY machines.

There is an amusing explanation for why TTY uses a 7.42 unit
code (in the U.S.) but I'll forbear to tell it unless someone
asks.

Jim W6JVE

[digitalradio] Re: on another note

[jhaynesatalumni]

--- In digitalradio@yahoogroups.com, "Patrick Lindecker" 
wrote:
 
> A synchronous RTTY under Windows is possible with a standard symbol 
> synchronization (with or without a PLL which can be seen as the
"digital 
> flywheel"). However, the stop bit (1.5 symbols) complicates all as
it is not 
> an integer multiple of the symbol length.
> 
> Now, RTTY must be supposed to be asynchronous to be compatible with
all RTTY 
> apparatus and programs. Let's work on more modern modes...

I did some work earlier with "compatible synchronous RTTY" using
7.00 unit start-stop code, to make it easier to synchronize.
Even mechanical TTY machines can easily receive 7.00 unit code.
I built a transmitting converter that would send the 7.00 unit
code, and insert fill characters (LTRS or FIGS) if there was
no input character available when one was called for.  Another
ham was working on the receiver - I don't know if he ever got it
working.

Then years later K6STI did his "digital flywheel" and he said it
didn't matter that the character length was not an integral
multiple of the bit length so long as the character length was
constant.  Which required transmitting "diddle".

But I fully agree about more modern modes.  Last night I was copying
a couple of RTTY stations, pretty good copy except for QSB, and
one of them was using 1KW and the other using 500W.  And back in
the glory days of RTTY we were all trying to run that kind of power.
I have a big TMC kilowatt transmitter gathering dust out with all
the TTY machines.

There is an amusing explanation for why TTY uses a 7.42 unit
code (in the U.S.) but I'll forbear to tell it unless someone
asks.

Jim W6JVE

Re: [digitalradio] Re: Newbie looking for a bbs packet radio

[Patrick Lindecker]

Hello Hugo,

You can use Kiss commands from your program. Some programs (considered as 
modems) support these commands through serial port (physical or virtual) as 
AGWPE, Mixw (I think) or Multipsk.  In the last test version of this one, I 
added TCP/IP Kiss commands (contact me in direct for details if you need).

73
Patrick
  - Original Message - 
  From: Hugo Correa Sena 
  To: digitalradio@yahoogroups.com 
  Sent: Wednesday, February 25, 2009 2:37 PM
  Subject: Re: [digitalradio] Re: Newbie looking for a bbs packet radio


  Thanks Andy for fast aswer. I take a lok in those very interesting programs.

  My first plan is use some graphic and dedicade program. Somethink like butons 
of connect, open a graphic menu window, make fews commands just clicking mouse 
buttons. Somethink easy to start, you know?

  Later I´ll but more hard tasks in BBS.


  2009/2/24 Andrew O'Brien 

Hugo, Your English is good!

Did you try PSKMAIL? That may help, or perhaps Multipsk's packet
functions.

Andy K3UK

--- In digitalradio@yahoogroups.com, Hugo Correa Sena 
wrote: 


>
> Dear friends,
> 
> I´d like some help in a simple (not to me, HI) project. I´d like to
try of
> putting in the air a station BBS packet radio (I think that´s the
name) just
> to send/recieve personal messenger, little files and general
messenger (like
> QTC). Later I´ll connect in others net
> 
> The big objective of this project is start interesting in Amateur
radio of
> digital modes in VHF. As not activitie, I´d like to start with
programs to
> emulate tnc and baycom modems (like as mixW does, I supose).
> 
> Supose again that this project is divided in two poles: server and user.
> 
> So my ask for you is some programs (I´ll appreciate graphics
programs) to
> use on this task.
> 
> Thanks for help and sorry for bad english
> 
> -- 
> Hugo Sena
> 
> PP8HS
> PX8C1546
> http://pp8hs.110mb.com
>







  -- 
  Hugo Sena
  
  PP8HS
  PX8C1546
  http://pp8hs.110mb.com



  

[digitalradio] Re: Using CTSS on a digipeater?

[vinceinwaukesha]

--- In digitalradio@yahoogroups.com, "Terry Breitenfeldt" 
 wrote:
>
> Let me thow out a couple more issues about this problem:
> 
> 1) The Digi would be located on a hill over 10,000ft high, in an
>area prone to immense RF inference.  Because of its height
>and the nature of digital signals, I'm concerned that a KPC+
>would be overwhelmed hearing multiple signals from
>hundreds of miles away that might make the TNC unavailable, just
>when it needs to be available exclusively for ECOM.

Even if a "closed group" were technologically possible, even inside a 
closed group you can still have massive hidden transmitter problems 
causing thruput problems.  So if ham X 50 miles N can't hear the 
transmissions of ham Y 50 miles south, then the LAN will break down 
if ham X and ham Y both try to access the same digi.  All the 
stations on the network will need "hundreds of miles of range" not 
just the digipeater.

You may want to look at what the folks in WI and MI and MN (and 
probably many other locations) have done.

Now if you installed multiple directional antennas and radios 
pointing to distinct metro areas on distinct frequencies, that culd 
work quite well.  So antenna 1 pointing to metro area #1 where 
everyone in metro area #1 can hear each other while using off the 
shelf mobiles could work.  Use nodes instead of digis and link them 
together.

73 de Vince N9NFB

Re: [digitalradio] Re: Newbie looking for a bbs packet radio

[Hugo Correa Sena]

Thanks Andy for fast aswer. I take a lok in those very interesting programs.

My first plan is use some graphic and dedicade program. Somethink like
butons of connect, open a graphic menu window, make fews commands just
clicking mouse buttons. Somethink easy to start, you know?

Later I´ll but more hard tasks in BBS.

2009/2/24 Andrew O'Brien 

>   Hugo, Your English is good!
>
> Did you try PSKMAIL? That may help, or perhaps Multipsk's packet
> functions.
>
> Andy K3UK
>
> --- In digitalradio@yahoogroups.com , Hugo
> Correa Sena 
> wrote:
>
> >
> > Dear friends,
> >
> > I´d like some help in a simple (not to me, HI) project. I´d like to
> try of
> > putting in the air a station BBS packet radio (I think that´s the
> name) just
> > to send/recieve personal messenger, little files and general
> messenger (like
> > QTC). Later I´ll connect in others net
> >
> > The big objective of this project is start interesting in Amateur
> radio of
> > digital modes in VHF. As not activitie, I´d like to start with
> programs to
> > emulate tnc and baycom modems (like as mixW does, I supose).
> >
> > Supose again that this project is divided in two poles: server and user.
> >
> > So my ask for you is some programs (I´ll appreciate graphics
> programs) to
> > use on this task.
> >
> > Thanks for help and sorry for bad english
> >
> > --
> > Hugo Sena
> > 
> > PP8HS
> > PX8C1546
> > http://pp8hs.110mb.com
> >
>
>  
>



-- 
Hugo Sena

PP8HS
PX8C1546
http://pp8hs.110mb.com

Re: [digitalradio] Re: on another note

[Patrick Lindecker]

Hello Votjech and Jim,

TKS for the information.
I suppose the difference must be the same as between CW (not coherent) and 
CCW (coherent) so a gain of several dB on the S/N.

A synchronous RTTY under Windows is possible with a standard symbol 
synchronization (with or without a PLL which can be seen as the "digital 
flywheel"). However, the stop bit (1.5 symbols) complicates all as it is not 
an integer multiple of the symbol length.

Now, RTTY must be supposed to be asynchronous to be compatible with all RTTY 
apparatus and programs. Let's work on more modern modes...

73
Patrick

- Original Message - 
From: "jhaynesatalumni" 
To: 
Sent: Wednesday, February 25, 2009 5:54 PM
Subject: [digitalradio] Re: on another note


> --- In digitalradio@yahoogroups.com, "Vojtech Bubnik"  wrote:
>
>> Patrick, I have a proposal for one low hanging fruit project. How
>> about to receive RTTY in a synchronous way? I believe most SW really
>> generate precise synchronous RTTY, where the only variable is the
>> unknown stop bit length (mostly 1.5?). If the stop bit length is being
>> estimated or selected from menu, one could receive RTTY synchronously
>> and greatly increase sensitivity of this legacy but often used mode.
>
> It's been done, in the K6STI RITTY software some years ago.  Not that
> it couldn't be done again.  K6STI was selling his software and pulled
> it off the market when users began stealing it.  Also it was basically
> DOS software, and that may have been a necessity considering the timing
> vagaries of multitasking operating systems.  There was for a time an
> implementation of Pactor-I in RTTY, later taken out.
>
> What K6STI did was something I had been dreaming about ever since the
> vacuum tube and heavy metal days of RTTY, so I was tickled pink that
> he did it.  I had a few arguments with him about the dynamics of the
> "digital flywheel" as he called it; but he's the expert and I'm not.
> As things turned out it did not greatly increase the sensitivity -
> it was good for a db or two and that was about all.
>
> One neat thing he did, that I wish other RTTY software writers
> would do, was to output cleaned-up Baudot while receiving, so
> that one could drive a TTY machine from it, using his software as
> sort of the ultimate T.U.
>
> Jim W6JVE
>
>
>
>
> 
>
> Announce your digital presence via our Interactive Sked Page at
> http://www.obriensweb.com/sked
>
>
> Recommended software:  Winwarbler, FLDIGI, DM780, or Multipsk
>
>
>
> Yahoo! Groups Links
>
>
>
>
> 

Re: [digitalradio] on another note

[Patrick Lindecker]

Hello John,

>RFSM8000 has come as close as anything so far, but it's weakness was operating 
>well under poor conditions (read >normally poor these days)
As far as I know, RFSM8000 uses a protocol close to 110A. This protocol is fine 
as it permits a great dynamic of data speed and moreover it has an excellent 
"Mean power/Peak power" ratio, very close to 1.

However, it has a problem as the symbol rate being equal to 2400 bauds, it is 
required an equalization (indispensable above 100 bauds). This equalization is 
efficient only for good (or not too bad) signal to noise ratio (with too much 
noise, the equalizer does not converge or lead to false solutions). 

The other solution is to be at 100 bauds or less and to multiply the number of 
carriers (as in MT63). However, in that case the "Mean power/Peak power" ratio 
is not good (as in MT63) and it can be a problem if for example, you are 
limited to 10 watts (to keep linear) with a 100 watts transceiver.

To be able to have a very good S/N ratio (as good as the one supposed for P3), 
it is necessary to have a sequence of symbols (carrying the specific 
transmission parameters) at slow speed that can be recognized easily without 
error (i.e with a strong autocorrelation function) as for the RS ID. Once 
recognized, all is more simple as this sequence acts as a pivot: you can add 
your message at a given speed, repeat it if necessary (an "ARQ memory" is of 
course indispensable), increase or decrease the speed according to the 
ionospheric conditions...

73

Patrick

- Original Message - 

  From: John Bradley 
  To: digitalradio@yahoogroups.com 
  Cc: multi...@yahoogroups.com 
  Sent: Tuesday, February 24, 2009 11:48 PM
  Subject: RE: [digitalradio] on another note


   

  "I don't think it would be technically very difficult to do something 
equivalent to P3 with sound cards. I think that it would even possible to do 
much better with, for example, multi-users protocol."

   

  RFSM8000 has come as close as anything so far, but it's weakness was 
operating well under poor conditions (read normally poor these days)

   

  "The problem is the time necessary to do this. An amateur can work (with 
pleasure and passion of course), let's say a day per week, when a company can 
make work a small team 5 days a week. Now an amateur project must be short in 
time (several months at a maximum) as it is done for fun. Working on the same 
project during years seems very difficult (and surely boring) for amateurs."

   

  No kidding.. it is amazing and very appreciated with what you and other 
software authors have done, and is especially important when it is done as a 
hobby.

   

   

  "Another point is that the number of Hams really interested in ARQ modes is 
very weak..."

   

  I can't answer that , outside of the fact there are a pile of winlink users. 
Think you might underestimate the number of folks interested in ARQ soundcard 
modes, and maybe this is an opportunity for Andy to do a survey on his website?

   

   

  "Note: have tests on the minimum S/N versus the data rate done, for pactot P2 
and P3? (as it is difficult to trust commercial data) "

   

  don't know, but think so . but my ear tells me it works better than OLIVIA, 
which is about the top of the heap right now. I cannot hear the other station 
and yet the connect runs at fast speed.

   

  John

  VE5MU

   




  

RE: [digitalradio] Re: Using CTSS on a digipeater?

[Bob Donnell]

Your situation is creating for you a huge hidden transmitter problem.  

Is there anything that says you can't do either of these things:

1) Use a directional antenna - reduce the signal strength from the far-away
mountains.  Using down-tilt to both better illuminate the valleys close to
the digi, and at the same time, reduce the strength of signals on the
horizon, by tilting enough to put them well down the main lobe.

2) Move the antenna or digipeater site to a lower location, perhaps where
you can gain some benefit from putting the mountain between the digipeater
antenna and the most likely interferers

3) Use a different band entirely.  It's usually easier to find underutilized
frequencies to use for packet, on 222 and 420-450 MHz.

A thought associated with hidden transmitters, that we've had huge success
with here, but is more complicated, and that's to get a repeater allocation
and put up a repeater dedicate for packet communications.  This has a number
of benefits:

1) No hidden transmitters - at all.  Collisions are pretty much
non-existant.

2) Everyone connects to everyone "direct".  No digipeating needed, which
instantly doubles your throughput.

3) All fixed operations can use beam antennas for packet because they don't
need to be able to hear or talk in multiple directions.  Additionally, using
beams usually means that if multipath is a problem, you can usually find a
direction to point the beam to eliminate the multipath.  Movable resources
can be equipped with a beam, which can be set up if multipath at that site
is a problem. 
 
4) If you don't provide any "services" on the repeater, like a public BBS,
node, or DX Cluster, chances are the repeater won't see a lot of use,
meaning it'll be available.

The biggest down side is that a repeater is more complicated than a
digipeater.  There are more pieces to go wrong.  But the repeater doesn't
need a fancy controller.  In fact, using the TNC DCD indicator line (with a
KPC 3x set for software DCD) or any other TNC with True DCD, provides the
"COR" line to key the transmitter.  Further, the TNC can act as the repeater
ID'er - just to send an ID packet every 10 minutes.  That has been confirmed
to constitute a legal same-mode ID, when the repeater is intended for packet
use.  If that's an interesting option, I can provide more details.  We've
had a number of packet repeaters over the years, one of which has been on
the air since 1985 or so.  The others were on 9600 baud, which is a can of
worms I don't recommend, because so few radios that claim to be 9600 baud
ready really are not.

73, Bob, KD7NM


-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of Terry Breitenfeldt
Sent: Tuesday, February 24, 2009 8:00 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Using CTSS on a digipeater?

Let me thow out a couple more issues about this problem:

1) The Digi would be located on a hill over 10,000ft high, in an
   area prone to immense RF inference.  Because of its height
   and the nature of digital signals, I'm concerned that a KPC+
   would be overwhelmed hearing multiple signals from
   hundreds of miles away that might make the TNC unavailable, just
   when it needs to be available exclusively for ECOM.
2) The purpose of the Digi is specically for RACES traffic and
   needs to pass ECOM traffic from mobile command posts back to the
   EOC, for both large and small events. There are other circuts
   available for non-RACES traffic, so I'm not really concerned that
   other hams would be excluded from this "one" Digi. The goal would
   be to provide the County with a high point that doesn't currently
   exist.

>From a technical stand point, I would be concerned if a CTSS tone would be
counter productive to the radio reponding quick enough for reliable packet
communications.  I was also concerned about packet collisions that could be
caused by the TNC not hearing all packet traffic on the frequency.

I guess the best solution would be choose a packet frequency thats used very
rarely by other groups and leave the Digi as a open machine.

Thanks.


 
--- In digitalradio@yahoogroups.com, "Bob Donnell"  wrote:
>
> I'm with Vince on a number of points.  
> 
> If there's really a serious emergency, that will benefit from
packet radio,
> chances are that the hobbiest hams are not going to be on the air,
unless
> it's in support of your goals.  I think it's far better to have the
local
> community exercising your digipeater for you, so you know if it
fails.
> 
> If you're truly insistent on having the ability to lock out
stations, it'd
> be better to do a couple of things to achieve that:
> 
> 1) Use a TNC that allows performing over-the-air settings
modifications
> 
> 2) When an event happens, and you determine that the level of
emcomm traffic
> vs. regular user traffic requires it, set up a beacon that
frequently (every
> minute or two) informs all users that the digipeater has bee

[digitalradio] Re: on another note

[jhaynesatalumni]

--- In digitalradio@yahoogroups.com, "Vojtech Bubnik"  wrote:

> Patrick, I have a proposal for one low hanging fruit project. How
> about to receive RTTY in a synchronous way? I believe most SW really
> generate precise synchronous RTTY, where the only variable is the
> unknown stop bit length (mostly 1.5?). If the stop bit length is being
> estimated or selected from menu, one could receive RTTY synchronously
> and greatly increase sensitivity of this legacy but often used mode.

It's been done, in the K6STI RITTY software some years ago.  Not that
it couldn't be done again.  K6STI was selling his software and pulled
it off the market when users began stealing it.  Also it was basically
DOS software, and that may have been a necessity considering the timing
vagaries of multitasking operating systems.  There was for a time an
implementation of Pactor-I in RTTY, later taken out.

What K6STI did was something I had been dreaming about ever since the
vacuum tube and heavy metal days of RTTY, so I was tickled pink that
he did it.  I had a few arguments with him about the dynamics of the
"digital flywheel" as he called it; but he's the expert and I'm not.
As things turned out it did not greatly increase the sensitivity -
it was good for a db or two and that was about all.

One neat thing he did, that I wish other RTTY software writers
would do, was to output cleaned-up Baudot while receiving, so
that one could drive a TTY machine from it, using his software as
sort of the ultimate T.U.

Jim W6JVE

Re: [digitalradio] The Basics On WINMOR

[Rick W]

Hard to respond as you did not indicate what you found confusing.

There is no question that WINMOR, if reasonably successful, will cause 
an increase use of Winlink 2000, maybe even more than they might prefer, 
HI. And it will also impact sales of SCS to a certain extent. As Patrick 
pointed out, there is no technical reason that sound card modes could 
not improve over Pactor 2 and 3. Maybe he is too optimistic right now, 
but in the long term 

73,

Rick, KV9U

John Becker, WØJAB wrote:
> Rick
> I'm a bit confused over your long post.
> But I can say that he has said that it's not
> a replacement for P2 or P3 or ever will be.
>
> John
>
>   

[digitalradio] Re: on another note

[Vojtech Bubnik]

Hi Patrick and others.

> I don't think it would be technically very difficult to do something
equivalent to P3 with sound cards. I think that it would even possible
to do much better with, for example, multi-users protocol.

I completely agree.

> The problem is the time necessary to do this. An amateur can work
(with pleasure and passion of course), let's say a day per week, when
a company can make work a small team 5 days a week.

Much less than one day per week if one has toddler or two to take care of.

I admire your endurance in developing a complex free HAM software.

> Now an amateur project must be short in time (several months at a
maximum) as it is done for fun. Working on the same project during
years seems very difficult (and surely boring) for amateurs.

Very true. If the project is too complex, it will simply become
obsoleted by a commercial product before it is finished.

The same thinking applies to development of hardware as I learned
during my tinkering with ATS-3b.

Patrick, I have a proposal for one low hanging fruit project. How
about to receive RTTY in a synchronous way? I believe most SW really
generate precise synchronous RTTY, where the only variable is the
unknown stop bit length (mostly 1.5?). If the stop bit length is being
estimated or selected from menu, one could receive RTTY synchronously
and greatly increase sensitivity of this legacy but often used mode.

73, Vojtech OK1IAK

[digitalradio] Re: Using CTSS on a digipeater?

[Terry Breitenfeldt]

Let me thow out a couple more issues about this problem:

1) The Digi would be located on a hill over 10,000ft high, in an
   area prone to immense RF inference.  Because of its height
   and the nature of digital signals, I'm concerned that a KPC+
   would be overwhelmed hearing multiple signals from
   hundreds of miles away that might make the TNC unavailable, just
   when it needs to be available exclusively for ECOM.
2) The purpose of the Digi is specically for RACES traffic and
   needs to pass ECOM traffic from mobile command posts back to the
   EOC, for both large and small events. There are other circuts
   available for non-RACES traffic, so I'm not really concerned that
   other hams would be excluded from this "one" Digi. The goal would
   be to provide the County with a high point that doesn't currently
   exist.

>From a technical stand point, I would be concerned if a CTSS tone
would be counter productive to the radio reponding quick enough for
reliable packet communications.  I was also concerned about packet
collisions that could be caused by the TNC not hearing all packet
traffic on the frequency.

I guess the best solution would be choose a packet frequency thats
used very rarely by other groups and leave the Digi as a open machine.

Thanks.


 
--- In digitalradio@yahoogroups.com, "Bob Donnell"  wrote:
>
> I'm with Vince on a number of points.  
> 
> If there's really a serious emergency, that will benefit from 
packet radio,
> chances are that the hobbiest hams are not going to be on the air, 
unless
> it's in support of your goals.  I think it's far better to have the 
local
> community exercising your digipeater for you, so you know if it 
fails.
> 
> If you're truly insistent on having the ability to lock out 
stations, it'd
> be better to do a couple of things to achieve that:
> 
> 1) Use a TNC that allows performing over-the-air settings 
modifications
> 
> 2) When an event happens, and you determine that the level of 
emcomm traffic
> vs. regular user traffic requires it, set up a beacon that 
frequently (every
> minute or two) informs all users that the digipeater has been 
configured for
> emcomm operations, and create a buddy list of stations that are 
allowed to
> connect and digipeat via the digipeater, and implement it.  Another
> alternative that can be done remotely is to change the "MYDIGI" 
setting to
> respond to something else, but that's only a short-term fix, since 
anyone
> that's monitoring can see the digipeater callsign.
> 
> Perhaps the most important thing, is if the operation is of a 
limited
> period, remember to set operations back to normal operations before 
shutting
> operations down, or when the emcomm traffic volume is reduced 
enough to
> support normal operations.
> 
> From a technical perspective, using CTCSS as an operational 
modifier is a
> poor solution, for the reason Vince mentioned, and additionally, 
depending
> on the TNC and radio combination, having the the CTCSS tone present 
at the
> input to the TNC may cause it to make more reception errors than if 
it's not
> present.  Also, anything that delays the digipeater (especially) 
from being
> able to tell that the channel is busy, and that to wait for the 
channel to
> clear before transmitting, is going to kill performance and require 
many
> more retries than leaving the digipeater open.
> 
> Hope that helps!
> 
> 73, Bob, KD7NM  
> 
> -Original Message-
> From: digitalradio@yahoogroups.com 
[mailto:digitalra...@yahoogroups.com] On
> Behalf Of Terry Breitenfeldt
> Sent: Sunday, February 22, 2009 11:37 PM
> To: digitalradio@yahoogroups.com
> Subject: [digitalradio] Using CTSS on a digipeater?
> 
> If I wanted to setup a "closed" Digipreater on 145.09 Mhz on a high 
mountain
> peak, so that I could limit activity to only ECOM traffic, would 
the use of
> a CTSS tone decode be a viable option?  Would a CTSS tone interfere 
with
> Packet operations?  
>  
> 
> 
> 
> 
> 
> Announce your digital presence via our Interactive Sked Page at
> http://www.obriensweb.com/sked
> 
> 
> Recommended software:  Winwarbler, FLDIGI, DM780, or Multipsk
> 
> 
> 
> Yahoo! Groups Links
>