No local date / time printed in merged NMEA Timezone with Georevcache

(deleted)

(deleted)

NMEA_Reverse_GeoCache.ino (17.3 KB)

1)function Only need to be called once. When I put it in setup() did not work at all. Why not ?

Because you need a fix.dateTime to know the year. The changeover time is different for different years, because the "last Sunday" is a different date in different years.

If you select a hard-coded year (e.g., 2017), you could do the calculation in setup. Then it would not work after that year is over (e.g., Dec 31, 2017).

If you want it to work for any year, you have to use the same structure as NMEAtimezone.ino. It checks the changeover date every time, but it only calculates the springForward/fallBack times once per reset/year. It adjusts the fix.dateTime to CET every time.

I do not see a date / time at all.

It looks like Print_DST only prints to the DEBUG_PORT, not the LCD. Initially, springForward/fallBack should be zero. After calling Run_Once, they will only get changed if fix has a valid date AND a valid time. That would require parsing an RMC sentence with a valid date AND time. You may be calling Run_once when the date and/or the time is not valid yet. loop does not check those flags before checking

    if (springForward == fallBack)

Again, I would use the same structure as NMEAtimezone, because it checks the flags and springForward/fallBack in the correct order, before adjusting the fix.dateTime.

Cheers,
/dev

(deleted)

NMEA_Reverse_GeoCache_4.ino (17.1 KB)

I think the main thing is that gps.read() should only be called from one place. To adjust the time, you have to adjust every fix that you read, but just once, and only when the date/time is valid. I moved a few things around. Now loop is the only code that will call gps.read to get the new fix.

If the fix it gets has a valid date/time, it adjusts it from GMT to CET and prints it to the DEBUG_PORT.

If the fix it gets has a valid location, it calculates the range from the target to see if it should operate the Servo.

Note that it can have a valid date/time before it has a valid location. As the GPS device uses more satellites for tracking, it can eventually calculate a location.

From a cold start, the attached sketch will print

  • “Acquiring Signal…” for a while.

  • CET date/time and “.” for a while.

  • Location/range and CET date/time for a while (no dots printed).

  • “Acquiring Signal…”, CET date/time and “.” again, if it loses a few satellites (location not valid).

  • Location/range and CET date/time forever (no dots printed).

Cheers,
/dev

JevanHa_4.ino (16.5 KB)

(deleted)

Did I describe it a little right in this way? In any case, it gave me a better insight into the matter.

Yes!

The GPSfix_cfg.h is the master "list" for NeoGPS. All the uncommented pieces will be in the fix "grocery bag". If you don't use some of the pieces, you can comment them out. This will save some "money" (RAM, program size, CPU time) if you need to. Your sketch is small enough that it doesn't matter.

Can I ask what you're using the Reverse Geocache box for? Some special event?

Cheers,
/dev

I noticed in your program, you are using $GPRMC, which is one of the NMEA "Recommended Minimum Data" strings, so almost all GPS receiver chips output this string by default.

The Ublox chips are ROM based chips, but configurable via serial and can output other NMEA strings.

One such string that might be more convenient for local time is $GPZDA.

$GPZDA,hhmmss.ss,dd,mm,yyyy,xx,yyCC
$GPZDA,201530.00,04,07,2002,00,00
60

where:
hhmmss HrMinSec(UTC)
dd,mm,yyy Day,Month,Year
xx local zone hours -13..13
yy local zone minutes 0..59
*CC checksum

I am not sure how accurate it is around time zone change lines, as I've not tested it there...

(deleted)

(deleted)

Perehama:
noticed in your program, you are using $GPRMC

Actually, he's not "using" an RMC -- there's no code in his sketch that refers to an RMC. NeoGPS parses all the sentences that the GPS device sends (RMC, ZDA, GGA, etc.) to fill out one fix structure. This is one of the major differences between NeoGPS and all other libraries.

But since he needs the location, at least one of the location sentences must be parsed: RMC, GGA, GLL. See this table.

-dev:
Actually, he's not "using" an RMC -- there's no code in his sketch that refers to an RMC. NeoGPS parses all the sentences that the GPS device sends (RMC, ZDA, GGA, etc.) to fill out one fix structure. This is one of the major differences between NeoGPS and all other libraries.

But since he needs the location, at least one of the location sentences must be parsed: RMC, GGA, GLL. See this table.

I am not familiar with the NeoGPS library, but saw the reference in remarks. Most ROM Based Ublox receivers, especially the very low cost ones from ebay china stores etc., do not output ZDA by default, and many only have 3 wires connected (+v, GND & Tx), so I was only sharing my general experience with GPS receivers. I don't know if the NeoGPS outputs the config strings needed to turn on some of the non-default strings.