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

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

Expand Messages
  • scott@opentrac.org
    Not yet. I d be wary of throwing them in between KISS frames - too much potential for interference there. What software currently supports the Control-E
    Message 1 of 12 , Oct 1, 2006
    View Source
    • 0 Attachment
      Not yet.  I'd be wary of throwing them in between KISS frames - too much potential for interference there.  What software currently supports the Control-E thing?  How exactly is it supposed to behave?
       
      Scott


      From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of Curt, WE7U
      Sent: Friday, September 29, 2006 10:22 AM
      To: tracker2@yahoogroups.com
      Subject: [tracker2] GPS data to computer as well?


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

    • 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 2 of 12 , Oct 3, 2006
      View Source
      • 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 3 of 12 , Oct 4, 2006
        View Source
        • 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 4 of 12 , Oct 4, 2006
          View Source
          • 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 5 of 12 , Oct 4, 2006
            View Source
            • 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 6 of 12 , Oct 5, 2006
              View Source
              • 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 7 of 12 , Oct 5, 2006
                View Source
                • 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 8 of 12 , Oct 5, 2006
                  View Source
                  • 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 9 of 12 , Oct 5, 2006
                    View Source
                    • 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 10 of 12 , Oct 5, 2006
                      View Source
                      • 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 11 of 12 , Oct 5, 2006
                        View Source
                        • 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.