Re: Recommendation for high sample rate receiver?
Hi Mike, thanks for following up on this: A signal with 0.1 microsecond rise time definitely has definitely more than 6 MHz bandwidth :) so that's where my confusion stems from. It will have something upwards of 20 MHz, rule of thumb should be around 100 MHz bandwidths, and that fits nicely with the bare necessary 40 MHz bandwidth for do anything at a 25ns timescale. As said, if you can capture that amount of bandwidth, you can infer the timing – you really do not need 500 MS/s, as far as I can tell from your description of the signal. Then again, there might be complicating factors – extreme dynamic range, for example. Could you tell us more details about your signal? And also, "as accurately as possible" is not a spec; could you say "I need a timing accuracy of X ns, given an SNR of Y dB", so that we could help you there? Best regards, Marcus On Sat, 2020-02-01 at 02:58 -0500, Mike wrote: > Thank you to all who commented. > > The target signal of interest uses pulse modulation where each pulse > is 1 microsecond in duration, with a rise time of less than 0.1 > microsecond and a decay time of less than 0.2 microseconds. The goal > is to identify the start (arrival) of a transmission at each receiver > site as accurately as possible (better than 25 ns). > > Interpolation adds no useful information regarding start time, of > course. Lower sampling rates lose arrival time resolution. > > No affordable SDR supports 500 MS/sec; I'm looking at A/D evaluation > boards with an RF front end. > > > Thanks! > > > > On 1/29/2020 10:34 PM, Kyeong Su Shin wrote: > > To whom it may concern: > > > > Forgot to mention: There is a Wikipedia article, listing SDR > > receivers with various capabilities ( > > https://en.wikipedia.org/wiki/List_of_software-defined_radios ). > > There's also something called OneRadio ( > > http://www.oneradiocorp.com/ ). I saw an actual build of OneRadio, > > and it was pretty impressive (but expensive, of course). > > > > Do not expect these receivers to be well-supported by GNU Radio, > > however. However (I think it is not necessary, but), if you still > > want to get a fast receiver and do not want to roll out your own > > receiver using oscilloscopes or FPGAs, then I guess these > > are possible alternatives. > > > > Regards, > > Kyeong Su Shin > > 보낸 사람: Kyeong Su Shin 대신 Discuss-gnuradio < > > discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org> > > 보낸 날짜: 2020년 1월 30일 목요일 오후 12:10 > > 받는 사람: discuss-gnuradio@gnu.org ; > > mike.nel...@rdss.com > > 제목: Re: Recommendation for high sample rate receiver? > > > > To whom it may concern: > > > > It is already well-discussed, but I would like to add a few points: > > > > -If you absolutely want to have a such receiver (it's pretty > > meaningless, as discussed already, but if you still want to), then > > you can grab a digital oscilloscope or a similar hardware and > > attach a RF frontend to it. You will end up losing some (actually, > > most of) samples, but you cannot run non-trivial data processing > > chains at 500MS/s in real-time with a generic desktop CPU anyway. > > > > -Regarding on why this is pretty meaningless (not using the Nyquist > > criterion or maths, but using intuitions): consider two consecutive > > samples, sampled by your receiver. Since the sampling rate is way > > higher than the bandwidth of the signal, these values are going to > > be nearly identical. There could be a bit of differences in the > > amplitude and the phase, but the differences will be pretty small > > and will be easily washed out by the noise. You cannot expect to > > get reliable TDOA results from that. You will have to use > > more samples to get more reliable results.. or just use a slower > > receiver, anything that satisfies the Nyquist criterion. > > > > -If you know the structure of the transmitted signal (like PRNs in > > GPS), and if you are dealing with CDMA-like signals, then maybe you > > want to review the GPS receiver design principles and apply that to > > your design. Not sure if that's the case, though.. > > > > -Please consider power difference of arrival or phase > > interferometry as alternative methods. > > > > Regards, > > Kyeong Su Shin > > 보낸 사람: Qasim Chaudhari 대신 Discuss- > > gnuradio > > 보낸 날짜: 2020년 1월 30일 목요일 오전 11:05 > > 받는 사람: discuss-gnuradio@gnu.org ; > > mike.nel...@rdss.com > > 제목: Re: Recommendation for high sample rate receiver? > > > > Hi > >A high sample rate for such ns times of arrival resolution is > > impractical. Same holds for high SNR and longer times of > > measurement. GPS and most other high resolution positioning systems > > stitch the information together from the signal time of arrival > > with the carrier phase of arrival. Since carrier frequencies are > > incredibly high, their phase can provide such ns accuracy because > > the phase information is preserved across the downconversion stages > > with sufficient linearity. For this purpos
RE: [EXT] Re: Recommendation for high sample rate receiver?
Your statement " A signal with 0.1 microsecond rise time definitely has definitely more than 6 MHz bandwidth" is not necessarily true. Simple proof: The first 3 components of a 1 Mcycle/sec square wave are: sin(2*pi*1e6*t) + (1/3) sin(2*pi*3*1e6*t) + (1/5) sin(2*pi*5*1e6*t). If you add just the above 3 components, the highest component of the resultant signal is obviously 5 MHz. Its rise time is 0.1 microseconds. Aaron -Original Message- From: Discuss-gnuradio On Behalf Of Müller, Marcus (CEL) Sent: Monday, February 3, 2020 6:18 AM To: mike.nel...@rdss.com; discuss-gnuradio@gnu.org Subject: [EXT] Re: Recommendation for high sample rate receiver? Hi Mike, thanks for following up on this: A signal with 0.1 microsecond rise time definitely has definitely more than 6 MHz bandwidth :) so that's where my confusion stems from. It will have something upwards of 20 MHz, rule of thumb should be around 100 MHz bandwidths, and that fits nicely with the bare necessary 40 MHz bandwidth for do anything at a 25ns timescale. As said, if you can capture that amount of bandwidth, you can infer the timing – you really do not need 500 MS/s, as far as I can tell from your description of the signal. Then again, there might be complicating factors – extreme dynamic range, for example. Could you tell us more details about your signal? And also, "as accurately as possible" is not a spec; could you say "I need a timing accuracy of X ns, given an SNR of Y dB", so that we could help you there? Best regards, Marcus On Sat, 2020-02-01 at 02:58 -0500, Mike wrote: > Thank you to all who commented. > > The target signal of interest uses pulse modulation where each pulse > is 1 microsecond in duration, with a rise time of less than 0.1 > microsecond and a decay time of less than 0.2 microseconds. The goal > is to identify the start (arrival) of a transmission at each receiver > site as accurately as possible (better than 25 ns). > > Interpolation adds no useful information regarding start time, of > course. Lower sampling rates lose arrival time resolution. > > No affordable SDR supports 500 MS/sec; I'm looking at A/D evaluation > boards with an RF front end. > > > Thanks! > > > > On 1/29/2020 10:34 PM, Kyeong Su Shin wrote: > > To whom it may concern: > > > > Forgot to mention: There is a Wikipedia article, listing SDR > > receivers with various capabilities ( > > https://en.wikipedia.org/wiki/List_of_software-defined_radios ). > > There's also something called OneRadio ( > > http://www.oneradiocorp.com/ ). I saw an actual build of OneRadio, > > and it was pretty impressive (but expensive, of course). > > > > Do not expect these receivers to be well-supported by GNU Radio, > > however. However (I think it is not necessary, but), if you still > > want to get a fast receiver and do not want to roll out your own > > receiver using oscilloscopes or FPGAs, then I guess these > > are possible alternatives. > > > > Regards, > > Kyeong Su Shin > > 보낸 사람: Kyeong Su Shin 대신 Discuss-gnuradio < > > discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org> > > 보낸 날짜: 2020년 1월 30일 목요일 오후 12:10 > > 받는 사람: discuss-gnuradio@gnu.org ; > > mike.nel...@rdss.com > > 제목: Re: Recommendation for high sample rate receiver? > > > > To whom it may concern: > > > > It is already well-discussed, but I would like to add a few points: > > > > -If you absolutely want to have a such receiver (it's pretty > > meaningless, as discussed already, but if you still want to), then > > you can grab a digital oscilloscope or a similar hardware and attach > > a RF frontend to it. You will end up losing some (actually, most of) > > samples, but you cannot run non-trivial data processing chains at > > 500MS/s in real-time with a generic desktop CPU anyway. > > > > -Regarding on why this is pretty meaningless (not using the Nyquist > > criterion or maths, but using intuitions): consider two consecutive > > samples, sampled by your receiver. Since the sampling rate is way > > higher than the bandwidth of the signal, these values are going to > > be nearly identical. There could be a bit of differences in the > > amplitude and the phase, but the differences will be pretty small > > and will be easily washed out by the noise. You cannot expect to > > get reliable TDOA results from that. You will have to use > > more samples to get more reliable results.. or just use a slower > > receiver, anything that satisfies the Nyquist criterion. > > > > -If you know the structure of the transmitted signal (like PRNs in > > GPS), and if you are dealing with CDMA-like signals, then maybe you > > want to review the GPS receiver design principles and apply that to > > your design. Not sure if that's the case, though.. > > > > -Please consider power difference of arrival or phase interferometry > > as alternative methods. > > > > Regards, > > Kyeong Su Shin > > 보낸 사람: Qasim Chaudhari 대신 Discuss- > > gnur
Re: Recommendation for high sample rate receiver?
On Sat, Feb 01, 2020 at 02:58:06AM -0500, Mike wrote: > The target signal of interest uses pulse modulation where each pulse is > 1 microsecond in duration, with a rise time of less than 0.1 microsecond > and a decay time of less than 0.2 microseconds. The goal is to identify > the start (arrival) of a transmission at each receiver site as > accurately as possible (better than 25 ns). If this timing is to be derived from a _single_ pulse, this will require a high S/N ratio in order to achieve 25 ns precision, no matter what your sample rate is. > Interpolation adds no useful information regarding start time, of > course. True, it does not provide any new information, but it makes it easier to extract the available info. Assume you have sampled the signal at 10 MHz. Locally interpolating (i.e. upsampling) it with a linear phase polyphase filter will preserve the timing info and allow you to compare the interpolated values for the leading edge with some reference, e.g. half the value reached during the 1 us pulse length. > Lower sampling rates lose arrival time resolution. No they don't. But what could happen is that the filter which limits the bandwidth before sampling isn't linear phase and distorts the waveform. Ciao, -- FA
gr-iqbal->gr-osmosdr->gqrx missing pkgconfig files break gr-3.8 builds
Hello, Without a .pc in gr-iqbal, gr-osmosdr (3.8 branch) will not build as it can't find gr-iqbal. Likewise without a .pc in gr-osmosdr, gqrx will not build as it can't find gr-osmosdr. After creating .pc files for both the above all packages build and gqrx runs fine. I do not understand the logic in removing the pkgconfig files from gr-iqbal and gr-osmosdr upstream packages, as cmake relies on these to find these deps. I have brought this up before and it was dismissed. I am not a developer, just a packager who's life has been made more difficult, can someone please explain why? Thanks, Barry
Re: gr-iqbal->gr-osmosdr->gqrx missing pkgconfig files break gr-3.8 builds
> Without a .pc in gr-iqbal, gr-osmosdr (3.8 branch) will not build as it
> can't find gr-iqbal.
I just had a look at gr-osmosdr-0.1.4.127-3.mga7.src.rpm and this is
not using the official code from the gr3.8 branch of
git.osmocom.org/gr-osmosdr
The code in that repo at absolutely no point will ever look for a pkg
config file.
In 3.8 the modules install 3 cmake specific files :
gnuradio-osmosdrConfig.cmake
gnuradio-osmosdrTargets.cmake
gnuradio-osmosdrTargets-release.cmake
and these contain all the informations needed by cmake to know which
libraries to link and which include directory the add to the include
path and any dependency on other cmake modules.
Theses are also automatically generated by cmake, without the need to
duplicate the information in another file.
If you look at CMakeList for iqbal for instance :
target_include_directories(gnuradio-iqbalance
PRIVATE ${LIBOSMODSP_SEL_INCLUDE_DIRS}
PUBLIC ${Boost_INCLUDE_DIRS}
PUBLIC $
PUBLIC $
)
the PRIVATE / PUBLIC / INTERFACE / ... are all specifiers for cmake to
generate those files properly and include everything needed
automatically.
If this doesn't work for you, either :
- You're not using the right source as pointed out above ...
- Something is broken in the gr-iqbal / gr-osmosdr CMake that makes
it not work properly ( wronge PRIVATE / PUBLIC specifier or something
omitted or something like this )
- Something else in your setup is broken that breaks cmake's module system
In anycase, none of this requires pkg-config files.
Cheers,
Sylvain
