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 N2RJ)
Its been around for a while :-) Works well too.
But dontcha know?....Packet is no good, its
outdated, can't stream Video across it.......
Go ALE? 6000 Hams can't be wrong.....;-)
73s
Jack VK4JRC
