gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] Ublox EVK-M8T


From: John Klug
Subject: Re: [gpsd-users] Ublox EVK-M8T
Date: Tue, 19 Sep 2017 14:41:02 +0000

We use the U-Blox 8M (no T), and I accidentally came up with the following 
procedure, which always works.  (I noticed that the baud rate was being set 
correctly, then set back to the original baud rate before I used the "-T" on 
the 2nd gpsctl:

gpsctl -t 'u-blox' -s $GPS_BAUD -b  -f $GPS_LINE
# The next line is needed due to a bug in gpsctl.
# We will go back to the default baud rate if we don't do this step.
echo Expect a timeout error here.  Need this error.
gpsctl -T 2 -f $GPS_LINE

We set:

GPS_BAUD=115200

The GPS is using the serial port, and we have an EXAR USB/Serial chip connected 
to it.


From: gpsd-users address@hidden on behalf of Eric S. Raymond address@hidden
Sent: Monday, September 18, 2017 11:10 PM
To: Denny Page
Cc: address@hidden
Subject: Re: [gpsd-users] Ublox EVK-M8T

Denny Page <address@hidden>:
> 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.

That is pretty strange.  What type does it think it recognizes?  Because it
shouldn't lock to uBlox packets unless it sees the correct packet header, then
finds a correct checksum for the implied payload.  How that match could happen
at the wrong baud is pretty mysterious.

> 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).

Yeah, we deal with any *one* handshake line presenting 1PPS.

> 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:

Interpreting that is Gary's pigeon.
--
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: 
http://mail2.multitech.com:32224/?dmVyPTEuMDAxJiYzZWNkZDU0MmRjY2MwMjdmOD01OUMwOThERF83NDcxMV8xMjQ1Ml8xJiYyYjU2NTZkNzg1MGI1M2M9MTMzMyYmdXJsPWh0dHBzJTNBJTJGJTJGaWNlaSUyRW9yZw==
Please visit their site and donate: the civilization you save might be your own.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]