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

DF Object

Expand Messages
  • Fred Hillhouse
    Hi Lynn, This is cool stuff! Thanks for adding it! ... I noticed that when I have a DF object from my location, that I get two icons (DF triangle) in addition
    Message 1 of 16 , Apr 1, 2011
      Hi Lynn,


      This is cool stuff! Thanks for adding it!

      ----
      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.

      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.

      Is this a bug?

      ----
      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

      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.

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

      Any objects sent to the server APRSIS32 would be automatically forwarded out
      all active ports. This would enable stations to see the DF objects as well.

      ----

      Thanks for the distraction! (I think...)


      Best regards,
      Fred Hillhouse Jr

      http://kevan.org/brain.cgi?N7FMH
    • 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 2 of 16 , Apr 1, 2011
        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 3 of 16 , Apr 1, 2011
          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 4 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 5 of 16 , Apr 1, 2011
            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 6 of 16 , Apr 1, 2011
              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 7 of 16 , Apr 1, 2011
                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 8 of 16 , Apr 1, 2011
                  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 9 of 16 , Apr 1, 2011
                    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 10 of 16 , Apr 1, 2011
                      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 11 of 16 , Apr 1, 2011
                        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 12 of 16 , Apr 1, 2011
                          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 13 of 16 , Apr 4, 2011
                            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 14 of 16 , Apr 4, 2011
                              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 15 of 16 , Apr 4, 2011
                                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 16 of 16 , Apr 4, 2011
                                  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.