You're welcome! I marked it red to find it easier, since there are no line numbers either 😉 

I noticed that the acceleration data is very erratic.  If I do not touch the MPU6050 module the numbers on the display change and the data seems to be very erratic.  Any suggestions?

I was already wondering about that - then again: I do not have any experience with devices like the MPU6050.
I'd have to guess that the erratic behavior is like a nervous behavior?
Meaning: never holding a fixed set of values, always hovering around a certain value?

In that case, not being aware of what kind of numbers we're looking at, I'd only change "w, x, y, z" if the new value is more than a certain percentage or fraction different than the stored values.

So for example, say the value (again: I don't know what kind of values we're looking at) for X = 100, and the returning values hover between 98 and 102 when the MPU6050 is laying still, then I'd only update X is the new value is more than 2 bigger or smaller than the currently stored value. I'd make that "factor" a constant in your code so you can play with different values to see which one offers the best stability.

Something like this:

#define Fluctuation 0.02 // assuming 2%

...

if ( abs(X - newX) > (X * Fluctuation) ) {
  X = newX;
}

I hope I understood your issue correctly and I hope this helps 😊 

You got it right.  Really interesting idea.  I am going to look at that

I really want to solve the problem as to why the data gets crazy.  It seems to be a common problem of posts across various sites.  But I have not found one that actually solved the problem

I wonder if the issue could be related to the two I2C devices not playing well together.

The display is at address 0x3C and the MPU6050 is addresx 0x68

The interrupt pin can't be the culprit since the issue occurs in code not using an interrupt

I did a little more testing today and think the instability issue is related to how the code resets the FIFO buffer from the MPU6050.

To test I added a line to reset the FIFO after the sketch displays the data on the OLED.  I figured it couldn't hurt.
The code is mpu.resetFIFO();

Guess what?  It is very stable.  I left the test sketch running for a minute or so and there was very little variation in the accelerometer values.  It also seems to be better at detecting the changing x,y,z accelerometer data.

With that said, I think the issue is derived from the original code from the library example.
I don't think it is resetting the FIFO properly.  It seems to be good at detecting a FIFO overflow but not resetting the FIFO.

The block of code is as below.  Let me know what you think
Thanks

// wait for MPU extra packet(s) available
while (fifoCount < packetSize) {
if (fifoCount < packetSize) {
// try to get out of the infinite loop
fifoCount = mpu.getFIFOCount();
}
}

// get current FIFO count
fifoCount = mpu.getFIFOCount();
if(fifoCount < packetSize){
}
// check for FIFO overflow
else if (fifoCount >= 1024) {
// reset so we can continue cleanly
mpu.resetFIFO();
// fifoCount = mpu.getFIFOCount(); // will be zero after reset
Serial.println(F("FIFO overflow!"));
}

// read a packet from FIFO
while(fifoCount >= packetSize){
mpu.getFIFOBytes(fifoBuffer, packetSize);
// track FIFO count in case there is > 1 packet available
fifoCount -= packetSize;
}

Awesome and excellent find! 👍 I had not thought of that (probably because I do not have an MPU6050, but then still it would have been a lucky guess on my end haha)!

I see a place for I2C, but sometimes it can be a little challenging to find the culprit when things do not work they way we expect them to work.

Thanks for posting the code and happy to hear you got the issue resolved!
I hope someone will find it here and have a good use for it (maybe even myself once I get the chance to play with an MPU6050).

Any 9dea why that code snippet is not working to reset the FIFO?

No clue, but maybe this is helpful: (source)

I ended up clearing the buffer after every read. In your code it would be following the line

//read this packet from FIFO buffer 
mpu.getFIFOBytes(fifoBuffer,packetSize);

I added

mpu.resetFIFO();

Strange as it maybe, this suggest you should read the bytes first and then reset. A little weird, as I'd expect the reset to do just that to begin with.

In that post you'll find a modification of the mpu.h file (which I usually try to avoid, since updates will overwrite your change and when saving your code somewhere, you'll need to add documentation that you changed the mpu.h file), and a suggestion on how to increase the buffer.

I did find several other posts, but I'm sure you found those as well.

I came acorss a good page and it seems that you have the right idea.  It is definitely related to the FIFO not being cleared properly.

I inserted a line to test.  It printed the FIFO count to the serial monitor. 
As soon as the FIFO count is greater than 0 the erratic data starts.

If I clear the FIFO buffer after reading it then the FIFO count stays at 0 and the data from the MPU6050 is stable.

Take a look at this page.  The MPU6050 exoplained.  Very helpful
https://mjwhite8119.github.io/Robots/mpu6050

Oh wow, good find! 👍 

Just looked through the article and man that's very extensive and easy to understand. Cool!

I got the project working although there are a couple of issues and the code needs to be optimized.  Since the code is so large I am attaching it as a file.. I am also attaching two sample data files, one for GPS and the other for Accelerometer.

GPS File format is as follows:
date, time, latitude, longitude, altitude, speed, number of satellites

Acceleronmeter file format is as follows:
date, time, x, y, z, temperature

Issue 1-At times the sketch either gets stuck in the MPU6050 loop or for whatever reason stops processing and updating the OLED and SD card

Issue 2-The data shows gaps in racording, at times up to 10 seconds. 

Any help is greatly appreciated
Thanks

I'd love to help if I can ... 😊 

I would have a few questions, since I do not have a MPU6050.

1) When seeing your code:

//added 8-29-2020
mpu.resetFIFO();

// wait for MPU extra packet(s) available
while (fifoCount < packetSize) {
  if (fifoCount < packetSize) {
    // try to get out of the infinite loop 
    fifoCount = mpu.getFIFOCount();
  } 
}

I do not see an initial fifoCount read.
I do not know if this fixes anything, but I'd be inclined to write it this way, so fifoCount is properly initialized and has a proper value (I hope I didn't miss something in your code where you already did this):

//added 8-29-2020
mpu.resetFIFO();

fifoCount = mpu.getFIFOCount();

// wait for MPU extra packet(s) available
while (fifoCount < packetSize) {
  if (fifoCount < packetSize) {
  // try to get out of the infinite loop 
    fifoCount = mpu.getFIFOCount();
  } 
}

2) The gaps (I can see them in the data output as well) could be the MPU6050 "freezing up" for a little bit or maybe even completely resetting? Maybe it is an idea to refresh the data less often?

3) The code is reasonably readable, but maybe it is a good idea to clean it up a little to improve readability (use proper and consistent indentation) 😊 
(note: I'm not that great at that either when testing code - sometimes I use tools like this one to cleanup and beautify my code - I've attached a "cleaned up" version of your code, which I did with the link mentioned earlier)

These are just my initial thoughts ... not sure if they are helpful in any way 😊 

I noticed the same thing but the MPU6050 code was copied from the library example.  Here is the library DMP6 example with some code added for the ESP32 and OLED

I completely agree that the code needs to be cleaned up.  I am spending so much time troubleshooting that I do cleanups when I can

I added the line to set an initial FIFO count as you suggested.  It seems to be more stable but I need to do more testing
I did a short test and there were no dropouts in the data.  Both files from today attached

 You do have a point.  I do not need to log data multiple times per second.   The logs show an average of 5-6 times per second.
I think 1 maybe 2 data logs per second would be plenty. 

Is there a way to limit the interval the code logging to SD ?