deceiving name of fft_overlap variable

[jerabaul29]

OpenMetBuoy-v2021a/legacy_firmware/firmware/standard_gps_waves_drifter/params.h

Lines 80 to 81 in 8a1256e

	// we use FFT of length 2048; smaller is bad for frequency resolution
	constexpr size_t fft_length {2048};

vs.

OpenMetBuoy-v2021a/legacy_firmware/firmware/standard_gps_waves_drifter/params.h

Lines 88 to 89 in 8a1256e

	// use a 75% overlap in the Welch computation
	constexpr size_t fft_overlap {512};

vs.

OpenMetBuoy-v2021a/legacy_firmware/firmware/standard_gps_waves_drifter/wave_analyzer.cpp

Lines 181 to 183 in 8a1256e

	// prepare for the next segment
	start_current_segment += fft_overlap;
	end_current_segment += fft_overlap;

Note that this well corresponds to a 75% overlap as indicated in the comment of fft_overlap definition, but the fft_overlap name is poorly chosen; really it is the fft_nonoverlap, not the fft_overlap that is being defined (the relation between the two being, fft_nonoverlap = fft_length - fft_overlap). So, while the logics are correct / correspond to the 75% overlap comment, the naming of the variables is very poor / misleading.

Many thanks to @gauteh for pointing this :) . This does not affect the correctness of the computations run, so wont fix for now, but keeping this issue open so that it is visible.