RPN digipeaters accept WIDE1-1 only Please 2-way IGATES on RPN Effective 30m RPR Network
    Operative Aspects of RPR-HF-APRS on Frequency 10147.30kHz

Selected Digipeaters Here an optimized network will be presented to prevent unrequested digipeating pile-ups. The 30m RPR-HF-network progressively suffers from high traffic by not coordinated signals. And because things need a name we may call it

Selected Digipeaters System

Why?
It has been shown that in Central Europe there is a problem with coordination of digipeating signals. There are technical and operational problems to be solved.
To prevent double & parallel digipeating it is nessecary that one digipeater knows what the other is doing.
First the DCD detection must hear that someone is transmitting to keep silence during that periode.
Second the APRS software must evaluate if digipeating is needed or if it just the original packet bounced back by another station which already has been treated. Combined with all user that wish to be digipeated only using WIDE1-1 in their path a smooth operation would be possible.
The main problem on HF is that not everybody on the frequency hears everybody else. Issues like MUF, ionosphere hops and local QSB hinder that. The other problem is that digipeating APRS programs need to be coordinated amoung the network's sysops. Then UI-View digipeater settings allow a variation in the timer for to check if it would just repeat something is has already repeated just because another digipeater repeated the original packet (inside check - not outside 'on air' check. This is different than stated here previously). It can be found under Dupe secs and allows any amount of seconds you wish (15 sec minimum as a starting point).
If you want to refresh UI-View knowledge base click this UI-View link. If you have already or want to optimize your UI-View towards the needs of UI-View Digipeater Setup - RPN klick this one.

How?
Needed are digipeaters that have a chance to hear each other under statistically most likely probability. A range around 500km could be a good starting point. So we take the most farest corner points in Europe we have among our RPN members and top them up with 2 central operators. That results in what we can see on the image above (click to see live).
Now those once using UI-View do vary their 'Dupe secs' unequally and for those using APRSIS32 we hope for the DCD to at least prevent parallel transmissions. Let us go practical and have a look at the suggested stations (sequence north-south & west-east)

DK2EZ-10 [UI-View] Dupe secs = 15
HB9ZF-10 [UI-View] Dupe secs = 20
IR0UGN-10 [UI-View] Dupe secs = 25

The full detailed overview to be found under this link for Selected Digipeater Setup. A PDF document listing the present digipeater & igates can be found under IGATEs & DIGIs including The Selected Digipeater Concept.

Certainly it would be ideal if all were using UI-View respectively an APRS program allowing to implement a feature like 'Dupe secs'. But although APRSIS32 is not the best choice for digipeater operation a certain sexapeal of the wide range of features can not be denied. So no one exspects sysops to change anything here.

Back-up
DK2EZ-10 by DH8HP-1
HB9ZF-10 by IQ2LB-7
IR0UGN-10 no redundancy

So we have 2 stations that need to coordinate in times of system downs with normally non-dipipeating stations. In the far north and the far south there is no third option.

The Igates What do the others do?
All other Igates stick to their task as pure gates. But in order to prevent disappointments when it comes to messaging, querying and other 2-way communications it is essential that all Igates operate bi-directional (R-I-R) . Especially for maritime and aeronautical stations it is not easy to get in touch with a shore station and once they do they hope for response of course.
So forgive the little sticker campaign on RPN start website pointing that out.
It makes sense to keep all Igates running and let them answer i.e. a query from any user. Even if a station would be to weak to be heard by a vessel in the middle of the Atlantic it most probably is strong enough to get in touch with the next digipeater that might have missed that query but can now forward the answer.
At this point the use of parallel monitoring WebSDR might be an interesting aspect. DF8LS-10 once kept listening (10147.30kHz) on Twente WebSDR and did igate that to the APRS-IS via a spare SCS-Tracker. Normally this is an unwanted oneway communication. But another port (APRSIS32) provided 10147.30kHz transmission on the HF rig and therefore the ability to answer was given. In that case the WebSDR acted like a second remote antenna system. Again, even if to weak to answer directly to the station of origin it is no problem to reach the next digipeater.
For all of this to let it happen a clean digipeater operation within the Robust Packet Network is essential. This is the target of this page.

The Users Cui Bono?
A network makes sense when we have people benefiting from it. Now, in the first place we have all the mobile and stationary operators of which a random choice is given on the image (click to see live).
In the second place the Robust Packet Network meanwhile has an excellent reputation among hams as a net that really works 24/7/365. By this we have attracted quiet a lot new operators during the past 3 years. Especially the yachting and remote travelling hams are seeking for reliability.
Yes, this is still the experimental ham radio place. But like amateur radio has been a model for later commercial applications it can demonstrate as well the operational part of the technical possibilities. All too often we see brilliant tools, transceivers and systems in amateur radio and in the end operators just use a split of its capacity. That is a pity and for once it would be nice to keep a network 'straight and level'.

General Statement
Everybody is free to do what ever he wishes. All of the above is meant as a study on how the network could be optimized. Yes, amateur radio is about testing and enjoying the abilities of our radios, antennas and programs. But as administrator of a network you receive all the emails seeking for a more proper working net. So the interest of installing an effective system seems to be high. And instead of sharing thoughts with each emailing operator individually it was time for this page to come up.
Your feedback is strongly required to change this page towards a practical guideline for those who wish a focus on a clean plus straight & forward working network. There would be lots of 'political' statements on this as well but to stress it a last time:
It is just an idea !