Go Down

Topic: No local date / time printed in merged NMEA Timezone with Georevcache (Read 179 times) previous topic - next topic

JevanHa

I thought it was good to understand. But will have something essential overlooked.
Expected once to see a local date with Summer time. But unfortunately I do not see a date / time at all.
Apart from each other, NMEA Reverse Geocache & NMEA Timezone work for CET as expected. Important Timezone variables were created globally to allow me to get 2 separate functions.
1)function Only need to be called once. When I put it in setup() did not work at all. Why not ?
I've been able to solve this by using a SW switch.
2)function The other half makes the standard offset for Europe including the additional offset for Summer or Wintertime.
Together, Reverse Geocache and Timezone do not work as expected. I do not see a CET date / time.
What I want to know is where my thinking is wrong and what to do about it.



Kind regards
Jan
Nederlands Forum   http://arduino.cc/forum/index.php/board,77.0.html

JevanHa

I couldn't do it between code tages because I exceeded maximum characters allowed. So please see the attechment

IDE 1.8.2
Hardware Arduino Uno rev3 with GPS shield Neo-6M from Elecrow
Kind regards
Jan
Nederlands Forum   http://arduino.cc/forum/index.php/board,77.0.html

-dev

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

Quote
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

JevanHa

Hello /dev. Thank you for your extensive answer.
I've tried this before, but I still do not understand the complete operation yet. This was the result.
Code: [Select]
NMEA_Reverse_GeoCache.ino: Started
    fix object size = 46
NMEAGPS object size = 118
Local time : From here: N52 04.280 E004 30.856 to there: DMS N52 22' 12.779" E04 53' 42.599" Range is: 42.16 Km
2017-05-18 22:45:26
2017-05-18 22:45:27
2017-05-18 22:45:28
2017-05-18 22:45:29
From here: N52 04.278 E004 30.853 to there: DMS N52 22' 12.779" E04 53' 42.599" Range is: 42.17 Km
2017-05-18 22:45:31
2017-05-18 22:45:32
2017-05-18 22:45:33
2017-05-18 22:45:34
From here: N52 04.280 E004 30.858 to there: DMS N52 22' 12.779" E04 53' 42.599" Range is: 42.16 Km
2017-05-18 22:45:36
From here: N52 04.281 E004 30.860 to there: DMS N52 22' 12.779" E04 53' 42.599" Range is: 42.16 Km
From here: N52 04.281 E004 30.861 to there: DMS N52 22' 12.779" E04 53' 42.599" Range is: 42.16 Km
From here: N52 04.281 E004 30.862 to there: DMS N52 22' 12.779" E04 53' 42.599" Range is: 42.16 Km
From here: N52 04.282 E004 30.863 to there: DMS N52 22' 12.779" E04 53' 42.599" Range is: 42.16 Km
From here: N52 04.282 E004 30.864 to there: DMS N52 22' 12.779" E04 53' 42.599" Range is: 42.15 Km
2017-05-18 22:45:42
2017-05-18 22:45:43
2017-05-18 22:45:44
2017-05-18 22:45:45
2017-05-18 22:45:46
2017-05-18 22:45:47
From here: N52 04.284 E004 30.869 to there: DMS N52 22' 12.779" E04 53' 42.599" Range is: 42.15 Km
2017-05-18 22:45:49
From here: N52 04.284 E004 30.869 to there: DMS N52 22' 12.779" E04 53' 42.599" Range is: 42.15 Km


a complete mess of data.
This is what I have tried first
Code: [Select]

  DEBUG_PORT.print(F("\nNMEA_Reverse_GeoCache.ino: Started\n"));
  DEBUG_PORT.print(F("    fix object size = "));  DEBUG_PORT.println(sizeof(gps.fix()));
  DEBUG_PORT.print(F("NMEAGPS object size = "));  DEBUG_PORT.println(sizeof(gps));
  DEBUG_PORT.print(F("Local time : "));
  DEBUG_PORT.flush();
} // end of setup
 
//----------------------------------------------------------------
    DST_CET();
} //    end of GPSloop
 
