EM-406A no PPS

I’m building a gps controlled clock out of 7-segment led displays, and thought it’d be cool to use the pulse per second from the gps as an interrupt to drive an arduino to go fetch new data.

I hooked up 2 different EM-406A’s, and neither one seems to have voltage on the pps pin. Using the SiRFDemo software I can see I have a valid fix, and indeed the red led on the 406 itself is flashing. I hooked up an LED just as I had with my venus gps (which worked as I expected), and this will not do anything. (pps + led - ground) (Tapping the pps wire to +5v does light the led, so I don’t have it in backwards or anything)

I checked continunity on the 406 breakout board, and it’s fine.

Any ideas? Do I need to enable it somehow?

Hi,

I’ve been using the EM-406A for a while, but I’ve never used the PPS output. This morning, out of curiosity, I put a scope on the PPS output to see what was there! What I observed was a once-per-second pulse of 2.85V amplitude and 1.5 us duration. So, clearly, this output was never intended to drive an LED as the ON time is much too short!!

I don’t know anything about the Arduino, but presumably there is some interrupt capability?? You could hook the PPS signal to an interrupt input set to detect the rising edge of the PPS pulse, and then read the GPRMC NMEA message to update your display. Keep in mind the amplitude of this signal is only 2.85V, so you may need to “boost” it to +5V if your Arduino is powered by +5V and your logic input is a schmitt trigger input (with a higher logic threshold voltage).

Just a word of caution for the future. You should really determine the characteristics of a signal before making your electrical connections. Before I took my measurements, I assumed you probably damaged your EM-406 modules by connecting LEDs with no current limiting resistors, or by momentarily shorting the PPS output to +5V. In particular, the latter is NOT a good idea!!

John

Thanks for putting an oscilloscope on it. I tried mine on a new gps and while I can see the tx, I still can’t see the pps output. (It’s just the Seeed Studio $100 scope, not the most intuitive thing to use so I may well be missing it)

I did poorly word my connection description, and I at no time connected +5V to pps. I was just trying to indicate I used the wire that originally came from the pps pin. (ie, using a known good voltage source to make sure the led worked)

The arduino has 2 interrupts. The tinygps example code simply has a do while loop, and I was thinking it’d be cool to replace that with the pps so I could consistently get fresh data. I think the arduino can read 3.3V logic, but I’m not sure how low it can actually go. I’ll look into that.

Hi,

I don’t know how much accuracy you are after, but with the clock I designed that is based on the EM-406A, I turn off all the NMEA messages except the $GPRMC message. In my code, I simply loop looking for a new $GPRMC message, and when it’s received, I parse it for the current time, and display it. There may be a few hundred microseconds to do all this, and thus a short time lag in the time display, but it sure isn’t much! Is using the PPS output really worth the overhead in your particular application???

Thanks,

John

Hi John,

It’s definitely not necessary, I’m only building a desk clock. I was hoping it would do 2 things for me, first teach me how to use interrupts, and second, avoid using a pause command.

I added in a seconds display on my 7-segment modules last night, and the seconds will update very untimely. (1, 2, 3, 4, 6,7, 8, 9) etc Not sure if that’s due to the gps updating the clock, or the pause in the gps loop.

I shouldn’t be surprised with the pps, I spent all of Saturday saying how hard can it be to correct UTC to local time. lol

Hi,

A “stuttering” seconds display, or missing counts in the seconds display is a classic symptom of multiple NMEA messages being transmitted by the EM-406A. If you turn off all NMEA messages except the $GPRMC message, you will solve this problem!

You can use the SiRFDemo software to configure the EM-406A for just the $GPRMC message, but if the modules loses power for more than a few days, it will revert back to a multi message format. A safer way to do this is to have your code send the correct configuration commands to the module on each power up. Here are the required commands:

“$PSRF103,00,00,01*08” (GGA set to OFF)

“$PSRF103,01,00,01*09” (GLL set to OFF)

“$PSRF103,02,00,01*0A” (GSA set to OFF)

“$PSRF103,03,00,01*0B” (GSV set to OFF)

“$PSRF103,04,01,01*0D” (RMC set to 1 Hz)

“$PSRF103,05,00,01*0D” (VTL set to OFF)

I’m kind of a “clock nut”, and over the last few years I’ve built a number of clocks including a 7 segment LED clock, a GLCD clock, and a Nixie clock. My designs are based on a RTC chip (the Maxim DS-1307, or the Maxim DS-3231) with optional GPS time/date syncing. These clocks will run without the GPS, and will auto-correct the time/date when one is detected. As you note, the GPS broadcasts UTC (Greenwich Time), so it needs to be corrected for local time if that is what you want to display. I’ve developed a couple of routines that do the conversion on the time/date to correct for the ‘UTC offset’ at the clocks location. My firmware allows the UTC offset to be adjusted from -12 hours to +14 hours from UTC. My clock routines also auto-compensate for leap year and daylight savings! It was a bit of a chore to test these routines under all conditions, but they seem to have held up quite nicely over the past couple of years!

Let me know if I can provide anything else to help!

John

I think you might be onto something… I wonder if I should use a rtc as the clock source instead of the arduino’s internal clock. I could still update the rtc from the gps and have it correct for local time.

The pcf8583 also has a pps pin, so I might be able to put that to use. This was also my first foray into editing a library, and I got it to spit the hundredths back to me as well.

I don’t even have this working and you’ve got me thinking on DST now. :smiley: I was thinking of a switch on the enclosure to do it, but if I can figure out the day of the week, I think I could do it.

Hi,

I would definitely go with an RTC chip for the timekeeping with a GPS sync option, or even a sync to your PC time via USB! This strategy will give you a lot more flexibility! As for DST, there are well-defined times that these periods begin and end, and it’s a simple job to incorporate the logic to detect the change-over into your code. For example, I believe that daylight savings begins in the US (Europe is a week earlier?) on the 1st Sunday in November at 2AM.

John

I got it up and running tonight! I finally got it to read the gps time, change it to local time, update the rtc and read the rtc to display on 4, 4-digit 7-segment serial displays. I also added a routine to change their brightness based on the ambient lighting. I’ll need to add a DST routine yet.

As it stands it’s working perfectly but I think I may be nearly out of ram. I attempted to set the clock twice a day instead of once (by simply adding an OR and another time to pick), and that caused the display to run for a bit over a second and then pause, then run again. I had this happen earlier when I had a few debug messages as well. I have an Arduino Mega coming soon, so I’ll try it on there and see how it behaves.

Thanks for your help in getting me going!

Chanler