Can threading disturb sensing continuety

GNU Radio
1

Hello every one,

I am using USRP1 with RFX2400 daughter card.

I have a system (any state of the art system, let say Atmel’s narroband
FSK
which works in 2.4 GHz band) transmitting a fixed packet cyclically (let
say
cycle time = T ms).

I want to use USRP system to sense the spectrum and calculate (or guess)
the
cycle time of this FSK system, and to do this I have following idea:

I am using fftsink2.py to sense the spectrum with FFT = 512 at a fixed
center frequency (which must be exactly same as FSK system). Then I set
the
decimation rate = 160 , hence getting B = 400 kHz (FSK’s B = 800 kHz).
USRP
start scanning the spectrum and in each scan it come up with 512 bins
and I
compare the max(of 512 bins) with a predefined threshold energy level.
When
I find this max energy above my predefined threshold value, I suppose
FSK is
detected, I save this number and start counting the number of scans
which do
not detect the FSK system (lets call it empty scan). After ‘n’ empty
scans
there is again a scan with FSK detection. In this way between two FSK
detected scans I calculate the value of ‘n’ empty scans. Now I already
now
that one 512 bin scan take ‘K micrseconds’, so I simply calculate the
cycle
time in the following way:

cycle tile = K(time for one scan) * n (no. of empty scans between two
detected scans)

BUT IT IS NOT WORKING!!!

If ‘p’ stands for peak (the scan which detect the FSK system), and dots
represent empty scans, then I was expecting an output as follows:

----n----< >-----n—< [all n’s should be equal
because cycle time is fixed]
p . . . . . . p . . . . . .p . . . . . . p . . . . . . p

mean that after running for long time I would get the value of n (n=6 in
above example scenerio), the value of n would be almost same between any
two
peaks as shown in above scenerio. BUT I get following results:

----n—< > n < >---------n----------< [all n’s are not
equal???]
p…p…p…p…p…p…p…p…p…

Means that there is no consistency between the value of n between
different
peaks.

*POSSIBLE REASONING: I guessed that one possible reason can be that
there
are multiple threads and the scan process is not really continues and
because of this some times the FSK system is not detected (because when
the
FSK system transmits the scanning thread is not executing??? Is it
possible)which makes some p’s to disappear and hence leaving the length
of
intervals between different p’s (value of n) unequal.???

Now I want your suggestions:

1- Is the thread sharing time so significant that above given reasoning
(*POSSIBLE REASONING) has some worth.
2- What other possiblitities can be there
3- Can you suggest some different way to solve this problem, The problem
is
simply to calculate the cycle time of some system which is already
working
in the environment

Thaks in advance and Best Regards

–
View this message in context:
http://www.nabble.com/Can-threading-disturb-sensing-continuety-tp22598748p22598748.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

kaleem ahmad wrote:

3- Can you suggest some different way to solve this problem, The problem is
simply to calculate the cycle time of some system which is already working
in the environment

Since your unknown FSK signal has a regular cycle time, it should be
relatively easy to detect. For example, if your signal has a 1 ms
cycle time, the low frequency spectrum should exhibit a large spike
at 1 KHz. It seems that all you would need is an fft that covers
the range of frequencies that correspond to your possible cycle
times.

@(^.^)@ Ed

3

Thanks Ed,

ADC sampling rate = 64MHz
it gives resulution time = 1/64MHz = 156 ns
if we choose N=512 for FFT then total observation time for one scan(one
complete FFT) is = 156ns x 512 = 8 micro sec
if the maximum possible (expected) cycle time is 200ms then:
it needs 200ms/8microsec = 2500 continues FFT scans to cover the range
of
frequencies that correspond to 200ms cycle time.

Is above calculation correct?

The other possibility to increase the observation time is to increase
the
FFT size, but to cover entire 200ms would need 200ms/1/64MHz = 12800000

FFT size (Which is not possible! Is it ???)

Now please comment if my above calculations are correct or not and
secondaly
if my calculations are correct then how can I process (using GNURadio)
2500
cosective FFT’s (with surety that no FFT in between these 2500 FFT’s is
missing due to slow processing or thread switching) to find two peaks in
a
single array (availability of two peaks will give me the oppertunity to
calculate the time distance between them).

Thanks and Best Regards

Ed Criscuolo-2 wrote:

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
View this message in context:
http://www.nabble.com/Can-threading-disturb-sensing-continuety-tp22598748p22620394.html
Sent from the GnuRadio mailing list archive at Nabble.com.

4

Thank Brian,

Can you give some hint, what do mean ??? I mean a little idea what do
you
want to say?

Best Regards

Brian P. wrote:

