Mark Cheavens
2014-07-13 13:53:53 UTC
With the most common thread on the APRS sig over the last few months
being paths I thought it time to remind everyone of why we have the
current problem and what we should work together to first come up
with a needs list and to secondly work to solve the issue.
While I have brought this up on the list many years ago, there are
many new users and it might be time for a reminder.
The current system (Digi backbone) was built with the currently
available (and surplus) old TNC's. Many at the time were TNC-2's or
clones, as well as the then "modern" KPC-3 and 3+'s.
The KPC-3+ have suffered from the delayed packet problem, and the
TNC-2's have been implemented in many cases without UiDigi firmware.
As a result we have been fighting for years to try and educate end
users (the best of which are on this list) of what their path should
be in many different operating environments and parts of the country.
Solution:
Take "paths" and throw them out the window.
- (During the transition having a path will work with the "old" digi's)
The number of times a packet is digipeated is network specific based
upon the current load of the network.
The Digipeater should decide whether to throw out the packet, delay
it to see if it was heard by another digi, or digipeat it immediately.
The digipeater will have to know:
It's location
It's PHG (coverage area)
How many hops it is to a reliable I-Gate
It's altitude (both average ground elevation for the area and antenna
elevation above that terrain).
List of stations it has heard (MHeard)
- That list will also keep track of the packet location
Current channel loading
We need the digi to decide!
Examples:
If a digi hears a packet from one mile away (It knows it's location
and the location of the packet), and it has not heard a packet from
this station in X minutes the packet should be repeated!
(x is variable based upon the number of unique "direct" stations it
has heard, and has the station moved more than Y distance).
- If the station did not move (horizontally or vertically), and a
packet was heard from the same station 10 seconds prior should the
packet be digipeated?
- Normally most of us would say "no", but if the channel loading is
zero, then why not! (Private or test network)
If a digi hears a packet from a station 100 miles away, should the
packet be digipeated?
- Was it heard directly?
- Was it digipeated by another digi?
- What is the channel loading?
- Is the station moving or fixed?
- How long has it been since THIS digi repeated the packet?
----------------------------
With modern TNC's available there is no reason not to start working
on a modern solution.
- Existing TNC's could be used if put into KISS mode and using small
single board computers such as a Raspberry Pi.
- An ideal solution would be a dedicated solution (Tracker3, TNC-X, etc)
The idea of this email was not to list "all" of the needs, but simply
to point out that until (WE) begin to think of what is needed and
begin to think of the algorithms needed, we will continue to have
"path" problems.
Respectfully,
Mark Cheavens
KC5EVE
being paths I thought it time to remind everyone of why we have the
current problem and what we should work together to first come up
with a needs list and to secondly work to solve the issue.
While I have brought this up on the list many years ago, there are
many new users and it might be time for a reminder.
The current system (Digi backbone) was built with the currently
available (and surplus) old TNC's. Many at the time were TNC-2's or
clones, as well as the then "modern" KPC-3 and 3+'s.
The KPC-3+ have suffered from the delayed packet problem, and the
TNC-2's have been implemented in many cases without UiDigi firmware.
As a result we have been fighting for years to try and educate end
users (the best of which are on this list) of what their path should
be in many different operating environments and parts of the country.
Solution:
Take "paths" and throw them out the window.
- (During the transition having a path will work with the "old" digi's)
The number of times a packet is digipeated is network specific based
upon the current load of the network.
The Digipeater should decide whether to throw out the packet, delay
it to see if it was heard by another digi, or digipeat it immediately.
The digipeater will have to know:
It's location
It's PHG (coverage area)
How many hops it is to a reliable I-Gate
It's altitude (both average ground elevation for the area and antenna
elevation above that terrain).
List of stations it has heard (MHeard)
- That list will also keep track of the packet location
Current channel loading
We need the digi to decide!
Examples:
If a digi hears a packet from one mile away (It knows it's location
and the location of the packet), and it has not heard a packet from
this station in X minutes the packet should be repeated!
(x is variable based upon the number of unique "direct" stations it
has heard, and has the station moved more than Y distance).
- If the station did not move (horizontally or vertically), and a
packet was heard from the same station 10 seconds prior should the
packet be digipeated?
- Normally most of us would say "no", but if the channel loading is
zero, then why not! (Private or test network)
If a digi hears a packet from a station 100 miles away, should the
packet be digipeated?
- Was it heard directly?
- Was it digipeated by another digi?
- What is the channel loading?
- Is the station moving or fixed?
- How long has it been since THIS digi repeated the packet?
----------------------------
With modern TNC's available there is no reason not to start working
on a modern solution.
- Existing TNC's could be used if put into KISS mode and using small
single board computers such as a Raspberry Pi.
- An ideal solution would be a dedicated solution (Tracker3, TNC-X, etc)
The idea of this email was not to list "all" of the needs, but simply
to point out that until (WE) begin to think of what is needed and
begin to think of the algorithms needed, we will continue to have
"path" problems.
Respectfully,
Mark Cheavens
KC5EVE