[Top][All Lists]

## Re: [EXT] Re: Recommendation for high sample rate receiver?

 From: CEL Subject: Re: [EXT] Re: Recommendation for high sample rate receiver? Date: Tue, 4 Feb 2020 12:09:28 +0000

```Oh you're of course right :)
My rule of thumb was "7 to 9 times the fundamental frequency in
bandwidth for reliable edges".

Cheers,
Marcus

On Mon, 2020-02-03 at 14:05 +0000, Chesir, Aaron M. wrote:
> 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-----
> Müller, Marcus (CEL)
> Sent: Monday, February 3, 2020 6:18 AM
> 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
> > 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 (
> > > There's also something called OneRadio (
> > > http://www.oneradiocorp.com/ ). I saw an actual build of
> > > 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
> > > <
> > > 보낸 날짜: 2020년 1월 30일 목요일 오후 12:10
> > > 제목: 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 <address@hidden> 대신 Discuss-
> > > 보낸 날짜: 2020년 1월 30일 목요일 오전 11:05
> > > 제목: 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 purpose, the algorithms also
> > > need to determine the integer number of arriving wavelengths.
> > >
> > > Cheers,
> > > Qasim
```