//----------------------------------------------------------------
void loop() {
  static uint8_t  warningState = 0;
  static uint32_t lastFixTime, lastDotTime;
 
  while (gps.available(gps_port)) {
    gps_fix fix = gps.read();
 
    bool gpsWasFixed = fix.valid.status && (fix.status >= gps_fix::STATUS_STD);
    digitalWrite(LEDPin, gpsWasFixed);  // Set the "fix" LED to on or off
 
    GPSloop();  // first try, no result at all

With no result at all.
Second try, also no result at all.
Code: [Select]
  DEBUG_PORT.print(F("\nNMEA_Reverse_GeoCache.ino: Started\n"));
  DEBUG_PORT.print(F("    fix object size = "));  DEBUG_PORT.println(sizeof(gps.fix()));
  DEBUG_PORT.print(F("NMEAGPS object size = "));  DEBUG_PORT.println(sizeof(gps));
  DEBUG_PORT.print(F("Local time : "));
  DEBUG_PORT.flush();
 
  GPSloop();   // second try, no result at all
} // end of setup
 
//----------------------------------------------------------------
static void GPSloop() { 
  while (gps.available(gps_port))
    DST_CET(gps.read());
} //    end of GPSloop
 
//----------------------------------------------------------------
void loop() {
  static uint8_t  warningState = 0;
  static uint32_t lastFixTime, lastDotTime;
 
  while (gps.available(gps_port)) {
    gps_fix fix = gps.read();
 
    bool gpsWasFixed = fix.valid.status && (fix.status >= gps_fix::STATUS_STD);
    digitalWrite(LEDPin, gpsWasFixed);  // Set the "fix" LED to on or off
 


And this was the third try. I'm doing something completely wrong.
Because the source is more than 9000 characters I couldn't include it with code tags.
Please be so kind and look in the attachment
Thank you for your patience with me.


Kind regards
Jan
Nederlands Forum   http://arduino.cc/forum/index.php/board,77.0.html

-dev

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

Good morning.
Your solution is actually so very simple as I read it.

 It's a bit like a grocery list that I sometimes get from my wife. There are things we both need. Sometimes I add things too that I need for my selves. I am learning to make the right choice for things I wanted in wich store. If I do not right, I come  home with nothing or with the wrong things. In both cashes I am in trouble with my wife >:( .

This is my common grocery list "gps_fix fix ".
And this is I personal want to come home with and add to the common list "(fix.valid.date && fix.valid.time)".
I have learned that here's a right shop assistant that can help me with my personal list "UTC_to_DST_CET (fix)" so I give him my list. And he knows where to find the things I like to come home with ( gps_fix & fix ).

After that I'm happy to go home with the right stuff. :)

Did I describe it a little right in this way? In any case, it gave me a better insight into the matter.
Kind regards
Jan
Nederlands Forum   http://arduino.cc/forum/index.php/board,77.0.html

-dev

Quote
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

Perehama

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,yy*CC
  $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...

JevanHa

Hello Perehama. Thank you for the information.
I am familiar with the NMEA available sentence information, (http://aprs.gids.nl/nmea/) and so also with this.
I am pleased with the current local date / time calculations including Summer & Wintertime settings from NeoGPS
Kind regards
Jan
Nederlands Forum   http://arduino.cc/forum/index.php/board,77.0.html

JevanHa

Can I ask what you're using the Reverse Geocache box for?  Some special event?
Of course you may ask me that. The answer is No, not yet. After I bought the Arduino Uno I was looking for a project to make me familiar with the programming language and hardware possibilities. Yes I am also a Geocacher (2400 founds from july 2014) and visit regurlarly local events.  No I did not made my own Geocache yet.

I was visititing a local hardware store/website and I saw the nice looking Arduino GPS shield. So I bought it inclusief a GPS antenna with 3 meter antenna cable. The antenna is in the window sill near my desk. Also did I read the very interesting Geocache article from Mikal Hart on the Arduiniana website and saw serveral YouTube films wich gives me the idea to build my own Reverse Geocache. And so I did  start with this very interesting and educational project. On the GPS shield there is also a SD card reader/writer. This is my next project. But its connections are a bit conflicting with the 16*2 display. Therefore I has to bought a I2C interface and mount it on the backside of the display. This gives me enough connection space on the Arduino Uno. Etc. etc. etc. Maybe I am ready next wintertime. :)
Kind regards
Jan
Nederlands Forum   http://arduino.cc/forum/index.php/board,77.0.html

-dev

Quote from: 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.

Perehama

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.

Go Up