Determining Data Peaks & Valleys In Data

No workbook attached.

Re: C and D -- What alternatives to the overall average could you use? We could throw out possibilities, but I'm not sure we can make this decision for you. One possibility I see is that, because the smoothed data jumps above and below 0, I expect the overall average will always be near 0, so just use 0 instead of the average. But, I don't know if that fits into the overall algorithm that you are implementing.

Re: G -- I didn't fully understand the red highlighted values. If I assume that you intended those points to be highlighted and they weren't highlighted, then I would say that they failed one or more of the tests columns C and D (some represented local minima above the average, others were local maxima below the average, others were "flat" where two adjacent points were neither larger nor smaller). If peaks/valleys are being missed, it is because the current logic does not capture those values, and we would first need to understand how you want to change the logic before we can talk about programming the new logic into the spreadsheet.

Re: H -- No ideas, but the discussion probably needs to start by understanding what you mean by "minor" peaks and valleys. Then we can start talking about additional logic tests to filter out "minor" points.

The figures come close to averaging 0 in this case. Other tests vary.

Even so, could you choose the "average" or baseline beforehand? Or are you required to determine the "average" baseline value at runtime?

The red numbers were manually added to help me see where the real peaks and valleys were compared to the formulas.

The current logic for choosing a max (min) is "is the current value greater than (less than) both the value immediately before and immediately after, and is the value larger than (smaller than) the baseline average". Could you maybe walk us through a couple of the highlighted examples and explain why you highlighted them and compare that the current logic algorithm?

I would also note at this point that I'm not necessarily worrying about exact spreadsheet formulas or anything. It feels to me like we are still exploring the more generic signal processing ideas (independent of the programming language you want to use), so I'm just trying to understand how you want to identify peaks and valleys.

This is an academic exercise - not related to student grade. I'm 76 years old and left college many years ago. I'm doing some very early analysis for a professor in Greater Boston.

I can test the idea of averaging the baseline up to each point. Before doing that it may be advisable to see if there are any alternative formula approaches.

I'm mainly interested if the trend of the extreme peaks and valleys to see where these swings in centigrade temperature are about to change direction. I read somewhere that the guys in the stock market look at trend the same way.

I'm still not sure exactly what we are trying to do here.

In my own experimental work (completely different field that does not involve very much signal processing), I find that signal processing often wants clear "start of experiment" and "end of experiement" indicators in the data. In this case, are you expected (among other things) to identify start and end of experiment from the signal data, or are there other indicators outside of the data? You mention "24 hour cycles", but also that the data does not include any internal time indication. Would it be important to identify these 24 hour cycles, or, again, are you expected to identify 24 hour cycles from the raw data itself? You mention the existence of "stress points" but, again, there doesn't seem to be anything embedded in the raw data to tell us where the stress points occur.

In short, it seems like there is more information about the signal that is not present in the signal data that could be important in processing the signal data.

As far as the basic peak/valley identification, the current algorithm seems to work just fine -- I'm still not sure what you want to do differently about the "missed" peaks/valleys. My best guess is that the current algorithm "misses" peaks above/valleys below the "average" or "baseline" and that appears to be intentional. The current algorithm also assumes that peaks/valleys will be one data point wide and is not coded to handle cases where the peak/valley consists of two or more consecutive points with the same value. Am I understanding correctly, or is there more that I am missing?