[daip] SNR calculations in FRING
Z.-Q. Shen
zshen at perseus.vsop.isas.ac.jp
Thu Aug 1 20:33:06 EDT 2002
Hi Leonia,
It is still not that clear to me about the SNR calculation in FRING.
Maybe I didn't state clearly in my previous email. What I said about
the ratio is that between the presumed peak in the delay-rate domain
and the RMS thermal noise. The peak's amplitude can be measured out
in any case. But what about the noise? It is clear to me that the RMS
thermal noise should be inversely proportional to the square root of
the product of integration time and the bandwidth. But we want to
know how this is done exactly in FRING.
Also, could you please tell me the answer to my second question,
repeated below:
>There are essentially two different FRING modes in FRING. One
>with aparm(5)=0 will do fringe fitting on each IF independently,
>the other with aparm(5)>1 will solve for multi-band solutions.
>No matter what choice we use, the noise estimation will always
>assume a maximum bandwidth, i.e., the whole observing band.
>Is this right?
I believe what you said about Ketan Desai's work is related to
the KRING not FRING, right? For KRING, we found it behaved
sometimes strangely. We will report to you later.
Also, we would appreciated it very much if you can point out to
us any relevant memos. So far, we have read Ketan's AIPS Memo 101
about the SNR in KRING, but have no any detailed information on how
FRING deals with the SNR.
Thanks,
Eric
>You wrote:
>
> >And the noise is the RMS thermal
> >noise determined by the data integration time and the maximum
> >recording bandwidth. Then SNR is simply a ratio between both.
>
>SNR may be inversely proportional to the square root of the
>product of both but not their ratio.
>
> >The baseline stacking (if applied) could reduce the noise to
> >eventually increase the SNR measured for each datum. Is this
> >exactly what written in the FRING source code?
>
>Not exactly. The fringe rate esimation is carried out at the FRING
>having amplitude clipped before the estimation. This makes the
>estimation of the errors more complicate.
>Desai Ketan spent a time to make a beter math analysis of the problem and
>implemented his ideas at the FRING's code.
>
>There are relevant memos at the AIPS and VLBA serios about that and about
>stacking
>
>Leonia
More information about the Daip
mailing list