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-sensin... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2009-03-19 14:03

on 2009-03-19 14:51

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

on 2009-03-20 15:35

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 > removed_email_address@domain.invalid > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://www.nabble.com/Can-threading-disturb-sensin... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2009-03-20 16:35

On Fri, Mar 20, 2009 at 9:34 AM, kaleem ahmad <removed_email_address@domain.invalid> 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

on 2009-03-20 17:32

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. > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://www.nabble.com/Can-threading-disturb-sensin... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2009-03-20 19:11

On Fri, Mar 20, 2009 at 11:30 AM, kaleem ahmad <removed_email_address@domain.invalid> 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

on 2009-03-20 19:29

On Fri, Mar 20, 2009 at 10:11 AM, Brian P. <removed_email_address@domain.invalid> 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

on 2009-03-20 19:39

```
On Fri, Mar 20, 2009 at 1:27 PM, Johnathan C.
<removed_email_address@domain.invalid> 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
```

on 2009-03-20 23:53

On Fri, Mar 20, 2009 at 10:33 AM, Brian P. <removed_email_address@domain.invalid> 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

on 2009-03-22 22:33

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

on 2009-03-23 16:21

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 > removed_email_address@domain.invalid > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://www.nabble.com/Can-threading-disturb-sensin... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2009-03-23 16:58

On Mon, Mar 23, 2009 at 10:20 AM, kaleem ahmad <removed_email_address@domain.invalid> 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

on 2009-03-23 17:01

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-sensin... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2009-03-23 17:05

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 > removed_email_address@domain.invalid > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://www.nabble.com/Can-threading-disturb-sensin... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2009-03-23 17:41

On Mon, Mar 23, 2009 at 11:04 AM, kaleem ahmad <removed_email_address@domain.invalid> 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

on 2009-03-23 19:37

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

on 2009-04-21 17:44

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-sensin... Sent from the GnuRadio mailing list archive at Nabble.com.