Raw data

[joe045]

Hei @jerabaul29!

Here is a pdf with the raw data for three different days.

• 22.10.2021 is when everything was working
• 28.01.2022 is after extraIMU0 broke down
• 28.09.2022 is with the new RPI and Arduino, and only the main IMU working

To the right is the raw value, and to the left is the fluctuating value (subtracted the mean).

The y-labels display the value, and the x-labels display the date.

I realized that the main IMU has yaw range (-180,180) while the extra IMUs have yaw range (0,360). I don't think this is considered in the post-processing yet. Which range should I use?

Raw_data.pdf

[jerabaul29]

Looks good. I think in order to really "see what happens", it may be useful to also show plots focusing on shorter segments of data, for example, 60 seconds or so - when looking at long segments of data, in the end it is mostly only the general distribution width of the data that is visible :) .

There are always some "issues" with angles, as there is no reason why [0;360] would be more natural than [-180;180] or the opposite, so as you see now, it is quite common to meet a mix of both depending on the exact sensor used :) . I think the best solution may be that you decide what convention you want to use, and then to convert all data to this convention. I think (but you should double check / validate etc) that the conversion back and forth between these conventions is not too complex: some form of (not tested, just to illustrate the idea):

def plus_minus_180_to_0_360(pm180):
    if pm_180 < 0:
        return pm_180 + 360
    else:
        return pm_180

and something similar in the "opposite direction" :) .

[joe045]

Good point, here are some 60-second time series for the same dates.

I will try to change to the (0,360) range.

The elevation fluctuation has very different scales from before and after changing the processing unit. Also, the radar and ug2 have similar fluctuations with an opposite sign with the old processing unit. Should I try to change the sign of the radar elevation for the old processing unit?

60s_raw_data.pdf

[jerabaul29]

This is easier to understand / read :) .

A small note: the difference in fluctuations may come from either / both / any "combination" of:

• i) differences between the settings / calibration / hardware assembly of the arduino shield, sensors, raspberry pi code including the scaling parameters, etc as these get swapped: this is what you want to find out, and this needs to be "corrected" if this happens
• ii) differences in the actual conditions at sea: rough sea / calm sea / sailing straight / turning; this is not something you should "correct" for of course :)

From just looking at the pdf, it is a bit hard to say if i) or ii) is what is happening; maybe you could spend a bit of time "playing around / looking around" at the data by having interactive figures, moving around what time interval you look at, etc? :)

Also, looking at yaw is probably not interesting / relevant, as none of the magnetometers got calibrated in situ, so being located on a large metallic ship, the yaw information is probably useless :) .

It is a bit hard for me to get an idea about what is looking good or less good just by looking at the plot, but I think this will be a good support for the next discussion, we will certainly manage to find out of this when discussing while you have the data interactively available at the same time :) .

[joe045]

The unrealistic radar values are definitely fixed by changing the sign of the radar fluctuations! Since the fluctuations are so small for the new processing system, it does not change the wave height for the new system. But studying very short timeseries shows that it should also be changed for the new unit!

Is there any point in trying to scale the fluctuations for the new processing unit, or are we happy that the wave heights are realistic?

Raw_data_fix.pdf

[jerabaul29]

Ok, so the sign for the radar signal acquisition on the "new" system was wrong if I understand it well? Good you caught it :) .

Regarding the scaling: do you mean that you think that the scaling "ADC reading -> Radar / UG value" is wrong? If so yes, I think it needs to be corrected. We can discuss this in more details tomorrow :) .

[joe045]

The sign for the "old" system was also wrong, and had a larger impact on the wave height than the "new" system, because the fluctuations are larger for the first system. Lets discuss it more tomorrow :)

[jerabaul29]

Ok. Regarding the "fluctuations are larger" thing: do you think this is due to different wave regimes in different oceans (that would be perfectly fine, and maybe the fluctuations could be a few 10s of % smaller typically, maybe a factor 2), or do you think this comes from some calibration parameters that are not consistent (that would be a problem that would need to be fixed). I am sorry this is so confusing, I (largely) designed the systems but did not really build / calibrate these individual systems myself, maybe we should ask Fabian if in doubts, he is the one who really did the calibration.

[joe045]

If you look at the first slide of raw_data_fix.pdf with 30min mean values, you can already see that the elevation fluctuation of the "old" system is larger than for the "new" system. Slide 2 shows 60 seconds of the "old" system in the two upper panels, and the new system in the lower panel (same days as mentioned in the first comment). The sign of the radar fluctuation has been changed from left to right. The "old" system elevation fluctuation ranges [-3,3] but for the "new" system it ranges [-0.05,0.125]. These ranges are the same for several days, not just these three.

Raw_data_fix.pdf

[jerabaul29]

Ok, these are the "elevation averaged over a day", right? A few thoughts:

• there may be some offset values in the value logged, this is not a big deal; all we are interested is the waves, ie the relative changes in elevation; it is not a problem that there is an offset by ~10m (the height of the sensor over the sea at rest), or ~0m (if this offset is removed)
• similarly, the "fluctuations in the mean level reported" may actually be quite a bit different between different sailing conditions (if sailing against the wind in heavy sea, depending on the wind / wave / ship relative directions, the ship may be tilted in a quite different way, and the offset may be quite different; by contrast, if just sailing "with the wind" in nice stable conditions, the mean offset may be very constant for quite a while)
• however, what is important is to make sure that the dynamic range of the sensor, ie the relative variation in the elevation measured, is correct, as this is what influences the measurement of the SWH. It is clear from your picture that between the new and the old system, one has removed the "absolute offset" corresponding to the distance to the water, and the other not or not completely. I do not think this is a problem (adding a constant offset does not change the SWH). But this is what is not clear for me: are both systems correctly set up / calibrated, so that the dynamic range of the measurements (which is what influences the SWH) is correct in both cases?

It will be good to talk tomorrow, this is easier to discuss in a meeting than explain through writing :) .

[joe045]

Thanks for the input today Jean! You were right: the new system is only considering the z-position of the IMU, and are not dependent on the elevation from the radar probes.

The first slide of the pdf shows that the elevation fluctuations are noise for several (all) days for the new system. The second slide shows that (z-position minus elevation) only depends on the z-position for the new system, but not for the old system.

Is it still interesting to include the new system in the Master thesis @lahole? In that case, should I separate the analysis of the old system from the new system? I guess the new system is behaving like a drifter now?:)

Diff_between_old_and_new_system.pdf

[jerabaul29]

Thanks for the update. Yes, then it means something was wrong when the system got switched. As you say, the system after the switch is "just" using the whole ship as a buoy, so it is measuring the ship motion, which is a transfer function * the wave spectrum - so not so surprising it roughly reproduces the wave motion, but the transfer function of the ship is likely not trivial.

I think that you can mention this in the thesis, but it is better to focus on the data from the system before the hardware switch was performed then.