[aprssig] BLENDING APRS: SEEMLESS INTEGRATION IN A MULTI-FREQUENCY ENVIRONMENT

[Bob Bruninga]

Regarding blending APRS 1200 and 9600...
I may not have fully digested all of the issues below, but a few immediate thougts some to mind...

1) The complaint of the D700 muting 144.35 while transmitting on 144.39 is unsolvable by any means on any radio or pair of radios.  There are no cavities on earth capable of separating a 144.39 MHz signal from a 144.35 transmitter only 40 KHz away.

2)  I am concerned at the use of 144.34 which in my mind has been designated for balloons, and ATV simplex for the last 30 years or more.  It is as standard to them as 144.39 is to us.  I would have grave reservations to permanent use of this frequency.  Of course, I steal it for 6 hours once a year for the annual Golden Packet event (aprs.org/at-golden-packet.html), but that is no longer than a single balloon event and in keeping with the intent of the frqeuncy.  that is a clear, experimental, short duaration frequency.

3) We have always promoted that the best way to do data blending on APRS is to combine everything heard on all input frequencies and then send it all on a single comon output channel at 9600 baud.  Unfortunatelyl, 144.39 has to remain as a primarily INPUT frequency so that traverlers will be seen.  So the regional output at 9600 should be on UHF somewhere else.  And beacons on the 144.39 digis should have FREQ OBJECTRS alterting the 144.39 travelers where to tune for the full feed 9600 system.

Just my 2 cents.  Wouild this work up there?
Bob, Wb4APR

Bob, WB4APR


