[aprssig] Does anybody know what APZMVA is?

[Frank Knobbe]

On Mon, 2015-11-09 at 18:48 -0500, Robert Bruninga via aprssig wrote:
> In keeping with the goal of APRS, real-time tactical situational awareness,
> these traffic incidents are much better for the mobile operator if they are
> on RF.  But of course, transmitted ony via 1 hop to the local digi closest
> to the situation.
> 
> Hope you can figure out a way to do that and manage it to avoid abuse by
> people flooding their local area.


Bob,

These objects are on RF. That's what the system was designed for. I'll
give the overview of the system shortly. And yes, much thought was put
into this to keep RF from being flooded. The last thing I want this
service to be is a nuisance. I also kept a close eye on the performance
and our local RF area over the last couple years, and it's been doing
rather well.


> On a second note, any TOCALL  not beginning with "AP" will possibly be
> ignored by many clients since "AP..." is the flag that tells APRS clients
> that the packet is an APRS packet.


Which is why I'm using the TOCALL of APZMVA. My understanding was that
APZxxx was reserved for experimental applications. Please let me know if
I misunderstood the specs.

However, based on the way this email was quoted (as seen below), it
appears that the lines got a bit messed up. Here again (and I'll break
the links to avoid interference by a mailer):

As sent to APRS-IS:

T 2015/11/09 13:52:53.464157 66.179.102.190:1379 ->
             52.0.40.3:14580(iad2.aprs2.net)

user K4FHK-IS pass ***** vers TN-MotorVehicleAccidents V0.6 filter m/1

K4FHK-IS>APZMVA,TCPIP*:!3559.03NT08623.99W&Originator of TNMVA objects.
Send comments to tnmva at knobbe.us

K4FHK-IS>APZMVA,TCPIP*:>Seeking Gaters to RF in Mem/Jax/Chat/Knox/JC.
Please email me

K4FHK-15>APZMVA,TCPIP*:;TNMVA64c7*091633zI<c&V9#/0n __I-75-N INCIDENT,
ON-RAMP BLOCKED.

--------------------------------------------------------------------

As received through APRS-IS:

T 2015/11/09 13:52:53.800449 144.202.128.17:14580 (bwi.aprs2.net) ->
             66.179.102.190:3886

K4FHK-IS>APZMVA,TCPIP*,qAC,T2IAD2:!3559.03NT08623.99W&Originator of
TNMVA objects. Send comments to tnmva at knobbe.us

K4FHK-IS>APZMVA,TCPIP*,qAC,T2IAD2:>Seeking Gaters to RF in
Mem/Jax/Chat/Knox/JC. Please email me

K4FHK-15>APZMVA,TCPIP*,qAS,K4FHK-IS:;TNMVA64c7*091633zI<c&V9#/0n
__I-75-N INCIDENT, ON-RAMP BLOCKED



Please advise if a short introduction of myself and/or this application
is desired and proper etiquette for this list. If so, I will provide a
more comprehensive overview of the system.

Thanks!
Frank



