The following configuration changes to a Kenwood TH-D7AG will allow it to be used as a stand alone PropNET monitoring setup,  I haven't had time to explore all the possibilities here, or see how well it can serve as a PropNET transmitter.  Since the rumor mill has always been that the Kenwood radio's (with the built in APRS functions) and PropNET were not compatible, this should prove interesting for those interested in PropNET and CU2QSO.  I have no idea or way to test if the Kenwood D700 mobile can be configured off of APRS to become PropNET friendly, but I imagine it's likely to work.  I'd also be interested in knowing if this works on the older D7's that don't have the "G" firmware in them. 

I would not suggest that the D7 is a good way to monitor for DX packets directly.  The receiver is plenty hot, but the built in TNC requires a moderately strong and relatively noise free signal to decode reliably.  Weak AX25 packet decodes are probably best left to a hot 2m receiver feeding a KPC3+ running open squelch (hard to beat the KPC3+ for this purpose IMHO).  Now for monitoring what gets bounced in off your local PropNET hub, the D7 appears to be just fine for that purpose and that's what I was interested in to begin with.  Neat to monitor for a band opening using just a radio on your belt tuned to your local PropNET hub/digi, no PC, no cables, all nice and self contained.  Around here in EM78pp, most 2m repeaters are pretty much gone the way of 11 meters (or dead silent 99.9% of the time) so what a great use for the 2m FM side of the D7, you can always leave the UHF side on the local 440 repeater, grin.  There's some options for the CU2QSO and PropNET folks here.

Okay, how do you do it?  Pretty easy, while I'll admit it's got a glitch you need to be aware of.  So here goes:

1.  Obviously you need to be tuned in on 147.585 analog FM mode (yeah there are a few of us playing around with digital voice on the ham bands, aka Astro & etc).  Data speed set to 1200 baud and so forth.  Leave the TNC in APRS mode (not PACKET mode) D7 owners know what I mean here.

2.  In "Menu 2" (APRS cfg menu), you need to go to item "2-E" and change the UNPROTOCOL value to VK  (the altnet used by 2m PropNET). 

3.  Reinitialize the TNC back into APRS mode (not PACKET mode) and you should be working minus one glitch.  You may need to go into the UNPROTOCOL menu and just thumb through the existing VK value and enter it to get it to start decoding after a power up or the TNC has been reinitialized for whatever the reason.

Note 1:   If you power cycle or reinitialize the TNC in any way, you will need to just go into the UNPROTOCOL menu item and click through it (not changing a thing) and enter, then things will work again.  Apparently the TNC doesn't load the VK value on power on or reinitialization, it loads the hard coded APRS default EVEN though when you check the menu item it will still show "VK" so it doesn't work right till you force VK back into the UNPROTOCOL settings.  Seems just thumbing through the menu gets it kick started.  Go into the menu as if you're going to change it, but just ok/enter right over the existing data and presto.  Maybe this is just a "G" version radio thing?  Maybe some of the folks with the older D7A and any of the D700 mobiles can check this same trick and test these radios on PropNET.  I've tested this on a 439 MHz node at 9600 baud and a 441 MHz node at 1200 baud with the same results.  Seems to be a glitch in how the TNC reads in stored settings during reinitialization, just have to force the UNPROTOCOL parm into it.

Note 2:  You can turn tone encode/decode on, say 67.0 Hz if you wish to mute the rx audio (doesn't impact it on tx or rx), not a new trick with the D7 and not mandatory.  Having tone/PL decode on has no impact on the TNC's ability to decode incoming data, a high five for the Kenwood engineers.  This could, if done carefully and expecting to be QRM'ed by the digi at times, allow limited voice comm's on the same channel alongside the data.  Not my idea, the APRS D7 folks have known and used this trick for sometime now.  I think most on APRS use 100.0 Hz, I just used 67.0 Hz as it's way down there further away from the data tone freq's, how much this matters????  67.0 Hz does seem to false a LOT less then 100 Hz does, especially if you're around stations runny way too hot packet deviation. This PL trick is only for "manned" mobiles only, please don't set PL encode/decode on the digi's or home stations, reasons should be obvious.

Here's some screen shots of the D7 in action on 147.585 decoding PropNET beacons from the local hub/digi (KD4EVB-12).  Apologies for my photography skills, not much better than my web design skills.  Page and pictures done in a bit of a rush, you get what you paid for ;-)

New packets arrive and display on the screen and get stored in the stations list just like APRS packets do and you can thumb through the various screens for that particular station like so:

First screen:
Call and SID of station received.


Second screen:
Guess this is the D7's way of handling a packet with a grid in it versus the
usual lat/lon data.


Third Screen:
PHG data and the first part of the comments following it.


Forth Screen:
Since I've got static position data in it, it can calc dist/bearing.
How accurate, it looks pretty darn close on.


Fifth Screen:
Since the hub/digi isn't sending lat/lon data, I assume this is calculated off the
6 digi grid, maybe using the center of the grids?  I haven't checked yet to see
where these coordinates are in the grid square.  I tend to think they are darn
close.  Good enough for aiming a beam, CU2QSO, HAM-IM, etc.


Sixth Screen:
Since there's no wx data or moving object data to be displayed, obviously
nothing to be show here, but I show the screen for completeness.
Even got a incoming packet when this was taken (busy light & s-meter on)


Interesting to say the least for those of us with the Kenwoods that enjoy PropNET and CU2QSO.  Probably some kinks to work out, but the basic functionality needed is there, just that one glitch that's trivial to work around once you realize it's there.






Well allow me to soapbox a bit:

As many have witnessed, the APRS scene has continued to degenerated pretty severely, the last 2-3 years in particular.  APRS faces some serious problems going into the future and on it's present course the future of APRS doesn't look either bright or very clear.   If you were to go back 2-3 (or more) years and read over the main APRS SIG's you'd find the discussions on the SIG's back then very similar to today's arguing (oops, I meant discussions).  In other words the same old problems remain, just the problem has gotten worse and now in desperation the suggested solutions and discussion have become more heated and usually even less productive.  This is because the APRS in general refuses to address one of the key issues, you simply can't run that much user load and functionality on a 2m 1200 baud channel, more less using a unconnected packets.  There's a brick wall of capacity there, that even with all the protocol changes and user education is not going to move or solve in the long run.  Then you add to this a bunch of  serious ego's battling back and forth, folks with personal agendas, then add in all kinds of opinions presented as fact without any real world experimental data to back it up, stir in a few LIDs, a pinch of folks suggesting solutions to a problem they clearly  don't understand,  leaders taking the mainstream digipeating protocols backwards instead of forward, and you've got the recipe for the mess that is APRS on 144.390 in many areas.  A mess that just continues to get worse and affect more and more areas as the user load ramps up.  Yeah, I'm a little burned out on APRS ;-)  PropNET is so much more relaxed, focused, more to my VHF/UHF DXing interests, and with clear goals and future.....and it's still in it's infancy for all practical purposes.

Since PropNET is all about real world data, I offered up the few screenshots of the D7 in action on PropNET.  A picture is worth a thousand words and a few million opinions eh?  It can be done!