[digitalradio] Re: Software for the digital ham that multi-tasks while sleeping ?

[Brad]

--- In digitalradio@yahoogroups.com, "Andrew O'Brien"  exampl.
and so on?
> > 
> > just an idea
 
> Now there's an interesting idea.

It's an idea I have wanted to implement for a few years now. I would
like to have my SSTV webcam monitor 7171 LSB by day, 14230 USB by
night and 146.775 FM for 3 hours on Thursday nights. 

This in conjunction with KE5RS's bat.widget which I beleive now
displays a jpg on a webpage to announce which band I am monitoring,
would almost fully automate the remote monitoring functions of my station.

Brad VK2QQ
www.vk2qq.com

Re: [digitalradio] Re: ALE Sounding and How does it work?

[Steve Hajducek]

John,

Sorry but I know the relative level of activity 
at times. There is far less ALE than various 
other modes and more ALE than various other modes 
as well. It all depends on your point of 
reference, just as there is Hellscriber than GTOR 
and more CW than PSK31, regardless your statement 
as to the amount of activity is false, but its 
also moot in my opinion. I view ALE within the 
scope of Amateur Radio application as tool that 
needs to trained on and have networks in place 
for use as necessary, not necessarily used daily 
by all, although such use is just fine and the 
best tool for many pursuits within ARS, however 
its the application of ALE for ECOM where I see 
ALE having the biggest benefits to the ARS.

Rather than sitting on 20 meters you should try 
programming all the ALE frequencies into your 
choice of ALE controller and scanning for 24 
hours with appropriate antenna for NVIS below 
14Mhz and Skywave above 10Mhz for Amateur Radio 
and if you are properly configured you your results will be much different.

As to you what you are seeing on Channel One, it 
will depend on the geographic location of the 
HFlinkNet stations and what they are hearing 
based on the antenna type being used. Some are 
using NVIS antenna only, others Skywave antenna 
only, some are using something thing in between, 
those using automated antenna selection will be 
optimum, I do not know what all the stations are 
running. The MARS-ALE software which is being 
used by HFlinkNet stations supports programmable 
antenna selection during scanning using various 
devices, the CAT ANT ports in radios, external PC 
controlled ATU's with ant ports and dedicated 
antenna switches under PC control.

/s/ Steve, N2CKH

At 11:05 PM 1/11/2008, you wrote:
>
>If the statement below is False, why are there 
>not more call signs showing up on the main ALE frequencies?
>
>I can leave my rig on 14109.5 or 10145.5  for 24 
>hours and only see, at most 4 or 5 stations?  Ditto for the ALE website
>At HFlink.  And 99% of those are soundings. So 
>where are the QSO’s and the like?
>
>Who is up for testing the ability of PCALE to 
>handle a standard test document between 2 distant stations, compared to 141A or
>ALE400. Ditto for a file transfer?  I can’t on 
>PCALE since I can only receive, since I have a 
>problem getting the software to TX.
>
>Anyway , in the past I have told you guys at 
>least 20 million times not to exaggerate……
>
>
>John
>VE5MU

Re: [digitalradio] Re: ALE Sounding and How does it work?

[Les Warriner]

Now, 20 million + 1

73

At 08:05 PM 1/11/2008, you wrote:




If the statement below is False, why are there 
not more call signs showing up on the main ALE frequencies?




I can leave my rig on 14109.5 or 10145.5  for 24 
hours and only see, at most 4 or 5 stations?  Ditto for the ALE website


At HFlink.  And 99% of those are soundings. So 
where are the QSO’s and the like?




Who is up for testing the ability of PCALE to 
handle a standard test document between 2 distant stations, compared to 141A or


ALE400. Ditto for a file transfer?  I can’t on 
PCALE since I can only receive, since I have a 
problem getting the software to TX.




Anyway , in the past I have told you guys at 
least 20 million times not to exaggerate……






John

VE5MU







At 09:48 PM 1/10/2008, you wrote:
>
>Chris , ZL1BOE
>
>you will be told by others that ALE is widely
>used to set up QSO’s and QSY’s using the one
>line message ability . You will also be told
>that it is used widely for keyboard to keyboard
>QSO’s and that there are thousands of Hams using
>ALE ( last figure I heard was 6000) . These are
>folks who are using PCALE, who have aggressively
>set aside frequencies for ALE use in all bands,
>and are promoting ALE as the answer to emergency communications.

FALSE


No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.1/1220 
- Release Date: 1/11/2008 6:09 PM

[digitalradio] Re: ALE Sounding and How does it work?

[John Bradley]

 

If the statement below is False, why are there not more call signs showing
up on the main ALE frequencies?

 

I can leave my rig on 14109.5 or 10145.5  for 24 hours and only see, at most
4 or 5 stations?  Ditto for the ALE website

At HFlink.  And 99% of those are soundings. So where are the QSO's and the
like? 

 

Who is up for testing the ability of PCALE to handle a standard test
document between 2 distant stations, compared to 141A or

ALE400. Ditto for a file transfer?  I can't on PCALE since I can only
receive, since I have a problem getting the software to TX.

 

Anyway , in the past I have told you guys at least 20 million times not to
exaggerate..

 

 

John

VE5MU

 

 

 

At 09:48 PM 1/10/2008, you wrote:
>
>Chris , ZL1BOE
>
>you will be told by others that ALE is widely 
>used to set up QSO's and QSY's using the one 
>line message ability . You will also be told 
>that it is used widely for keyboard to keyboard 
>QSO's and that there are thousands of Hams using 
>ALE ( last figure I heard was 6000) . These are 
>folks who are using PCALE, who have aggressively 
>set aside frequencies for ALE use in all bands, 
>and are promoting ALE as the answer to emergency communications.

FALSE

[digitalradio] Re: Robust Packet-Radio (RPR)

[jhaynesatalumni]

--- In digitalradio@yahoogroups.com, Rick <[EMAIL PROTECTED]> wrote:
>
> Andy,
> 
> What I don't understand is if you already have a suite of modes,
Pactor, 
> Pactor 2, and Pactor 3, then why create another mode like they did?
> 
> This is not compatible with existing packet, right? So you would
have to 
> have SCS products on both ends? Then why not use Pactor modes, 
> especially the Pactor 2 mode which is of a similar bandwidth and
throughput?

Maybe not.  Seems like that say it doesn't involve tight timing
the way Pactor does, so potentially it is a mode that can be
implemented on sound cards, either by reverse engineering or by
their publishing complete specs.

[digitalradio] Re: Software for the digital ham that multi-tasks while sleeping ?

[Andrew O'Brien]

-
> would it be possible to write something like that via the macro Manager?
> 
> exampl. and 
> so on?
> 
> just an idea
> 
> The  macro could also come in handy on contests ... 
> using it in the limit on Band changes per hour.
> 
> 73 Steve, W1CDX
>


Now there's an interesting idea.

[digitalradio] Re: Software for the digital ham that multi-tasks while sleeping ?

[Steve Hunt]

--- In digitalradio@yahoogroups.com, "Simon Brown" <[EMAIL PROTECTED]> 
wrote:
>
> In my own case I can record the incoming audio and play it back later.
> 
> At the moment I leave DM780 running all night picking up SSTV 
pictures.
> 
> I'm not sure I would want a scheduler but were I to add one I would 
use a UI 
> similar to Outlook's calendar.
> 
> Simon Brown, HB9DRV

would it be possible to write something like that via the macro Manager?

exampl. and 
so on?

just an idea

The  macro could also come in handy on contests ... 
using it in the limit on Band changes per hour.

73 Steve, W1CDX

Re: [digitalradio] Software for the digital ham that multi-tasks while sleeping ?

[Leigh L Klotz, Jr.]

This would be an excellent client to write for znudigi.
73,
Leigh/WA5ZNU
On Fri, 11 Jan 2008 3:51 am, Andrew O'Brien wrote:
> If you are like me, there is SO MUCH happening in the amateur radio
> digital world that it is hard to keep up with ,  more fun to be had
> than can be squeezed in to 24 hours.  Some software ,like WSJT,  can
> be left active overnight or when out of the shack and the user gets
> time stamped information about stations detected while they were out.
> This is very useful but it is static, simply monitoring one frequency
> and one mode.   What would it take to develop an application that can
> scan different frequencies at larger time intervals that the "scan
> mode" in modern rigs.  Perhaps something that is user defined.
> Something that might monitor 14070 for 15 minutes and then
> automatically move to 3581 for an hour , then to 7034 for 30 minutes .
>  Not only would this software change frequency at designated times,
> it might switch modes too.  Listening on 14070 in PSK31 ,  changing to
> JT65A and QSYing to 14076 for 20 minutes,  and even listening  to
> Olivia on 3581 , etc etc.  I guess this could be a major add-on to
> something like Multipsk or DM780 but maybe it would take another form
> , something akin to DX Lab Launcher.  DX Lab Launcher enables the user
> to launch varying DX Lab Suit applications , something like this could
> be used to launch and close different applications at specified times.
>  Example:  At 1400Z it launches Winwarbler in RTTY mode, at 1500 it
> closes Winwarbler and  launches Multipsk in Olivia 500/16 and at 1700
> it launches VB-Digi/FLARQ in PSK250 .
>
>
> Anyone care to invent this ?
>
> --
> Andy K3UK
> www.obriensweb.com
> (QSL via N2RJ)
>
>
> Announce your digital presence via our Interactive Sked Page at
> http://www.obriensweb.com/sked
>
>
> DRCC contest info : http://www.obriensweb.com/drcc.htm
>
> Yahoo! Groups Links
>
>
>

Re: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm

[John Hirth]

Robert,

I may be in a minority, but I don't think you're off base.

If you stick around you WILL find posts that are more to what you (and 
I) sought as a focus of a digital radio forum.

You just have to sort through a myriad of repetitive philosophical 
postings on topics that sometimes seem to range a bit wide (take a peek 
at the subject line of this thread to which you replied, for example), 
or not infrequently include condescending comments (as in one earlier 
reply to your query).

Although I don't consider myself a newbie (licensed in '62, working 
digital for well over 20 years, and a member of this forum for quite 
some time), I think it's time for me to again stop receiving email 
postings. I'll just update my forum options and visit via the web from 
time to time. And yes, I DO actively participate in emergency and 
disaster  communications, both digital and voice.

