Recently I have noticed some gaps in the retrieved horizontal wind speed and wind direction data (derived from getWindProperties5Beam, using the single_dbs method), while original Windcube data was complete (and with radial_wind_status=1 for at least part of the range gates).
What I Did
In the calcHorWindComp_single_dbs module I noticed that the number of timestamps in compV is much less than compU (and less than compVN and compVS), for those period with gaps.
When looking at the timestamps of compVN and compVS I got suspicious on this “self.meanTimeNon90” parameter (which defines a mean timestamp for each DBS scan), and looked at dataOperator.py in which this time is constructed. In there I found one "data.elevation != 90" expression, which assumes the vertical beam is always perfectly at 90 degree, which is not the case (it can be 89.99 etc, and apparantly this happened more often recently). In many parts of the lidarwind code this is taken care of by adding a ".round(1)" (to both elevation and azimuth values), but not here. So I have added the .round(1) to the line that starts with "Index_new_scan".
Description
Recently I have noticed some gaps in the retrieved horizontal wind speed and wind direction data (derived from getWindProperties5Beam, using the single_dbs method), while original Windcube data was complete (and with radial_wind_status=1 for at least part of the range gates).
What I Did
In the calcHorWindComp_single_dbs module I noticed that the number of timestamps in compV is much less than compU (and less than compVN and compVS), for those period with gaps.
When looking at the timestamps of compVN and compVS I got suspicious on this “self.meanTimeNon90” parameter (which defines a mean timestamp for each DBS scan), and looked at dataOperator.py in which this time is constructed. In there I found one "data.elevation != 90" expression, which assumes the vertical beam is always perfectly at 90 degree, which is not the case (it can be 89.99 etc, and apparantly this happened more often recently). In many parts of the lidarwind code this is taken care of by adding a ".round(1)" (to both elevation and azimuth values), but not here. So I have added the .round(1) to the line that starts with "Index_new_scan".