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

Re: [aprsisce] DF Object

Expand Messages
  • James Ewen
    ... Lynn has implemented DF objects, and as such, there has to be an object created. APRS does have the ability to append BRG/NRQ data constructs onto the end
    Message 1 of 16 , Apr 1, 2011
    • 0 Attachment
      On Fri, Apr 1, 2011 at 10:47 AM, Fred Hillhouse <fmhillhouse@...> wrote:

      > I noticed that when I have a DF object from my location, that I get two
      > icons (DF triangle) in addition to the normal station icon.

      Lynn has implemented DF objects, and as such, there has to be an
      object created. APRS does have the ability to append BRG/NRQ data
      constructs onto the end of other sentences, but Lynn hasn't
      implemented that yet.

      > The normal station icon has a DF icon at the same location.
      > The actual DF object icon is shifted right about 1/2 minute. This icon has
      > the wedge extending from it.

      Did you perhaps move the center of the screen, and drop the DF unit
      there instead of at your location? Can you replicate and explain to us
      how to make it happen again?


      > Looking at the packet for the object above, I have:
      > *011611z4229.12N/07116.30W\.../.../033/608
      >
      > Since this station has no GPS it might be safe to assume it is stationary.
      > So, shouldn't the packet look like:
      > *011611z4229.12N/07116.30W\000/000/033/608

      The specification allows for spaces and periods to fill the course and
      speed portion. This makes more sense for an object, as the object does
      not have a course or speed. Reporting a course of zero and a speed of
      zero could indicate that the object might be able to move. Putting
      spaces or periods in place, you know that the object is not reporting
      course and speed.


      > I assume that if a GPS is connected, the course and speed gets filled if the
      > station is moving, else it would still be 000/000. I can't test that here.

      That would need to come from your external program that you're going
      to create that would automatically insert the CSE/SPD/BRG/NRQ
      information.

      Now here's the issue that I have with that concept... if you dead
      reckon the reported position, the DF vector should move along with the
      station... this would be a bad thing. A DF report should be a snapshot
      in time, reporting where the transmission was coming from at that
      instant.

      > I mentioned yesterday about making a DF object generator from my quickie
      > client. I now have a clearer picture of the direction to take.

      Have at it... What about making an external program that can move an
      object along a predefined path at a set rate? Lay out a GPX path, and
      drop an icon onto the path with an associated speed, and the program
      walks the object along, sending position reports as required. This is
      needed to support races and such, so that the estimated location of
      the lead runner, tail end charlie, etc can be seen on the map.

      I just set up my first server port yesterday, and have APRS icons
      automatically populating my RadioMobile instance... this stuff is
      getting more and more geeky as time goes by! I like geeky!!!

      James
      VE6SRV
    • Lynn W Deffenbaugh (Mr)
      ... And provide a screen shot please? If you enable -IS transmission of the objects and provide their names, we can even see it for ourselves. Lynn (D) -
      Message 2 of 16 , Apr 1, 2011
      • 0 Attachment
        On 4/1/2011 2:08 PM, James Ewen wrote:
        >
        > Did you perhaps move the center of the screen, and drop the DF unit
        > there instead of at your location? Can you replicate and explain to us
        > how to make it happen again?

        And provide a screen shot please? If you enable -IS transmission of the
        objects and provide their names, we can even see it for ourselves.

        Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
      • Fred Hillhouse
        I was interrupted while creating screen shots previously. The PNGs starting with DF are the items showing an object offset. There is a Show option which
        Message 3 of 16 , Apr 1, 2011
        I was interrupted while creating screen shots previously. The PNGs starting with DF are the items showing an object offset. There is a 'Show' option which makes a difference.
         
        The DF object was created after centering on the center of the universe: ME. :)
         
        Ah, the course and speed relates to the object. This is unknown if one is fox hunting, regardless of the fox.
         
        Explain the RM setup please.
         
        In addition, I have included another screenshot showing the results from using ARRL Travel Plus for Repeaters. They provide a bearing and distance but not latitude and longitude. The data they have is based on a generic position of locations. Location being towns, cities, etc.
         
        TP-DF.PNG shows the triangulation of three objects per location. The two locations are Bedford and Goffstown. As an exercise, it was fun but not really useful to determine the real location of a repeater. It is close enough though when one considers that from all the towns around Bedford or Goffstown, all the repeaters can be used using 5 watts. So precision is not necessary.
         
        Best regards,
        Fred
         
        PS. Here are the DF objects I created:
         
        <!--Object[0]-->
        <Object Name="BF1">
        <Group>fmh</Group>
        <Comment>.../.../192/938</Comment>
        <Table>/</Table>
        <Symbol>\</Symbol>
        <Latitude>43.000083</Latitude>
        <Longitude>-71.499992</Longitude>
        <Precision>0</Precision>
        <Item>0</Item>
        <HHMMSS>0</HHMMSS>
        <Permanent>0</Permanent>
        <Interval>10</Interval>
        <Kill>0</Kill>
        <Enabled>1</Enabled>
        <ISEnabled>0</ISEnabled>
        <RFEnabled>0</RFEnabled>
        <RFPath></RFPath>
        <LastTransmit>2011-04-01T18:22:15</LastTransmit>
        <Weather>0</Weather>
        <WeatherPath></WeatherPath>
        <LastWeather>0000-00-00T00:00:00</LastWeather>
        </Object>
        <!--Object[0]-->
         
        <!--Object[1]-->
        <Object Name="BF2">
        <Group>fmh</Group>
        <Comment>.../.../357/958</Comment>
        <Table>/</Table>
        <Symbol>\</Symbol>
        <Latitude>42.799964</Latitude>
        <Longitude>-71.500078</Longitude>
        <Precision>0</Precision>
        <Item>0</Item>
        <HHMMSS>0</HHMMSS>
        <Permanent>0</Permanent>
        <Interval>10</Interval>
        <Kill>0</Kill>
        <Enabled>1</Enabled>
        <ISEnabled>0</ISEnabled>
        <RFEnabled>0</RFEnabled>
        <RFPath></RFPath>
        <LastTransmit>2011-04-01T18:18:15</LastTransmit>
        <Weather>0</Weather>
        <WeatherPath></WeatherPath>
        <LastWeather>0000-00-00T00:00:00</LastWeather>
        </Object>
        <!--Object[1]-->
         
        <!--Object[2]-->
        <Object Name="BF3">
        <Group>fmh</Group>
        <Comment>.../.../299/948</Comment>
        <Table>/</Table>
        <Symbol>\</Symbol>
        <Latitude>42.899993</Latitude>
        <Longitude>-71.400000</Longitude>
        <Precision>0</Precision>
        <Item>0</Item>
        <HHMMSS>0</HHMMSS>
        <Permanent>0</Permanent>
        <Interval>10</Interval>
        <Kill>0</Kill>
        <Enabled>1</Enabled>
        <ISEnabled>0</ISEnabled>
        <RFEnabled>0</RFEnabled>
        <RFPath></RFPath>
        <LastTransmit>2011-04-01T18:22:45</LastTransmit>
        <Weather>0</Weather>
        <WeatherPath></WeatherPath>
        <LastWeather>0000-00-00T00:00:00</LastWeather>
        </Object>
        <!--Object[2]-->
         
        <!--Object[3]-->
        <Object Name="GF1">
        <Group>fmh</Group>
        <Comment>.../.../287/938</Comment>
        <Table>/</Table>
        <Symbol>\</Symbol>
        <Latitude>43.000083</Latitude>
        <Longitude>-71.499992</Longitude>
        <Precision>0</Precision>
        <Item>0</Item>
        <HHMMSS>0</HHMMSS>
        <Permanent>0</Permanent>
        <Interval>10</Interval>
        <Kill>0</Kill>
        <Enabled>1</Enabled>
        <ISEnabled>0</ISEnabled>
        <RFEnabled>0</RFEnabled>
        <RFPath></RFPath>
        <LastTransmit>2011-04-01T18:24:45</LastTransmit>
        <Weather>0</Weather>
        <WeatherPath></WeatherPath>
        <LastWeather>0000-00-00T00:00:00</LastWeather>
        </Object>
        <!--Object[3]-->
         
        <!--Object[4]-->
        <Object Name="GF2">
        <Group>fmh</Group>
        <Comment>.../.../342/958</Comment>
        <Table>/</Table>
        <Symbol>\</Symbol>
        <Latitude>42.799964</Latitude>
        <Longitude>-71.500078</Longitude>
        <Precision>0</Precision>
        <Item>0</Item>
        <HHMMSS>0</HHMMSS>
        <Permanent>0</Permanent>
        <Interval>10</Interval>
        <Kill>0</Kill>
        <Enabled>1</Enabled>
        <ISEnabled>0</ISEnabled>
        <RFEnabled>0</RFEnabled>
        <RFPath></RFPath>
        <LastTransmit>2011-04-01T18:27:15</LastTransmit>
        <Weather>0</Weather>
        <WeatherPath></WeatherPath>
        <LastWeather>0000-00-00T00:00:00</LastWeather>
        </Object>
        <!--Object[4]-->
         
        <!--Object[5]-->
        <Object Name="GF3">
        <Group>fmh</Group>
        <Comment>.../.../309/958</Comment>
        <Table>/</Table>
        <Symbol>\</Symbol>
        <Latitude>42.899993</Latitude>
        <Longitude>-71.400000</Longitude>
        <Precision>0</Precision>
        <Item>0</Item>
        <HHMMSS>0</HHMMSS>
        <Permanent>0</Permanent>
        <Interval>10</Interval>
        <Kill>0</Kill>
        <Enabled>1</Enabled>
        <ISEnabled>0</ISEnabled>
        <RFEnabled>0</RFEnabled>
        <RFPath></RFPath>
        <LastTransmit>2011-04-01T18:23:45</LastTransmit>
        <Weather>0</Weather>
        <WeatherPath></WeatherPath>
        <LastWeather>0000-00-00T00:00:00</LastWeather>
        </Object>
        <!--Object[5]-->
         
        <!--Object[6]-->
        <Object Name="T1">
        <Group>fmh</Group>
        <Comment>.../.../033/908</Comment>
        <Table>/</Table>
        <Symbol>\</Symbol>
        <Latitude>42.485342</Latitude>
        <Longitude>-71.271747</Longitude>
        <Precision>0</Precision>
        <Item>0</Item>
        <HHMMSS>0</HHMMSS>
        <Permanent>0</Permanent>
        <Interval>10</Interval>
        <Kill>0</Kill>
        <Enabled>1</Enabled>
        <ISEnabled>0</ISEnabled>
        <RFEnabled>0</RFEnabled>
        <RFPath></RFPath>
        <LastTransmit>0000-00-00T00:00:00</LastTransmit>
        <Weather>0</Weather>
        <WeatherPath></WeatherPath>
        <LastWeather>0000-00-00T00:00:00</LastWeather>
        </Object>
        <!--Object[6]-->


        From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of James Ewen
        Sent: Friday, April 01, 2011 14:08
        To: aprsisce@yahoogroups.com
        Subject: Re: [aprsisce] DF Object

         

        On Fri, Apr 1, 2011 at 10:47 AM, Fred Hillhouse <fmhillhouse@...> wrote:

        > I noticed that when I have a DF object from my location, that
        I get two
        > icons (DF triangle) in addition to the normal station
        icon.

        Lynn has implemented DF objects, and as such, there has to be an
        object created. APRS does have the ability to append BRG/NRQ data
        constructs onto the end of other sentences, but Lynn hasn't
        implemented that yet.

        > The normal station icon has a DF
        icon at the same location.
        > The actual DF object icon is shifted right
        about 1/2 minute. This icon has
        > the wedge extending from it.

        Did you perhaps move the center of the screen, and drop the DF unit
        there instead of at your location? Can you replicate and explain to us
        how to make it happen again?

        > Looking at the packet for the object above, I
        have:
        > *011611z4229.12N/07116.30W\.../.../033/608
        >
        > Since
        this station has no GPS it might be safe to assume it is stationary.
        > So,
        shouldn't the packet look like:
        >
        *011611z4229.12N/07116.30W\000/000/033/608

        The specification allows for spaces and periods to fill the course and
        speed portion. This makes more sense for an object, as the object does
        not have a course or speed. Reporting a course of zero and a speed of
        zero could indicate that the object might be able to move. Putting
        spaces or periods in place, you know that the object is not reporting
        course and speed.

        > I assume that if a GPS is
        connected, the course and speed gets filled if the
        > station is moving,
        else it would still be 000/000. I can't test that here.

        That would need to come from your external program that you're going
        to create that would automatically insert the CSE/SPD/BRG/NRQ
        information.

        Now here's the issue that I have with that concept... if you dead
        reckon the reported position, the DF vector should move along with the
        station... this would be a bad thing. A DF report should be a snapshot
        in time, reporting where the transmission was coming from at that
        instant.

        > I mentioned
        yesterday about making a DF object generator from my quickie
        > client. I
        now have a clearer picture of the direction to take.

        Have at it... What about making an external program that can move an
        object along a predefined path at a set rate? Lay out a GPX path, and
        drop an icon onto the path with an associated speed, and the program
        walks the object along, sending position reports as required. This is
        needed to support races and such, so that the estimated location of
        the lead runner, tail end charlie, etc can be seen on the map.

        I just set up my first server port yesterday, and have APRS icons
        automatically populating my RadioMobile instance... this stuff is
        getting more and more geeky as time goes by! I like geeky!!!

        James
        VE6SRV

      • James Ewen
        ... I just created 2 at center when centered on me. Both DF objects were created about 20 feet north of my location. I never noticed before because I was never
        Message 4 of 16 , Apr 1, 2011
        • 0 Attachment
          On Fri, Apr 1, 2011 at 12:48 PM, Fred Hillhouse <fmhillhouse@...> wrote:

          > The PNGs starting with DF are the items showing an object offset.
          >
          > The DF object was created after centering on the center of the universe: ME. :)

          I just created 2 at center when centered on me. Both DF objects were
          created about 20 feet north of my location. I never noticed before
          because I was never zoomed in that close.

          > Ah, the course and speed relates to the object. This is unknown
          > if one is fox hunting, regardless of the fox.

          Nope, the course and speed of the DF report object, not the RDF
          target. I know how fast the location that I took my bearing from is
          moving... it's not moving.

          James
          VE6SRV
        • Fred Hillhouse
          Okay, you are seeing the same thing then. Isn t the DF object (the fox) and DF report object (still the fox) really the same? At least I see it that way since
          Message 5 of 16 , Apr 1, 2011
          • 0 Attachment
            Okay, you are seeing the same thing then.
             
            Isn't the DF object (the fox) and DF report object (still the fox) really the same? At least I see it that way since I am pointing at the fox. Once the fox is found then it becomes an 'object' from a collection of 'DF objects'. We are probably splitting hairs at the moment.
             
            I will agree that '...' is better than '000' for course and speed since '000' implies it is known to be motionless. Once a series of readings are taken, then the calculated course and speed could be added to maybe determine an intercept course for the hunter(s).
             
            Gee, this is fun!
             
            Best regards,
            Fred
             
             
             

            From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of James Ewen
            Sent: Friday, April 01, 2011 15:25
            To: aprsisce@yahoogroups.com
            Subject: Re: [aprsisce] DF Object

             

            On Fri, Apr 1, 2011 at 12:48 PM, Fred Hillhouse <fmhillhouse@...> wrote:

            > The PNGs starting with DF are the items showing an object
            offset.
            >
            > The DF object was created after centering on the center
            of the universe: ME. :)

            I just created 2 at center when centered on me. Both DF objects were
            created about 20 feet north of my location. I never noticed before
            because I was never zoomed in that close.

            > Ah, the
            course and speed relates to the object. This is unknown
            > if one is fox
            hunting, regardless of the fox.

            Nope, the course and speed of the DF report object, not the RDF
            target. I know how fast the location that I took my bearing from is
            moving... it's not moving.

            James
            VE6SRV

          • Lynn W Deffenbaugh (Mr)
            Ever wonder why there s an option for additional digits of precision? ME is always displayed at full resolution. Other object s resolution depend on their DAO
            Message 6 of 16 , Apr 1, 2011
            • 0 Attachment
              Ever wonder why there's an option for additional digits of precision?
              ME is always displayed at full resolution. Other object's resolution
              depend on their DAO settings which defaults to only 0.01 minutes for
              your created objects. Edit the object definition in the XML and set
              precision to 2 on the objects. That'll give you another 1/91 precision,
              approximately 0.0001 minutes.

              The reason you might see two objects when you toggle on Configure /
              Objects / Show is that one of them (the one that you can't click on) is
              shown at the full precision coordinates and the other is the one that
              has been formatted, internally transmitted, and interpreted resulting in
              it rounding to 0.01 minutes. At least, I suspect that's what's going on
              here.

              APRSISCE/32 forces the DF objects to a .../.../bbb/nrq to indicate that
              it is not providing a speed or heading. 000/000/bbb/nrq might imply
              that you are capable of moving but are currently not. The spec allows
              for either so I opted for the more informative (and less visually
              intrusive) one.

              Question: If a DF object transmits a non-zero course and speed, does the
              cone move over time (which makes no sense) and if not, why do I care
              that the source of the DF information was moving when the reading was
              taken?

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


              On 4/1/2011 3:25 PM, James Ewen wrote:
              > On Fri, Apr 1, 2011 at 12:48 PM, Fred Hillhouse<fmhillhouse@...> wrote:
              >
              >> The PNGs starting with DF are the items showing an object offset.
              >>
              >> The DF object was created after centering on the center of the universe: ME. :)
              > I just created 2 at center when centered on me. Both DF objects were
              > created about 20 feet north of my location. I never noticed before
              > because I was never zoomed in that close.
              >
              >> Ah, the course and speed relates to the object. This is unknown
              >> if one is fox hunting, regardless of the fox.
              > Nope, the course and speed of the DF report object, not the RDF
              > target. I know how fast the location that I took my bearing from is
              > moving... it's not moving.
              >
              > James
              > VE6SRV
              >
              >
              > ------------------------------------
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
            • Lynn W Deffenbaugh (Mr)
              I thought all the DF objects were points at which readings were taken and were pointed toward the fox, but we don t know where the fox is? When enough DFs
              Message 7 of 16 , Apr 1, 2011
              • 0 Attachment
                I thought all the DF objects were points at which readings were taken and were pointed toward the fox, but we don't know where the fox is?

                When enough DFs overlap at a point, then the fox's location is approximately known.  If the fox is moving, then you'll have a bunch of DFs that probably don't intersect, but have some...I don't know....visual pattern to them if you knew what path the fox was following?

                To catch a moving fox, I'd think you'd need multiple simultaneously sample-grabbing DF stations that could be plotted so that an overlap would be determined.  Then, N minutes later, the same bunch of fox hunters simultaneously grab another reading and determine the overlap again.  Enough of those multi-observer samples would give you a series of time-based overlaps from which you may or may not be able to determine the fox's path.

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

                PS.  (Are you sure we don't need a red dot floating around in there somewhere?)

                On 4/1/2011 3:46 PM, Fred Hillhouse wrote:
                Okay, you are seeing the same thing then.
                 
                Isn't the DF object (the fox) and DF report object (still the fox) really the same? At least I see it that way since I am pointing at the fox. Once the fox is found then it becomes an 'object' from a collection of 'DF objects'. We are probably splitting hairs at the moment.
                 
                I will agree that '...' is better than '000' for course and speed since '000' implies it is known to be motionless. Once a series of readings are taken, then the calculated course and speed could be added to maybe determine an intercept course for the hunter(s).
                 
                Gee, this is fun!
                 
                Best regards,
                Fred
                 
                 
                 

                From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of James Ewen
                Sent: Friday, April 01, 2011 15:25
                To: aprsisce@yahoogroups.com
                Subject: Re: [aprsisce] DF Object

                 

                On Fri, Apr 1, 2011 at 12:48 PM, Fred Hillhouse <fmhillhouse@...> wrote:

                > The PNGs starting with DF are the items showing an object offset.
                >
                > The DF object was created after centering on the center of the universe: ME. :)

                I just created 2 at center when centered on me. Both DF objects were
                created about 20 feet north of my location. I never noticed before
                because I was never zoomed in that close.

                > Ah, the course and speed relates to the object. This is unknown
                > if one is fox hunting, regardless of the fox.

                Nope, the course and speed of the DF report object, not the RDF
                target. I know how fast the location that I took my bearing from is
                moving... it's not moving.

                James
                VE6SRV


              • Lynn W Deffenbaugh (Mr)
                ... Ok, now THAT shows me how DF might work out. Of course, it was done with repeater-directory-provided observation points and bearings from that point, but
                Message 8 of 16 , Apr 1, 2011
                • 0 Attachment
                  On 4/1/2011 2:48 PM, Fred Hillhouse wrote:
                  __._,

                • James Ewen
                  ... Aha! There s always a reason... I wish I had waited with my response until after Lynn said this so I could have said Duh Fred, don t you know anything
                  Message 9 of 16 , Apr 1, 2011
                  • 0 Attachment
                    On Fri, Apr 1, 2011 at 2:49 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:

                    > Ever wonder why there's an option for additional digits of precision?
                    > ME is always displayed at full resolution.  Other object's resolution
                    > depend on their DAO settings which defaults to only 0.01 minutes for
                    > your created objects.  Edit the object definition in the XML and set
                    > precision to 2 on the objects.  That'll give you another 1/91 precision,
                    > approximately 0.0001 minutes.

                    Aha! There's always a reason... I wish I had waited with my response
                    until after Lynn said this so I could have said "Duh Fred, don't you
                    know anything about digits of precision?" 8)

                    > Question: If a DF object transmits a non-zero course and speed, does the
                    > cone move over time (which makes no sense) and if not, why do I care
                    > that the source of the DF information was moving when the reading was
                    > taken?

                    That's what I was saying... If I were driving down the road, taking DF
                    readings in motion with my Doppler unit, it would be possible to have
                    a course and speed associated with the bearing. However, the bearing
                    reported was reported at a single instance in time. If the object were
                    to be dead reckoned, the DF vector should remain in place where it was
                    reported, even if the reporting station is moving.

                    That could make for an interesting display as the DF vectors would end
                    up being orphaned. There would be no source icon easily associated to
                    the DF vectors. The DF vectors would need to have times associated
                    with them in order to be timed out, even if the source station is
                    still active.

                    The more I look at the way DF reports can be sent in APRS, the more I
                    think that a DF report should always be generated as a DF vector
                    object like APRSISCE/32 does currently.

                    The only reason that I can see for needing a course in a DF report, is
                    if the reporting station hardware can only report a bearing relative
                    to the front of the array. If I am headed north, and my array reports
                    90 degrees, then the DF vector report should face east. However if I
                    am headed east, and my array reports 90 degrees, then the DF vector
                    report should face south.

                    That kind of thing needs to be taken care of within the program
                    creating the DF report though. There's no specification in the APRS DF
                    definition that I have seen yet to specify if the DF report is TRUE or
                    RELATIVE to direction of travel.

                    James
                    VE6SRV
                  • James Ewen
                    ... You thought correctly. ... Indeed, that s the process. If multiple units are working collaboratively, the foxes location can be quickly determined. If
                    Message 10 of 16 , Apr 1, 2011
                    • 0 Attachment
                      On Fri, Apr 1, 2011 at 2:54 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:

                      > I thought all the DF objects were points at which readings were taken
                      > and were pointed toward the fox, but we don't know where the fox is?

                      You thought correctly.

                      > When enough DFs overlap at a point, then the fox's location is approximately known.

                      Indeed, that's the process. If multiple units are working
                      collaboratively, the foxes location can be quickly determined. If
                      working competitively, then the hunting station needs to use some
                      cunning in order to be located in a spot that provides a cross
                      directional that narrows down the search area in a hurry when the fox
                      transmits again.

                      > If the fox is moving, then you'll have a bunch of DFs that probably don't
                      > intersect, but have some...I don't know....visual pattern to them if you
                      > knew what path the fox was following?

                      Cooperative hunts for moving foxes are much easier than running a
                      competitive hunt. It takes some serious effort to track down a mobile
                      fox, catch up to them, and finally capture them. I've been on a couple
                      of those, and you can rack up some serious mileage trying to get close
                      and capture that elusive fox. Stationary foxes are dead simple in
                      comparison.

                      > To catch a moving fox, I'd think you'd need multiple simultaneously
                      > sample-grabbing DF stations that could be plotted so that an overlap
                      > would be determined.  Then, N minutes later, the same bunch of fox
                      > hunters simultaneously grab another reading and determine the overlap
                      > again.  Enough of those multi-observer samples would give you a series
                      > of time-based overlaps from which you may or may not be able to determine
                      > the fox's path.

                      And for that to be readily apparent, it would be helpful if all
                      bearings reported at a specific time were coloured the same, and then
                      the next set of bearings with another colour set. With good quality
                      bearings, you would hopefully see the green DF sectors all overlapping
                      at a specific location, then the yellow DF sectors overlapping at
                      another location, the red DF sectors at a third location, and from
                      that a possible direction of travel, and perhaps even be able to
                      determine which road the fox might be travelling on.

                      Without colour sets, one could still visualize the progression, but it
                      might be harder to determine which vectors were taken at what time.

                      That however is a seriously advanced implementation... I'm good with
                      what we have in place now.

                      James
                      VE6SRV
                    • James Ewen
                      ... Absolutely not... the fox is your target. The DF vector report is an instantaneous heading towards the strongest signal source. The target will be a point
                      Message 11 of 16 , Apr 1, 2011
                      • 0 Attachment
                        On Fri, Apr 1, 2011 at 1:46 PM, Fred Hillhouse <fmhillhouse@...> wrote:

                        > Isn't the DF object (the fox) and DF report object (still the fox) really the same?

                        Absolutely not... the fox is your target. The DF vector report is an
                        instantaneous heading towards the strongest signal source. The target
                        will be a point at some unknown location. Three DF vector reports
                        taken at the same time from different locations will all have
                        different lat/long values, and different vectors, but all *should*
                        point to the target location.

                        > At least I see it that way since I am pointing at the fox. Once the fox is found
                        > then it becomes an 'object' from a collection of 'DF objects'. We are probably
                        > splitting hairs at the moment.

                        No, not splitting hares (that would be a bunny hunt!)... it is true
                        that we are all pointing at and describing the same target, but arrows
                        pointing at the target are not the target. If that were the case,
                        driving past a sign on the highway saying "Grande Canyon --->" would
                        be the same as actually being at the Grande Canyon.

                        > I will agree that '...' is better than '000' for course and speed since '000'
                        > implies it is known to be motionless. Once a series of readings are taken,
                        > then the calculated course and speed could be added to maybe determine
                        > an intercept course for the hunter(s).

                        Again, the course and speed reported in the DF object report is the
                        course and speed of the DF object (that's the signpost on the side of
                        the road), not the course and speed of the target. The DF report is
                        simply a direction and quality report, and the object used to describe
                        it is required to describe to the remote observer where the measured
                        directional and quality report was taken from.

                        Are you looking at these reports backwards? The triangle shaped sector
                        does not narrow down and point towards the DF object icon to describe
                        the fox location, but rather the DF object icon shows where the report
                        was initiated, and the directional expands away from there towards the
                        direction that the signal was heard from, where if all goes well, the
                        fox will be located within.

                        James
                        VE6SRV
                      • Fred Hillhouse
                        I hate these DOH moments. Thanks James for pointing me in the right direction! I liked the triangle shaped sector idea that is pointing to the DF object
                        Message 12 of 16 , Apr 4, 2011
                        • 0 Attachment
                          I hate these "DOH" moments. Thanks James for pointing me in the right direction!
                           
                          I liked the 'triangle shaped sector' idea that is pointing to the DF object location.
                           
                          Best regards,
                           
                          Fred, N7FMH


                          From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of James Ewen
                          Sent: Friday, April 01, 2011 21:08
                          To: aprsisce@yahoogroups.com
                          Subject: Re: [aprsisce] DF Object

                           

                          On Fri, Apr 1, 2011 at 1:46 PM, Fred Hillhouse <fmhillhouse@...> wrote:

                          > Isn't the DF object (the fox) and DF report object
                          (still the fox) really the same?

                          Absolutely not... the fox is your target. The DF vector report is an
                          instantaneous heading towards the strongest signal source. The target
                          will be a point at some unknown location. Three DF vector reports
                          taken at the same time from different locations will all have
                          different lat/long values, and different vectors, but all *should*
                          point to the target location.

                          > At least I see it that way
                          since I am pointing at the fox. Once the fox is found
                          > then it becomes an
                          'object' from a collection of 'DF objects'. We are probably
                          >
                          splitting hairs at the moment.

                          No, not splitting hares (that would be a bunny hunt!)... it is true
                          that we are all pointing at and describing the same target, but arrows
                          pointing at the target are not the target. If that were the case,
                          driving past a sign on the highway saying "Grande Canyon --->" would
                          be the same as actually being at the Grande Canyon.

                          > I will agree that '...' is better than '000' for course and
                          speed since '000'
                          > implies it is known to be motionless. Once a series of
                          readings are taken,
                          > then the calculated course and speed could be added
                          to maybe determine
                          > an intercept course for the hunter(s).

                          Again, the course and speed reported in the DF object report is the
                          course and speed of the DF object (that's the signpost on the side of
                          the road), not the course and speed of the target. The DF report is
                          simply a direction and quality report, and the object used to describe
                          it is required to describe to the remote observer where the measured
                          directional and quality report was taken from.

                          Are you looking at these reports backwards? The triangle shaped sector
                          does not narrow down and point towards the DF object icon to describe
                          the fox location, but rather the DF object icon shows where the report
                          was initiated, and the directional expands away from there towards the
                          direction that the signal was heard from, where if all goes well, the
                          fox will be located within.

                          James
                          VE6SRV

                        • Fred Hillhouse
                          James, I think Lynn likes answering questions. And, of course, hiding little details in the XML helps. :D Lynn, why not just use the precision of the station
                          Message 13 of 16 , Apr 4, 2011
                          • 0 Attachment
                            James, I think Lynn likes answering questions. And, of course, hiding little details in the XML helps. :D
                             
                            Lynn, why not just use the precision of the station generating the DF object? Does it add more bytes to the packet? I could look it up, but, Lynn likes answering questions anyway.
                             
                            Best regards,
                            Fred
                             

                            From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of James Ewen
                            Sent: Friday, April 01, 2011 19:25
                            To: aprsisce@yahoogroups.com
                            Subject: Re: [aprsisce] DF Object

                             

                            On Fri, Apr 1, 2011 at 2:49 PM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:

                            > Ever
                            wonder why there's an option for additional digits of precision?
                            > ME is
                            always displayed at full resolution.  Other object's resolution
                            >
                            depend on their DAO settings which defaults to only 0.01 minutes for
                            >
                            your created objects.  Edit the object definition in the XML and set
                            > precision to 2 on the objects.  That'll give you another 1/91
                            precision,
                            > approximately 0.0001 minutes.

                            Aha! There's always a reason... I wish I had waited with my response
                            until after Lynn said this so I could have said "Duh Fred, don't you
                            know anything about digits of precision?" 8)

                            > Question: If a DF object transmits a non-zero course
                            and speed, does the
                            > cone move over time (which makes no sense) and if
                            not, why do I care
                            > that the source of the DF information was moving when
                            the reading was
                            > taken?

                            That's what I was saying... If I were driving down the road, taking DF
                            readings in motion with my Doppler unit, it would be possible to have
                            a course and speed associated with the bearing. However, the bearing
                            reported was reported at a single instance in time. If the object were
                            to be dead reckoned, the DF vector should remain in place where it was
                            reported, even if the reporting station is moving.

                            That could make for an interesting display as the DF vectors would end
                            up being orphaned. There would be no source icon easily associated to
                            the DF vectors. The DF vectors would need to have times associated
                            with them in order to be timed out, even if the source station is
                            still active.

                            The more I look at the way DF reports can be sent in APRS, the more I
                            think that a DF report should always be generated as a DF vector
                            object like APRSISCE/32 does currently.

                            The only reason that I can see for needing a course in a DF report, is
                            if the reporting station hardware can only report a bearing relative
                            to the front of the array. If I am headed north, and my array reports
                            90 degrees, then the DF vector report should face east. However if I
                            am headed east, and my array reports 90 degrees, then the DF vector
                            report should face south.

                            That kind of thing needs to be taken care of within the program
                            creating the DF report though. There's no specification in the APRS DF
                            definition that I have seen yet to specify if the DF report is TRUE or
                            RELATIVE to direction of travel.

                            James
                            VE6SRV

                          • Lynn W Deffenbaugh (Mr)
                            I ll try to remember that when I finally figure out how to rotate the symbol bitmaps. Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                            Message 14 of 16 , Apr 4, 2011
                            • 0 Attachment
                              I'll try to remember that when I finally figure out how to rotate the symbol bitmaps.

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

                              On 4/4/2011 12:23 PM, Fred Hillhouse wrote:
                              I hate these "DOH" moments. Thanks James for pointing me in the right direction!
                               
                              I liked the 'triangle shaped sector' idea that is pointing to the DF object location.
                               
                              Best regards,
                               
                              Fred, N7FMH


                              From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of James Ewen
                              Sent: Friday, April 01, 2011 21:08
                              To: aprsisce@yahoogroups.com
                              Subject: Re: [aprsisce] DF Object

                               

                              On Fri, Apr 1, 2011 at 1:46 PM, Fred Hillhouse <fmhillhouse@...> wrote:

                              > Isn't the DF object (the fox) and DF report object (still the fox) really the same?

                              Absolutely not... the fox is your target. The DF vector report is an
                              instantaneous heading towards the strongest signal source. The target
                              will be a point at some unknown location. Three DF vector reports
                              taken at the same time from different locations will all have
                              different lat/long values, and different vectors, but all *should*
                              point to the target location.

                              > At least I see it that way since I am pointing at the fox. Once the fox is found
                              > then it becomes an 'object' from a collection of 'DF objects'. We are probably
                              > splitting hairs at the moment.

                              No, not splitting hares (that would be a bunny hunt!)... it is true
                              that we are all pointing at and describing the same target, but arrows
                              pointing at the target are not the target. If that were the case,
                              driving past a sign on the highway saying "Grande Canyon --->" would
                              be the same as actually being at the Grande Canyon.

                              > I will agree that '...' is better than '000' for course and speed since '000'
                              > implies it is known to be motionless. Once a series of readings are taken,
                              > then the calculated course and speed could be added to maybe determine
                              > an intercept course for the hunter(s).

                              Again, the course and speed reported in the DF object report is the
                              course and speed of the DF object (that's the signpost on the side of
                              the road), not the course and speed of the target. The DF report is
                              simply a direction and quality report, and the object used to describe
                              it is required to describe to the remote observer where the measured
                              directional and quality report was taken from.

                              Are you looking at these reports backwards? The triangle shaped sector
                              does not narrow down and point towards the DF object icon to describe
                              the fox location, but rather the DF object icon shows where the report
                              was initiated, and the directional expands away from there towards the
                              direction that the signal was heard from, where if all goes well, the
                              fox will be located within.

                              James
                              VE6SRV


                            • Fred Hillhouse
                              Nothing to remember. It already points at the source of the object. This is right. The triangle shaped sector does not narrow down and point towards the DF
                              Message 15 of 16 , Apr 4, 2011
                              • 0 Attachment
                                Nothing to remember. It already points at the source of the object. This is right.
                                 
                                "The triangle shaped sector does not narrow down and point towards the DF object icon to describe the fox location, but rather the DF object icon shows where the report was initiated"
                                 
                                Best regards,
                                Fred, N7FMH

                                From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Lynn W Deffenbaugh (Mr)
                                Sent: Monday, April 04, 2011 13:32
                                To: aprsisce@yahoogroups.com
                                Subject: Re: [aprsisce] DF Object

                                 

                                I'll try to remember that when I finally figure out how to rotate the symbol bitmaps.

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

                                On 4/4/2011 12:23 PM, Fred Hillhouse wrote:
                                I hate these "DOH" moments. Thanks James for pointing me in the right direction!
                                 
                                I liked the 'triangle shaped sector' idea that is pointing to the DF object location.
                                 
                                Best regards,
                                 
                                Fred, N7FMH


                                From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of James Ewen
                                Sent: Friday, April 01, 2011 21:08
                                To: aprsisce@yahoogroups.com
                                Subject: Re: [aprsisce] DF Object

                                 

                                On Fri, Apr 1, 2011 at 1:46 PM, Fred Hillhouse <fmhillhouse@...> wrote:

                                > Isn't the DF object (the fox) and DF report object (still the fox) really the same?

                                Absolutely not... the fox is your target. The DF vector report is an
                                instantaneous heading towards the strongest signal source. The target
                                will be a point at some unknown location. Three DF vector reports
                                taken at the same time from different locations will all have
                                different lat/long values, and different vectors, but all *should*
                                point to the target location.

                                > At least I see it that way since I am pointing at the fox. Once the fox is found
                                > then it becomes an 'object' from a collection of 'DF objects'. We are probably
                                > splitting hairs at the moment.

                                No, not splitting hares (that would be a bunny hunt!)... it is true
                                that we are all pointing at and describing the same target, but arrows
                                pointing at the target are not the target. If that were the case,
                                driving past a sign on the highway saying "Grande Canyon --->" would
                                be the same as actually being at the Grande Canyon.

                                > I will agree that '...' is better than '000' for course and speed since '000'
                                > implies it is known to be motionless. Once a series of readings are taken,
                                > then the calculated course and speed could be added to maybe determine
                                > an intercept course for the hunter(s).

                                Again, the course and speed reported in the DF object report is the
                                course and speed of the DF object (that's the signpost on the side of
                                the road), not the course and speed of the target. The DF report is
                                simply a direction and quality report, and the object used to describe
                                it is required to describe to the remote observer where the measured
                                directional and quality report was taken from.

                                Are you looking at these reports backwards? The triangle shaped sector
                                does not narrow down and point towards the DF object icon to describe
                                the fox location, but rather the DF object icon shows where the report
                                was initiated, and the directional expands away from there towards the
                                direction that the signal was heard from, where if all goes well, the
                                fox will be located within.

                                James
                                VE6SRV


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