Re: [gpsd-dev] Initialization & probing questions

[Kai Harrekilde-Petersen]

Hi Gary.

On 30-03-2018 04:46, Gary E. Miller wrote:

On Thu, 29 Mar 2018 19:26:08 +0200
Kai Harrekilde-Petersen <address@hidden> wrote:

The next problem I am facing is that test/daemon/skytraq-bin.log
fails, because the test sends out 56 (pseudo)NMEA sentences that
shouldn't be there. Some of them ($GPALM) are sent by pseudonmea.c -
a file I haven't touched at all, which is a bit confusing.

Well, all the regressions pass for me right now on git head, so if
you have a failing regression test you either broke something, or
improved something.

Yup, that's why we all love regression tests.

Interestingly, it was the gpsd.h change of SKY_PACKET from 20 to 16 that made it fail. I don't quite understand why, though.

I looked into skytraq-bin.log and it contains Raw Measurement Data 
Extention sentences (AN0030) /only/.

Yup, ALl the logs are jsut binary captures of what a GPS ouput at
one time.  Usually captured with: gpspipe -w > tmp.log

Ah, cool. Testcase & check-file attached.

It seems like that gpsd needs to see a \xA0\xA1 sequence from the
module before it wants to switch. Sending a "gpsctl -b -t
Skytraq /dev/ttyS0" don't get a message through to the driver
selection code at all (or so it seems). What does work is killing
gpsd and using echo to send a hand-crafted message (echo -n -e 
'\xA0\xA1\x00\x03\x09\x02\x00\x0B\x0D\x0A' > /dev/ttyS0) to the
module go into binary mode and /then/ start gpsd.

Could be.  How about when gpsd is already running?  Different code
paths.

Oh, I wasn't aware of that. I have only been trying it when gpsd is running as I thought it only worked when gpsd is running.

I just tried it without gpsd (gpsctl -b -t Skytraq /dev/ttyS0). Interestingly, it starts out with an ERROR, complaining that gpsd isn't running and then proceeds to change the mode.
Changing cycletime alone appears not to work; I need to set the mode (binary or nmea) at the same time to make gpsctl change the cycletime as well. I didn't try changing the baudrate.
When gpsd is running (and it has detected Skytraq) just using -c alone works.

Coming along, big mistake here:

+#define MAX_GPSPACKET_TYPE	16	/* increment this as necessary */

Think about the comment!

I did, and that's why I asked a couple of days back. I read the comments and looked at macros just below (TEXTUAL_PACKET_TYPE, GPS_PACKET_TYPE, GPS_TYPEMASK) as the text/ASCII-based formats come first (1...MAX_TEXTUAL_TYPE), then the binary formats (4...MAX_GPSPACKET_TYPE) and finally non-GPS types (17...PACKET_TYPES).

Like I wrote, this is why the skytraq-bin.log test was failing.

I will undo the change no problems, I'd just like to understand what I missed.

Did you test this in gpsctl, both with and without gpsd?

I'm testing with gpsd and using gpsctl (with gpsd running) to change modes. At one point I was using a logic analyzer to measure the delay between the 1PPS output and the first $GPRMC message on the UART, when varying the baudrate, and I found that using a simple script was much simpler than talking gpsd into doing it.

Regards,

Kai

0001-Add-testcase-with-Navigation-Data-Message-0xA8-that-.patch
Description: Text document