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
- Posts: 2487
- Joined: Tue Aug 02, 2011 7:27 am
- Contact: Website
Re: Garmin GPS 18x LVC to Pi
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
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

- Attachments
-
- voltage_divider.GIF (3.14 KiB) Viewed 17997 times
Re: Garmin GPS 18x LVC to Pi
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:
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
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
pi@raspberrypi:~$ 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'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
Re: Garmin GPS 18x LVC to Pi
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

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
Re: Garmin GPS 18x LVC to Pi
Totally in agreement. That's why I'm spending so much time on it =]goodney wrote: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![]()
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:goodney wrote: 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.
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
Code: Select all
pi@raspberrypi:~$ cu --nostop -l /dev/ttyAMA0 -s 115200
Connected.
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
This is a good idea. I'll try this later.goodney wrote: 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
Yep, just broke this out today and reconfigured it.goodney wrote: 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.
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.goodney wrote: Try using a bi-directional 3.3-5V convertor.
Re: Garmin GPS 18x LVC to Pi
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:goodney wrote: Make sure the settings as seen with stty -F make sense.
Code: Select all
pi@raspberrypi:~$ 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û;Û
Code: Select all
pi@raspberrypi:~$ 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 did this today, and I think it worked:goodney wrote: 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
Code: Select all
Terminal 1:
pi@raspberrypi:~$ cat < /dev/ttyAMA0
test
raspberry pi serial test
raspberry pi serial test plugged back in
Terminal 2:
pi@raspberrypi:~$ echo "test" > /dev/ttyAMA0
pi@raspberrypi:~$ echo "raspberry pi serial test" > /dev/ttyAMA0
pi@raspberrypi:~$ echo "raspberry pi serial test unplugged" > /dev/ttyAMA0
pi@raspberrypi:~$ echo "raspberry pi serial test tx unplugged 2" > /dev/ttyAMA0
pi@raspberrypi:~$ echo "raspberry pi serial test plugged back in" > /dev/ttyAMA0

Re: Garmin GPS 18x LVC to Pi
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
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
Re: Garmin GPS 18x LVC to Pi
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.goodney wrote: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.
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.goodney wrote: 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.
It's configured to pulse at 200ms.goodney wrote: 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.
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 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.goodney wrote: 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 must admit that while I understand what you're asking for, I have absolutely no idea how I'd make it.goodney wrote: 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.
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.
Re: Garmin GPS 18x LVC to Pi
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 -pIt'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.
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
He says that he now has "Applied the GPIO interrupt patches from the official kernel"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.
This should be all that is needed to create a PPS source from a GPIO interrupt.
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.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.
Good luck!
-Andrew
Re: Garmin GPS 18x LVC to Pi
Good idea. I'll try this next, assuming I can get it back to a single pulse per second setup.goodney wrote: 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
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=139797goodney wrote: 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.
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.goodney wrote: 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.
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.
Re: Garmin GPS 18x LVC to Pi
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:
Which is right on the money. I moved on to ntpd, I still ended up with it as a false ticker:
After further research, I noticed that it was sporadically asserting on the falling edge of the pulse. For example:
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.
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
pi@raspberrypi ~ $ 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
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
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
Re: Garmin GPS 18x LVC to Pi
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
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
Re: Garmin GPS 18x LVC to Pi
In case this helps (NTP with PPS on the Pi is apparently now working for me):
http://www.raspberrypi.org/phpBB3/viewt ... 06#p142606
http://www.raspberrypi.org/phpBB3/viewt ... 06#p142606
Re: Garmin GPS 18x LVC to Pi
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.goodney wrote: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.
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.goodney wrote: How are you powering the 18xLVC?
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.goodney wrote: How are you powering the RPi?
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?goodney wrote: The 18xLVC connector has a power ground, signal ground and a shield. How are you connecting these pins?
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.goodney wrote: How are you connecting the PPS pin from the 18xLVC to the RPi?
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.goodney wrote: The good news is that problems like this are usually easy to solve once you know what you're looking for
-a[g
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.
Re: Garmin GPS 18x LVC to Pi
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
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
Re: Garmin GPS 18x LVC to Pi
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.mckimzey wrote: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
thanks,
Roman