OK guys, flame me if you wish. They won't clutter my mail box.

73 to all. Truly. Nothing personal, Andy. See you all on the digital modes.

John Hirth W2KI

Re: [digitalradio] Robust Packet-Radio (RPR)

[Rick]

Actually, Jack, this makes more sense. In a way, this would be one way 
of interoperability between modes.

For those of  us who did Amtor and later Pactor and Clover II, the old 
Aplink and later Winlink systems allowed us to connect to a MBO (Mail 
Box Operation, I think that was what they used to call them) with any of 
the modes and the station would be able to switch to the correct mode 
and store and play the messages. RTTY Journal (or it could have been 
renamed RTTY Digital Journal) had an extensive article on how this was 
done. Manageable, but a bit messy to do it.

So no matter what mode we had, we could still communicate with these 
MBO's and they in turn would forward the traffic world wide or whatever 
was needed.

Otherwise, just having a new mode would not make much sense to put that 
much energy into development. But since regular 300 baud packet is so 
very poor on HF, just about any improved modulation scheme would be so 
much better.

For sound card modes today, we have the 110 baud packet mode which does 
work much better, but of course is about a third the speed of 300 baud 
packet and you would need to match your speed to anyone with that mode. 
Even then, other modes are so much better now, particularly the ALE400 
mode or better yet the 8FSK50 FAE 400 ARQ mode.

73,

Rick, KV9U



Jack Chomley wrote:
> Rick,
> Well, its just another mode, to add to the 
> pile!  You get RPR with the SCS DSP 
> Tracker,  APRS is also using it and the DSP 
> Tracker will send BOTH mode APRS frames out, that 
> is a standard 300 baud HF Packet data frame, THEN 
> the next one out is an RPR frame, alternating. 
> This is so any RPR OR standard 300 baud stations 
> or IGATEs will pick up the signals.
> At least in this case, SCS thought of the 300 
> baud HF Packet users on APRS, when they developed this TNC.
> The other SCS PTC models also have the RPR mode too.
> I think the mode is a good one, given it is a 
> hardware based one, that can be used in a reasonable cost piece of hardware.
> https://www.scs-ptc.com/controller.html
>
> 73s
>
> Jack VK4JRC
>
>   

Re: [digitalradio] PACTO! I CQ

[w6ids]

- Original Message - 
From: "kh6ty" <[EMAIL PROTECTED]>
To: 
Sent: Friday, January 11, 2008 2:14 PM
Subject: Re: [digitalradio] PACTO! I CQ


> Copying you FB in South Carolina, Howard, using DigiPan 2.0.
>
> Sorry - No Pactor 1 transmit capability - my PK-232 is in mothballs!
>


Super!  Thanks, Skip.  Well, shucks, would have been neat to pick
you up, Skip.  I picked up NT3K (Ken) in Las Cruces, NM with an
S9 signal both ways on 14.078 and it made for pretty well 100%
copy using FEC. Had no problems at all.  The contact lasted about
an hour or so.  He was using his MultiPSK package.

No one bother us for using PACTOR, had no apparent problems with
any PMBOs either.  I know, I know, PACTOR I is verrry "retro" but
what the heck - it was great fun.

C'mon, Skip.  I know you've got a few things on your plate, what with
NBEMS and all, but take a few sometime; break out that PK and
play with it.  It's still viable - it's better than just leaving the 
electrolytics
to dry up if it isn't broke.

Thanks again..

Howard W6IDS
Richmond, IN 

Re: [digitalradio] Robust Packet-Radio (RPR)

[Jack Chomley]

Rick,
Well, its just another mode, to add to the 
pile!  You get RPR with the SCS DSP 
Tracker,  APRS is also using it and the DSP 
Tracker will send BOTH mode APRS frames out, that 
is a standard 300 baud HF Packet data frame, THEN 
the next one out is an RPR frame, alternating. 
This is so any RPR OR standard 300 baud stations 
or IGATEs will pick up the signals.
At least in this case, SCS thought of the 300 
baud HF Packet users on APRS, when they developed this TNC.
The other SCS PTC models also have the RPR mode too.
I think the mode is a good one, given it is a 
hardware based one, that can be used in a reasonable cost piece of hardware.
https://www.scs-ptc.com/controller.html

73s

Jack VK4JRC




At 06:02 AM 1/12/2008, Rick wrote:

>Andy,
>
>What I don't understand is if you already have a suite of modes, Pactor,
>Pactor 2, and Pactor 3, then why create another mode like they did?
>
>This is not compatible with existing packet, right? So you would have to
>have SCS products on both ends? Then why not use Pactor modes,
>especially the Pactor 2 mode which is of a similar bandwidth and throughput?
>
>73,
>
>Rick, KV9U
>
>Andrew O'Brien wrote:
> > I found the item (below) on the SCS web site. Anyone use this "new
> > class" of packet ?
> >
> >
> > Robust Packet-Radio (RPR)
> >
> > Up to now Packet-Radio over shortwave has been basically a
> > non-starter, it has even been heavily criticized because of the low
> > effective throughput and repeats. AX.25 is for shortwave not an ideal
> > protocol, but with automatic FRack-setting and a small MAXFrame value
> > the protocol should, however, function much better on a shortwave
> > channel than has previously been the case generally.
> >
> > One cannot of course expect an asynchrone protocol to reach the same
> > efficiency as a tight synchrone ARQ protocol (e.g. PACTOR), but for
> > some applications a multi-user service, with very uncritical
> > transmit/receive switching, as well as almost zero power holding up a
> > connection when no data passing, brings a real advantage that
> > outweighs the lower data throughput.
> >
> > What finally are the reasons that up to now HF-PR works so poorly, and
> > apart from "forwarding" is hardly ever used? One finds a simple
> > answer: The current modulation type for HF-PR namely uncoded 300 Bd
> > FSK is really unsuitable for normal HF channels. The symbols are much
> > too short even with moderate "Multi-Path effect" ("delay spread") to
> > work. Additionally, because no sort of error correction code is used,
> > even short troughs or "static" will destroy a many seconds long
> > Packet. Just one missing bit leads to a repeat of the whole packet.
> >
> > To help cure this problem, SCS has developed a new class of robust
> > modulations types especially for Packet-Radio. As a special feature
> > for all the variants of this "Robust PR", a completely new
> > synchronizations algorithm with "catch" properties that were not
> > possible before has been realized. Frequency deviations of ±250 Hz are
> > immediately recognized and without any loss of sensitivity
> > compensated, and this with signals that are buried deep in the noise.
> > Because of this it's possible to remove a tuning display. One can say
> > with good conscience that this is "Plug and Play" for shortwave.
> >
> > The currently available "Robust PR" modulation types have the
> > following properties:
> > Bandwidth:500 Hz @ -30 dB
> > Modulation:Pulse-Shaped OFDM (BPSK, QPSK), similar to PACTOR-III
> > Average Throughput:200 or 600 Bit/sec
> > Crestfaktor:3.0 or 4.2 dB
> > Delay-Spread:up to ±8 msec is tolerated
> > Coding:High performance convolutional code, "full-frame interleaved",
> > rate/2 or rate3/4
> >
> >

[digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm

[jgorman01]

I've not been involved in general disasters like katrina.  But I still
seriously doubt that even there ARC and SA shelters were operated in
areas that had not been cleared by search and rescue.  I know here,
the SA which I've been involved with for tornadoes and floods will not
consider putting a canteen or shelter in the middle of search and
rescue operations.  They only serve evacuees. 

Jim
WA0LYK

--- In digitalradio@yahoogroups.com, "Rud Merriam" <[EMAIL PROTECTED]> wrote:
>
> In Katrina and Rita shelters were opened where there were people in
need.
> Whether supplies could readily reach them was a problem to be
solved, not a
> requirement for shelter location. You are not understanding the
widespread
> nature of these disasters. It was easier to solve the supply problem
than
> the rescue problem. 
> 
> A supply truck or helicopter with supplies can make it in once a
day. The
> multiple vehicles, trucks or helicopters, to evacuate people were not
> available. 
> 
> Your "hypothetical" versus others "real world" experience is
misleading you.
> 
>  
> Rud Merriam K5RUD 
> ARES AEC Montgomery County, TX
> http://TheHamNetwork.net
> 
> 
> 
> Your first paragraph indicates that the shelter was so remote and
isolated
> that it required helicopter delivery of food and water.  Yet you also
> indicate that you were in your truck which indicates you could drive
to the
> shelter.  Maybe you were driving a monster truck? Some of this
appears to be
> an appeal to emotion.  
> 
> I HAVE been around long enough to know neither the ARC or SA would
open a
> shelter in a location that was not reachable by regular supply
vehicles nor
> that had SOME kind of communications.  I am pretty sure that the
government
> authorities would not authorize this either.  To do otherwise is simply
> asking for the shelter staff to require 'rescuing' at some time in the
> future thereby adding to the problem. 
> Consequently, when you say no communications, you are overstating
the facts.
> Now maybe, a runner in a vehicle may the only means of
communication, but
> never the less, it is communications.
> 
> 
> 
> Jim
> WA0LYK
>

[digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm

[jgorman01]

Where did I say hams weren't needed for support communications?  Jeez,
when did ham radio volunteers become first line search and rescue
personnel?  Too many people seem to miss the distinction between
communications emergency and search and rescue operations.  Emergency
communications doesn't mean being in the front line right alongside
the search and rescue folks.  I certainly am not trained to be in that
kind of an area even if only doing communications work!

What I did say was that hams, acting as hams, shouldn't put themselves
in a position where they could add to the load on the search and
RESCUE personnel.  If a ham is also a search and rescue member that is
a different story.  Here in the US, neither the ARC or SA will open
shelters that are not fully supportable by their own personnel.  They
do not open shelters that are only supportable by search and rescue
personnel.  In most cases I've been involved with, the authorities
won't even let them into a disaster area until it has been cleared.

I already have the beard growth!

Jim
WA0LYK

--- In digitalradio@yahoogroups.com, Les Warriner <[EMAIL PROTECTED]> wrote:
>
> You have led a sheltered life.  Try operating in the Philipines after 
> a volcano blows, or in Mexico after the same incident, or in Africa 
> after a transvaal fire,  then tell me Hams are not needed.  It's too 
> bad we are getting comments like this from the uninformed with no 
> experience. Get some beard growth and you'll rapidly change your mind.
> 
> 73
> 
> Les
> 
> At 08:13 AM 1/11/2008, jgorman01 wrote:
> 
> >--- In 
> >digitalradio@yahoogroups.com, 
> >Alan Barrow  wrote:
> > >
> > > ""snip""
> > >
> > > I personally had a Red Cross shelter leader run after my truck and
> > > flag me down because she thought we were packing up. quote: "You
> > > don't know how much we still need you guys. Until you arrived we had
> > > no communications since the big green helicopter landed and kicked
> > > out pallets or MRE's. The phones still don't work, please do not
> > > leave."
> > >
> > > Don't think that did not change my perspective and disillusionment.
> > > This is not an ego thing, exactly the opposite. Made me realize that
> > > independent of what I thought we could or should do (my ego), we had
> > > a job to do. I should set aside my annoyances & preferences, that
> > > what we were doing was important and needed.
> >
> >Your first paragraph indicates that the shelter was so remote and
> >isolated that it required helicopter delivery of food and water. Yet
> >you also indicate that you were in your truck which indicates you
> >could drive to the shelter. Maybe you were driving a monster truck?
> >Some of this appears to be an appeal to emotion.
> >
> >I HAVE been around long enough to know neither the ARC or SA would
> >open a shelter in a location that was not reachable by regular supply
> >vehicles nor that had SOME kind of communications. I am pretty sure
> >that the government authorities would not authorize this either. To
> >do otherwise is simply asking for the shelter staff to require
> >'rescuing' at some time in the future thereby adding to the problem.
> >Consequently, when you say no communications, you are overstating the
> >facts. Now maybe, a runner in a vehicle may the only means of
> >communication, but never the less, it is communications.
> >
> >""snip""
> >
> > > I guess the core difference is some are saying we have no business
> > > even providing emergency service. And I believe that is a very
> > > extreme and unsound position.
> > >
> >
> >Your guess is wrong. No one I have seen post is saying that we have
> >no business providing emergency communications where appropriate and
> >in a manner that support the public best.
> >
> > >
> > > ""snip""
> > >
> > > So what's this have to do with digital radio? I think we have a
> > > large opportunity to contribute. We all want an alternative to $1k
> > > proprietary modems. But until we get that alternative there is some
> > > value there.
> > >
> > > That does not mean we can or should compromise operation in the rest
> > > of the bands. But there needs to be a place. Just like there should
> > > be for other digital modes, current and future.
> > >
> > > The whole idea that a legal limit rtty contest op is somehow
> > > appropriate & allowed, yet other digi sigs should not be is
> > > non-sensical. Some of the new modes offer incredible performance &
> > > efficiency. they can be fun for casual work. But they could also
> > > offer significant value in an emergency if harnessed.
> > >
> >
> >You might have continued and made an argument for full blown pactor 3
> >bandwidth for emergencies but you blew it by including casual use. The
> >use of wide signals within a limited spectrum WILL displace several
> >others that want to use narrow signals. It is obvious that you have
> >no love for rtty, yet several rtty signals can fit into the bandwidth
> >of a 2.2 kHz pacto

Re: [digitalradio] Robust Packet-Radio (RPR)

[Rick]

Andy,

What I don't understand is if you already have a suite of modes, Pactor, 
Pactor 2, and Pactor 3, then why create another mode like they did?

This is not compatible with existing packet, right? So you would have to 
have SCS products on both ends? Then why not use Pactor modes, 
especially the Pactor 2 mode which is of a similar bandwidth and throughput?

73,

Rick, KV9U



Andrew O'Brien wrote:
> I found the item (below) on the SCS web site.  Anyone use this  "new
> class"  of packet ?
>
>
> Robust Packet-Radio (RPR)
>
> Up to now Packet-Radio over shortwave has been basically a
> non-starter, it has even been heavily criticized because of the low
> effective throughput and repeats. AX.25 is for shortwave not an ideal
> protocol, but with automatic FRack-setting and a small MAXFrame value
> the protocol should, however, function much better on a shortwave
> channel than has previously been the case generally.
>
> One cannot of course expect an asynchrone protocol to reach the same
> efficiency as a tight synchrone ARQ protocol (e.g. PACTOR), but for
> some applications a multi-user service, with very uncritical
> transmit/receive switching, as well as almost zero power holding up a
> connection when no data passing, brings a real advantage that
> outweighs the lower data throughput.
>
> What finally are the reasons that up to now HF-PR works so poorly, and
> apart from "forwarding" is hardly ever used? One finds a simple
> answer: The current modulation type for HF-PR namely uncoded 300 Bd
> FSK is really unsuitable for normal HF channels. The symbols are much
> too short even with moderate "Multi-Path effect" ("delay spread") to
> work. Additionally, because no sort of error correction code is used,
> even short troughs or "static" will destroy a many seconds long
> Packet. Just one missing bit leads to a repeat of the whole packet.
>
> To help cure this problem, SCS has developed a new class of robust
> modulations types especially for Packet-Radio. As a special feature
> for all the variants of this "Robust PR", a completely new
> synchronizations algorithm with "catch" properties that were not
> possible before has been realized. Frequency deviations of ±250 Hz are
> immediately recognized and without any loss of sensitivity
> compensated, and this with signals that are buried deep in the noise.
> Because of this it's possible to remove a tuning display. One can say
> with good conscience that this is "Plug and Play" for shortwave.
>
> The currently available "Robust PR" modulation types have the
> following properties:
> Bandwidth:500 Hz @ -30 dB
> Modulation:   Pulse-Shaped OFDM (BPSK, QPSK), similar to PACTOR-III
> Average Throughput:   200 or 600 Bit/sec
> Crestfaktor:  3.0 or 4.2 dB
> Delay-Spread: up to ±8 msec is tolerated
> Coding:   High performance convolutional code, "full-frame interleaved",
> rate/2 or rate3/4
>   
>   

Re: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm

[Rick]

Robert,

All these issues on exploring the digital modes are and should be 
discussed. It depends upon what interests the posters who are willing to 
share that information. Be thankful that they do. Many of these 
discussions are vital to amateur radio. The decisions to come will 
affect you personally. Perhaps in ways you like and then again perhaps 
in ways you do not like. You can choose to ignore them and not 
participate, this is up to each individual.

As far as weeding, it does take work. I have to remove many posts that 
do not interest me such as on individuals making contacts through the 
group, that sort of thing, so it does sometimes take an extra minute per 
day to do this.

For specific discussion on emergency communications, there is the hfdec 
(hams for disaster and emergency communication).

There have been times I have asked a digital specific question and 
received no help. Probably because no one knows the answer. On the other 
hand, there have been many times that I have asked a question and 
received help.

What specific digital information were you looking for that you can not 
find elsewhere?

73,

Rick, KV9U



n4ijs wrote:
> Hello!
>
> I am new to this forum, so please forgive me if this comes across off
> base.  But, I came here looking for information on digital modes for
> Amateur Radio - not various, multi-post messages about various peoples
> opinion (and arguments) on unrelated topics.
>
> I am sure that these discussions are important to a select group of
> folks, but are there no other places for these types of discussions to
> take place?  
>
> I belong to several Ham related Yahoo! forums and this one certainly
> produces (by far) the most emails; however, few are related to the
> topic at hand.  So, I have to weed through these other messages to get
> to the "real" ones.
>
> If this just the way of this forum, that's fine - I will just
> unsubscribe.  I hope that isn't the case, but, if it is, can anyone
> recommend a forum for exploring digital modes within Ham Radio?
>
> Thanks and 73,
> Robert - N4IJS
>   
>
>   

RE: [digitalradio] Software for the digital ham that multi-tasks while sleeping ?

[Dave AA6YQ]

WinWarbler can decode all PSK31 or PSK63 QSOs within any 3.5 khz band
segment, determine the stations involved, and maintain a "Stations Heard"
window like this:

http://www.dxlabsuite.com/winwarbler/Heard.jpg

WinWarbler can be configured insert station's heard into SpotCollector's
database, thereby enabling long-term capture and analysis. Awhile back,
4X1DA used this to assemble this interesting analysis of 8 hours of 20m PSK
monitoring from his QTH:

http://www.dxlabsuite.com/winwarbler/4X1DA.xls

73,

 Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED]
Behalf Of Peter G. Viscarola
Sent: Friday, January 11, 2008 8:46 AM
To: DIGITALRADIO
Subject: RE: [digitalradio] Software for the digital ham that multi-tasks
while sleeping ?


>
>
>Anyone care to invent this ?
>

What you're describing could be done quite easily from within a
particular program. It could easily be built as an external program
that sends ActiveX commands to MixW, for example.

The only hang-up that I see is in terms of tuning: So, you tune to
14070 in PSK31 mode and listen for 20 minutes, or whatever. Suppose the
station is on 14070.5?

My point is that especially with these narrow modes, wouldn't what
you're describing require activity directly on the frequency in
question? PSK31 tuning is pretty fussy.

de Peter K1PGV

Re: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm

[tailfeathers]

Yeah...that would be the one where you buy a book and sit in the corner 
and not insult other peoples intelligence with your 
arrogance...Especially as an newbie...:>)

