Hi All,
As you can read previous posts on this thread and can know from that I am
trying to detect the cycle time of a cyclic data transmitter by sensing the
channel.
>From discussion on this thread I understood in the following way:
USRP RF sampling rate----After decimation with D=256-------Second level
decimation with gr.fir_filter_ccf
64MHz 64MHz/256=250kHz
gr.fir_filter_ccf(125, filter_coeff) = 2k
it finally gives me 2ksample/sec-> sample time=500micro sec, which means if
I take 512 fft, I will get a time resolution of 500micro sec * 512 = 256 ms,
with 500 micr sec distance between consective fft bins.
Now suppose a cyclic data transmisster is transmitting with 10ms cycle time,
i.e. after every 10ms there is a signal to be detected by my USRP system.
>From above calculation 10ms = 500 micro sec * 20....It means that in my 512
FFT bin after every 20 bins there should be a peak (Am I correct??? Please
note that there is only one transmitter in the area, no other source of
interference)
In similar way if I choose 75, 50 or 25 for second level decimation by
gr.fir_filter_ccf, then I should get a peak after every 33.33, 50, and 100
bins respectively, as explained below.
gr.fir_filter_ccf(75, filter_coeff) = 3.33k -> 512 FFT resulution = 300 micr
sec -> 10ms = 33.33 bins
gr.fir_filter_ccf(50, filter_coeff) = 5k -> 512 FFT resulution = 200 micr
sec -> 10ms = 50 bins
gr.fir_filter_ccf(25, filter_coeff) = 10k -> 512 FFT resulution = 100 micr
sec -> 10ms = 100 bins
But unfortunately I am unable to get these results, for example with
gr.fir_filter_ccf(125, filter_coeff) I got following results, for few
consective scans:
To understand these results please not that there are two columns, first is
the power level of the peak and the second is the index of it in 512 FFT bin
(Only peaks are displayed, and all values with smaller than a predefined
threshold value are discarded).
Amplitude index_in_512_FFT_array
-----------------------------
Scan 1
18.6298904419 74
19.0259571075 75
18.2597370148 87
19.7134284973 88
19.5969486237 101
19.1021556854 114
18.6094284058 149
19.4388046265 161
19.6380805969 162
20.0642223358 174
19.3017559052 175
18.2230033875 187
-----------------------------------------------------------
scan 2
21.5638103485 74
21.9744911194 112
23.012506485 125
21.8563117981 126
21.370016098 137
23.2401256561 138
21.655248642 139
22.3047294617 151
-----------------------------------------------------------
scan 3
22.1015739441 139
22.8458404541 151
22.8282699585 152
23.0492572784 163
23.7630844116 164
22.387878418 165
22.9494457245 176
22.7077884674 177
-----------------------------------------------------------
scan 4
19.5143814087 2
19.4494800568 15
20.1066360474 65
20.4122695923 78
21.3697834015 172
20.4298725128 173
21.0880489349 185
20.013879776 186
-----------------------------------------------------------
scan 5
19.0756263733 112
19.4551143646 153
19.4751834869 163
19.4504451752 165
20.5185012817 166
21.0303726196 175
21.0539245605 176
19.1459999084 177
19.1931247711 178
20.0467262268 188
19.1717777252 189
-----------------------------------
So you can see that from FFT bin it is impossible to interpret what is the
cycle time, when I used 75/50/25 in fir_filter_ccf or if I used FFT lenght
different from 512, it was still meaningless and I got similar results.
If you like to have a look at my code then it is very short and is attached.
If some of you can specially have a look on at least the filter
coeefficients and entire decimation process in this code then it will be
great help for me, because I am not very good in filter design.
Please suggest me what/where is the problem and how can I solve it.
Any suggestion to calculate this cycle time in a different way will also be
welcomed.
Thanks and Best Regards
Kaleem
http://www.nabble.com/file/p23156375/Cycle_sensing.py Cycle_sensing.py
--
View this message in context:
http://www.nabble.com/Can-threading-disturb-sensing-continuety-tp22598748p23156375.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
