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

RE: [tracker2] GPS data to computer as well?

Expand Messages
  • scott@opentrac.org
    The KISS thing should be doable. I ve just got to figure out how I m going to handle it, given that the whole NMEA string is never buffered in memory. Also,
    Message 1 of 12 , Oct 4, 2006
    • 0 Attachment
      The KISS thing should be doable.  I've just got to figure out how I'm going to handle it, given that the whole NMEA string is never buffered in memory.  Also, it'd be possible to generate a string from data obtained in Garmin binary mode, but it'd take some extra work.
       
      Scott
       
       
      From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of Curt, WE7U
      Sent: Tuesday, October 03, 2006 8:21 AM
      To: tracker2@yahoogroups.com
      Subject: RE: [tracker2] GPS data to computer as well?

      On Sun, 1 Oct 2006 scott@opentrac. org wrote:

      > Not yet. I'd be wary of throwing them in between KISS frames - too much
      > potential for interference there.

      Actually you might be able to do something tricky like enclose the
      GPS strings in a KISS packet but give it a different port ID (like
      MKISS), but then put in a CRLF just before the GPS string(s) so that
      software which is looking for $GPGGA/$GPRMC at the beginning of a
      string can find it. It'd be kind of like running an HSP port but
      without the string corruption you get with HSP.

      > What software currently supports the
      > Control-E thing?

      PocketAPRS, Xastir, SmartPalm I think, others. It's usually called
      PicoPacket mode, after the Paccomm dual-port PicoPacket (which I
      have one of somewhere) which first implemented it. Hmmm. Forgot I
      even had that TNC... Might have to hook it to my HamHUD for a bit
      to play, if I can still find it.

      > How exactly is it supposed to behave?

      The computer sends a Control-E out the TNC port whenever it wants
      the TNC to send it the GPS string(s). Otherwise the computer is
      receiving packet strings from the TNC.

      --
      Curt, WE7U. APRS Client Comparisons: http://www.eskimo. com/~archer
      "Lotto: A tax on people who are bad at math." -- unknown
      "Windows: Microsoft's tax on computer illiterates. " -- WE7U
      "The world DOES revolve around me: I picked the coordinate system!"

    • Wes Johnston, AI4PX
      My vote would be to format the packets to appear within a kiss frame with another kiss identifier... like having a dual port TNC.... just use port 15. That
      Message 2 of 12 , Oct 4, 2006
      • 0 Attachment
        My vote would be to format the packets to appear within a kiss frame with another kiss identifier... like having a dual port TNC.... just use port 15.  That way it maintains compatibility with the ax.25 kernel.
         
        Wes

         
        On 9/29/06, Curt, WE7U <archer@...> wrote:


        Is there a method to dump GPRMC/GPGGA sentences to the computer when
        using both Tracker2 serial ports?

        Any of these perhaps:

        *) Send the NMEA strings when the computer requests them via
        Control-E (Picopacket mode).

        *) Send the NMEA strings as normal ASCII text in between the KISS
        data packets.

        *) Send the NMEA strings inside KISS packets but with a different
        KISS interface ID (MKISS protocol).

        ??

        One could always wire the GPS-out line in parallel to the Tracker2
        and another serial port on the computer, but it'd be nicer if one
        could get the data directly from the Tracker2 over the same serial
        port as being used for KISS communication.

        --
        Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer
        "Lotto: A tax on people who are bad at math." -- unknown
        "Windows: Microsoft's tax on computer illiterates." -- WE7U
        "The world DOES revolve around me: I picked the coordinate system!"


      • Wes Johnston, AI4PX
        After reading the responses... I don t see how the tracker 2 would keep up with seeing a cntrl-e on the serial port... what if controlE came in the middle of
        Message 3 of 12 , Oct 4, 2006
        • 0 Attachment
          After reading the responses...
           
          I don't see how the tracker 2 would keep up with seeing a cntrl-e on the serial port... what if controlE came in the middle of sending a kiss frame to the tracker?  The tracker would presumably have to keep up with the bounds of a kiss frame and look for cntrl e when it was not bounded by $C0.  But let's not forget that anything in the KISS buffer is sent upon receipt of a $C0.... as a courtesy, most devices send a C0 in the beginning and at the end, but only at the end is required.
           
          Let's say I have kiss frames coming in like this:
          C0 <insert your data here> C0
          C0 <insert your data here> C0
           
          But if we simply insert NMEA sentances between the above kiss frames, like this:
          C0 <insert your data here> C0
          <crlf>$GPGGA<crlf>
          C0 <insert your data here> C0
           
          what gets received is:
          Frame 1:<insert your data here>
          Frame 2:<crlf>$GPGGA<crlf>  ****invalid ax.25 frame
          Frame 3:<insert your data here>
           
          The reason is that the first c0 in the second frame purges the buffer by transmitting it.  How would ax.25 handle the invalid "GPGGA" frames?  I don't think it would crash, but you'd have to use kiss serial instead of ax.25 kernel if you wanted to see any of the data, right?
           
          For the MKISS method, I'd say create a valid ax.25 frame (header and data portion) with a faked out source callsign.... and port #15 (0F)
          C0 0F<insert following ax25 frame:GPS>GPS:$GPGGA...........<cr><lf> <end of rame>C0
           
          The above would be easily decoded by aprs software, but wait there's more.... what if the faked out ax.25 packet looked like this instead:
          C0 0F<insert following ax25 frame:GPS>GPS:<cr><lf>$GPGGA...........<cr><lf> <end of frame>C0
           
          Now the stream of KISS data going by would contain a crlf, some clean bounded NMEA data, and a crlf.  Should be decodable by anyold device sitting on the serial line listening... and doesn't break any rules to do with kiss frames.  And it would probably be decoded by APRS software too.
           
          Hope all these ramblings make sense... it's difficult to express the mix match of hex, kiss and ax.25 headers.
           
          Wes
           


           
          On 10/4/06, Wes Johnston, AI4PX <wes@...> wrote:
          My vote would be to format the packets to appear within a kiss frame with another kiss identifier... like having a dual port TNC.... just use port 15.  That way it maintains compatibility with the ax.25 kernel.
           
          Wes

           
          On 9/29/06, Curt, WE7U <archer@...> wrote:


          Is there a method to dump GPRMC/GPGGA sentences to the computer when
          using both Tracker2 serial ports?

          Any of these perhaps:

          *) Send the NMEA strings when the computer requests them via
          Control-E (Picopacket mode).

          *) Send the NMEA strings as normal ASCII text in between the KISS
          data packets.

          *) Send the NMEA strings inside KISS packets but with a different
          KISS interface ID (MKISS protocol).

          ??

          One could always wire the GPS-out line in parallel to the Tracker2
          and another serial port on the computer, but it'd be nicer if one
          could get the data directly from the Tracker2 over the same serial
          port as being used for KISS communication.

          --
          Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer
          "Lotto: A tax on people who are bad at math." -- unknown
          "Windows: Microsoft's tax on computer illiterates." -- WE7U
          "The world DOES revolve around me: I picked the coordinate system!"



        • scott@opentrac.org
          Rather than assigning it another port number, I think it d make more sense to use a different command number. Only type 0 frames should be interpreted as data
          Message 4 of 12 , Oct 5, 2006
          • 0 Attachment
            Rather than assigning it another port number, I think it'd make more sense to use a different command number.  Only type 0 frames should be interpreted as data frames.  If you make it type 0x0d, for example, it *should* be ignored by any properly-written KISS implementation.
             
            The problem of actually coming up with the NMEA strings still remains, though.
             
            Scott


            From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of Wes Johnston, AI4PX
            Sent: Wednesday, October 04, 2006 7:06 PM
            To: tracker2@yahoogroups.com
            Subject: Re: [tracker2] GPS data to computer as well?

            After reading the responses...
             
            I don't see how the tracker 2 would keep up with seeing a cntrl-e on the serial port... what if controlE came in the middle of sending a kiss frame to the tracker?  The tracker would presumably have to keep up with the bounds of a kiss frame and look for cntrl e when it was not bounded by $C0.  But let's not forget that anything in the KISS buffer is sent upon receipt of a $C0.... as a courtesy, most devices send a C0 in the beginning and at the end, but only at the end is required.
             
            Let's say I have kiss frames coming in like this:
            C0 <insert your data here> C0
            C0 <insert your data here> C0
             
            But if we simply insert NMEA sentances between the above kiss frames, like this:
            C0 <insert your data here> C0
            <crlf>$GPGGA<crlf>
            C0 <insert your data here> C0
             
            what gets received is:
            Frame 1:<insert your data here>
            Frame 2:<crlf>$GPGGA<crlf>  ****invalid ax.25 frame
            Frame 3:<insert your data here>
             
            The reason is that the first c0 in the second frame purges the buffer by transmitting it.  How would ax.25 handle the invalid "GPGGA" frames?  I don't think it would crash, but you'd have to use kiss serial instead of ax.25 kernel if you wanted to see any of the data, right?
             
            For the MKISS method, I'd say create a valid ax.25 frame (header and data portion) with a faked out source callsign.... and port #15 (0F)
            C0 0F<insert following ax25 frame:GPS>GPS:$GPGGA.. .........<cr><lf> <end of rame>C0
             
            The above would be easily decoded by aprs software, but wait there's more.... what if the faked out ax.25 packet looked like this instead:
            C0 0F<insert following ax25 frame:GPS>GPS:<cr><lf>$GPGGA...... .....<cr><lf> <end of frame>C0
             
            Now the stream of KISS data going by would contain a crlf, some clean bounded NMEA data, and a crlf.  Should be decodable by anyold device sitting on the serial line listening... and doesn't break any rules to do with kiss frames.  And it would probably be decoded by APRS software too.
             
            Hope all these ramblings make sense... it's difficult to express the mix match of hex, kiss and ax.25 headers.
             
            Wes
             


             
            On 10/4/06, Wes Johnston, AI4PX <wes@...> wrote:
            My vote would be to format the packets to appear within a kiss frame with another kiss identifier.. . like having a dual port TNC.... just use port 15.  That way it maintains compatibility with the ax.25 kernel.
             
            Wes

             
            On 9/29/06, Curt, WE7U <archer@eskimo. com> wrote:


            Is there a method to dump GPRMC/GPGGA sentences to the computer when
            using both Tracker2 serial ports?

            Any of these perhaps:

            *) Send the NMEA strings when the computer requests them via
            Control-E (Picopacket mode).

            *) Send the NMEA strings as normal ASCII text in between the KISS
            data packets.

            *) Send the NMEA strings inside KISS packets but with a different
            KISS interface ID (MKISS protocol).

            ??

            One could always wire the GPS-out line in parallel to the Tracker2
            and another serial port on the computer, but it'd be nicer if one
            could get the data directly from the Tracker2 over the same serial
            port as being used for KISS communication.

            --
            Curt, WE7U. APRS Client Comparisons: http://www.eskimo. com/~archer
            "Lotto: A tax on people who are bad at math." -- unknown
            "Windows: Microsoft's tax on computer illiterates." -- WE7U
            "The world DOES revolve around me: I picked the coordinate system!"



          • J. Lance Cotton
            ... haha. Yeah, right! -- J. Lance Cotton, KJ5O joe@lightningflash.net http://kj5o.lightningflash.net Three Step Plan: 1. Take over the world. 2. Get a lot of
            Message 5 of 12 , Oct 5, 2006
            • 0 Attachment
              scott@... wrote:
              > Only type 0 frames should be
              > interpreted as data frames. If you make it type 0x0d, for example, it
              > *should* be ignored by any properly-written KISS implementation.

              Forgive me, but:

              > *should* be ignored by any properly-written KISS implementation.

              haha. Yeah, right!

              --
              J. Lance Cotton, KJ5O
              joe@...
              http://kj5o.lightningflash.net
              Three Step Plan: 1. Take over the world. 2. Get a lot of cookies. 3. Eat the
              cookies.
            • Curt, WE7U
              ... FRAM? Simulate NMEA from the data you do have? -- Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer Lotto: A tax on people who are
              Message 6 of 12 , Oct 5, 2006
              • 0 Attachment
                On Thu, 5 Oct 2006 scott@... wrote:

                > Rather than assigning it another port number, I think it'd make more sense
                > to use a different command number. Only type 0 frames should be interpreted
                > as data frames. If you make it type 0x0d, for example, it *should* be
                > ignored by any properly-written KISS implementation.
                >
                > The problem of actually coming up with the NMEA strings still remains,
                > though.

                FRAM?

                Simulate NMEA from the data you do have?

                --
                Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer
                "Lotto: A tax on people who are bad at math." -- unknown
                "Windows: Microsoft's tax on computer illiterates." -- WE7U
                "The world DOES revolve around me: I picked the coordinate system!"
              • scott@opentrac.org
                I d probably go with simulating, since the data might be from Garmin mode. _____ From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of
                Message 7 of 12 , Oct 5, 2006
                • 0 Attachment
                  I'd probably go with simulating, since the data might be from Garmin mode.


                  From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of Curt, WE7U
                  Sent: Thursday, October 05, 2006 9:54 AM
                  To: tracker2@yahoogroups.com
                  Subject: RE: [tracker2] GPS data to computer as well?

                  On Thu, 5 Oct 2006 scott@opentrac. org wrote:

                  > Rather than assigning it another port number, I think it'd make more sense
                  > to use a different command number. Only type 0 frames should be interpreted
                  > as data frames. If you make it type 0x0d, for example, it *should* be
                  > ignored by any properly-written KISS implementation.
                  >
                  > The problem of actually coming up with the NMEA strings still remains,
                  > though.

                  FRAM?

                  Simulate NMEA from the data you do have?

                  --
                  Curt, WE7U. APRS Client Comparisons: http://www.eskimo. com/~archer
                  "Lotto: A tax on people who are bad at math." -- unknown
                  "Windows: Microsoft's tax on computer illiterates. " -- WE7U
                  "The world DOES revolve around me: I picked the coordinate system!"

                • Jason Winningham
                  ... stream data from the GPS directly out the port (bypassing the microcontroller), and use a mux to interrupt it to inject the KISS/ APRS data? yeah, more
                  Message 8 of 12 , Oct 5, 2006
                  • 0 Attachment
                    On Oct 5, 2006, at 11:53 AM, Curt, WE7U wrote:


                    > FRAM?
                    >
                    > Simulate NMEA from the data you do have?

                    stream data from the GPS directly out the port (bypassing the
                    microcontroller), and use a mux to interrupt it to inject the KISS/
                    APRS data?

                    yeah, more hardware.

                    -Jason
                    kg4wsv
                  • scott@opentrac.org
                    One can only hope! Of course, you d think that APRS applications would ignore non-text PIDs too, but oh well. Oh, another argument for the synthesized NMEA
                    Message 9 of 12 , Oct 5, 2006
                    • 0 Attachment
                      One can only hope!  Of course, you'd think that APRS applications would ignore non-text PIDs too, but oh well.
                       
                      Oh, another argument for the synthesized NMEA approach is that you could generate it from ANOTHER station's data, and use a mapping program to track that station.
                       
                      Scott


                      From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of J. Lance Cotton
                      Sent: Thursday, October 05, 2006 9:49 AM
                      To: tracker2@yahoogroups.com
                      Subject: Re: [tracker2] GPS data to computer as well?

                      scott@opentrac. org wrote:
                      > Only type 0 frames should be
                      > interpreted as data frames. If you make it type 0x0d, for example, it
                      > *should* be ignored by any properly-written KISS implementation.

                      Forgive me, but:

                      > *should* be ignored by any properly-written KISS implementation.

                      haha. Yeah, right!

                      --
                      J. Lance Cotton, KJ5O
                      joe@lightningflash. net
                      http://kj5o. lightningflash. net
                      Three Step Plan: 1. Take over the world. 2. Get a lot of cookies. 3. Eat the
                      cookies.

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