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

RE: [aprsisce] DF Object

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.