datalogger overwrite/delete older records when full --questions

Hello,

I'm using a sainsmart mega2560 and a LC studio SD module:

and a GPS shield and OBD TTL Adapter.

I have it connected and coded to store OBD data and GPS data in a datalogger type of setting.

My only concern now is that if it ever gets full, does it simply stop saving?

I've read in some forum threads that it's simply done through copying from one record, then deleting everything but saving only the remaining record from the previous text file needed
But I've seen other threads doing something like, only 100+ records per text file, then deleting the oldest record by date (or name).

I'm only starting my methods before actually coding the overwrite but I already saved records from my gps and obd to the sd card, I just wanted to ask for advice when it comes to file size.
Because I'm making a sort of Event Data Recorder, but recording for the entirety of the journey and that 32gb is, from my calculation, can be easily filled within 5.6 days(Continuous) both with OBD and GPS record.

Thank you for sparing time to read my question.

..cant see your prob:
log every second? 86k loggings a day, 1/4k each (a lot) -> 21M / day
-> 1000+ days to reach 30G
looks to me more like 3 yrs

knut_ny:
..cant see your prob:
log every second? 86k loggings a day, 1/4k each (a lot) -> 21M / day
-> 1000+ days to reach 30G
looks to me more like 3 yrs

Actually, I did a test with GPS first, and timed it manually.
I got several saves, and it saved 2.4kb/5 mins.

Okay, it just clicked to me.
What I saved was actually unparsed(correct term?) data.
The whole $GPGGA,,,,,,,,,,,,,,,,,,,,,,,,, data.

So in terms of saving, it's better to save it as parsed data, am I correct?

Thank you for your comment, I wasn't thinking straight, gonna test parsing then saving in bits.

By the way, If I'm saving exactly per second, do I reduce/increase the baudrate of my serial(cause it retrieves the string from Serial1, or the GPS) or is delay enough?

The RMC sentence contain time and position. save the string every time GPS-time changes
So prog (use GPS-lib) reads GPS over and over again
if 'new' data arrived (time stamp changed) save to SD-card

Sorry, I forgot to update my progress: Been busy with the other functions of our project. But basically I got to save the GPS in the SD card.

This is 61 records in 1min 1 second.

Only took the important data Lat, Long, Time and that makes 3.3kb per 1min 1sec. Though I didn't get yet the weight for the OBD(basically taking Speed, RPM, Fuel_Level and Ambient_Temperature). And we planned to actually add a camera but I'm finding it hard to find the right resources... only got the C328R library but no solid examples (there was a basic sample but I didn't know where the file goes to because all I needed was to save directly.)

Saying that OBD data takes up another 3kb per min, I guess you are right that it will take ~11 years still to fill up a 32gb(theoretically 32 ~though some are like ~27~29Gb in total) SD card... now to move on with the camera though I think I'll put a delay for the camera... like a jpeg camera per 5 seconds? Does that take a lot? I've seen a lot of pics from people who've used C328R and they got like 5.4kb raw format. Dunno if that is true and if it was, I think it still won't be a burden, unless it's like x10 of that size. That's by 640x480 res. Thanks again, sir!

UNO and cameras is a tricky combo. Be sure to find a camera that can take a still, and hold this while arduino reads it from the cameras memory. (I'm afraid this taks so long you'll miss gps logg-point(s))
A QVGA-picture (320*240) may be good enough.
I dont know if there exist some simple/smart fileformat that allows for easy picture viewing / film playback...
The solution may even already exist.. search..

knut_ny:
UNO and cameras is a tricky combo. Be sure to find a camera that can take a still, and hold this while arduino reads it from the cameras memory. (I'm afraid this taks so long you'll miss gps logg-point(s))
A QVGA-picture (320*240) may be good enough.
I dont know if there exist some simple/smart fileformat that allows for easy picture viewing / film playback...
The solution may even already exist.. search..

Actually I did a search awhile back, gets really confusing with the C328,C329 and Serial TTL cameras... if they are the same thing or should I use the C328 library... confusing.

I'm working now on my http://www.e-gizmo.com/KIT/serial%20camera.html on my Mega
I think I'll post in a couple of days if I find it good... or the money was wasted(well, learning is well spent on failures)

..I cannot see the documentation. (guess no-exists)
Ask supplier - they may provide som code/info
--- missing info may tell "trouble ahead".
Keep us informed..

knut_ny:
..I cannot see the documentation. (guess no-exists)
Ask supplier - they may provide som code/info
--- missing info may tell "trouble ahead".
Keep us informed..

My friend, who the seller sold to, was just told to visit http://www.fut-electronics.com/wp-content/plugins/fe_downloads/Uploads/Serial%20Camera%20Module%20Programming%20Instructions%20and%20Tutorial.pdf
Never did helped me, so I searched for more resources. And also found out that the library C328R hasn't been updated since 2009 neither was the sample code which really worried me.
Hopefully, I can connect it properly and save it as well in the sd card.

The thing that always worries me here is that most of the given code in the google searches I find are all for arduino IDE 0021 and lower(like BYTE still being used for print). But I'm kind of lacking time to change the code to fit 1.0.5.
Hmm, I'll still see what I can do in this short time frame.
Also had to add a weight and pressure sensor a little while ago, it just added another 1kb/min.
And also because of the OBD, it had delay issues I believe, dunno why, might be a logical flaw on my part, the time it records now goes for a record per 3 seconds.
:
So that 3.3kb/min for GPS became 1.1kb/min
OBD data for 1kb/min
other sensor for .4kb/min
2.5kb/min ~ 1.29Gb/year continuous

so my problem really was not a problem.
But I think my real worry is the weight of the camera input, maybe I'll just have to adjust the capture rate(If I get the code to run first)

Change of plans, the video record will be done on Raspberry Pi instead, adviser advised us to.

let's see how this goes.