Opened 10 years ago

Last modified 10 years ago

#373 new defect

Possible problem with ROPP spectral tools

Reported by: Ian Culverwell Owned by: Ian Culverwell
Priority: normal Milestone: Whenever
Component: ropp_pp Version: 7.1
Keywords: Cc:

Description

Estel Cardellach (IEEC) writes:

I have been playing with ROPP spectral tools, checking if it's a suitable way
for us to proceed with the reflection processing. As you might know, part of our
SVM analysis is based on radio holographic images.

I have found several differences between the radio-holograms generated by ropp
and those we have been generating. Some of them are not relevant, but another
one could be relevant. I don't know to which extent the spectral analysis is
used in the normal processing chain, or if it is just a tool for general
visualization, etc.

I attach three plots as examples. All generated from the same RO case, 1 of them
is IEEC radio-holographic analysis (atmPhs....png). Another one is ropp original
analysis (note however, that we plot them using a different tool, because we
don't have IDL license):  orig_ROanalysis...png. The third one is a modification
I made in the ropp tool (ROanalys...png).

The non-relevant differences between our approach and original ropp approach
are: 0) we un-aliase the reflected branch below -25 Hz (irrelevant) 1) ropp
re-normalizes each slice of the radio-hologram. For this reason the final noise
level (no signal) is all very high compared with our approach (irrelevant) 2)
ropp "stops" the signal (counter-rotates) with a model (climatological?), while
we counter-rotate or stop the signal by means of the smoothed version of the
excess-phase. For this reason our plot shows the maximum power around zero,
without large "excursions" (ropp excursions are due to differences between the
data and the model used to stop it). Irrelevant.

However, there is another difference, which I believe it's relevant (if this
spectral analysis is used later on): 3) the reflected branch (as it would happen
with atmospheric multipath) has symmetric features in ropp analysis, while it's
a-symmetric in our approach. Our a-symmetry indicates that it's a phasor
rotating w.r.t.  the direct radio-signal, while symmetric approaches would
indicate modulations rather than phasors. I understand that atmospheric
multi-path should also be matter of phasors, as reflections are.

I have been looking at ropp code to find the reason of this difference.  I found
that the FFT is applied to the exp(imaginary*stopped_phases), but it does not
account for the SNR variations. We've modified ropp to include the SNR
variations in the FFT, and then we get the third plot, where now the reflected
branch is asymmetric (to positive frequencies probably because of the sign of
the stopped signal, etc...).

If you think this could be relevant for other processing steps, we can discuss
this later this week. Otherwise, if this is not used at all, then it's fine (I
will just use the modified version).

Thank you,

Estel

I'm not competent to judge whether ROPP should be changed in the way Estel suggests. To discussed at ROPP GG or PT meeting.

Attachments (3)

atmPhs_C005.2009.318.23.50.G23_2009.2650_nc_freq.dat.png (82.6 KB ) - added by Ian Culverwell 10 years ago.
orig_ROanalysis_dt_L1.dat.png (139.9 KB ) - added by Ian Culverwell 10 years ago.
ROanalysis_dt_L1.dat.png (144.9 KB ) - added by Ian Culverwell 10 years ago.

Download all attachments as: .zip

Change history (5)

by Ian Culverwell, 10 years ago

by Ian Culverwell, 10 years ago

Attachment: ROanalysis_dt_L1.dat.png added

comment:1 by Ian Culverwell, 10 years ago

Estel adds:

Perhaps it would be enough to add a comment on the header part, or just before
the construction of the complex field, so the user is aware of it. Something
like: "For full spectral analysis the time series of the SNR should also be
included. This version does not include it".

comment:2 by Ian Culverwell, 10 years ago

Discussed at ROPP GG4 on 29/7/14. Nobody had any strong objections to correcting it as Estel suggests. I agreed to look into the origin of this plotting code - HW or MG.

Note: See TracTickets for help on using tickets.