Garmin GPS 18x LVC to Pi

[chrisprt]

I have interest in interfacing a Garmin GPS 18x LVC to the Raspberry Pi. In particular, I plan to read NMEA GPS data over the serial interface into the Pi's UART.

I also plan to use this for time synchronization. The GPS 18x LVC issues a 1hz pulse for 20-200ms every second at the rising edge of the second which can be used to sync the time accurately. I believe I've tackled all the software issues (http://www.raspberrypi.org/phpBB3/viewt ... =41&t=1970), but I'm uncomfortable with the hardware side.

The main issue is that both the synchronization pulse as well as the output serial voltage levels are 5V. I believe I need a voltage regulator (MAX232 variant?). I've read quite a few posts about serial input into the Pi, but they all were based on connecting to a 12v RS232 device, not a TTL 5V device like the GPS. Do I just need a basic voltage regulator (such as LM3940) for the pulse? Do I need something similar to the MAX3232?

[Gert van Loo]

If the signal is genuine 5V all you need is two resistors which divide to 5V volt down to 3V3
and that only for the signal going into the Pi.
So you need a ration of 3.3/5 = 0.66. Try 1.2K and 2.2K (Or written in PF**: 1K2 and 2K2)



**PF: Professional format

[chrisprt]

Gert: Thanks for the help so far, I'm happy to report that the Pi is sensing the pulse correctly.

With that said, I'm still having problems with the serial communications over the UART. I've wired up a similar voltage divider circuit for the tx wire of the GPS to GPIO 15 (RXD) of the Pi. I checked the voltage using a multimeter before I made the connection, and everything still seems to be at or below 3.5v. Unfortunately, when I tried to read off of the UART, all I receive is garbage:

Code: Select all

[email protected]:~$ cu --nostop -l /dev/ttyAMA0 -s 9600
Connected.
æffxææxxxxxææxx~æxxàæx~æþxàæxøæx~àæxfþxxx`þxþxþxx`þxxxx`~~æþxxf`üÃ~æffxfþæffxææxæx

I'm almost certain it's actually sensing the GPS data though, because the rate and amount of output is the same as I'd expect from the NMEA sentences that normally would be coming off the GPS. I've tried using minicom and cu, with a ton of different bauds/settings, but after checking my freebsd install I'm confident that the settings I used in the above example are the actual expected settings from the GPS.

I've disabled getty in /etc/inittab and removed the console options in the /boot/cmdline.txt file, so in theory the UART should be open for use now. Can you think of anything else that could be causing this problem?

Thanks

[goodney]

This is/was my idea for my first RPi project as well since I've got several GPS-PPS ntp servers up and running over the last year. Seemed like a cool idea to have a <$100 NTP Stratum 1 server

Good luck and please keep this thread updated with your project. Sorry I don't have any experience with the serial port problem, but you could try a few things:

Make sure the settings as seen with stty -F make sense.

Hook up RX to TX on the RPi so you are in loopback, turn off local echo and make sure you can echo characters to/from the RPi

Hook up the 18xLVC to a PC and make sure the settings are correct. You can download a little program from Garmin that gives you all kinds of control over the 18xLVC.

Try using a bi-directional 3.3-5V convertor.

-a[g

[chrisprt]

This is/was my idea for my first RPi project as well since I've got several GPS-PPS ntp servers up and running over the last year. Seemed like a cool idea to have a <$100 NTP Stratum 1 server

Totally in agreement. That's why I'm spending so much time on it =]

Good luck and please keep this thread updated with your project. Sorry I don't have any experience with the serial port problem, but you could try a few things:

Make sure the settings as seen with stty -F make sense.

Yeah. I finally broke down today and connected a breadboard up to my windows machine so I could use the Garmin tool. I've reset everything to settings that I know, and also connected my FreeBSD VM to probe it. It's working fine:

Code: Select all

cu -l /dev/cuau0 -s 115200
$GPRMC, 001055, A, X, N, X, W, 000.0, 000.0, 210712, 006.0, W*7B
$GPRMC, 001056 A, X, N, X, W, 000.0, 000.0, 210712, 006.0, W*78
$GPRMC, 001057 A, X, N, X, W, 000.0, 000.0, 210712, 006.0, W*79

