There were some single quotes, but now I have changed all to double-quotes. Does this matter?
I wish I could get rid of TinyGPS++ and SdFat libraries as well
I'm sorry if my first advice seemed odd. I was looking at the first section of output you printed, and it looked like all zeros, I didn't see there was some actual data down at the bottom of the file, it was out of the viewing window.You did not say you were a GPS expert.
If your program runs and then hangs up, or restarts, then it is likely to be one of three things. Program corruption ( unlikely on the arduino ) , running out of memory ( much more likely ), or some kind of power supply problem. How reliable is your arduino power supply ? Is there enough power to keep your GPS chip running ?
This TinyGPSPlus is new, I didn't see it before today, I just downloaded it and was playing with it myself. Are you using the very latest version of it ? Are you sure there is no memory leak in it? Try running it for a long time, without using the SD card, does it work for hours without hanging up or resettting ?
The reason I suggested reducing the number of calls to the file printing function, is that I don't know what time and memory space latency is involved in making all of those calls, and I don't know how much code they generate. Other people may know, but not me. I'd be inclined to write the whole output line into a single text line and then write it to the file once, that's just the way I would always do it, PaulS has a different view, well he would know more than me.
I've done some tests with latency time on SD cards, sometimes it is fast, sometimes it takes a long time, there is probably some reason for it to do with the buffering but from the point of view of the arduino sketch the latency can be pretty "random" or unpredictable. The point is, your code cannot be set up to "rely" on some particular performance.
A single quote 'A' is used for only a single character. Any sort of sequence of more than one character requires double quotes "text".I would have thought your previous code would have been a compiler error, I have no idea how it would have been interpreted. You can have a string with only one character "B", but you cannot fit more than one character into a single char variable.
If memory space really is your issue, the TinyGPS library still works fine and it is smaller than the TinyGPS++ library.
But your program runs, so it has enough space, at least to begin with. And then it may be running out later.
But that you have what is called a "memory leak". You need to find it, and fix it.
I am still concerned that your hdop figure always seems to be zero.
Now, you seem to get data after about 6 seconds after your arduino appears to be re-setting. Do you have a backup battery on your GPS chip ? Because this 6 second delay looks like what the GPS chips call a hot start rather than a cold start. That may be some kind of clue.
what would your code do if one of the NMEA sentences is missing or corrupted ? What would your code do if you "lost the gps fix" for two seconds and then regained it ? Would your code then try to start writing another brand new logging file ? That may be a logical flaw in your scheme.
Did you get rid of your three second delay in the loop ?
I had a look at the code of my GPS logging applications. I never try to open the same SD file which I had before. I have a system of numbered files and I always open a new file with a different number every time the process restarts. When I first started using SD files on the arduino about 3 years ago, I had a lot of reliability problems , and still do, although not as many.
The last suggestion, is to make either the GPS baud rate or the serial connection baud rate faster. The arduino then spends less time waiting around for serial data. I found that the whole GPS process works better at higher speeds.
One problem I had, was that the GPS chip was outputting 5 different messages, and sometimes it got corrupted and tried to write two of its messages simultaneously, which messed tham up. Hard to believe that the manufacturer did not think of that problem. I thought it was me, not reading them properly. Anyway, solved the problem by turning the ones I didn't need, off.
I agree with the suggestion to increase the serial console baud rate to as large as can be supported. I always use 115200 baud. If you print to the console at slow baud rates you unnecessarily increase the risk that GPS data will be dropped. That won't explain the device resets, but it would explain not being able to get a TinyGPS++ fix.
I wouldn't increase the GPS baud rate unless your application requires it.
Could it be a wiring issue?
GPS data logging starts at 5994 mSecsdate,time,lat,lon,altitude,HDOP,speed,course,FreeMem2013/12/16,14:23:35.0,22.340959,91.830001,0.30000,1300,1.41,0.00,9022013/12/16,14:23:39.0,22.340953,91.830001,1.60000,1300,1.39,254.40,9022013/12/16,14:23:41.0,22.340957,91.830001,1.10000,1300,0.33,254.40,9022013/12/16,14:23:45.0,22.340965,91.830009,1.00000,1300,0.22,254.40,9022013/12/16,14:23:47.0,22.340965,91.830009,1.00000,304444,0.22,254.40,9022013/12/16,14:23:51.0,22.340965,91.830009,1.00000,304444,0.22,254.40,902... several hundred records deleted here .....2013/12/16,14:48:40.0,22.341001,91.829986,20.10000,343,0.67,37.88,9022013/12/16,14:48:42.0,22.340993,91.829986,18.70000,401,0.41,37.88,9022013/12/16,14:48:46.0,22.340986,91.829978,16.70000,343,0.13,37.88,9022013/12/16,14:48:48.0,22.340978,91.829978,15.70000,343,0.41,37.88,9022013/12/16,14:48:52.0,22.340969,91.829971,13.60000,343,0.30,37.88,9022013/12/16,14:48:56.0,22.340965,91.829963,13.00000,343,0.39,37.88,902
That's great news, Sayedur. I should have thought of the low battery problem possibility.Just FYI, when we do logging like this we use AA or AAA batteries, which have much greater capacities (and therefore lifespans) than 9V. In your case I would probably use 3 batteries regulated down to 3.1V. (We use 2 or 3 boosted UP to 5V.)I don't think there is any memory leak.