Feature Request: Digi Failover

[nayrnet]

User Story: As an operator I want to be able to Digipeat packets only when I cannot establish or maintain a APRS-IS connection.

In Depth: On my WX3in1Plus2.0 it contained a feature/filter that would only enable Digipeating if the connection to the aprs-is server failed or otherwise could not be made.. I use this feature on my mobile iGate because 3G data connectivity might not always be available, when this happens it fails over to WIDE1-1 Digi when the connection can not be established.

Now that I have a home station established I'm thinking of emergency situations, in such conditions that the power and/or internet are not available the area, I have emergency generator and battery backup but unless I can reconfigure my Direwolf station (unlikely) the gap in coverage I'm providing would go dark again once I lost internet connectivity.. not to mention normal planned outages.

I've got a lot of mountain top digi's around me and typically it makes no sense for me to digi anything, but there is a rather large area that I'm providing primary coverage for because terrain and the urban landscape interferes with even those digi's.

I'm thinking perhaps a new filter capability for DIGI so could be chained with other logic, such as: if no IS AND packet is direct (not been digi'd), AND within a certain range of specified coordinates (the area I fill in), then DIGI the packet.. I know those mountain top digi's can hear me, I hit one 60m away consistently.

73's N4YRE

[VA2XJM]

I came exactly to check if someone already raised the idea and boom, you just did.

In my case, the local Digi have no power backup, so I have to gain access to my home rPi and change the config to make the digipeating active while there is no power at the local Digi site.

My idea is:

• Add a new configuration parameter to hold a list of comma separated callsigns list of other local digipeaters. Another value could be "ALL".
• When receiving a packet, listen for 1 or 2 seconds to let above configured digipeaters do their job.
• When the delay is past if none of above configured digipeaters made their job, Direwolf digipeat it.
• If one of the configured DP made their job, the packet is not digipeated.
• If "ALL" is specified, it will only digipeat a packet coming from a end-user, if no digipeater at all digipeated a packet. (useful for mobile setup to cover blindspot or operation area)

However Igate goes out as usual.

Advantage: Always ready to digipeat, will not requires any intervention from users, will not clog the network for nothing and will digipeat weaker stations (portable in urban area) if others are receiving it. It is also good for mobile operation and emergency management.

[dranch]

This selective digipeater feature would be very difficult to make reliable. From my personal experience, changing propagation, intermittent interference, hidden nodes, random poor decodes, etc. all would potentially hinder the correct behavior here.

[VA2XJM]

@dranch It is not ideal, but my home station is less than 2km from the local digipeater and I cover a blind spot made by terrain... However I keep DP features disabled because it would become a mess.

Also the local DP has no power backup and being at high ground location, it is not uncommon to find out it is down due to power outage in that area because of strong winds. If I am not home, there is no DP active in the area for several hours sometimes...

It would be interesting to have a mechanism for a backup DP to get active when needed...

[wa7nwp]

@dranch It is not ideal, but my home station is less than 2km from the local digipeater and I cover a blind spot made by terrain...

Isn't this essentially the same as (the controversial) Viscous Digipeating? http://ham.zmailer.org/oh2mqk/aprx/wiki-Viscous_APRS_Digipeater.html

[VA2XJM]

@wa7nwp Interesting link... pretty much except that I would prefer to specify digipeaters to monitor. In the area, we have digipeater about 50-70km apparts, so if I get the same packet from 2 digipeater 50km away and the local digipeater is down, my local station would not do its job for other APRS station locally that are not catching remote traffic...

[dranch]

Yes, there are aspects of the original request but I don't think APRX's feature can track the state of the APRS-IS connection and change it's behavior. For the RF side, you try out this functionality in APRX to see how it goes. Just be sure to configure Direwolf's APRS protocol stack to not create any conflicting APRS functionality by disabling it's DIGIPEAT and IGATE sections.

--David