Unfortunately, here's the output in the pi

Code: Select all

[email protected]:~$ cu --nostop -l /dev/ttyAMA0 -s 115200
Connected.

And nothing after that.

I'm beginning to wonder if the not-so-perfect resistors that I setup are the cause. The reason for my wonder, is that routinely when using a multimeter the voltage seem pretty erratic with the pulse. Anywhere from 3.5v - 0.8v.

I tried setting up the NTPD ATOM driver, just to use the pulse for now, since I was able to capture it in the pi. Initially it didn't work - the driver was marked as a false ticker. After some research w/ PPS Debugging enabled, I had to agree. It was missing 1 in every 10 seconds or so. Definitely not ticking accurately. I recompiled the kernel making sure that it also captured the CLEAR part of the pps as well. So far, with that, it's ticking okay:

Code: Select all

      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 PPS(0)          .PPS.            0 l    7   16  377    0.000    9.650   0.896 
 resnet1.resnet. .GPS.            1 u    2   64  301   43.322    0.926   2.994
 tick.usno.navy. .IRIG.           1 u   57   64  177   72.987   22.011   3.196
*ntp-s1.cise.ufl .GPS.            1 u   62   64  177   61.463   -7.454   2.503
 navobs1.gatech. .GPS.            1 u   55   64  177   66.834   12.106  11.275

Note: don't take that jitter as long term. It's only been on 10 minutes.

Hook up RX to TX on the RPi so you are in loopback, turn off local echo and make sure you can echo characters to/from the RPi

This is a good idea. I'll try this later.

Hook up the 18xLVC to a PC and make sure the settings are correct. You can download a little program from Garmin that gives you all kinds of control over the 18xLVC.

Yep, just broke this out today and reconfigured it.

Try using a bi-directional 3.3-5V convertor.

Yeah, I'm thinking about using a more precise voltage regulator. Either my multimeter is slow at sensing the voltage (since the pulse is only 100ms), or something in my circuit isn't appropriate. At the moment I'm using 1000o and 2000o resistors in the voltage divider setup that Gert described above. I wish I knew more about electrical engineering, but I'm usually a software guy.

[chrisprt]

Make sure the settings as seen with stty -F make sense.

So, in the last post I said that when I listened on the serial port, nothing was displayed. This was due to a wiring error. Now I'm back to where I am before, which is:

Code: Select all

[email protected]:~$ cu -l /dev/ttyAMA0 -s 115200
Connected.
[×µUå§}§fÖ¶6ËËÙZYö6v£§ö6û;ÛëûëÛvûû­åë[×µUå§}§fÖ¶6ËËÙZYö6v£§ö6û;ÛëûëÛvûû­å§}§fÖ¶6ËËÙZYö6v£§ö6û;ÛëûëÛvûû­yåë[×µUå§}§fÖ¶6ËËÙZYö6v£§ö6û;ÛëûëÛ{ûû­ë[×µUåÙZYö6v£§ö6û;Û

The data is coming in at the same interval that is normal with the GPS, so I believe it's wired correctly, but either the signal is corrupted or my settings are wrong. Here's my settings:

Code: Select all

[email protected]:~$ stty -a -F /dev/ttyAMA0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

I've tried cu and minicom with no success.

Hook up RX to TX on the RPi so you are in loopback, turn off local echo and make sure you can echo characters to/from the RPi

I did this today, and I think it worked:

Code: Select all

Terminal 1:
[email protected]:~$ cat < /dev/ttyAMA0
test
raspberry pi serial test
raspberry pi serial test plugged back in

Terminal 2:
[email protected]:~$ echo "test" > /dev/ttyAMA0
[email protected]:~$ echo "raspberry pi serial test" > /dev/ttyAMA0
[email protected]:~$ echo "raspberry pi serial test unplugged" > /dev/ttyAMA0
[email protected]:~$ echo "raspberry pi serial test tx unplugged 2" > /dev/ttyAMA0
[email protected]:~$ echo "raspberry pi serial test plugged back in" > /dev/ttyAMA0

Lastly, adding clear asserts into the kernel seemed to help ticker stability a little bit, but eventually, the pulse was marked as a false ticker On manual inspection, it missed a second every once and a while. I tried again this morning, and it almost immediately went false ticker.

[goodney]

Ok... great work. Let's try a few things:

re: Serial

Maybe the RPi can't handle 115200 for some reason. I know loop-back worked, but that could be a special case. Try hooking the RPi up to a PC and try different baud rates and/or try setting the 18xLVC to 9600 or even 1200 baud.

Try using a USB to serial adapter. I know this adds latency, but NTP should be able to compensate as all it really needs from the serial is the approximate time.

re: Dropped clear/asserts

Try using the configuration program to set the PPS pulse width to 200ms or even 400ms. If the pulse is too short, the kernel can miss it.

Which kernel are you using? It seems like you had to modify the kernel to get GPIO interrupts working. Chris' kernel from http://www.bootc.net/ should have the GPIO interrupt patches included, perhaps his kernel will work better.

Can you make a 1hz square wave oscillator, or get a bench-top oscillator? You can make a nice clean 40% duty cycle 3.3V square wave to feed into the GPIO. If this works without dropping any pulses, then the problem lies in getting the PPS signal into the RPi. If this still drops ticks, then we probably have a kernel/PPS driver issue.

Good luck!

-a[g

[chrisprt]

Ok... great work. Let's try a few things:

re: Serial

Maybe the RPi can't handle 115200 for some reason. I know loop-back worked, but that could be a special case. Try hooking the RPi up to a PC and try different baud rates and/or try setting the 18xLVC to 9600 or even 1200 baud.

My normal run is to FreeBSD, which I'm now using to set the time during the day. It's trained to 4800 bps, which is what the GPS is currently set to. It still comes in corrupted to the Pi.

Try using a USB to serial adapter. I know this adds latency, but NTP should be able to compensate as all it really needs from the serial is the approximate time.

This is true, and it's a good idea. With that said, I don't have one of these readily available. Maybe I'll try to order something cheap off of amazon.

re: Dropped clear/asserts

Try using the configuration program to set the PPS pulse width to 200ms or even 400ms. If the pulse is too short, the kernel can miss it.

It's configured to pulse at 200ms.
I also ran it for over an hour, and then wrote a program to parse the dmesg output (I have kernel PPS debugging on). It didn't miss a single second, but it still was reported as a false ticker. This was confusing - maybe it's pulsing erratically? See the last paragraph below for more on this.

Which kernel are you using? It seems like you had to modify the kernel to get GPIO interrupts working. Chris' kernel from http://www.bootc.net/ should have the GPIO interrupt patches included, perhaps his kernel will work better.

I am using a modified kernel. It's the base raspberry pi kernel with GPIO and PPS GPIO support, which Chris' kernel doesn't appear to have. Do you know if his kernel has anything needed other than the GPIO stuff turned on in the kernel's menuconfig? Maybe I should make a github or something so that others can take a look at my minor patches.

Can you make a 1hz square wave oscillator, or get a bench-top oscillator? You can make a nice clean 40% duty cycle 3.3V square wave to feed into the GPIO. If this works without dropping any pulses, then the problem lies in getting the PPS signal into the RPi. If this still drops ticks, then we probably have a kernel/PPS driver issue.

I must admit that while I understand what you're asking for, I have absolutely no idea how I'd make it.

Over the last week I received a few goodies from adafruit and updated my setup, which unfortunately is still not working as desired.

I'm using the 8-channel Bi-directional logic level shifter(https://www.adafruit.com/products/395) from adafruit to try to deal with the voltage stepping. I'm not really sure if I should be using output enable or not, or if I'm wiring the ground up. I'm feeding two power sources into it, 1 from USB, and 1 from the Pi, and connecting both to the ground. Maybe I'll take a picture to show what the circuit looks like.

I also noticed something confusing last night:
I use a cobbler kit for the Pi now, so that I can more easily wire the pi's pins. With everything disconnected besides the ribbon cable to the pi, if I wiggled the cable, the pin would assert like 20x a second. I'm don't know why it's happening, maybe it's short circuiting? I'm tempted to try another pin, but It'd presumably need to be one that reads low, unless I want to recompile the kernel.

As always, any suggestions are helpful.

[goodney]

It's configured to pulse at 200ms.
I also ran it for over an hour, and then wrote a program to parse the dmesg output (I have kernel PPS debugging on). It didn't miss a single second, but it still was reported as a false ticker. This was confusing - maybe it's pulsing erratically? See the last paragraph below for more on this.

I would get NTP working with a network source. This should get the RPi clock fairly accurate. Then if you look at the assert/clear timestamps you should be able to see that they are approximately 1s apart. The jitter should be on the order of what is reported by ntpq -p

If the PPS pulse is erratic or has false detections, then you should see the anomalous timestamp in your kernel log.

If the PPS pulses are being reported by the kernel at approximately 1s apart, but NTP is having issues then try increasing the debug level on NTP to see why it thinks there is a problem. There maybe some weird bug in the kernel-NTP PPS interface... pure speculation here ;-p

I am using a modified kernel. It's the base raspberry pi kernel with GPIO and PPS GPIO support, which Chris' kernel doesn't appear to have. Do you know if his kernel has anything needed other than the GPIO stuff turned on in the kernel's menuconfig? Maybe I should make a github or something so that others can take a look at my minor patches.

He says that he now has "Applied the GPIO interrupt patches from the official kernel"

This should be all that is needed to create a PPS source from a GPIO interrupt.

I also noticed something confusing last night:
I use a cobbler kit for the Pi now, so that I can more easily wire the pi's pins. With everything disconnected besides the ribbon cable to the pi, if I wiggled the cable, the pin would assert like 20x a second. I'm don't know why it's happening, maybe it's short circuiting? I'm tempted to try another pin, but It'd presumably need to be one that reads low, unless I want to recompile the kernel.

Hrm... this could be the source of the problem. Sounds like the pin you're using may be intermittent. Have you tried the same thing without the cobbler kit attached? How were you attaching the PPS signal from the 18xLVC to the RPi? If there is an intermittent connection, then the kernel log should show a missed or extra assert.

Good luck!

-Andrew

[chrisprt]

I would get NTP working with a network source. This should get the RPi clock fairly accurate. Then if you look at the assert/clear timestamps you should be able to see that they are approximately 1s apart. The jitter should be on the order of what is reported by ntpq -p

If the PPS pulse is erratic or has false detections, then you should see the anomalous timestamp in your kernel log.

If the PPS pulses are being reported by the kernel at approximately 1s apart, but NTP is having issues then try increasing the debug level on NTP to see why it thinks there is a problem. There maybe some weird bug in the kernel-NTP PPS interface... pure speculation here ;-p

Good idea. I'll try this next, assuming I can get it back to a single pulse per second setup.

He says that he now has "Applied the GPIO interrupt patches from the official kernel"
This should be all that is needed to create a PPS source from a GPIO interrupt.

Disagree, unless you know something that I don't. I've been registering the "pps-gpio" device to gain LinuxPPS support. This has required platform device registration in the kernel. See http://www.raspberrypi.org/phpBB3/viewt ... 0&p=139797

Hrm... this could be the source of the problem. Sounds like the pin you're using may be intermittent. Have you tried the same thing without the cobbler kit attached? How were you attaching the PPS signal from the 18xLVC to the RPi? If there is an intermittent connection, then the kernel log should show a missed or extra assert.

Yes. I've tried directly from the 3.3v pin to the GPIO pin, and it has multiple asserts. This may may be normal though - as I lift the wire in my finger away from the pin surely the voltage level spikes over and under the tolerance levels.
Before I used a 1k and 2k resistor in a voltage divider config, as suggested by Gert Van Loo earlier. As I also said before, the pulses were causing it to be registered as a false ticker, but looked okay otherwise. That's why I got the logic level shifter and cobbler kit. I thought the shoddy wiring + simple voltage divider setup might be causing issues.

[chrisprt]

Update:

I wired it all up again tonight, and was able to get back to the problem I've been having, false tickers. Here's my setup (sorry for the poor labeling, I was in a hurry):

http://i.imgur.com/3niq0.jpg
In case anyone cares, the pi:

http://i.imgur.com/MJ84T.jpg
Oddly enough, I saw some random assertions even with just the wire as shown above. It seems sensitive.

Once I hooked it up, I consistently saw values like this:

Code: Select all

[email protected] ~ $ sudo /usr/src/pps-tools/ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1343965075.995903094, sequence: 1142408 - clear  0.000000000, sequence: 0
source 0 - assert 1343965076.995907979, sequence: 1142409 - clear  0.000000000, sequence: 0
source 0 - assert 1343965077.995907848, sequence: 1142410 - clear  0.000000000, sequence: 0
source 0 - assert 1343965078.995910705, sequence: 1142411 - clear  0.000000000, sequence: 0
source 0 - assert 1343965079.995912548, sequence: 1142412 - clear  0.000000000, sequence: 0
source 0 - assert 1343965080.995915374, sequence: 1142413 - clear  0.000000000, sequence: 0
source 0 - assert 1343965081.995920190, sequence: 1142414 - clear  0.000000000, sequence: 0
source 0 - assert 1343965082.995920989, sequence: 1142415 - clear  0.000000000, sequence: 0
source 0 - assert 1343965083.995922776, sequence: 1142416 - clear  0.000000000, sequence: 0
source 0 - assert 1343965084.995925547, sequence: 1142417 - clear  0.000000000, sequence: 0
source 0 - assert 1343965085.995927306, sequence: 1142418 - clear  0.000000000, sequence: 0

Which is right on the money. I moved on to ntpd, I still ended up with it as a false ticker:

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*resnet1.resnet. .GPS.            1 u   52   64  377   42.787   -2.726   5.094
+tick.usno.navy. .IRIG.           1 u   48   64  377   50.370    1.690   8.913
-ntp-s1.cise.ufl .GPS.            1 u   55   64  377   61.023  -15.183   6.654
+navobs1.gatech. .GPS.            1 u   48   64  377   65.763    3.844   8.759
xPPS(0)          .PPS.            0 l   16   16  377    0.000    4.323   0.092

After further research, I noticed that it was sporadically asserting on the falling edge of the pulse. For example:

Code: Select all

source 0 - assert 1343969703.996309232, sequence: 2563 - clear  0.000000000, sequence: 0
source 0 - assert 1343969704.996320380, sequence: 2564 - clear  0.000000000, sequence: 0
*source 0 - assert 1343969705.196323998, sequence: 2565 - clear  0.000000000, sequence: 0
source 0 - assert 1343969705.996331467, sequence: 2566 - clear  0.000000000, sequence: 0

Oddly enough, when I switched the power source of the GPS, this behavior increased in frequency. It seems as if the voltage across this system is pretty sensitive, so I might need to look into cleaner power sources. When I powered it with a 1amp "charging" usb port, the GPS wouldn't even turn on. When I powered it with a regular port from a powered hub, the aforementioned behavior increased. Straight from one of my computer's USB port has resulted in the lowest double-asserts.

[goodney]

Good to know it probably isn't a kernel or ntp bug. I was 90% sure we'd see those false asserts in the log. Looks like we're closing in on a cause... now to find a solution ;-p

It could be a power issue, or it could be a grounding issue or both as it sounds like noise on the transition is causing the false assert.

How are you powering the 18xLVC?

How are you powering the RPi?

The 18xLVC connector has a power ground, signal ground and a shield. How are you connecting these pins?

How are you connecting the PPS pin from the 18xLVC to the RPi?

The good news is that problems like this are usually easy to solve once you know what you're looking for

-a[g

[jbeale]

In case this helps (NTP with PPS on the Pi is apparently now working for me):
http://www.raspberrypi.org/phpBB3/viewt ... 06#p142606

[chrisprt]

Good to know it probably isn't a kernel or ntp bug. I was 90% sure we'd see those false asserts in the log. Looks like we're closing in on a cause... now to find a solution ;-p

It could be a power issue, or it could be a grounding issue or both as it sounds like noise on the transition is causing the false assert.

While that's true, I DO believe I've had cases before where it still went false ticker while the assert logs were impeccable (pre 8 lane logic level shifter). A guy in the other thread (http://www.raspberrypi.org/phpBB3/viewt ... =41&t=1970) pointed out that I may be missing a flag though.

How are you powering the 18xLVC?

It depends, but almost always USB ports. After measuring current, the USB ports have slightly different amperes, but they usually are around 400mA. The 18x LVC only requires ~92mA.

How are you powering the RPi?

Usually with a 5v 1amp usb converter that I also use to quick-charge my phone. Unfortunately, I recently incorporated a USB hub that wasn't actually supplying charging power to the two designated charge ports, so it dropped down to what I'd guess is 400ma as well. This may have been one issue, not enough current to the Pi. I've sent that hub back, and will return to the USB converter.

The 18xLVC connector has a power ground, signal ground and a shield. How are you connecting these pins?

This I haven't done much with. I simply connected 1 of the black pins to ground. Even the GPS Tech Specs from Garmin list pin 3 and pin 5 as "Ground" only. Do you think I should wire the other ground up?

How are you connecting the PPS pin from the 18xLVC to the RPi?

This is variable. I started with the voltage divider circuit shown above by Gert. I've now moved on to the 8 lane logic level shifter IC. Since the pin pulses at 5v, I'm scared to ever try it directly to the Pi. I must admit though, my multimeter has never seen the pulse from the GPS go above 3v. That may just be because the multimeter hasn't clocked the true voltage in time though.

The good news is that problems like this are usually easy to solve once you know what you're looking for

-a[g

Hopefully. One thing I might try to reinforce is the connections. I'm using pretty small wire (28 or 30 gauge jumper wires that are just twisted together with other wires). On more than once occasion I've felt the power lines and noticed they are quite hot.

Another thing to note is that I've been syncing a FreeBSD box for a long time with this basic setup. Granted, in the last week, I've changed the wiring of the GPS quite a bit to incorporate the Pi, but it still seems to be syncing okay on the FreeBSD side.

[mckimzey]

If I might post a quick reply.  The problem is that you actually have to read the INVERSE of the serial input.  Let me explain ever so briefly.

     I tried to do something similar with an Ardurino.  The GPS unit puts out a signal that is to be read in a serial port...whether that is 5v or the 12v of a "real" serial port.  Real serial ports invert the signals.  When I used a special library that could read an inverted serial stream, it worked like a charm.  To say it another way...the GPS confuses things by putting out a TTL voltage, but still with a rs-232 format (again...signals are inverted). You may have to google this...

So, I guess there are several options...
1)  use a FTDI serial to USB converter.  They come as 3v3, 5v and standard 12v.  The 18xLVC needs at least 5v, though.  I guess if you use the 5v model you could then connect the 1 pps through the voltage dropper and into the GPOI.
You could use an inverter...either a chip or with discrete components ...I built one with some Radio Shack 2N2222 transistors.

Hope this helps!

-mike

[remaeder]

If I might post a quick reply.  The problem is that you actually have to read the INVERSE of the serial input.  Let me explain ever so briefly.

     I tried to do something similar with an Ardurino.  The GPS unit puts out a signal that is to be read in a serial port...whether that is 5v or the 12v of a "real" serial port.  Real serial ports invert the signals.  When I used a special library that could read an inverted serial stream, it worked like a charm.  To say it another way...the GPS confuses things by putting out a TTL voltage, but still with a rs-232 format (again...signals are inverted). You may have to google this...
-mike

I would never have guessed that! So I found an old LS7404 and inserted it between the level shifter and the GPS 18, on the Tx and Rx lines. Works perfectly. No need to invert the PPS signal.

thanks,

Roman