bugGPSD - Bugs: bug #38077, TSIP parser doesn't handle packet...

 
 

bug #38077: TSIP parser doesn't handle packet id 0x38

Submitted by:  None
Submitted on:  Mon 14 Jan 2013 07:30:02 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 29 Jan 2013 12:34:10 AM UTC, comment #4:

Building from the repo head gives me this in the log (at -D5, maybe lower levels, didn't check):

gpsd:IO: TSIP REJECT pkt_id = 0x38, packetlen= 7

... but does not restart trying to find the GPS, So as long as the log message is what you desired, it doesn't appear to be breaking my gps anymore, which is what I desired, so that works.

Thanks!

Anonymous
Tue 22 Jan 2013 10:27:09 AM UTC, comment #3:

Try the repo tip version, please. The key line is

else if ((0x38 == pkt_id) && (0x03 == packetlen))
/* pass */ ;

near line 1676; I think that 0x03 is right but it's possible 0x02 (not counting the operation type byte) might be needed.

Eric S. Raymond <esr>
Project Administrator
Mon 21 Jan 2013 04:13:15 AM UTC, comment #2:

Sorry about the delay -- needed some time to do some checking to make sure I got the right answer (since the docs are.. vague).

It's 7 bytes total, if you count the TSIP framing and everything... 3 actual data bytes (in order: operation, type of data, PRN)

Anonymous
Mon 14 Jan 2013 11:52:00 AM UTC, comment #1:

I can teach the packet parser to ignore these. What's the length of the 0x38 packet?

Eric S. Raymond <esr>
Project Administrator
Mon 14 Jan 2013 07:30:02 AM UTC, original submission:

While working with a shiny new raspberry pi trying to make NTP work and be happy, I've had an issue where gpsd would periodically stop reporting back data from my GPS chip.

Turning on debugging shows that it is periodically going into baud rate search for no apparent reason. It eventually either re-acquires the GPS, or gives up (because for some reason it likes to hunt at 7N2 sometimes, instead of 8N1 or 8O1, not sure if that's a bug, resets, and reacquires.

Turning on deeper debugging, it turns out the following line always appears immediately before gpsd starts the baud rate search:

17:40:32 E: gpsd:IO: Packet ID 0x38 out of range for TSIP

According to the documentation, this is a "request SV system data" packet, which seems like it would be for loading AGPS data -- so I have no clue why it keeps popping up in the datastream. But regardless, it does appear to be a valid output packet and seems to be breaking things when received. It should be possible to just ignore this packet (the documentation does note that it's never a requirement to actually send AGPS to the chip).

Version numbers and such:
- gpsd 3.6, as shipped with the current raspian linux distribution, which is debian-wheezy based. (I confirmed in git that support for the 0x38 TSIP message isn't in the latest code, too)
- Chip: Trimble ICM-SMT timekeeping chip
- Chip firmware: 1.10.2
- Chip docs: http://trl.trimble.com/docushare/dsweb/Get/Document-577771/ICM_SMT_UG2B_76858-00-ENG.pdf (see pages 46, 96, 100, 110)

I can provide any further info / logs / testing needed, just say what!

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by esr (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 15 May 2013 02:25:12 PM UTCesrOpen/ClosedOpen=>Closed
    Tue 23 Apr 2013 11:48:12 PM UTCesrStatusReady For Test=>Fixed
    Tue 22 Jan 2013 10:27:09 AM UTCesrStatusFixed=>Ready For Test
    Tue 15 Jan 2013 10:29:03 AM UTCesrStatusNone=>Fixed

    Back to the top


    Powered by Savane 3.1-cleanup1