if the maximum possible (expected) cycle time is 200ms then:
secondaly
phases.
Discuss-gnuradio Info Page

–
View this message in context:
http://www.nabble.com/Can-threading-disturb-sensing-continuety-tp22598748p22621780.html
Sent from the GnuRadio mailing list archive at Nabble.com.

5

On Fri, Mar 20, 2009 at 11:30 AM, kaleem ahmad [email protected]
wrote:

Thank Brian,

Can you give some hint, what do mean ??? I mean a little idea what do you
want to say?

FSK is all about delta phase shifts. If a mark is a + frequency, and
a space is a - frequency (or vice versa, your choice), then I would
think it would be easy to keep track of how large the deltas between
phases were and when they happened.

Since you’re expecting random data, you should be able to average some
information and - voila; autobaud.

Right? What do you think? I don’t want to detract you from your FFT
algorithm if you feel that is better suited. I’ve never done autobaud
before, so this was just a random thought.

Good luck.

Brian

6

On Fri, Mar 20, 2009 at 10:11 AM, Brian P. [email protected]
wrote:

FSK is all about delta phase shifts. If a mark is a + frequency, and
a space is a - frequency (or vice versa, your choice), then I would
think it would be easy to keep track of how large the deltas between
phases were and when they happened.

A common, non-coherent method for FSK demodulation and baud rate
detection is to multiply each succeeding sample by the complex
conjugate of the preceding sample, then take the phase of the product.
This turns the sample series into baseband “level” shifts. If you
are at zero IF, then the sample stream will be roughly symmetrical
about zero (frequency offsets are turned into DC offsets, though).
From here you can use zero crossings to estimate baud rate and
integration between transitions to improve noise performance. The
success of this technique relies on sufficient zero crossing density,
and has a higher bit error rate than coherent detection and
demodulation.

GNU Radio has a block, gr.quadrature_demod_cf, that does the first
portion of this, taking a complex baseband stream, doing the conjugate
multiply and arctan, and outputting a float stream of demodulated
samples. An example is in gr-pager, where the FLEX pager protocol’s
4-level FSK is first processed by it.

Johnathan

7

On Fri, Mar 20, 2009 at 9:34 AM, kaleem ahmad [email protected]
wrote:

single array (availability of two peaks will give me the oppertunity to
calculate the time distance between them).

It sounds like you’re trying to do autobaud for an unknown FSK system

  • but using the frequency domain to do this instead of the time domain
    phases.

I’d recommend thinking of an algorithm in the time domain that would
suit your needs.

Brian

8

On Fri, Mar 20, 2009 at 1:27 PM, Johnathan C.
[email protected] wrote:

demodulation.
Assuming an FSK system with unknown frequency separation and baudrate,
is the above algorithm robust enough to determine said parameters to
then pass along to a coherent demodulator to achieve a better BER?

I would assume yes - since you’re just taking a quick guess/estimate
and letting the coherent demodulator actually timetrack, figure out
the bits, etc.

Brian

9

kaleem ahmad wrote:

Is above calculation correct?
As Firas already noted, you should be using the decimated sample rate
NOT the ADC rate.

The other possibility to increase the observation time is to increase the
FFT size, but to cover entire 200ms would need 200ms/1/64MHz = 12800000 =
FFT size (Which is not possible! Is it ???)

There’s no need to go that big. The problem is that you are sampling
too high for the cycle time you’re looking for.

As an example, if the cycle time will be between 1 and 200 ms, this
corresponds to a frequency range of 1KHz to 5 Hz. So you only need a
minimum sample rate of 2 K-samples/sec. Let’s use 3 so we have some
margin. Now, simply take your high-rate data stream, run it through
a 1.5 KHz low-pass filter (for anti-aliasing) and downsample the data
to a 3 Ksample/sec rate. A 512 bin FFT now has a resolution of around
5 Hz per bin.

@(^.^)@ Ed

10

On Fri, Mar 20, 2009 at 10:33 AM, Brian P. [email protected]
wrote:

Assuming an FSK system with unknown frequency separation and baudrate,
is the above algorithm robust enough to determine said parameters to
then pass along to a coherent demodulator to achieve a better BER?

Yes, though perhaps not in low SNR situations.

Johnathan

11

Thanks for all these replies,

The problem is my investigation about cycle time is not restricted to
FSK,
I just gave the example of FSK system. I would like to calculate the
cycle
time of any system (ZigBee, FSK, CSS etc) present in the area. My target
is
to sense as much systems as possible and then calculate the cycle time
of
that.

Best Regards

Brian P. wrote:

integration between transitions to improve noise performance. Â The
the bits, etc.

