Anyone on this list know anything about coherent de-dispersion
filtering, and how it’s supposed to work?
I’ve had one implemented for years, and still don’t really know whether
it works or not, looking for
clueage about how to test it. Maybe there’s somebody who knows
something about 'em?
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Hi Marcus
I havn’t quiet got my head around coherant dedispersion myself, I use in
coherant. Basically as far as I’m aware it does all the delays in
fourier space. It is generally far superior to the standard incoherant
method but for searching is ineficient as it can not usually be done in
real time across a wide bandwidth.
Hence unless your trying to find a signal at a specific DM a blind
search usually uses incoherant, unless you have a cluster at your
disposal. If you are trying to test if the signal is ther for a specific
object and not sure about your disperser then I suggest folding the
spectral data at a pulse period, you can then find it in a waterfall
plot of your bandpass.
or else you can try and download DSPSR and use something that is known
to work, if you can work out the install.
Regards Bruce
From:
discuss-gnuradio-bounces+bruce.stansby=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+bruce.stansby=removed_email_address@domain.invalid]
on behalf of Marcus D. Leech [[email protected]]
Sent: Thursday, 1 July 2010 8:50 AM
To: GNURadio D.ion List
Subject: [Discuss-gnuradio] Coherent de-dispersion
Anyone on this list know anything about coherent de-dispersion
filtering, and how it’s supposed to work?
I’ve had one implemented for years, and still don’t really know whether
it works or not, looking for
clueage about how to test it. Maybe there’s somebody who knows
something about 'em?
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 07/01/2010 07:28 AM, Bruce Stansby wrote:
Hi Marcus
I havn’t quiet got my head around coherant dedispersion myself, I use in coherant. Basically as far as I’m aware it does all the delays in fourier space. It is generally far superior to the standard incoherant method but for searching is ineficient as it can not usually be done in real time across a wide bandwidth.
Yup, I’m well aware of that 
Hence unless your trying to find a signal at a specific DM a blind search usually uses incoherant, unless you have a cluster at your disposal. If you are trying to test if the signal is ther for a specific object and not sure about your disperser then I suggest folding the spectral data at a pulse period, you can then find it in a waterfall plot of your bandpass.
or else you can try and download DSPSR and use something that is known to work, if you can work out the install.
Regards Bruce
Actually, my frequency-domain coefficient generator is based loosely on
some earlier Swinburne
code, and then I use the Gnu Radio FFT filter block, after turning the
frequency-domain
coefficients into time-domain ones (for some bizarre reason, the Gnu
Radio FFT filter takes
its coefficients in time-domain, rather than frequency domain).
Since I won’t have a live instrument to connect this stuff to for
months (http://www.sbrac.org),
I wondered if anyone had thought of test strategies for testing a
coherent de-disperser prior
to “live” tests using real objects.
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On 07/01/2010 11:31 AM, Tom R. wrote:
Oh, I agree that it’s in the tradition of Gnu Radio filters. It’s just
that after you’ve finished reading
paper after paper about FFT filters for de-dispersion, with everything
being expressed in the
frequency domain, it’s a bit jolting to find that the FFT filter takes
“taps” in the time-domain.
Perhaps “bizarre” was too stong a term
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Thursday, July 01, 2010 11:35:13 am Marcus D. Leech wrote:
Oh, I agree that it’s in the tradition of Gnu Radio filters. It’s just
that after you’ve finished reading
paper after paper about FFT filters for de-dispersion, with everything
being expressed in the
frequency domain, it’s a bit jolting to find that the FFT filter takes
“taps” in the time-domain.
The old way with hardware was a massive filter bank; we have an old
hardware de-dispersion machine here that isn’t working at the moment.
Given that dispersion produces a ‘chirp’ from a pulse, de-dispersion is
essentially de-chirping, and providing programmable delay per band.
But a low DM pulsar shows up very well on a waterfall display.
Or to put it exceptionally bluntly, the frequency domain doesn’t really
exist anyway, as all signals are in the time-domain to begin with. Even
hardware filters act on the time domain signal to produce a frequency
domain result, whether they are lumped constant LC or RC filters or
distributed constant cavities.
But yes I sympathize with your mind-bending there, Marcus. Much like
the mind-bending required when dealing with audio feedback; it doesn’t
seem to make sense that the amount of feedback doesn’t change the
amplitude of the end oscillation, but rather the amount (and phase) of
feedback determines the frequency of the oscillation. And due to the
acoustics of some venues, there is actually a ‘sour’ spot on the volume
level where the feedback is worse, and goes away when the level is
turned up (not down, but up). Counterintuitive, but definitely a real
effect.
Actually, my frequency-domain coefficient generator is based loosely on
some earlier Swinburne
code, and then I use the Gnu Radio FFT filter block, after turning the
frequency-domain
coefficients into time-domain ones (for some bizarre reason, the Gnu
Radio FFT filter takes
its coefficients in time-domain, rather than frequency domain).
(I should probably change the subject, but this is just a quick
interlude and hopefully won’t spawn a long conversation.)
Do you really think that’s bizarre? I always think of filter taps
being naturally expressed in the time domain. But maybe that’s just a
limitation of my background. In the constructor of the fft filter
block we do the FFT to convert them. Since all of our algorithms
return the taps in the time domain, it makes sense to me to handle
both filters the same.
Tom
On Thu, Jul 01, 2010 at 11:35:13AM -0400, Marcus D. Leech wrote:
interlude and hopefully won’t spawn a long conversation.)
Oh, I agree that it’s in the tradition of Gnu Radio filters. It’s just
that after you’ve finished reading
paper after paper about FFT filters for de-dispersion, with everything
being expressed in the
frequency domain, it’s a bit jolting to find that the FFT filter takes
“taps” in the time-domain.Perhaps “bizarre” was too stong a term
It was done that way so that you could swap the FFT based filter
for the dotproduct based filter with no other changes. They take the
same constructor args.
Please feel free to build another block that takes the freq domain
taps if you like, or wrap the existing one in a hier block that does
the conversion of the taps for you.
Eric
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs