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

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

Expand Messages
  • Curt, WE7U
    ... 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
    Message 1 of 12 , Oct 3, 2006
    • 0 Attachment
      On Sun, 1 Oct 2006 scott@... 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!"
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.