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

1085Re: [tracker2] GPS data to computer as well?

Expand Messages
  • Wes Johnston, AI4PX
    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
      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.

      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.

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

    • Show all 12 messages in this topic