---- Original message ----
>Date: Sat, 17 Apr 2010 17:37:36 -0700
>From: aprssig-bounces at tapr.org (on behalf of David Dobbins <ddobbins at gmail.com>)
>Subject: [aprssig] BLENDING APRS: SEEMLESS INTEGRATION IN A MULTI-FREQUENCY ENVIRONMENT  
>To: aprssig at tapr.org,nwaprssig at nwaprs.info
>
>   Hi all APRS and NWAPRS enthusiasts:
>    
>   Within the NWAPRS region a couple groups of hams
>   have been developing alternate APRS networks on
>   9600bd with great success. The project started
>   because the saturation of APRS activity on the
>   primary freq, 144.39 at 1200bd, particularly around
>   the Puget Sound region and Seattle. If you'd tune
>   into the 144.39 freq you'll rarely hear a quiet
>   moment, and we suspect upwards of 50% of the packet
>   activity never gets through due to collisions of u/i
>   packets. I suppose this is happening in other larger
>   metro areas around the country and with our overseas
>   friends.
>   The desire for further optimization sparked
>   experimentation of 9600bd APRS on both UHF and VHF
>   frequencies. Success was found on both bands, but
>   one draw back on UHF was locating a common freq that
>   could be expanded out of the Puget Sound region. We
>   still haven't discovered that common freq that will
>   work everywhere as we have on VHF, but we continue
>   experimenting on 440.800Mhz under the direction of
>   Bob (K7OFT) in Seattle. A typical WIDEn-N digi on
>   9600bd employs a Kenwood TM-D700 in some locations,
>   or an Icom IC-207 and Kantronics KPC-9612 in others.
>   Bob continues APRS development on 220Mhz around the
>   Seattle area as well. Bob (K7OFT) has proven APRS
>   at 9600bd is a viable alternative to the crowded
>   1200bd activity on 144.39Mhz, but also notes that
>   while the D700 can DIGIPEAT in APRS Packet mode, it
>   does so with a limited set of commands. The D700
>   internal TNC is not fully compatible with what we
>   want to do within the compatibility
>   requirements. The D700 is just about the only rig
>   we can use if we stay on 144.350 and
>   144.390MHz. The reason is because the D700 turns
>   off the receiver opposite of the band you are
>   transmitting on. So if you transmit on 144.350 then
>   the receiver on 144.390MHz is shut off, and
>   vice-versa. Otherwise the front end of the
>   listening receiver could suffer damage because the
>   40Khz may be too close to not cause problems. In
>   Bob's experimentation, we believe that the only way
>   we can get around the limited commands problem is to
>   use Digi_ned at the digi site. Bob (K7OFT) also
>   notes we should be looking for an easy solution to
>   passing messages and one-liners to and from the
>   primary and alternate frequencies.
>   From early analysis we discovered a new problem of
>   sharing data within the two environments in what
>   later evolved into the topic of this report, BLENDED
>   APRS DEVELOPMENT.  At our planning meeting for the
>   NWAPRS Summer Gathering Scott (N7FSP), brought up
>   "Blended APRS Networks" to allow the sharing of APRS
>   information across the various networks in the area
>   so that users were able to better share information
>   between networks without the use of the Internet.
>   Simply put, we haven't discovered an easy way to
>   implement the crossband sharing of data specific to
>   a mountaintop WIDEn-N digipeater. Our work
>   continues.
>   In steps Scott (N7FSP), and Casey (KJ7XE), who both
>   have interest and most importantly, mountaintop
>   access, where development of a VHF 9600bd experiment
>   could continue. Scott settled on 144.35Mhz as it
>   appears widely under-utilized across the spectrum.
>   The real "jewel" in this development was the
>   reduction in implementation cost by combining a
>   Kenwood TM-D700 and external Kantronics KPC-3 to
>   come up with one "easy" digipeater package resulting
>   in 1200bd and 9600bd APRS on VHF with no need for
>   another (UHF) antenna, feed line or coax, or other
>   ancillary equipment needed to install a separate UHF
>   radio at the remote location. The Kenwood D700 is
>   configured to digipeat APRS on the radio's A band on
>   144.35Mhz and internal TNC at 9600bd, while the B
>   band is tuned to 144.39Mhz and uses an external
>   KPC-3 set at 1200bd. The cost savings is better than
>   two separate radio systems at the mountaintop, and
>   upgrading a typical VHF radio plus KPC-3 digipeater
>   is easy; just replace the radio with a Kenwood
>   TM-D700 and you're in business on two freqs, one at
>   1200bd and the other 9600bd. The XTAL/CRYSTL
>   digipeater is the FIRST true "Double Sided Digi"
>   (quote to K7MCR) that we know of.
>   OK, so we have lots of room for growth at the 9600bd
>   environment, which means more data can be pumped to
>   the users on 9600bd. We're still working out exactly
>   what we want to expand with, but for the most part
>   there's room for those 10 second trackers or club
>   announcements and flood closure warnings or
>   whatever.
>   Now comes the problem we're attempting to resolve
>   now, with our BLENDED APRS DEVELOPMENT project. As
>   it exists now, two mobile travelers, one on the
>   primary freq 144.39Mhz at 1200bd, and the other on
>   the secondary freq 144.35Mhz or 440.800Mhz at
>   9600bd, both driving down I-5 equipped with Kenwood
>   TM-D710 radios and AvMap G5 GPSs, neither will know
>   of each other's presence unless they're both
>   communicating on a common voice frequency. A nearby
>   home station, typically setup for the primary freq,
>   will only see the one station unless his APRS
>   application, typically UI-View, is also pulling data
>   from the APRS-IS. Many don't, relying only on the RF
>   picture plotted on their screen. Another nearby home
>   station, new and improved, but monitoring only the
>   secondary freq with a 96kb-only TNC, will see only
>   the one station unless his APRS application is also
>   pulling data from the APRS-IS. A third home station,
>   pulling only the APRS-IS feed, may see both stations
>   while the fourth home station, with deeper pockets,
>   has UI-View running on his computer connected to a
>   KPC-9612 and two radios, one on 144.35Mhz or
>   440.800Mhz and the other 144.39Mhz.
>   From this comes our goal of blending the various
>   APRS frequencies and baud rates, preferably at the
>   mountaintop digipeater site, or at a home station,
>   to where other home and mobile stations are aware of
>   ALL APRS activity in their area, and the blend makes
>   it transparent for any user to access this data, and
>   include some filtering or adjusting of path
>   selection and other variables.
>   We continue our discussions on the nwaprssig
>   reflector, and have it included in our list of
>   presentations for the September 10th NWAPRS Summer
>   Gathering, more info for which can be found on the
>   http://www.nwaprs.info web site. Many thanks to Bob
>   (K7OFT) and Scott (N7FSP) for their assistance in
>   preparing this message for discussion.
>    
>   Regret I won't be able to attend the TAPR DCC in
>   Portland at the end of September, but wanted to get
>   this out there now in hopes there will be some
>   discussions on it here in the sigs and at DCC.
>   David K7GPS
>   Lead Coordinator NWAPRS
>   Home QTH Spokane
>   Sunning by the pool in Tucson
>________________
>_______________________________________________
>aprssig mailing list
>aprssig at tapr.org
>https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig