Forum: GNU Radio Re: cycle/period detection of a cyclic/periodic transmitter

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3d593de8acbe2510722af740d8668352?d=identicon&s=25 Firas Abbas (Guest)
on 2009-04-22 14:06
(Received via mailing list)
Hi,

> On Wed, 4/22/09, kaleem ahmad <kaleem_str@yahoo.com> wrote:
>
> Thanks Firas,
>
> But I can simply tell that it always transmit a fix packet (with
> bitrate=500kbps) of 1220 micro sec including preamble. It means that
> after every T ms (T is repetition cycle time and can be a fixed
> value from range: 1ms...200ms, I selected 10ms for above given data) it
> transmits a 1220 microsec long signal.
>

If your transmitter works for 1220 microsec (1.22 msec) and it repeat
the transmission (for example) every 10 msec, then your calculations is
wrong.

If you want to sense the time of a signal, you have to run your FFT
frames with a rate at least equal to required minimum signal time. For
example in your case, If the signal to be detected has a 1.22 msec then
you have to collect the data at rate of 500K (USRP decimation =128). The
512 FFT length will be 1.024 msec. This means (after using appropriate
spectrum threshold value) you need to count number of FFT frames that
the desired signal is exist in it.

So, back to our example (signal with duty 1.22msec and repetition of
10msec), if data rate is 500k, and you used 512 FFT points, then you
will see this signal once in every 10 FFT frames. The resolution will be
1.024 msec.

However, if you received the signal with data rate of 8MHz (USRP
decimation =8), and you computed 512 FFT points then your resolution
will be 64 usec, which means that the signal will be ON for 19 FFT
frames and OFF for 137 FFT frames.

Is that clear ?



Best Regards,

Firas
895162eb8f65673b6eefca9e7e8acf62?d=identicon&s=25 Kaleem Ahmad (kaleem)
on 2009-04-22 14:21
(Received via mailing list)
Thanks Firas,

It is clear and I will implement it and will come back soon hopefully
with
successfull results.

Best Regards


Firas A. wrote:
>> after every T ms (T is repetition cycle time and can be a fixed
> collect the data at rate of 500K (USRP decimation =128). The 512 FFT
> decimation =8), and you computed 512 FFT points then your resolution will
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context:
http://www.nabble.com/cycle-period-detection-of-a-...
Sent from the GnuRadio mailing list archive at Nabble.com.
895162eb8f65673b6eefca9e7e8acf62?d=identicon&s=25 Kaleem Ahmad (kaleem)
on 2009-05-25 14:15
(Received via mailing list)
Dear All,

A few weeks ago I was involved in a discussion about calculating the
cycle
time of an unknown system present in the area by sensing the spectrum
with
the help of RFX2400+USRP1 system. For details you may have a look on
previous mails on this thread.

As Firas suggested to choose a decimation factor with respect to duty
cycle
of the cyclic system. I implemented it in this way but I am facing two
problems:

1- I am using following formula to calculate the cycle time:

if

ADC_rate = 64MHz, D=decimation rate, fft_size, count= total no. of
fft_scans
where signal is not present

Then following would give me the value of cycle time:

[1/(ADC_rate/D)]*fft_size*count*1e3 ---> where [1/(ADC_rate/D)] simply
gives
the time resolution or time gap between two points in fft bin. 1e3 for
conversion in ms.

with D=128, fft_size=512, I scanned the spectrum for more than one times
and
stored the results in an array, then I choose maximum occerence in that
array as 'count' in above formula e.g.

for 200ms cycle time my array look like [27, 200, 27, 27, 27, 27, 276,
27],
here count = 27, other values are actually some errors

for 100ms cycle time my array look like [13, 13, 87, 13, 13, 13, 13,
167],
here count = 13, other values are actually some errors

for 50ms cycle time my array look like [6, 6, 6, 6, 6, 6, 6, 6], here
count
= 6.

From this array with multiple scans I was able to see that some cyclic
behaviour is correctly detected. BUT when I put all values in above
mentioned formula then I found that to get exact value of cycle time I
must
multiply my answer with a 'factor' ranging from 7-8 (some times 7.25, or
7.4, or 7.5 etc). But this 'factor' is not a fixed value and variation
in
its value depend on the cycle time. So final formula becomes

[1/(ADC_rate/D)]*fft_size*count * factor *1.e3  --->  The value of
factor is
changing on following pattern:

for 200ms cycle time factor ~ 7.25 would give me exact answer
for 150ms cycle time factor ~ 7.35 would give me exact answer
for 100ms cycle time factor ~ 7.5 would give me exact answer
for 50ms cycle time factor ~ 8 would give me exact answer

I cant understand what this factor is and where it is comming from. Is
there
any processing in USRP which I am forgetting? Can someone help me to
figureout this factor.

2-My second problem is that, I am able to detect cycle time for any duty
cycle with the help of 128, and 256 decimation rates , but with any
other
decimation rate my answers are quite random and I cant get a cyclic
answer
in my above mentioned array. Or simply you can say as it was looking
from
theretical side that for any specific decimation rate I should get a
cyclic
answer but the only thing which would change was the no. of detected and
undetected scans. But its not happening in this way. e.g with any other
decimation rate except 128, 256, I am getting answer like follows:

for 200ms cycle time my array look like [20, 2, 187, 17, 87, 65, 13,
167],
which dont provide me any clue. Similarly for any other cycle time I am
getting random values.

Is there any thing wrong with selection of decimation rate? can some one
help me to figure out where I am doing wrong.

Thanks and Best Regards


Firas A. wrote:
>> after every T ms (T is repetition cycle time and can be a fixed
> collect the data at rate of 500K (USRP decimation =128). The 512 FFT
> decimation =8), and you computed 512 FFT points then your resolution will
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context:
http://www.nabble.com/cycle-period-detection-of-a-...
Sent from the GnuRadio mailing list archive at Nabble.com.
This topic is locked and can not be replied to.