Gary
n8gsj

n4ijs wrote:
> Hello!
>
> I am new to this forum, so please forgive me if this comes across off
> base.  But, I came here looking for information on digital modes for
> Amateur Radio - not various, multi-post messages about various peoples
> opinion (and arguments) on unrelated topics.
>
> I am sure that these discussions are important to a select group of
> folks, but are there no other places for these types of discussions to
> take place?  
>
> I belong to several Ham related Yahoo! forums and this one certainly
> produces (by far) the most emails; however, few are related to the
> topic at hand.  So, I have to weed through these other messages to get
> to the "real" ones.
>
> If this just the way of this forum, that's fine - I will just
> unsubscribe.  I hope that isn't the case, but, if it is, can anyone
> recommend a forum for exploring digital modes within Ham Radio?
>
> Thanks and 73,
> Robert - N4IJS
>
>
> --- In digitalradio@yahoogroups.com, "Rud Merriam" <[EMAIL PROTECTED]> wrote:
>   
>> In Katrina and Rita shelters were opened where there were people in
>> 
> need.
>   
>> Whether supplies could readily reach them was a problem to be
>> 
> solved, not a
>   
>> requirement for shelter location. You are not understanding the
>> 
> widespread
>   
>> nature of these disasters. It was easier to solve the supply problem
>> 
> than
>   
>> the rescue problem. 
>>
>> A supply truck or helicopter with supplies can make it in once a
>> 
> day. The
>   
>> multiple vehicles, trucks or helicopters, to evacuate people were not
>> available. 
>>
>> Your "hypothetical" versus others "real world" experience is
>> 
> misleading you.
>   
>>  
>> Rud Merriam K5RUD 
>> ARES AEC Montgomery County, TX
>> http://TheHamNetwork.net
>>
>>
>>
>> Your first paragraph indicates that the shelter was so remote and
>> 
> isolated
>   
>> that it required helicopter delivery of food and water.  Yet you also
>> indicate that you were in your truck which indicates you could drive
>> 
> to the
>   
>> shelter.  Maybe you were driving a monster truck? Some of this
>> 
> appears to be
>   
>> an appeal to emotion.  
>>
>> I HAVE been around long enough to know neither the ARC or SA would
>> 
> open a
>   
>> shelter in a location that was not reachable by regular supply
>> 
> vehicles nor
>   
>> that had SOME kind of communications.  I am pretty sure that the
>> 
> government
>   
>> authorities would not authorize this either.  To do otherwise is simply
>> asking for the shelter staff to require 'rescuing' at some time in the
>> future thereby adding to the problem. 
>> Consequently, when you say no communications, you are overstating
>> 
> the facts.
>   
>> Now maybe, a runner in a vehicle may the only means of
>> 
> communication, but
>   
>> never the less, it is communications.
>>
>>
>>
>> Jim
>> WA0LYK
>>
>> 
>
>
>
>
> Announce your digital presence via our Interactive Sked Page at
> http://www.obriensweb.com/sked
>
>
> DRCC contest info : http://www.obriensweb.com/drcc.htm
>  
> Yahoo! Groups Links
>
>
>
>
>
>
>   

Re: [digitalradio] PACTO! I CQ

[kh6ty]

Copying you FB in South Carolina, Howard, using DigiPan 2.0.

Sorry - No Pactor 1 transmit capability - my PK-232 is in mothballs!

Skip


- Original Message - 
From: "w6ids" <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>
Sent: Friday, January 11, 2008 2:10 PM
Subject: [digitalradio] PACTO! I CQ


>
> Just for info, I'm on 18.085 running PACTOR I and
> calling CQ.pointed Westerly.
>
> I'm posted on the spotting page:
>
> http://www.projectsandparts.com/pactor/
>
> if anyone might be interested.in trying it
>
> Howard W6IDS
> Richmond, IN
>





No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.1/1219 - Release Date: 1/11/2008 
10:19 AM

Re: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm

[Steinar Aanesland]

Thanks Robert,  I support you 100%

73 de LA5VNA Steinar


n4ijs skrev:
>
> Hello!
>
> I am new to this forum, so please forgive me if this comes across off
> base. But, I came here looking for information on digital modes for
> Amateur Radio - not various, multi-post messages about various peoples
> opinion (and arguments) on unrelated topics.
>
> I am sure that these discussions are important to a select group of
> folks, but are there no other places for these types of discussions to
> take place?
>
> I belong to several Ham related Yahoo! forums and this one certainly
> produces (by far) the most emails; however, few are related to the
> topic at hand. So, I have to weed through these other messages to get
> to the "real" ones.
>
> If this just the way of this forum, that's fine - I will just
> unsubscribe. I hope that isn't the case, but, if it is, can anyone
> recommend a forum for exploring digital modes within Ham Radio?
>
> Thanks and 73,
> Robert - N4IJS
>
> --- In digitalradio@yahoogroups.com 
> , "Rud Merriam" <[EMAIL PROTECTED]> 
> wrote:
> >
> > In Katrina and Rita shelters were opened where there were people in
> need.
> > Whether supplies could readily reach them was a problem to be
> solved, not a
> > requirement for shelter location. You are not understanding the
> widespread
> > nature of these disasters. It was easier to solve the supply problem
> than
> > the rescue problem.
> >
> > A supply truck or helicopter with supplies can make it in once a
> day. The
> > multiple vehicles, trucks or helicopters, to evacuate people were not
> > available.
> >
> > Your "hypothetical" versus others "real world" experience is
> misleading you.
> >
> >
> > Rud Merriam K5RUD
> > ARES AEC Montgomery County, TX
> > http://TheHamNetwork.net 
> >
> >
> >
> > Your first paragraph indicates that the shelter was so remote and
> isolated
> > that it required helicopter delivery of food and water. Yet you also
> > indicate that you were in your truck which indicates you could drive
> to the
> > shelter. Maybe you were driving a monster truck? Some of this
> appears to be
> > an appeal to emotion.
> >
> > I HAVE been around long enough to know neither the ARC or SA would
> open a
> > shelter in a location that was not reachable by regular supply
> vehicles nor
> > that had SOME kind of communications. I am pretty sure that the
> government
> > authorities would not authorize this either. To do otherwise is simply
> > asking for the shelter staff to require 'rescuing' at some time in the
> > future thereby adding to the problem.
> > Consequently, when you say no communications, you are overstating
> the facts.
> > Now maybe, a runner in a vehicle may the only means of
> communication, but
> > never the less, it is communications.
> >
> >
> >
> > Jim
> > WA0LYK
> >
>
>  

