Loading ...
Sorry, an error occurred while loading the content.

RE: [aprsisce] Priority Status via APRS IS bug

Expand Messages
  • Robert Bruninga
    Lets not confuse the PRIORITY status comment in Mic-E with the “priority” bit we want to define. The PRIORITY status comment is for human to human
    Message 1 of 13 , Jan 15, 2013
    • 0 Attachment

      Lets not confuse the PRIORITY status comment in Mic-E with the “priority” bit we want to define.  The PRIORITY status comment is for human to human conveyance of the word “PRIORITY”.  The “priority” bit flags certain RF packets as higher priority than some less mundane and less important packets that can be dropped if loading gets too high.

       

      Just a clarification.

       

      Bob

       

      From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Lynn W Deffenbaugh (Mr)
      Sent: Tuesday, January 15, 2013 2:35 PM
      To: aprsisce@yahoogroups.com
      Subject: Re: [aprsisce] Priority Status via APRS IS bug

       

      On 1/15/2013 1:22 PM, Pat Ryan KC6VVT wrote:

      Did not have this status issue with APRS DOS, anyway, before APRSIS32.


      Prior to APRSISCE/32, most APRS clients ignored the notification specification from http://aprs.org/aprs12/EmergencyCode.txt

      I've never had the opportunity to run APRSdos, so I can't speak to what it did or did not do.


      Good thing I did not set up all the local hospitals equipped with V/UHF/APRS to beacon with this 'Priority' status when activated for the critical need since I know that this alert goes out to ALL stations via RF and the APRS IS Internet system. I think that worked on APRS DOS without issue, but did not ring the alarm like EMERGENCY would do, and zoom in on the position of the station using EMERGENCY status.


      That goes along with my implementation of someone's suggestion that the Emergency symbol (\!) be treated like !EMERGENCY! or the Mic-E Emergency status.  I've never seen that specified, but there's an amazing number of stations that think Emergency should be used for Police, Fire, and EOCs.  When I see one of those, I suggest the possible better symbol.


      But I still would like to use 'Priority' status, when this status response is fixed to be for RF networks only, as a local attention flag only. 


      Feel free to use it, but you can expect questions about their use.  Just like I respond to Emergency status with a question as to whether remote assistance would be helpful, you might get the occasional question as to what you're up to.  I'd do the same if I heard it via RF or via APRS-IS.


      And it would be nice to have another status available that would turn on just my own local RF terminal remotely in Multi-Track mode of APRSIS32. 


      As you are now probably aware, I didn't make up the statuses.  They're part of the Mic-E and APRS specification, along with the fact that notifications are attached to certain selections.


      Such a map/route function could be used in APRS as a Pathfinder mode, or to arrange meetings of other users to home in on hamfests, ARES or Field Day use. 


      That's what !Shriek!s are for.  Yes, with APRSISCE/32 you can group stations together, or they can group themselves together, with an arbitrary !ACTIVITY! added to their beacon text.  And you can then filter the display to see only those stations that are transmitting, or that you have nicknamed, with !ACTIVITY! (where ACTIVITY is any (hopefully shorter) word that describes your event).


      At least APRSIS32 finally has the "Drive Track" function to replay line by line any saved *.gpx file, the trick is to get a local APRS operator to save it for use. That is what 'Priority' status should do, turn on Multi-Track and AUTOMATICALLY save that user's path until cancelled by that mobile's use of any other status, except 'EMERGENCY'.


      Unfortunately, there's no mention in the spec that certain status values should have their tracks automatically saved.  BUT, have you selected the Tracks / Save Track to GPX on a moving station?  It offers to "Auto-Save Future Track Changes" so you can "set it and forget it" and still get the entire track saved as it keeps moving.


      I also understand that *.gpx file can be loaded into some GPS to drive a route provided by others, but have not tested that as my NUVI 350 GPS does not have a ROUTE function like my old Garmin GP-45 had.


      Loading things into a Nuvi 350 is something that I haven't found to be very convenient.


      Perhaps in the APRSIS32 program, one of the 'Custom #' numbered status statements that Kenwood made available on the TM-D700/710 and TH-D7/72 Radios for your local RF network could be recognized by the APRSIS32 program to do this auto Multi-Track function for network testing and path saving, without triggering ALL the APRS IS users of this program.


      Those would be the the View / Mic-E Custom-0 to Custom-6 and Kenwood didn't make them up.  They're part of the original Mic-E status bits specification.  As I pointed about above, once you save the track of a moving station, APRSISCE/32 can auto-save it as it changes.  I really don't think you want a status that triggers your program to start consuming disk space every time a station uses it, do you?



      Using View / Mic-E / Custom-1 (for instance), you can see only those Mic-E status transmitting the Custom-1 status on your screen.  Unfortunately, this leaves out all of the non-Mic-E devices that might be participating in your event which is why I introduced the concept of !Shriek!s and allow you to apply them via a local nickname for those folks that come to an event without the ability to configure their particular APRS tracker device.


      Again, just trigger the MT function on RF only, when heard direct, ok?


      Sorry, but no.  Spec says it happens and the APRS-IS is just an extension of the RF environment.  They're one and the same to my implementation.  Besides, "heard direct" via HF APRS might still be from across the planet!  There's always someone out there using APRS differently than you've done so far which is why I'm trying to stick to the published specs.

      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

    • Lynn W Deffenbaugh (Mr)
      What priority bit? Can you point me to a reference on that one? I ve been discussion the Mic-E Priority status A=0 B=0 C=1 in the Standard Mic-E Message
      Message 2 of 13 , Jan 15, 2013
      • 0 Attachment
        What "priority" bit?  Can you point me to a reference on that one?

        I've been discussion the Mic-E Priority status A=0 B=0 C=1 in the Standard Mic-E Message Type table as extended by the humanly specifiable !PRIORITY! in the status text as described at http://aprs.org/aprs12/EmergencyCode.txt

        What "priority" bit are you referring to that is in an RF packet?  I thought AX.25 UI packets were just that, AX.25 UI packets.

        Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

        On 1/15/2013 5:07 PM, Robert Bruninga wrote:

        Lets not confuse the PRIORITY status comment in Mic-E with the “priority” bit we want to define.  The PRIORITY status comment is for human to human conveyance of the word “PRIORITY”.  The “priority” bit flags certain RF packets as higher priority than some less mundane and less important packets that can be dropped if loading gets too high.

         

        Just a clarification.

         

        Bob

         

        From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Lynn W Deffenbaugh (Mr)
        Sent: Tuesday, January 15, 2013 2:35 PM
        To: aprsisce@yahoogroups.com
        Subject: Re: [aprsisce] Priority Status via APRS IS bug

         

        On 1/15/2013 1:22 PM, Pat Ryan KC6VVT wrote:

        Did not have this status issue with APRS DOS, anyway, before APRSIS32.


        Prior to APRSISCE/32, most APRS clients ignored the notification specification from http://aprs.org/aprs12/EmergencyCode.txt

        I've never had the opportunity to run APRSdos, so I can't speak to what it did or did not do.


        Good thing I did not set up all the local hospitals equipped with V/UHF/APRS to beacon with this 'Priority' status when activated for the critical need since I know that this alert goes out to ALL stations via RF and the APRS IS Internet system. I think that worked on APRS DOS without issue, but did not ring the alarm like EMERGENCY would do, and zoom in on the position of the station using EMERGENCY status.


        That goes along with my implementation of someone's suggestion that the Emergency symbol (\!) be treated like !EMERGENCY! or the Mic-E Emergency status.  I've never seen that specified, but there's an amazing number of stations that think Emergency should be used for Police, Fire, and EOCs.  When I see one of those, I suggest the possible better symbol.


        But I still would like to use 'Priority' status, when this status response is fixed to be for RF networks only, as a local attention flag only. 


        Feel free to use it, but you can expect questions about their use.  Just like I respond to Emergency status with a question as to whether remote assistance would be helpful, you might get the occasional question as to what you're up to.  I'd do the same if I heard it via RF or via APRS-IS.


        And it would be nice to have another status available that would turn on just my own local RF terminal remotely in Multi-Track mode of APRSIS32. 


        As you are now probably aware, I didn't make up the statuses.  They're part of the Mic-E and APRS specification, along with the fact that notifications are attached to certain selections.


        Such a map/route function could be used in APRS as a Pathfinder mode, or to arrange meetings of other users to home in on hamfests, ARES or Field Day use. 


        That's what !Shriek!s are for.  Yes, with APRSISCE/32 you can group stations together, or they can group themselves together, with an arbitrary !ACTIVITY! added to their beacon text.  And you can then filter the display to see only those stations that are transmitting, or that you have nicknamed, with !ACTIVITY! (where ACTIVITY is any (hopefully shorter) word that describes your event).


        At least APRSIS32 finally has the "Drive Track" function to replay line by line any saved *.gpx file, the trick is to get a local APRS operator to save it for use. That is what 'Priority' status should do, turn on Multi-Track and AUTOMATICALLY save that user's path until cancelled by that mobile's use of any other status, except 'EMERGENCY'.


        Unfortunately, there's no mention in the spec that certain status values should have their tracks automatically saved.  BUT, have you selected the Tracks / Save Track to GPX on a moving station?  It offers to "Auto-Save Future Track Changes" so you can "set it and forget it" and still get the entire track saved as it keeps moving.


        I also understand that *.gpx file can be loaded into some GPS to drive a route provided by others, but have not tested that as my NUVI 350 GPS does not have a ROUTE function like my old Garmin GP-45 had.


        Loading things into a Nuvi 350 is something that I haven't found to be very convenient.


        Perhaps in the APRSIS32 program, one of the 'Custom #' numbered status statements that Kenwood made available on the TM-D700/710 and TH-D7/72 Radios for your local RF network could be recognized by the APRSIS32 program to do this auto Multi-Track function for network testing and path saving, without triggering ALL the APRS IS users of this program.


        Those would be the the View / Mic-E Custom-0 to Custom-6 and Kenwood didn't make them up.  They're part of the original Mic-E status bits specification.  As I pointed about above, once you save the track of a moving station, APRSISCE/32 can auto-save it as it changes.  I really don't think you want a status that triggers your program to start consuming disk space every time a station uses it, do you?



        Using View / Mic-E / Custom-1 (for instance), you can see only those Mic-E status transmitting the Custom-1 status on your screen.  Unfortunately, this leaves out all of the non-Mic-E devices that might be participating in your event which is why I introduced the concept of !Shriek!s and allow you to apply them via a local nickname for those folks that come to an event without the ability to configure their particular APRS tracker device.


        Again, just trigger the MT function on RF only, when heard direct, ok?


        Sorry, but no.  Spec says it happens and the APRS-IS is just an extension of the RF environment.  They're one and the same to my implementation.  Besides, "heard direct" via HF APRS might still be from across the planet!  There's always someone out there using APRS differently than you've done so far which is why I'm trying to stick to the published specs.

        Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


      • PE1RDW
        I think bob refers to his drive to use the 2 reserved bits in the ssid byte: http://www.aprs.org/aprs12/RR-bits.txt so far the discusion on the mailing lists
        Message 3 of 13 , Jan 15, 2013
        • 0 Attachment
          I think bob refers to his drive to use the 2 reserved bits in the ssid
          byte:
          http://www.aprs.org/aprs12/RR-bits.txt

          so far the discusion on the mailing lists has been about use in digi
          fields for pre-emptive digipeating but looks like bob wants to use these
          bits in the source field to



          --
          73 Andre PE1RDW

          On Tue, 15 Jan 2013 23:11:52 +0100, Lynn W Deffenbaugh (Mr)
          <kj4erj@...> wrote:

          > What "priority" bit? Can you point me to a reference on that one?
          >
          > I've been discussion the Mic-E Priority status A=0 B=0 C=1 in the
          > Standard Mic-E Message Type table as extended by the humanly specifiable
          > !PRIORITY! in the status text as described at
          > http://aprs.org/aprs12/EmergencyCode.txt
          >
          > What "priority" bit are you referring to that is in an RF packet? I
          > thought AX.25 UI packets were just that, AX.25 UI packets.
          >
          > Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
          >
          > On 1/15/2013 5:07 PM, Robert Bruninga wrote:
          >>
          >>
          >> Lets not confuse the PRIORITY status comment in Mic-E with the
          >> “priority” bit we want to define. The PRIORITY status comment is for
          >> human to human conveyance of the word “PRIORITY”. The “priority” bit
          >> flags certain RF packets as higher priority than some less mundane and
          >> less important packets that can be dropped if loading gets too high.
          >>
          >> Just a clarification.
          >>
          >> Bob
          >>
          >> *From:*aprsisce@yahoogroups.com <mailto:aprsisce@yahoogroups.com>
          >> [mailto:aprsisce@yahoogroups.com <mailto:aprsisce@yahoogroups.com>]
          >> *On Behalf Of *Lynn W Deffenbaugh (Mr)
          >> *Sent:* Tuesday, January 15, 2013 2:35 PM
          >> *To:* aprsisce@yahoogroups.com <mailto:aprsisce@yahoogroups.com>
          >> *Subject:* Re: [aprsisce] Priority Status via APRS IS bug
          >>
          >> On 1/15/2013 1:22 PM, Pat Ryan KC6VVT wrote:
          >>
          >> Did not have this status issue with APRS DOS, anyway, before
          >> APRSIS32.
          >>
          >>
          >> Prior to APRSISCE/32, most APRS clients ignored the notification
          >> specification from http://aprs.org/aprs12/EmergencyCode.txt
          >>
          >> I've never had the opportunity to run APRSdos, so I can't speak to
          >> what it did or did not do.
          >>
          >>
          >> Good thing I did not set up all the local hospitals equipped with
          >> V/UHF/APRS to beacon with this 'Priority' status when activated for the
          >> critical need since I know that this alert goes out to ALL stations via
          >> RF and the APRS IS Internet system. I think that worked on APRS DOS
          >> without issue, but did not ring the alarm like EMERGENCY would do, and
          >> zoom in on the position of the station using EMERGENCY status.
          >>
          >>
          >> That goes along with my implementation of someone's suggestion that
          >> the Emergency symbol (\!) be treated like !EMERGENCY! or the Mic-E
          >> Emergency status. I've never seen that specified, but there's an
          >> amazing number of stations that think Emergency should be used for
          >> Police, Fire, and EOCs. When I see one of those, I suggest the
          >> possible better symbol.
          >>
          >>
          >> But I still would like to use 'Priority' status, when this status
          >> response is fixed to be for RF networks only, as a local attention flag
          >> only.
          >>
          >>
          >> Feel free to use it, but you can expect questions about their use.
          >> Just like I respond to Emergency status with a question as to whether
          >> remote assistance would be helpful, you might get the occasional
          >> question as to what you're up to. I'd do the same if I heard it via
          >> RF or via APRS-IS.
          >>
          >>
          >> And it would be nice to have another status available that would turn
          >> on just my own local RF terminal remotely in Multi-Track mode of
          >> APRSIS32.
          >>
          >>
          >> As you are now probably aware, I didn't make up the statuses. They're
          >> part of the Mic-E and APRS specification, along with the fact that
          >> notifications are attached to certain selections.
          >>
          >>
          >> Such a map/route function could be used in APRS as a Pathfinder mode,
          >> or to arrange meetings of other users to home in on hamfests, ARES or
          >> Field Day use.
          >>
          >>
          >> That's what !Shriek!s are for. Yes, with APRSISCE/32 you can group
          >> stations together, or they can group themselves together, with an
          >> arbitrary !ACTIVITY! added to their beacon text. And you can then
          >> filter the display to see only those stations that are transmitting,
          >> or that you have nicknamed, with !ACTIVITY! (where ACTIVITY is any
          >> (hopefully shorter) word that describes your event).
          >>
          >>
          >> At least APRSIS32 finally has the "Drive Track" function to replay line
          >> by line any saved *.gpx file, the trick is to get a local APRS operator
          >> to save it for use. That is what 'Priority' status should do, turn on
          >> Multi-Track and AUTOMATICALLY save that user's path until cancelled by
          >> that mobile's use of any other status, except 'EMERGENCY'.
          >>
          >>
          >> Unfortunately, there's no mention in the spec that certain status
          >> values should have their tracks automatically saved. BUT, have you
          >> selected the Tracks / Save Track to GPX on a moving station? It
          >> offers to "Auto-Save Future Track Changes" so you can "set it and
          >> forget it" and still get the entire track saved as it keeps moving.
          >>
          >>
          >> I also understand that *.gpx file can be loaded into some GPS to drive
          >> a route provided by others, but have not tested that as my NUVI 350 GPS
          >> does not have a ROUTE function like my old Garmin GP-45 had.
          >>
          >>
          >> Loading things into a Nuvi 350 is something that I haven't found to be
          >> very convenient.
          >>
          >>
          >> Perhaps in the APRSIS32 program, one of the 'Custom #' numbered status
          >> statements that Kenwood made available on the TM-D700/710 and TH-D7/72
          >> Radios for your local RF network could be recognized by the APRSIS32
          >> program to do this auto Multi-Track function for network testing and
          >> path saving, without triggering ALL the APRS IS users of this program.
          >>
          >>
          >> Those would be the the View / Mic-E Custom-0 to Custom-6 and Kenwood
          >> didn't make them up. They're part of the original Mic-E status bits
          >> specification. As I pointed about above, once you save the track of a
          >> moving station, APRSISCE/32 can auto-save it as it changes. I really
          >> don't think you want a status that triggers your program to start
          >> consuming disk space every time a station uses it, do you?
          >>
          >>
          >>
          >> Using View / Mic-E / Custom-1 (for instance), you can see only those
          >> Mic-E status transmitting the Custom-1 status on your screen.
          >> Unfortunately, this leaves out all of the non-Mic-E devices that might
          >> be participating in your event which is why I introduced the concept
          >> of !Shriek!s and allow you to apply them via a local nickname for
          >> those folks that come to an event without the ability to configure
          >> their particular APRS tracker device.
          >>
          >>
          >> Again, just trigger the MT function on RF only, when heard direct, ok?
          >>
          >>
          >> Sorry, but no. Spec says it happens and the APRS-IS is just an
          >> extension of the RF environment. They're one and the same to my
          >> implementation. Besides, "heard direct" via HF APRS might still be
          >> from across the planet! There's always someone out there using APRS
          >> differently than you've done so far which is why I'm trying to stick
          >> to the published specs.
          >>
          >> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
          >>
          >>
          >>
          >>
        • Steve Daniels
          I turned off special detection, as so many people send them out. I do have Emergengcy enabled. And will query if the person requires help, I have a world feed
          Message 4 of 13 , Jan 15, 2013
          • 0 Attachment

            I turned off special detection, as so many people send them out. I do have Emergengcy enabled. And will query if the person requires help, I have a world feed but it’s not that hard to hit google and get the local emergency services phone number.

            To my mind an Emergency broadcast is just that, you need help urgently. I know people think a Mic-E Emergency is for Hospital objects unfortunately.

             

            With Emergencies in mind it would not be hard to build a database, of localities country codes and emergency numbers, would be a nice feature of APRS.

            And obviously a feature which tells people that someone has contacted the emergency services, to stop the services being overrun with calls.

             

            It’s not unknown for radio amateurs to save someones life

             

            Steve Daniels

            Amateur Radio Callsign G6UIM

            Torbay Freecycle  Owner

            http://uk.groups.yahoo.com/group/torbay_freecycle

            APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

             


            From: aprsisce@yahoogroups.com [mailto: aprsisce@yahoogroups.com ] On Behalf Of Adam Mahnke
            Sent: 15 January 2013 20:35
            To: aprsisce@yahoogroups.com
            Subject: RE: [aprsisce] Priority Status via APRS IS bug

             

             

            You may not be running a full world view, or continental view that some of us do either. :) 
             
            Adam
            KC2ANT
             


            To: aprsisce@yahoogroups.com
            From: kb8rco@...
            Date: Tue, 15 Jan 2013 11:55:19 -0800
            Subject: Re: [aprsisce] Priority Status via APRS IS bug

             

            In a related question:

              Does the message have to get through your IS filters?

             

            I would assume that if I have a range filter set, then only MIC-E status messages that get through will trigger events. 

            In other words, there is NO SPECIAL provision to bypass the filter for an EMERGENCY status?

             

            I am pretty sure that is correct, as I have not received some of the actions that others have, but thought I'd ask.

             

            Robert Giuliano
            KB8RCO

             

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

            From: Lynn W Deffenbaugh (Mr) <kj4erj@...>
            To: aprsisce@yahoogroups.com
            Sent: Tuesday, January 15, 2013 2:41 PM
            Subject: Re: [aprsisce] Priority Status via APRS IS bug

             

            On 1/15/2013 1:51 PM, Robert Bruninga wrote:

            > I'm not following closely, but just because we have internet voyeur
            > capabilities that can drink from the global flood of APRS data worldwide,
            > the reaction of their systems to what we do locally on RF is of no local
            > concern. The global voyeur systems have to deal with the flood of data
            > entirely on their own because they are the cause that opened the global
            > tap in the first place.

            Indeed, that is the case. But the local operators also shouldn't take
            offense to a simple question like "What is the PRIORITY?" when they
            haven't taken the time to set anything descriptive into their status
            text. If I received this on my D700 via RF, I'd probably ask the same
            question.

            The APRS-IS is an extension to the RF network and APRS is planet-wide.
            Whatever you transmit, you can expect to be seen way beyond your local
            simplex range and therefore might even get offers of assistance from
            further afield than you might have otherwise anticipated.

            > Anyone should be able to use SPECIAL and PRIORITY locally on RF anytime it
            > is appropriate without concern for impact afar.

            Exactly! But by the same token, remote education is not a bad thing,
            and hence my innocent question about the nature of the Priority
            transmission. Many folks that transmit it are completely unaware of the
            notification actions that the status is requesting because Kenwood
            didn't include such details in their APRS manuals.

            It doesn't matter if the impact is on the local RF area or the global
            APRS-IS, transmitting Special, Priority, and/or Emergency is documented
            as requesting notifications at the receiving client end. And it's this
            fact that the casual user that simply thinks his/her station is
            "Special" needs to be aware of.

            Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

             

          Your message has been successfully submitted and would be delivered to recipients shortly.