Re: [gpsd-users] Ublox EVK-M8T

[Denny Page]

> On Sep 19, 2017, at 14:18, Gary E. Miller <address@hidden> wrote:
> 
> Yo Denny!
> 
> On Mon, 18 Sep 2017 18:28:38 -0700
> Denny Page <address@hidden> wrote:
> 
>> I can confirm that gpsd doesn’t work with the EVK-M8T. I’ve
>> encountered several issues...
> 
> We have other people reporting success.

I’ve seen reports of success with the M8, but not with the M8T (timing chip). I 
have seen reports of failure by others previously in this list which is why I 
asked the question a couple of weeks back.


>> The first issue is that the gpsd auto-baud detection doesn’t appear
>> to work well with the unit. At 115200, gpsd will settle on 4800 if
>> the unit is in binary mode. It’s unclear why. This means that gpsd
>> without the -b option will work once, but fail the second time. For
>> the time being, I’ve locked the unit at 9600.
> 
> Have you tried setting the port speed before starting gpsd?  That
> simple workaround usually suffices.

Yes.


>> The second issue is that a standard serial cable does not work. The
>> EVK has the time pulse tied to both pin 1(DCD) and to pin 7 (RTS). I
>> don’t know why they’ve also tied it to RTS, but it wreaks havoc on
>> the kernel’s PPS detector, with ppstest reporting more than a
>> thousand events per second. A custom cable fixes this. I am currently
>> using a cable with just pin 1(DCD), pin 2 (TXD), pin 3 (RXD), and pin
>> 5 (GND).
> 
> Are you sure you do not have a voltage level problem instead?  Many
> ublox output at 3.5V and most serial inputs can not handle that.

Yes, I’m quite sure. The EVK is pretty well documented. It offers 3.3V on a 
standard test connector and +/- 12V RS-232 on a DB9. Further, I have also 
tested pin 7 (RTS) on the EVK's DB9 to pin 1 (DCD) on the host. It works the 
same as if pin 1 on the EVK’s DB9 is used. The problem occurs is if you connect 
either PPS signal to pin 7 (RTS) on the host. 

With the cable described above, things work as expected. Both ppstest and 
gpsmon (sans gpsd) indicate good PPS.


>> The third problem is where things get interesting. While gpsmon run
>> against the tty device happily reports a functioning PPS with both
>> the NMEA or UBX protocols, gpsd itself does not. Gpsd is rejecting
>> the PPS signal:
> 
> Uh, no.  lease reread the output.  gpsd is accepting the leading edge, and
> rejeecting the trailing edge.  Just as it should.
> 
>> Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: KPPS:/dev/ttyS2 assert> 
>> 1505777810.100060219, sequence: 8, clear   1505777810.000026753, sequence: 8 
>> - using: assert
> 
> Accepted edge.
> 
>> Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: PPS:/dev/ttyS2 Assert rejected 
>> 1Hz trailing edge
> 
> Rejected trailing edge.
> 
> A pulse has two edges.  PPS uses the eading one, and ignores the
> trailing edge.

Okay, my bad. I misinterpreted what the “reject” meant.

So, any speculation you can offer as to what the problem is?

Thanks,
Denny