[digitalradio] PACTO! I CQ

[w6ids]

Just for info, I'm on 18.085 running PACTOR I and 
calling CQ.pointed Westerly.

I'm posted on the spotting page:

http://www.projectsandparts.com/pactor/

if anyone might be interested.in trying it 

Howard W6IDS
Richmond, IN

[digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm

[n4ijs]

Hello!

I am new to this forum, so please forgive me if this comes across off
base.  But, I came here looking for information on digital modes for
Amateur Radio - not various, multi-post messages about various peoples
opinion (and arguments) on unrelated topics.

I am sure that these discussions are important to a select group of
folks, but are there no other places for these types of discussions to
take place?  

I belong to several Ham related Yahoo! forums and this one certainly
produces (by far) the most emails; however, few are related to the
topic at hand.  So, I have to weed through these other messages to get
to the "real" ones.

If this just the way of this forum, that's fine - I will just
unsubscribe.  I hope that isn't the case, but, if it is, can anyone
recommend a forum for exploring digital modes within Ham Radio?

Thanks and 73,
Robert - N4IJS


--- In digitalradio@yahoogroups.com, "Rud Merriam" <[EMAIL PROTECTED]> wrote:
>
> In Katrina and Rita shelters were opened where there were people in
need.
> Whether supplies could readily reach them was a problem to be
solved, not a
> requirement for shelter location. You are not understanding the
widespread
> nature of these disasters. It was easier to solve the supply problem
than
> the rescue problem. 
> 
> A supply truck or helicopter with supplies can make it in once a
day. The
> multiple vehicles, trucks or helicopters, to evacuate people were not
> available. 
> 
> Your "hypothetical" versus others "real world" experience is
misleading you.
> 
>  
> Rud Merriam K5RUD 
> ARES AEC Montgomery County, TX
> http://TheHamNetwork.net
> 
> 
> 
> Your first paragraph indicates that the shelter was so remote and
isolated
> that it required helicopter delivery of food and water.  Yet you also
> indicate that you were in your truck which indicates you could drive
to the
> shelter.  Maybe you were driving a monster truck? Some of this
appears to be
> an appeal to emotion.  
> 
> I HAVE been around long enough to know neither the ARC or SA would
open a
> shelter in a location that was not reachable by regular supply
vehicles nor
> that had SOME kind of communications.  I am pretty sure that the
government
> authorities would not authorize this either.  To do otherwise is simply
> asking for the shelter staff to require 'rescuing' at some time in the
> future thereby adding to the problem. 
> Consequently, when you say no communications, you are overstating
the facts.
> Now maybe, a runner in a vehicle may the only means of
communication, but
> never the less, it is communications.
> 
> 
> 
> Jim
> WA0LYK
>

RE: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm

[Rud Merriam]

In Katrina and Rita shelters were opened where there were people in need.
Whether supplies could readily reach them was a problem to be solved, not a
requirement for shelter location. You are not understanding the widespread
nature of these disasters. It was easier to solve the supply problem than
the rescue problem. 

A supply truck or helicopter with supplies can make it in once a day. The
multiple vehicles, trucks or helicopters, to evacuate people were not
available. 

Your "hypothetical" versus others "real world" experience is misleading you.

 
Rud Merriam K5RUD 
ARES AEC Montgomery County, TX
http://TheHamNetwork.net



Your first paragraph indicates that the shelter was so remote and isolated
that it required helicopter delivery of food and water.  Yet you also
indicate that you were in your truck which indicates you could drive to the
shelter.  Maybe you were driving a monster truck? Some of this appears to be
an appeal to emotion.  

I HAVE been around long enough to know neither the ARC or SA would open a
shelter in a location that was not reachable by regular supply vehicles nor
that had SOME kind of communications.  I am pretty sure that the government
authorities would not authorize this either.  To do otherwise is simply
asking for the shelter staff to require 'rescuing' at some time in the
future thereby adding to the problem. 
Consequently, when you say no communications, you are overstating the facts.
Now maybe, a runner in a vehicle may the only means of communication, but
never the less, it is communications.



Jim
WA0LYK

Re: [digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm

[Les Warriner]

You have led a sheltered life.  Try operating in the Philipines after 
a volcano blows, or in Mexico after the same incident, or in Africa 
after a transvaal fire,  then tell me Hams are not needed.  It's too 
bad we are getting comments like this from the uninformed with no 
experience. Get some beard growth and you'll rapidly change your mind.


73

Les

At 08:13 AM 1/11/2008, jgorman01 wrote:

--- In 
digitalradio@yahoogroups.com, 
Alan Barrow <[EMAIL PROTECTED]> wrote:

>
> ""snip""
>
> I personally had a Red Cross shelter leader run after my truck and
> flag me down because she thought we were packing up. quote: "You
> don't know how much we still need you guys. Until you arrived we had
> no communications since the big green helicopter landed and kicked
> out pallets or MRE's. The phones still don't work, please do not
> leave."
>
> Don't think that did not change my perspective and disillusionment.
> This is not an ego thing, exactly the opposite. Made me realize that
> independent of what I thought we could or should do (my ego), we had
> a job to do. I should set aside my annoyances & preferences, that
> what we were doing was important and needed.

Your first paragraph indicates that the shelter was so remote and
isolated that it required helicopter delivery of food and water. Yet
you also indicate that you were in your truck which indicates you
could drive to the shelter. Maybe you were driving a monster truck?
Some of this appears to be an appeal to emotion.

I HAVE been around long enough to know neither the ARC or SA would
open a shelter in a location that was not reachable by regular supply
vehicles nor that had SOME kind of communications. I am pretty sure
that the government authorities would not authorize this either. To
do otherwise is simply asking for the shelter staff to require
'rescuing' at some time in the future thereby adding to the problem.
Consequently, when you say no communications, you are overstating the
facts. Now maybe, a runner in a vehicle may the only means of
communication, but never the less, it is communications.

""snip""

> I guess the core difference is some are saying we have no business
> even providing emergency service. And I believe that is a very
> extreme and unsound position.
>

Your guess is wrong. No one I have seen post is saying that we have
no business providing emergency communications where appropriate and
in a manner that support the public best.

>
> ""snip""
>
> So what's this have to do with digital radio? I think we have a
> large opportunity to contribute. We all want an alternative to $1k
> proprietary modems. But until we get that alternative there is some
> value there.
>
> That does not mean we can or should compromise operation in the rest
> of the bands. But there needs to be a place. Just like there should
> be for other digital modes, current and future.
>
> The whole idea that a legal limit rtty contest op is somehow
> appropriate & allowed, yet other digi sigs should not be is
> non-sensical. Some of the new modes offer incredible performance &
> efficiency. they can be fun for casual work. But they could also
> offer significant value in an emergency if harnessed.
>

You might have continued and made an argument for full blown pactor 3
bandwidth for emergencies but you blew it by including casual use. The
use of wide signals within a limited spectrum WILL displace several
others that want to use narrow signals. It is obvious that you have
no love for rtty, yet several rtty signals can fit into the bandwidth
of a 2.2 kHz pactor 3 signal. Would you impinge upon their preferred
mode of operation for your casual use? It sounds like it. No one is
guaranteed a time or place to operate. The wider the signal you wish
to use, the fewer places and times there are that you can use it.
That's life, move on.

I also assume you are upset over rm-11392 that would limit bandwidths.
You really haven't made a case for casual use of anything wider than
the 1.5 kHz that is being asked for. Remember, this bandwidth limit
has been there for a long time, it just wasn't codified. The current
rules were adequate prior to the introduction of ofdm modulation to
the amateur bands. Pactor 3 is simply EXPLOITING a loophole in the
way that the regulations are currently written. Perhaps you should
write a comment to the fcc that you believe bandwidth limits are ok
for all data modes except for ofdm emissions which should have no
limits on their bandwidth. It sounds like that is what you wish.

> ""snip""
>
> Have fun,
>
> Alan
>

Jim
WA0LYK


No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.0/1218 - Release Date: 
1/10/2008 1:32 PM

[digitalradio] Re: Emergency agencies/ ham equipment/ hams in emcomm

[jgorman01]

--- In digitalradio@yahoogroups.com, Alan Barrow <[EMAIL PROTECTED]> wrote:
>
> ""snip""
> 
> I personally had a Red Cross shelter leader run after my truck and 
> flag me down because she thought we were packing up. quote: "You 
> don't know how much we still need you guys. Until you arrived we had
> no communications since the big green helicopter landed and kicked 
> out pallets or MRE's. The phones still don't work, please do not 
> leave."
> 
> Don't think that did not change my perspective and disillusionment. 
> This is not an ego thing, exactly the opposite. Made me realize that
> independent of what I thought we could or should do (my ego), we had
> a job to do. I should set aside my annoyances & preferences, that 
> what we were doing was important and needed.

Your first paragraph indicates that the shelter was so remote and
isolated that it required helicopter delivery of food and water.  Yet
you also indicate that you were in your truck which indicates you
could drive to the shelter.  Maybe you were driving a monster truck?
Some of this appears to be an appeal to emotion.  

I HAVE been around long enough to know neither the ARC or SA would
open a shelter in a location that was not reachable by regular supply
vehicles nor that had SOME kind of communications.  I am pretty sure
that the government authorities would not authorize this either.  To
do otherwise is simply asking for the shelter staff to require
'rescuing' at some time in the future thereby adding to the problem. 
Consequently, when you say no communications, you are overstating the
facts.  Now maybe, a runner in a vehicle may the only means of
communication, but never the less, it is communications.


""snip""


> I guess the core difference is some are saying we have no business 
> even providing emergency service. And I believe that is a very 
> extreme and unsound position.
>

Your guess is wrong.  No one I have seen post is saying that we have
no business providing emergency communications where appropriate and
in a manner that support the public best.

> 
> ""snip"" 
>
> So what's this have to do with digital radio? I think we have a 
> large opportunity to contribute. We all want an alternative to $1k 
> proprietary modems. But until we get that alternative there is some 
> value there. 
>
> That does not mean we can or should compromise operation in the rest
> of the bands. But there needs to be a place. Just like there should 
> be for other digital modes, current and future.
> 
> The whole idea that a legal limit rtty contest op is somehow 
> appropriate & allowed, yet other digi sigs should not be is 
> non-sensical. Some of the new modes offer incredible performance & 
> efficiency. they can be fun for casual work. But they could also 
> offer significant value in an emergency if harnessed.
> 

You might have continued and made an argument for full blown pactor 3
bandwidth for emergencies but you blew it by including casual use. The
use of wide signals within a limited spectrum WILL displace several
others that want to use narrow signals.  It is obvious that you have
no love for rtty, yet several rtty signals can fit into the bandwidth
of a 2.2 kHz pactor 3 signal.  Would you impinge upon their preferred
mode of operation for your casual use?  It sounds like it.  No one is
guaranteed a time or place to operate.  The wider the signal you wish
to use, the fewer places and times there are that you can use it. 
That's life, move on.

I also assume you are upset over rm-11392 that would limit bandwidths.
 You really haven't made a case for casual use of anything wider than
the 1.5 kHz that is being asked for.  Remember, this bandwidth limit
has been there for a long time, it just wasn't codified.  The current
rules were adequate prior to the introduction of ofdm modulation to
the amateur bands.  Pactor 3 is simply EXPLOITING a loophole in the
way that the regulations are currently written.  Perhaps you should
write a comment to the fcc that you believe bandwidth limits are ok
for all data modes except for ofdm emissions which should have no
limits on their bandwidth.  It sounds like that is what you wish.


> ""snip""
> 
> Have fun,
> 
> Alan
>


Jim
WA0LYK

[digitalradio] Re: Curmudgions and an idea for digital operation

[jgorman01]

I've been remiss in answering some of your questions.  You'll either
have the start of a pactor type emission or an illegal emission type.  

I had this argument several years ago when pactor 3 showed up.  If you
look at J7D, it is defined as "Single-sideband, suppressed carrier;
with two or more channels containing quantized or digital information;
consisting of data transmission, telemetry, telecommand.  I'm still
not sure how pactor 3 got designated as J2D rather than J7D.  The only
answer I got was that pactor 3 modems are designed to be connected to
one computer at a time and the single data stream is multiplexed over
all the "tones" that are in use.  In other words, the modem itself is
not a multiplexing device and there are not "individual" channels for
different data streams.  It seems to me that if you did the
multiplexing in your computer so that you end up with only one data
stream and did not dedicate psk channels to a given data channel then
you would be ok.  This would require some "demuxing" at the far end
computer.

You'll need to be careful in your design to make sure it doesn't get
classed as J7D, which is not allowed on the amateur bands.

Jim
WA0LYK

--- In digitalradio@yahoogroups.com, Alan Barrow <[EMAIL PROTECTED]> wrote:
>
>""snip""
> 
> But back to digital radio I've got an idea to stack 3 psk 
> signals together side by side and run in a normal SSB radio. 
> Multiplex the data across the multiple psk paths. I think that would
> be legal, and technically possible. No restriction I see on multiple
> transmissions with different data streams.  Any single signal meets 
> symbol rate & bandwidth fcc restrictions even as proposed by the new
> petition. Might could even do 4! Or maybe do the same with Pactor 1 
> to get ARQ, already looking at the linux source.
> 
> Kind of like the fsk/afsk debate. Is it a different mode if you 
> can't tell the signal's apart remotely? Turing test for radio.
> 
> That's what I'll move to if we ban the wider data modes. Think it 
> will work?
> 
> Have fun,
> 
> Alan
>

Re: [digitalradio] Software for the digital ham that multi-tasks while sleeping ?

[Simon Brown]

In my own case I can record the incoming audio and play it back later.

At the moment I leave DM780 running all night picking up SSTV pictures.

I'm not sure I would want a scheduler but were I to add one I would use a UI 
similar to Outlook's calendar.

Simon Brown, HB9DRV

- Original Message - 
From: "Peter G. Viscarola" <[EMAIL PROTECTED]>
>
> What you're describing could be done quite easily from within a
> particular program.  It could easily be built as an external program
> that sends ActiveX commands to MixW, for example.
>

RE: [digitalradio] Software for the digital ham that multi-tasks while sleeping ?

[Peter G. Viscarola]

>
>
>Anyone care to invent this ?
>

What you're describing could be done quite easily from within a
particular program.  It could easily be built as an external program
that sends ActiveX commands to MixW, for example.

The only hang-up that I see is in terms of tuning:  So, you tune to
14070 in PSK31 mode and listen for 20 minutes, or whatever.  Suppose the
station is on 14070.5?

My point is that especially with these narrow modes, wouldn't what
you're describing require activity directly on the frequency in
question?  PSK31 tuning is pretty fussy.

de Peter K1PGV

Re: [digitalradio] Software for the digital ham that multi-tasks while sleeping ?

[Jose A. Amador]

Andy,

I believe that somehow it has been already done and is hidden to most of us.

How ?

I have not tried to run the recent Linux ham apps from the command line, 
but the cron can be used to start and stop tasks in one minute 
intervals. You can invoke either applications or scripts with arguments.

Years ago (some 8+ years ago), I used the FBB cron to switch bands with 
an automatic antenna tuner / switch, that even allowed remote QSY of the 
BBS with a simple CAT program I wrote for the FT-757.

I am crossposting this reply to both linuxham* lists and the WSJT Group, 
because that even when I have not done it, somebody might already have 
done it and might comment about this.

73,

Jose, CO2JA

--

Andrew O'Brien wrote:

> If you are like me, there is SO MUCH happening in the amateur radio
> digital world that it is hard to keep up with ,  more fun to be had
> than can be squeezed in to 24 hours.  Some software ,like WSJT,  can
> be left active overnight or when out of the shack and the user gets
> time stamped information about stations detected while they were out.
> This is very useful but it is static, simply monitoring one frequency
> and one mode.   What would it take to develop an application that can
> scan different frequencies at larger time intervals that the "scan
> mode" in modern rigs.  Perhaps something that is user defined.
> Something that might monitor 14070 for 15 minutes and then
> automatically move to 3581 for an hour , then to 7034 for 30 minutes .
>  Not only would this software change frequency at designated times,
> it might switch modes too.  Listening on 14070 in PSK31 ,  changing to
> JT65A and QSYing to 14076 for 20 minutes,  and even listening  to
> Olivia on 3581 , etc etc.  I guess this could be a major add-on to
> something like Multipsk or DM780 but maybe it would take another form
> , something akin to DX Lab Launcher.  DX Lab Launcher enables the user
> to launch varying DX Lab Suit applications , something like this could
> be used to launch and close different applications at specified times.
>  Example:  At 1400Z it launches Winwarbler in RTTY mode, at 1500 it
> closes Winwarbler and  launches Multipsk in Olivia 500/16 and at 1700
> it launches VB-Digi/FLARQ in PSK250 .
> 
> 
> Anyone care to invent this ?
> 


-- 
MSc. Jose Angel Amador Fundora
Departamento de Telecomunicaciones
Facultad de Ingenieria Electrica, CUJAE
Calle 114 #11901 e/ 119 y 127
Marianao 19390, Ciudad de la Habana, Cuba
Tel:(53 7) 266-3445
Email: [EMAIL PROTECTED]


__

Participe en Universidad 2008.
11 al 15 de febrero del 2008.
Palacio de las Convenciones, Ciudad de la Habana, Cuba
http://www.universidad2008.cu

Re: [digitalradio] Robust Packet-Radio (RPR)

[Jack Chomley]

At 09:27 PM 1/11/2008, Andy  wrote:

>I found the item (below) on the SCS web site. Anyone use this "new
>class" of packet ?
>
>Robust Packet-Radio (RPR)
>
>Up to now Packet-Radio over shortwave has been basically a
>non-starter, it has even been heavily criticized because of the low
>effective throughput and repeats. AX.25 is for shortwave not an ideal
>protocol, but with automatic FRack-setting and a small MAXFrame value
>the protocol should, however, function much better on a shortwave
>channel than has previously been the case generally.
>
>One cannot of course expect an asynchrone protocol to reach the same
>efficiency as a tight synchrone ARQ protocol (e.g. PACTOR), but for
>some applications a multi-user service, with very uncritical
>transmit/receive switching, as well as almost zero power holding up a
>connection when no data passing, brings a real advantage that
>outweighs the lower data throughput.
>
>What finally are the reasons that up to now HF-PR works so poorly, and
>apart from "forwarding" is hardly ever used? One finds a simple
>answer: The current modulation type for HF-PR namely uncoded 300 Bd
>FSK is really unsuitable for normal HF channels. The symbols are much
>too short even with moderate "Multi-Path effect" ("delay spread") to
>work. Additionally, because no sort of error correction code is used,
>even short troughs or "static" will destroy a many seconds long
>Packet. Just one missing bit leads to a repeat of the whole packet.
>
>To help cure this problem, SCS has developed a new class of robust
>modulations types especially for Packet-Radio. As a special feature
>for all the variants of this "Robust PR", a completely new
>synchronizations algorithm with "catch" properties that were not
>possible before has been realized. Frequency deviations of ±250 Hz are
>immediately recognized and without any loss of sensitivity
>compensated, and this with signals that are buried deep in the noise.
>Because of this it's possible to remove a tuning display. One can say
>with good conscience that this is "Plug and Play" for shortwave.
>
>The currently available "Robust PR" modulation types have the
>following properties:
>Bandwidth:500 Hz @ -30 dB
>Modulation:Pulse-Shaped OFDM (BPSK, QPSK), similar to PACTOR-III
>Average Throughput:200 or 600 Bit/sec
>Crestfaktor:3.0 or 4.2 dB
>Delay-Spread:up to ±8 msec is tolerated
>Coding:High performance convolutional code, "full-frame interleaved",
>rate/2 or rate3/4
>
>Digipeater and APRS Gateway
>
>DB0UAL
>DialModePath
>3610.0 USBRPRAPRS DB0UAL
>14102.0 USBRPRAPRS DB0UAL
>APRS Gateway
>
>XY0XYZ
>DialModePath
>10147.3 USBRPR FSK300APXY RELAY WIDE
>14103.3 LSBRPR FSK300APXY RELAY WIDE
>
>DH1TI
>DialModePath
>10147.3 USBRPRAPRS
>
>OE3XMU-4
>DialModePath
>10147.3 USBRPR FSK300APRS
>
>OE3KJN
>DialModePath
>10147.3 USBRPRAPRS
>
>ZS1AAZ
>DialModePath
>10147.3 USBRPRAPRS
>
>Note:
>
>To use the following features you need the 
>current Firmware for the SCS DSP-TNC:
>
>Legende:
>
>Recommendation: For transmitting position data with the Tracker/DSP
>TNC, we suggest always to use the frequencies as shown in the list
>with the respective sideband. The position data can then be
>transmitted either only in RPR, or in RPR and FSK alternately (%AH =
>1). In both operating conditions all physical channels are then
>automatically set in the correct way.
>
>(In case of an alternating transmission, i.e. %AH = 1, the Tracker
>automatically uses %F = 2000 Hz, in order to set the correct interval
>of 500 Hz between RPR and FSK channels without any user intervention.)
>
>With gateways offering RPR and FSK 300 on one channel simultaneously,
>it is assumed that the center audio frequency of the FSK demodulator
>(%F-parameter) is 500 Hz higher than the center audio frequency of the
>RPR demodulator. The space between the center frequencies of a
>simultaneous FSK/RPR channel pair is always 500 Hz.
>
>Basically, gateways receiving RPR and FSK300 simultaneously can also
>be reached in FSK300 with the %F standard setting of the Tracker
>(center frequency of 1700 Hz) in LSB mode.
>
>In this case, if LSB is actually used, 3.7 kHz have to be added to the
>figure shown in USB dial frequency listings. In case of an LSB
>channel, 0.3 kHz have to be deducted from the listed frequency.
>Gateways shown in the list as 10147.3 kHz USB can hence be reached in
>LSB mode with the standard setting of the Tracker (%F = 1700 Hz, %AH =
>0) on the standard dial frequency of 10151.0 kHz. Gateways listed as
>14103.3 kHz LSB, can be reached in LSB with the default setting of the
>Tracker (%F = 1700, %AH = 0) on the standard dial frequency of 14103.0
>kHz.
>
>In case of alternating RPR and FSK transmissions (%AH = 1), the
>frequencies shown in the list and the respective side bands have to be
>programmed. For example, the dial frequencies of 10151.0 kHz LSB or
>14103.0 kHz USB MUST NOT be set, as neither the RPR, nor the FSK
>channel would be reached correctly.
>
>--
>Andy K3UK
>www.obriensweb.com
>(QSL via N

Re: [digitalradio] Ale Sounding: What is it and how does it work?

[Steve Hajducek]

John,

Your message below is easy to summarize  succinctly, thanks.

At 09:48 PM 1/10/2008, you wrote:
>
>Chris , ZL1BOE
>
>you will be told by others that ALE is widely 
>used to set up QSO’s and QSY’s using the one 
>line message ability . You will also be told 
>that it is used widely for keyboard to keyboard 
>QSO’s and that there are thousands of Hams using 
>ALE ( last figure I heard was 6000) . These are 
>folks who are using PCALE, who have aggressively 
>set aside frequencies for ALE use in all bands, 
>and are promoting ALE as the answer to emergency communications.

FALSE


>
>Granted, PCALE, in its MARS form may be a great 
>piece of software to pass messages from overseas

TRUE

NOTE: MARS does not make use of ALE for OCONUS traffic relay.

>  but that ability is certainly not evident on the ham bands.

FALSE


>
>The reality is that there are likely under 50 
>hams active with PCALE  worldwide, those using 
>PCALE spend most of the time sounding , with 
>little , if any message traffic passed, and no 
>QSO’s. PCALE does not work very well into the 
>noise, and is certainly not user friendly when 
>setting up a rig and computer to run the 
>program. Beyond using the sounding function 
>there appears not to be much interest in running 
>nets, or exploring emergency communications aspect of PCALE.

FALSE


>
>ALE400 (multiPSK) might be closer to your needs 
>since it is narrow band and works well into the 
>noise. It can be readily used for soundings, 
>file transfer, and is a pleasure to use for 
>digital QSO’s, keyboard to keyboard. The author 
>is constantly working on the software, and 
>appears to be moving closer to the Holy Grail of 
>being able to pass messages and files from HF to 
>the internet. It is simple to install, simple to 
>use, (although the screen can be a little 
>overwhelming at first)  .There is a plan afoot 
>which would see some extensive cross Canada 
>testing of this mode to determine it’s 
>suitability for emergency communications.

TRUE


>
>There are some other software out there to look 
>at. NBEMS has promise, but , since it uses BPSK 
>for the most part, suffers from multipath 
>flutter and other ozone maladies. The authors 
>state that it’s intention was to run over 
>VHF/UHF, and , while I haven’t tried it, would 
>probably work very well. This software is also 
>under active development so will be interesting 
>to see what other capabilities it will have.

TRUE


>
>RFSM8000  gets very little mention  on these 
>reflectors, since hams in the USA cannot exceed 
>300baud speed. Dimitry and his team have posted 
>the latest version which looks interesting , but 
>haven’t tried it, but is something we can run 
>here in Canada on most bands except 30m.( 
>bandwidth issues rather than speed)  It 
>apparently has the ability to pass traffic to 
>and from the internet from HF, using a sound card modem.

TRUE


>
>So much software, so little time……….

SO TRUE

/s/ Steve, N2CKH


>
>73’s John
>VE5MU
>

[digitalradio] Software for the digital ham that multi-tasks while sleeping ?

[Andrew O'Brien]

If you are like me, there is SO MUCH happening in the amateur radio
digital world that it is hard to keep up with ,  more fun to be had
than can be squeezed in to 24 hours.  Some software ,like WSJT,  can
be left active overnight or when out of the shack and the user gets
time stamped information about stations detected while they were out.
This is very useful but it is static, simply monitoring one frequency
and one mode.   What would it take to develop an application that can
scan different frequencies at larger time intervals that the "scan
mode" in modern rigs.  Perhaps something that is user defined.
Something that might monitor 14070 for 15 minutes and then
automatically move to 3581 for an hour , then to 7034 for 30 minutes .
 Not only would this software change frequency at designated times,
it might switch modes too.  Listening on 14070 in PSK31 ,  changing to
JT65A and QSYing to 14076 for 20 minutes,  and even listening  to
Olivia on 3581 , etc etc.  I guess this could be a major add-on to
something like Multipsk or DM780 but maybe it would take another form
, something akin to DX Lab Launcher.  DX Lab Launcher enables the user
to launch varying DX Lab Suit applications , something like this could
be used to launch and close different applications at specified times.
 Example:  At 1400Z it launches Winwarbler in RTTY mode, at 1500 it
closes Winwarbler and  launches Multipsk in Olivia 500/16 and at 1700
it launches VB-Digi/FLARQ in PSK250 .


Anyone care to invent this ?

-- 
Andy K3UK
www.obriensweb.com
(QSL via N2RJ)

[digitalradio] Robust Packet-Radio (RPR)

[Andrew O'Brien]

I found the item (below) on the SCS web site.  Anyone use this  "new
class"  of packet ?


Robust Packet-Radio (RPR)

Up to now Packet-Radio over shortwave has been basically a
non-starter, it has even been heavily criticized because of the low
effective throughput and repeats. AX.25 is for shortwave not an ideal
protocol, but with automatic FRack-setting and a small MAXFrame value
the protocol should, however, function much better on a shortwave
channel than has previously been the case generally.

One cannot of course expect an asynchrone protocol to reach the same
efficiency as a tight synchrone ARQ protocol (e.g. PACTOR), but for
some applications a multi-user service, with very uncritical
transmit/receive switching, as well as almost zero power holding up a
connection when no data passing, brings a real advantage that
outweighs the lower data throughput.

What finally are the reasons that up to now HF-PR works so poorly, and
apart from "forwarding" is hardly ever used? One finds a simple
answer: The current modulation type for HF-PR namely uncoded 300 Bd
FSK is really unsuitable for normal HF channels. The symbols are much
too short even with moderate "Multi-Path effect" ("delay spread") to
work. Additionally, because no sort of error correction code is used,
even short troughs or "static" will destroy a many seconds long
Packet. Just one missing bit leads to a repeat of the whole packet.

To help cure this problem, SCS has developed a new class of robust
modulations types especially for Packet-Radio. As a special feature
for all the variants of this "Robust PR", a completely new
synchronizations algorithm with "catch" properties that were not
possible before has been realized. Frequency deviations of ±250 Hz are
immediately recognized and without any loss of sensitivity
compensated, and this with signals that are buried deep in the noise.
Because of this it's possible to remove a tuning display. One can say
with good conscience that this is "Plug and Play" for shortwave.

The currently available "Robust PR" modulation types have the
following properties:
Bandwidth:  500 Hz @ -30 dB
Modulation: Pulse-Shaped OFDM (BPSK, QPSK), similar to PACTOR-III
Average Throughput: 200 or 600 Bit/sec
Crestfaktor:3.0 or 4.2 dB
Delay-Spread:   up to ±8 msec is tolerated
Coding: High performance convolutional code, "full-frame interleaved",
rate/2 or rate3/4

Digipeater and APRS Gateway

DB0UAL
DialModePath
3610.0 USB  RPR APRS DB0UAL
14102.0 USB RPR APRS DB0UAL
APRS Gateway

XY0XYZ
DialModePath
10147.3 USB RPR FSK300  APXY RELAY WIDE
14103.3 LSB RPR FSK300  APXY RELAY WIDE

DH1TI
DialModePath
10147.3 USB RPR APRS

OE3XMU-4
DialModePath
10147.3 USB RPR FSK300  APRS

OE3KJN
DialModePath
10147.3 USB RPR APRS

ZS1AAZ
DialModePath
10147.3 USB RPR APRS

Note:

To use the following features you need the current Firmware for the SCS DSP-TNC:

Legende:

Recommendation: For transmitting position data with the Tracker/DSP
TNC, we suggest always to use the frequencies as shown in the list
with the respective sideband. The position data can then be
transmitted either only in RPR, or in RPR and FSK alternately (%AH =
1). In both operating conditions all physical channels are then
automatically set in the correct way.

(In case of an alternating transmission, i.e. %AH = 1, the Tracker
automatically uses %F = 2000 Hz, in order to set the correct interval
of 500 Hz between RPR and FSK channels without any user intervention.)

With gateways offering RPR and FSK 300 on one channel simultaneously,
it is assumed that the center audio frequency of the FSK demodulator
(%F-parameter) is 500 Hz higher than the center audio frequency of the
RPR demodulator. The space between the center frequencies of a
simultaneous FSK/RPR channel pair is always 500 Hz.

Basically, gateways receiving RPR and FSK300 simultaneously can also
be reached in FSK300 with the %F standard setting of the Tracker
(center frequency of 1700 Hz) in LSB mode.

In this case, if LSB is actually used, 3.7 kHz have to be added to the
figure shown in USB dial frequency listings. In case of an LSB
channel, 0.3 kHz have to be deducted from the listed frequency.
Gateways shown in the list as 10147.3 kHz USB can hence be reached in
LSB mode with the standard setting of the Tracker (%F = 1700 Hz, %AH =
0) on the standard dial frequency of 10151.0 kHz. Gateways listed as
14103.3 kHz LSB, can be reached in LSB with the default setting of the
Tracker (%F = 1700, %AH = 0) on the standard dial frequency of 14103.0
kHz.

In case of alternating RPR and FSK transmissions (%AH = 1), the
frequencies shown in the list and the respective side bands have to be
programmed. For example, the dial frequencies of 10151.0 kHz LSB or
14103.0 kHz USB MUST NOT be set, as neither the RPR, nor the FSK
channel would be reached c

[digitalradio] Seventh ANNUAL 070 CLUB PSKFEST 12 January 2008

[Andrew O'Brien]

Seventh ANNUAL 070 CLUB PSKFEST
Sponsored by the Penn-Ohio DX Society (PODXS)



  PURPOSE
  To work as many stations as possible in the allotted time using
PSK31 mode.


  ENTRY CATEGORIES
   (SINGLE OP ONLY)
  QRP Single Band (max power 5 watts output)
  QRP Multiband (max power 5 watts output)
  Low Power (max power 50 watts output)
  Medium Power (max power 100 watts output).

  DATE: Z-2400Z, 12 January 2008

  EXCHANGE:
  Call sign, signal report and state/province/country (SPC). Call
"CQ PSKFEST".

  BANDS:
  80 thru 10 meters, no WARC bands. Work each station once/band.
  All contacts must be 2-way PSK31.
  No repeater, cross-mode or cross-band contacts allowed.

  SCORING:
  QSO points - Each contact counts one (1) QSO point, dupes count
(0) points.
  Multipliers - Each different state/province/country (SPC)
worked. Use current ARRL
  DXCC list for country reference.

  Final Score = (Total QSO Points) x (Total Different SPC's).

  Scoring Notes:
  First U.S. station worked counts as two (2) multipliers (country
and state).
  First VE station worked counts as two (2) multipliers (country
and province).
  First Alaska station worked counts as two (2) multipliers
(country and state).
  First Hawaii station worked counts as two (2) multipliers
(country and state).

  AWARDS: Top score will receive a trophy, courtesy of the
Penn-Ohio DX Society (PODXS). Top scores from each continent will
receive a certificate. All 070 Club member entries received will
automatically qualify for an Attaboy. For more info on the 070 Club
check out
  .

  ENTRIES: Send log data showing date, time(z), band, exchange
received and claimed score. For entries with 100 contacts or more
include a dupe sheet listing contacts in call sign alphanumeric order.
Be sure to also include your call sign, address, e-mail address, entry
class and 070 Club member number if applicable. Send your entry as a
.txt file via E-mail (best way) to <[EMAIL PROTECTED]> or via
post to:

JAY BUDZOWSKI
070 CLUB PSKFEST
109 S. NORTHVIEW AVE.
NEW CASTLE, PA 16102-1633 USA

  All entries must be received by February 15, 2008. A listing of
logs received and claimed scores will be posted on the 070 Club web
site .
Entries with excessive dupes will be listed as check logs. All entries
are subject to verification.



  PSKFEST LINKS:
  Rules - .
  2008 Results -
.
  Results Archives -
.
  PODXS 070 Club - .



The Penn-Ohio DX Society (PODXS) reserves the right to
disqualify entries deemed not in accordance with the above rules or
contrary to the spirit of this event. Please direct all inquiries
regarding this event to <[EMAIL PROTECTED]>73 de Jay N3DQU
  ---




-- 
Andy K3UK
www.obriensweb.com
(QSL via N2RJ)