Order Tray | Contact Us | Home | SIG Lists

[aprssig] APRS Bandwidth

Bob Bruninga bruninga at usna.edu
Tue Jun 23 15:55:09 UTC 2009

Agree completely with Keith.  We began the APRS channel on 30m back in 1983 with the Vic-20/C64 BBS/gateway system and then it evolved to APRS, but from day one, there was never any desire for digipeaters.  They consume bandwidth and jam the channel, block others that cannot hear it.

As keith says, the number one goal of any HF station should be to be a gateway for all signals heard.  This makes the APRS 30m channel be one of the largest spacial-diversity reception systems on HF.  If any station anywhere decodes the signal and injects it into the APRS-IS, then the probability is very much higher than conventional point-to-point communications.

With APRS HF gateways there is a path open somewhere sometimes most of the time.

A concomitant problem thought is how to handle 2-way igates.  Generally, they are discouraged, because they cannot tell which one can hear the mobile or remote station best, and so if even two of them TX at the same time, there is a collision and the link fails.  THere could be an IGate negotiation algorithm, but none of the IGate code has implemented anything to resolve this problem.

Unlike VHF, there is no FM capture effect, and so we must avoid collisions on HF.

This includes prohibiting Digipeaters on HF.

I admit that I have not listened to the load on the 30m channel recently, but the propogation model on HF has not changed.

Bob, Wb4APR

---- Original message ----
>Date: Tue, 23 Jun 2009 08:26:07 -0700
>From: "Keith VE7GDH" <ve7gdh at rac.ca>  
>Subject: Re: [aprssig] APRS Bandwidth  
>To: "TAPR APRS Mailing List" <aprssig at tapr.org>
>Jim G0JXN wrote...
>> The UK Amateur Radio license no longer allows the operation of an APRS
>> digipeater without special permission (Notice of Variation) from the
>> regulator (Ofcom). It being filtered first through the RSGB.
>I think it's sad that the rules are so repressive in the UK when it
>comes to APRS. Not just there, but it is the amateurs themselves that
>should be setting most of the rules. In the UK it would be reasonable if
>RSGB took on that function.
>> I wish to run a digipeater on 10.151MHz (KAM) but am advised the it
>> would probably not be recommended by the RSGB because the bandwidth of
>> 300bd would exceed the 500Hz laid down in the IARU bandplan for 30m.
>> The implication being that we should not operate APRS on 30m at all.
>Regarding 500 Hz bandwidth... aren't 300 baud tones just 200 Hz apart?
>I viewed the reply from Chris G4HYG (most people will probably see
>it as a blank message with a text attachment) about Carson's rule...
>http://en.wikipedia.org/wiki/Carson_bandwidth_rule. Doesn't that apply
>to FM? See  For SSB, I would have thought the 200 Hz difference between
>the two tones would set the bandwidth.
>See http://www.apritch.myby.co.uk/hf.htm... yes, I see your name and
>callsign at the top of the page! I agree with almost everything on the
>page except the paragraph about digipeaters. There shouldn't be a need
>for a digi on HF. Unlike VHF where digis are needed  to extend the
>range, on HF, if there is propagation, everyone will hear whatever
>activity there is in the frequency. What would be valuable would be an
>IGate. A digi would just take up more airtime. Just think if a dozen HF
>digis sprouted up in the UK and Europe (or hundreds around the world)
>instead of everyone listening to mobile stations, they would be
>listening to the digis too, and if propagation was such that a few of
>them didn't hear the original beacon, they might hear the digipeated
>version from the fixed station, probably with a better antenna than the
>mobile station and possibly running more power. The implication should
>not be to discourage APRS on 30 M, done properly with 300 baud on
>SSB and not FM and well within the 500 Hz bandwidth recommended
>by IARU, but that digis should not be used on HF.
>73 es cul - Keith VE7GDH
>"I may be lost, but I know exactly where I am!"
>aprssig mailing list
>aprssig at tapr.org

More information about the aprssig mailing list