Brian

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
View this message in context:
http://www.nabble.com/Can-threading-disturb-sensing-continuety-tp22598748p22661057.html
Sent from the GnuRadio mailing list archive at Nabble.com.

12

Hi,

I have one more confusion about this sampling rate of USRP.

At FPGA level it is 64MSps and when we decimate (D = 4…256), the
sampling
rate is reduced to 64MSps/D. Now I am confused that if the actual
sampling
rate of USRP is changed from 64MSps to the new decimated sampling rate
or
the USRP is still sampling at 64MSps and only internal sampling rate
(i.e
just for channel selection) is changed.

Addition to this as maximum value of decimation rate is 256 so sampling
rate
can be reduced to 250ks/s, if I want to set it to 3ksps then how it is
possible.

Best Regards

Ed Criscuolo-2 wrote:

if the maximum possible (expected) cycle time is 200ms then:
FFT size, but to cover entire 200ms would need 200ms/1/64MHz = 12800000 =
to a 3 Ksample/sec rate. A 512 bin FFT now has a resolution of around

–
View this message in context:
http://www.nabble.com/Can-threading-disturb-sensing-continuety-tp22598748p22661896.html
Sent from the GnuRadio mailing list archive at Nabble.com.

13

Thanks Brian,

By cycle time I mean that a transmitter (e.g. FSK, ZigBee or any other)
is
transmitting something (I am not interested what is being transmitted)
after
fixed time intervals let say 50ms. Now this transmitter will continue
transmitting data after every 50ms. This 50ms is the cycle time.

Best Regards

Brian P. wrote:

time of any system (ZigBee, FSK, CSS etc) present in the area. My target
others.

Brian

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
View this message in context:
http://www.nabble.com/Can-threading-disturb-sensing-continuety-tp22598748p22661956.html
Sent from the GnuRadio mailing list archive at Nabble.com.

14

On Mon, Mar 23, 2009 at 11:04 AM, kaleem ahmad [email protected]
wrote:

Thanks Brian,

By cycle time I mean that a transmitter (e.g. FSK, ZigBee or any other) is
transmitting something (I am not interested what is being transmitted) after
fixed time intervals let say 50ms. Now this transmitter will continue
transmitting data after every 50ms. This 50ms is the cycle time.

Keep it in the time domain and just do RSSI estimation. Then count
the number of samples between high power and no power input. This
should work well for high SNR situations. If you need to work in
lower SNR situations, you can perform some other operations on the
signal to detect if there is something there that resembles a digital
signal (an exercise left to the reader).

You definitely don’t need to move to the frequency domain and should
probably be avoided.

As for your ADC question, it’s just doing filtering with decimation.
The actual ADC sample rate stays the same, but your signal is
digitally filtered and samples thrown away. The filtering avoids
aliasing that occurs when you throw samples away.

Good luck.

Brian

15

On Mon, Mar 23, 2009 at 10:20 AM, kaleem ahmad [email protected]
wrote:

Thanks for all these replies,

The problem is my investigation about cycle time is not restricted to FSK,
I just gave the example of FSK system. I would like to calculate the cycle
time of any system (ZigBee, FSK, CSS etc) present in the area. My target is
to sense as much systems as possible and then calculate the cycle time of
that.

I suppose I am missing the meaning of “cycle time”. Do you mean
symbol rate? Or do you mean how often a TDMA system gets on the
channel? Both are significantly different metrics.

It’s best to describe what you want to try to accomplish as clearly as
possible. In some cases, it helps your understanding as well as
others.

Brian

16

On Mon, Mar 23, 2009 at 08:00:52AM -0700, kaleem ahmad wrote:

Hi,

I have one more confusion about this sampling rate of USRP.

At FPGA level it is 64MSps and when we decimate (D = 4…256), the sampling
rate is reduced to 64MSps/D. Now I am confused that if the actual sampling
rate of USRP is changed from 64MSps to the new decimated sampling rate or
the USRP is still sampling at 64MSps and only internal sampling rate (i.e
just for channel selection) is changed.

The ADCs on the USRP always run at 64MS/s. The decimation occurs
inside of the FPGA. This is explained in the USRP FAQ on the wiki.

If this concept is still confusing, you might want to spend some time
looking at a text book that talks about decimating filters and/or
multirate signal processing.
http://gnuradio.org/trac/wiki/SuggestedReading

Addition to this as maximum value of decimation rate is 256 so sampling rate
can be reduced to 250ks/s, if I want to set it to 3ksps then how it is
possible.

You will need to do additional decimation on the host. You can do
that after the usrp.source_c block with a gr.fir_filter_ccf.
grep the examples for examples.

Eric

17

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.