[aprssig] D700 digi and unproto

[Chris Rose]

Forgive if you have solutions to your query.  To help eliminate unwanted 
signals in your SAR efforts the Kenwoods support special messages and calls 
if I am not mistaken.  Your last paragraph addresses this issue.  Plug in a 
the special code and set all of your units to this setting.  In order to 
keep all your units talking to each other a special call sign would need to 
be used I believe.  The special code may only apply to messaging, not 
parsing of position data.

Use tactical calls and address your digi path to address that.  Don't use 
generic Wides, use specific calls for your portable digis and mobiles to 
help eliminate unwanted traffic on your net.

What about PLing all of your rigs to make sure you only hear your group and 
not other signals?

What about using an alternate frequency or frequencies?  Then use one of 
your portable digis to tie into the main frequency on 144.39 if necessary?

Good luck,
Chris
KB8UIH

----- Original Message ----- 
From: "Steve Sobodos" <steve at scsvideo.com>
To: <aprssig at lists.tapr.org>
Sent: Monday, February 13, 2006 2:30 PM
Subject: [aprssig] D700 digi and unproto


> I am a member of a search and rescue unit in Southern California . We are
> about to start using APRS to track our teams in the field during events. 
> For
> several reasons, we have selected TM-D700 radios for our vehicles and 
> TH-D7A
> radios for our ground pounding teams (one per team). We will be using 
> UIview
> at the command post. After much research on the Internet I am confused on
> how to set up field Digi's so that we complement (not hinder) the LA/OC
> fixed digi's and network load.
>
> Here is a scenario so you can get a feel of the challenge.
>
> There is a search In the eastern mountains of Orange County, lets say in a
> canyon. The command post is in the canyon (RF hole), teams are in other
> canyons and high on hills (LOS to a wide area digi). The foot teams do not
> digi but the vehicles do. Placement of one or more vehicles might be
> strategically selected to digi the canyon units to the command post and 
> into
> the public digi system for Internet monitoring by command staff back at an
> EOC. If resources are thin, the vehicle(s) will be part of the search and
> could be anywhere. One of the goals is to pre-set the radios so that 
> little
> if any configuration settings need to be changed in the field. A
> transportable digi in a box (KPC-3/radio/battery) can also be used if a
> long-term search is anticipated. The multiple canyons (hidden 
> transmitters)
> and the high stations make the solution tricky.
>
> The two ways I think it can go are:
>
> 1.  The D700's digi's have UIFLOOD set to "UIFLOOD WIDE,FIRST" and the
> trackers use WIDE3-3 for location beacons. The D700's that could hear each
> other would not duplicate packets but would propagate them back to the
> command post and potentially into the OC/LA network via the WIDE public
> digi's.
>
> Downsides:   The D700's mobiles on high hills might pickup traffic in the
> OC/LA network and use up hops, especially if they were high on a hill.
>
> 2.  The D700's digi's have a digi alias of WIDE1-1, no UIFLOOD and the
> trackers use "WIDE1-1, WIDE2-2" for location beacons. The first D700 that
> heard a location beacon would strip off the WIDE1-1 and digi the WIDE3-3
> which would only be picked up by the LA/OC network (if it heard it and 
> there
> was no collision). The LA/OC network might hear the WIDE1-1 beacon but it
> would do little harm.
>
> Downsides:   The command post is less likely to get one-hop beacons as the
> one local digi might be out of range of the command post.
>                    The LA/OC network also might not hear an individual
> beacon.
> Upside:        The local digi's ignore LA/OC traffic.
>
> Do you know if the D700 Group Code applies to digipeating? The manual says
> that when the UNPROTOCOL (menu 3-E) is set to something starting with 
> other
> than AP, like SPCL - the radio ignores any packet that is directed to 
> other
> than SPCL. This way choice #1 would ignore the LA/OC traffic and might
> become the choice.
>
> Got any other ideas?
>
> Steve
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>