> -----Original Message-----
> From: aprssig [mailto:aprssig-bounces at tapr.org] On Behalf Of Frank Knobbe
> via aprssig
> Sent: Monday, November 09, 2015 4:19 PM
> To: aprssig at tapr.org
> Subject: Re: [aprssig] Does anybody know what APZMVA is?
> 
> On 11/7/2015 4:17 PM, Andrew P. via aprssig wrote:
> > Greetings.
> >
> > I've noticed an unusual new experimental tocall value APZMVA, that
> > seems to be associated with some oddly formatted APRS-IS messages. I
> > was just curious what that might be.
> >
> > Regarding the unusual formatting (which probably has nothing to do
> > with the APZMVA program, as I am seeing from other tocalls as well),
> I
> > am seeing packets from the APRS-IS that look like this:
> >
> >
> K4FHK-15>APZMVA:K4FHK-15>APZMVA,TCPIP*,qAS,K4FHK-IS:;TNMVA64a2_072105zI<
> K4FHK-15>/yn8U#*n
> > __I-65-N DEBRIS, LEFT LNS BLOCKED
> 
> 
> Greetings,
> 
> I'm the developer of the TNMVA project. I double-checked the code and also
> monitored network traffic to the APRS-IS server, and I am not seeing this
> issue. I monitored the network sessions with ngrep.
> 66.179.102.190 is my server running the TNMVA and other APRS applications.
> The packets are sent to APRS-IS like so:
> 
> T 2015/11/09 13:52:53.464157 66.179.102.190:1379 -> 52.0.40.3:14580
> (iad2.aprs2.net)
> 
> user K4FHK-IS pass ***** vers TN-MotorVehicleAccidents V0.6 filter m/1
> K4FHK-IS>APZMVA,TCPIP*:!3559.03NT08623.99W&Originator of TNMVA objects.
> K4FHK-IS>Send comments to tnmva at knobbe.us APZMVA,TCPIP*:>Seeking Gaters
> K4FHK-IS>to RF in Mem/Jax/Chat/Knox/JC. Please email me
> K4FHK-15>APZMVA,TCPIP*:;TNMVA64c7*091633zI<c&V9#/0n __I-75-N INCIDENT,
> ON-RAMP BLOCKED.
> 
> 
> I also have another application running that is tapped into APRS-IS as well,
> with a different connection. On that connection, I observed the same object
> placement as it was propagated and received through APRS-IS, and it appears
> to arrive properly:
> 
> 
> T 2015/11/09 13:52:53.800449 144.202.128.17:14580 (bwi.aprs2.net) ->
> 66.179.102.190:3886
> 
> K4FHK-IS>APZMVA,TCPIP*,qAC,T2IAD2:!3559.03NT08623.99W&Originator of
> K4FHK-IS>TNMVA objects. Send comments to tnmva at knobbe.us
> K4FHK-IS>APZMVA,TCPIP*,qAC,T2IAD2:>Seeking Gaters to RF in
> K4FHK-IS>Mem/Jax/Chat/Knox/JC. Please email me
> K4FHK-15>APZMVA,TCPIP*,qAS,K4FHK-IS:;TNMVA64c7*091633zI<c&V9#/0n
> K4FHK-15>__I-75-N INCIDENT, ON-RAMP BLOCKED
> 
> 
> K4FHK-IS is the application/server that is injecting objects into APRS-IS.
> The objects themselves are injected either with callsign
> K4FHK-15 or K4FHK-51.
> 
> Note that K4FHK-51 is intended to be APRS-IS only. K4FHK-15 may be picked up
> by Igates and brought onto RF. Currently, the only Igate doing so is my own,
> and if any such objects are gated back from RF to IS, they would be coming
> from callsign K4FHK-3. So your observation of the issue with callsign
> K4FHK-15 related to packets are only present on the APRS-IS side, and were
> not gated from RF to APRS.
> 
> 
> 
> > Note that the sender>tocall section is repeated twice, with a colon
> > (':') delimiting the two occurrences. I'm wondering if this might be
> > an issue with some dialects of the APRS-IS server code (specifically
> > aprsc, since it is the one that shows up for every I-gate I've
> > back-tracked), should my application not be reading the TCP socket
> > connection fast enough, that the server might get the first part of a
> > message stuffed in the stream, and then discards the rest of the
> > message because of a TCP window overflow. That would make this appear
> > like two concatenated messages with most of the first message gone,
> > including the CRLF delimiter between the two messages. I've got a
> 48Kb
> > TCP window size configured in my application, so there should be
> > plenty of kernel-level buffering to allow for any pauses at the
> > application level.
> >
> > The occurrence doesn't seem to be a function of the incoming message
> rate.
> 
> 
> I'm not sure that this is a timing issue. While the status and object of
> K4FHK-IS are sent out rapidly, followed by any objects from K4FHK-51, any
> interspersed object from K4FHK-15 would incur a pause due to the server
> controlled throttling of these objects intended for RF.
> 
> If multiple IS-only packets can not be sent in succession, I can certainly
> add a sleep time of a second or two between these, but given the low amount
> of successive packets, I didn't think that would be necessary. I think there
> are other applications out there (Metar/weather, Winlink, etc) that also
> send large batches onto IS without wait times between packets.
> 
> 
> BTW: I just joined this list today, since your mentioning of my call sign
> and MVA application was forwarded to me by a fellow Ham (Thanks Andrew!). I
> can write up a short introduction of myself and the TNMVA service and post
> it to this list shortly, if this is proper etiquette and desired on this
> list.
> 
> There is also another application I developed and would like to introduce to
> the community as well. For that application, I would like to "apply" for an
> APRS-IS callsign, so I would like to seek your input on the application
> itself, and the proper process of acquiring and using a tactical, IS-only
> callsign.
> 
> 
> Best regards,
> Frank Knobbe, K4FHK
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig