<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_default" style="font-family:georgia,serif">Lynn,</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Thanks for the 'sequence of operation'.​ some in-line comments in-line for redundancy:</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The APRS-IS server will typically provide a LOT more packets than the criteria above.  Most interesting is the fact that an IGate will receive all packets for stations that were "recently" (typically 30 minutes) gated from RF to the APRS-IS.  This means that if your IGate copies a single packet station that is transmitting on RF and the APRS-IS, then you will receive ALL packets generated by that station for the next 30 minutes. <br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:georgia,serif">​And this is where things have diverged between the java code and the C code.​ I have observed that in a side-by side comparison, Aprsc is a lot more conservative from the get-go. This should make no difference to what a well-crafted Igate client transmits on RF. However, it certainly can make a difference on the local map display of that I-gate client instance. And as an Igate operator, I prefer to see only what my station has heard on RF, though I will tolerate a little fluff from messaging.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">But then, when you combine JavAPRSSrvr's interpretation of the spec, with some I-gate clients that are arguably broken in a default configuration (as you know, Direwolf not being the first) hooking one of these things to a transceiver would flood the local RF channel* (I don't like the word network here). And I believe that has been a factor in APRS messaging not catching on. </div></div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">The following story is partly anecdotal, but it is *the take-away message*:</div><div class="gmail_default" style="font-family:georgia,serif">Years before I became licensed, some smart people with some real commercial radio resources put quite a bit of effort into establishing an APRS network in the Centre region. And they made the decision that they could not do a TX I-gate, because when they did, the already very busy RF channel became flooded. So for many years this community had a RX-only I-gate. Then I arrived on the scene, following the lead of the Elmers, and would activate a receive-only Igate when the other one went down, or to supplement the network in an RF hole for special events. I had Xastir tethered to a Nextel IDEN phone at one point; just to get the dots on the map.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">So, recently, when the local I-gate went down hard with a dead computer, I filled that role again, but this time I have some PSARC resources to transmit with, and connect to the Interwebs, and a fill-in digi sure would help my lowly HT. So I started researching - surely we can transmit messages from here??? Then I stumbled upon Pete Lovell's conclusion that a receive-only I gate is the death of many a message packet, under certain circumstances. So we have been running a huge black hole for messaging here in Centre County - hearing from hundreds of miles away and gating them to the internet, but transmitting nothing.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">"Crap!" I said as I shut my RX-only I-gate down.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">And so I refreshed my setup with new versions of good software, and tried out a 'new kid on the block' TNC app that has an elegant algorithm for demodulating unbalanced tone levels, and started testing.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">And so, here we are. Can anyone else see why APRS messaging has fizzled, if this happened in other places? I hope Bob's baby can survive a re-boot. I am certainly ready to give it a try!!!</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">But for some reason, I can't seem to get that IDEN modem software to work anymore...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Again, "good" (whatever that means to you) IGate software won't forward all of these packets to RF, but only enough to be relatively certain that the message recipient received the information. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline">​And to me, 'gud' means configurable.​</div> <div class="gmail_default" style="font-family:georgia,serif;display:inline">​And, that makes Direwolf GREAT!​ - don't get the idea I am bashing it. It is still in my test suite because it is configurable. More on that later.</div></div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline">Thanks for being there!</div></div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:georgia,serif;display:inline">Jim A. (KB3TBX)</div></div></div></div></div>