Skip to content

Conversation

yZenox
Copy link

@yZenox yZenox commented Aug 21, 2025

The signal data in the first bins behaves unusual / non physical. This affects smoothing and differentiation for the Raman retrieval methods. So the first 10 bins are set equal to the value at the 10th bin. This is done for 532 and 1064nm. For 355nm this might be beneficial as well.

@yZenox yZenox closed this Aug 21, 2025
@yZenox yZenox reopened this Aug 21, 2025
@HolgerPollyNet
Copy link
Collaborator

Hi @yZenox , your "patch" has severe implication for all lidars. Also I think the statement that the first 10 bins are unphysical is not valid. THus, we need to disucss about it. Currently I would not like to merge it in dev.

@HolgerPollyNet
Copy link
Collaborator

@ulysses78 @martin-rdz What do you think? I guess we cannot do it in such a hard coded way, right? Maybe to use the config file instead? E.g. starting with range bin 262 and then allocating height 41.25 m to it?

@ulysses78
Copy link
Collaborator

Yes, those cutoffs definitly have to be added to the config file for the single polly-device, not in the python file itself.

Nathan Skupin added 4 commits October 6, 2025 09:59
…ut partial bins. "slope" parameter should be tested. This replaces the default "smooth" function. Behaviour should get tested besides the pollyFernald module.
… data. flag387OC/flag607OC is missing. Much repetetive copy-pasted code, which eventually should get replaced by loops.
…ut files. The run is splitted into calibrated and uncalibrated mode (=usage of mean lidar constants). The parameter should be put into config file. Run_picasso_test can probably be replaced by an extended picassoProcTodolist.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants