[Discuss-gnuradio] Artefacts in usrp_fft.py
Hi all, We implemented a spectrum senser based on GnuRadio for our cognitive radio research. In order to calibrate the senser we check the performance of the RFX2400 and DBS RX d'board with the usrp_fft.py script. We use the norma FFT and the waterfall plot of the script. Feeding the usrp with generated signals by a high performance signal generator we could observe the appearance of some strong artefacts in the spectrum. To find out the origin of this artefacts we put a calibrated 50 ohm termination on the sma antenna connector in order to assure we only measuring the noise floor of the usrp. Now we could observe several artefact in almost all frequencies between 800 and 2500 MHz. Sometimes the artefacts are sharp peaks some times wider peaks and the total number of peaks varies also from center frequency to center frequency. Normally we use a decimation rate of 8 to sense a chunk of 8 MHz and we try several gains of the d'board. If someone know how the origin of these artefacts and/or how to avoid getting them in the sensed spectrum please answer. Every advice will be appreciated. Thank you all in advance Luis Simoes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What is MIMO B?
Hi all, I've implemented an application script to cover both ISM bands 433 MHz and 2.4GHz. For that purpose I connect a Flex 2400 (RXA/TXA) and a Flex 400 (RXB/TXB) on a USRP Rev 3 motherboard. Everything goes well. But if I connect a USRP rev 4.1 or 4.2 with the same d'board configuration to the USB-Bus, the python script prints out: Using RX d'board B: Flex 400 Rx MIMO B Using TX d'board B: Flex 400 Tx MIMO B The script runs normal but no packet is received and no packet is send (no packet is arriving at another receiver (No Gnuradio receiver). If the USRP rev 3 is used the print out is: Using RX d'board B: Flex 400 Rx MIMO B Using TX d'board B: Flex 400 Tx MIMO B and packets are received and sent. The print output is obtained by 'print Using TX d'board %s % (self.subdev.side_and_name(),)'. Where comes this MIMO B difference comes from? Is this the reason why the application runs with one board and not with the other? How can I solve the problem? Ah, before I forget it. Perhapes this could help you to give me an answer. If I run usrp_fft.py from the examples, I get a 'Failed to tune to initial frequency' in the status bar of the application window. If I try to introduce a frequency, the shell outputs: ... File /usr/local/lib/python2.4/site-packages/gnuradio/usrp.py, line 184, in tune return tune(self, chan, subdev, target_freq) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp.py, line 122, in tune ok, baseband_freq = subdev.set_freq(target_freq) File /usr/local/lib/python2.4/site-packages/gnuradio/db_flexrf.py, line 174, in set_freq R, control, N, actual_freq = self._compute_regs(freq) File /usr/local/lib/python2.4/site-packages/gnuradio/db_flexrf.py, line 392, in _compute_regs assert self.B_DIV = self.A_DIV AssertionError Please, help me... I am very grateful for every kind of help Thank you guys! Luis Simoes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What is MIMO B?
Hi all, sorry, but in the previous mail I wrote something wrong. when USRP rev3 is connected the output is: Using RX d'board B: Flex 400 Rx Using TX d'board B: Flex 400 Tx everything without MIMO B... all the rest remains the same Luis Simoes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What is MIMO B?
Thank you, Eric Which daughterboard are you using and what is the value that you are passing to the -f freq command line option? I am using the Flex400 daughterboard on TXB/RXB and I run ./usrp_fft.py -d16 -R B -f 43300. With the rev3 usrp there is no problem but rev4 usrp gives the AssertationError. It is not possible to tune to the desired frequency while ./usrp_fft.py is running. The response is always 'Failed' and values for DDC and Analog BB are 0. Please, help me... I am very grateful for every kind of help Thank you guys! You're welcome! Eric Luis Simoes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sampling artefact because of two step mixing?
Hi Don, the problem is that the second peaks are not at DC in baseband. For example: I generate a sine tone at 2.444 Ghz. Then I tune the usrp to centre frequency of 2.448 GHz. Now I can see the peak at -3 Mhz in base band. Ok, this is correct because what Iam seeing is the original sine. When I tune the USPR to centre frequency 2.450 Ghz I see an attenuated peak at 1 MHz in baseband what correspond to 2.451Ghz. This second peak is 6 Mhz above the original sine. If I rise the gain in the usrp_fft.py tool there appear more undesired peaks but I am still feeding the USRP with olny one tone. If I decrease the gain to eliminate all secondary peaks my original signal gets too weak and it is less than 10 db over the noise floor. I am trying several setting to find out what is the reason of all this. The last try was: 1 sine tone at 2.488 Ghz feed into USRP The result was: one peak at 2.488 Ghz and one alt 2.432 GHz (20 dB's lower) Now the secondary peak is 56 MHz away from the original tone!!! Please, can anyone help me? I am getting desperate... Luis On Wednesday 18 October 2006 20:12, you wrote: I have observed a similar phenomenon with the LFRX daughterboard. It seems there is often (or always?) a peak at DC in the baseband (USRP output) spectrum, regardless of the tuned frequency of the USRP. I suspect it is due to rounding down in the CIC decimation filter. Adding a value of e*complex(1.0,1.0) where 0.5 = e = 0.8 to the USRP output will cancel it. -- Don W. - Original Message - From: Luis Simoes [EMAIL PROTECTED] [snipped] As I feed the USRP with a single sine tone with a frequency of 2.444 GHz and an amplitude of -50dbm I saw on my plot a nice peak at 2.444 GHZ but also a second peak at 2.452 GHZ but attenuated by 15 db's when daughter board is tuned to 2.452 Ghz. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] sampling artefact because of two step mixing?
Hello everybody, I am currently using the flex2400 board and I feed it with some designed signals from a sophisticated signal generator. I analyse the spectrum of interest by fft and pass all information to a file sink. I plot the file data in Matlab to evaluate the results. As I feed the USRP with a single sine tone with a frequency of 2.444 GHz and an amplitude of -50dbm I saw on my plot a nice peak at 2.444 GHZ but also a second peak at 2.452 GHZ but attenuated by 15 db's when daughter board is tuned to 2.452 Ghz. To verify the accuracy of the signal generator I connected it to a high quality spectrum analyser. The spectrum analyser verified that the output of the signal generator is a clean peak without any side peaks. However, the usrp_fft.py tool from the gnuradio examples shows the same phenomenon including the second peak. The parameters I use in my application are : Flex2400 daughterboard Decimation factor 8 complex samples at 16bit I and 16 bits Q each fft size 64 ( corresponds to 125 kHz bin resolution) My first idea points to the effect of the second mixing in the DDC from the remaining frequency offset after the analog mixing in the daughterboard tuned the centre frequency as close as possible to baseband. When the tune method is set to the centre frequency of 2.452 Ghz, the flex mixes with 2.448 GHz and the DDC with -4MHz. By mixing with a cos wave we get two peaks, one at (f-f0) and one at (f+f0), but both with half signal strength. The resulting peak from mixing with the double frequency (f+f0) can now explain the appearance of this side peak in my plot. But: 1. Why is the second peak attenuated? If it is a result of mixing it should be as high as the original signal? 2. If the assumption of the two peaks is correct, why are the assumed and the real measured peaks mirrored in other configurations (other signal frequency and center frequency of the usrp)? 3. The flex2400 is able to tune to every frequency between 2400 and 2500 MHz in steps of 1 MHZ. Why can I not tune the flex directly to the centre frequency without another mixing stage in the DDC? The DDC frequency is allways between -2 and -5.5MHz. Would this effect disappear if no second stage mixing is needed? I found almost no documentation about the configuration of the DDC. Which filters are implemented and what are the parameters used in the logical steps of mixing, decimating and low pass filtering? Is there any way to avoid this physically not existing signals and if not is there a detailed explanation why this phenomenon occurs in an irrational (it seams so) way? I am very grateful for any advice, Perhaps Matt and Eric are the experts in this matter. So this question is specially directed to you. Thanks a lot Luis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OQPSK for IEEE 802.15.4
Hi all, I will implement a ZigBee transceiver on Gnuradio using channels in the 2.4GHz ISM band. I studied a bit the IEEE standart and I could observe that ZigBee uses DSSS channel encoding with 32 chips long random noise sequences and an offset QPSK modulation scheme. The offset between In-phase and quadrature streams is a half symbol duration. Does anybody have an idea how to build a phase detector and decision device for this modulation in Gnuradio? What's about the costas loop for QPSK detection? Is this loop able to trigger the offset fast enough or should I build two phase detection loops, one for each stream (I Q). After having the two streams what could be the best way to achieve symbol recovery? And , as last question for the moment, in transmission mode how can I build a delay for the offset needed? DSSS is not a big deal and I think that I will write a block with simple mapping tables. I am still designing the application and some tips would be very precious to start implementation by the right way. I appreciate any advise or tip and I'd like to thank all of you in advance. Luis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MICA2 reception at ISM 433MHz
Hi all, I still have problems receiving any data packets from my MICA2 Mote at ISM band 433 MHz. I have tuned the usrp to the right frequency and designed the channel filters and uspr_fft_py shows me nice results. On the other side I changed the gmsk_test.py file in gnuradio-examples to my needs (manchester encoding/decoding) and the test worked fine, i.e. Test packets were manchester encoded, then modulated, I add some noise , demodulating, manchester decoding, at the end everything was written into a file. Everything was ok. When I try to combine the usrp_source with its filters to the demod chain of the manchester_test file(changed gmsk_test.py) there is nothing at the output. I've tried to change some parameters, e.g. the Threshold of gmsk2_demod_pkt, etc., but without getting any result. The format of data packet sent by the MICA2 is the following (MAC): 3 bytes preamble 1 byte sync 5 bytes header 29 bytes payload 2 bytes CRC16 the preamble and sync bytes are the access_code of gmsk2 (8 bytes in PHY layer after manchester encoding - 0x). I changed also the gr_packet_sink block to return a constant packet length. I don't know what to try out now and hope that someone who has done something similar can give me some tips or advises. I am very grateful for all kind of help, Luis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new tarballs
Hi Eric, thanks a lot. Every thing is working fine now. Now I have still one question: Was the module tv_rx extinguished in the new tarballs? My old applications return the message global name tv_rx unknown. Shall I change all the applications to the way benchmark_gmsk_rx.py works? Thanks again, your tips helped me a lot. Luis On Wednesday 05 April 2006 19:43, you wrote: On Wed, Apr 05, 2006 at 06:12:06PM +0200, Luis Simoes wrote: Hi all, I tried to use benchmark_gmsk_rx.py and i noticed that my system does not have all the usrp stuff receive_path.py uses. So I install the usrp-011 and the gr-usrp-0.7 package and uninstall the previous ones (usrp-0.8 and gr-usrp-0.5). After finishing (I am still running on gnuradio-cor 2.6) I tried to start benchmark again and this traceback error report came out: [EMAIL PROTECTED]:~/GnuRadio/Code/gnuradio-examples-0.5/python/gmsk2 ./benchmark_gmsk_rx.py Using RX d'board A: TV Rx len(rx_chan_coeffs) = 63 gr_fir_fff: using 3DNow! Traceback (most recent call last): ... ... File /usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py, line 230, in _check_port if signature.max_streams () == -1: # infinite AttributeError: 'PySwigObject' object has no attribute 'max_streams' I have seen some messages posted here in this mailing list. In all cases it was a problem with swig. I reinstalled SWIG (I am using version 1.3.24) and then gnuradio-core 2.6. No result. I uninstalled core 2.6 and after reinstalling SWIG I have installed the new core 2.7 No result. I build everything from tarballs and not from cvs and until today everything worked fine. If someone have had this problem or similar in the past, please help!... Thanks in advance... Luis You have a stale installation, or partial installation in more than one place. Remove them all from the installation directories, then make install from the new tarballs. There's a reason we release 10 tarballs at at a time: They have dependencies between them. You really want all the new ones that are relevant to your configuration. They also have to be built in a reasonable order. Most people need at least gnuradio-core, usrp, gr-usrp, gnuradio-examples, gr-wxgui and one of of the gr-audio-* blocks. Build them in this order. Leave out those you're not using: /home/eb/gr-build/gnuradio-core /home/eb/gr-build/usrp /home/eb/gr-build/gr-audio-alsa /home/eb/gr-build/gr-audio-jack /home/eb/gr-build/gr-audio-oss /home/eb/gr-build/gr-audio-portaudio /home/eb/gr-build/gr-usrp /home/eb/gr-build/gr-wxgui /home/eb/gr-build/gnuradio-examples /home/eb/gr-build/gr-howto-write-a-block Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_crc16
Hi all, I need to check payload data with only 2 crc bytes. Unfortunately my transmitter sends only data with 2 crc bytes. There is only the gr_crc32 module in gnuradio core with an algorithm that uses a table array with 256 elements. I want to ask if there is someone out there who has had a similar problem and implemented a gr_crc16 module? Please give me some help because I don't know how was created this table and which algorithm was used? Thanks in advance, Luis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] array to string conversion (packet_utils.py)
Hi everybody, do somebody know how to convert a list or an array to a string when changed the size of the items? I use the packet_utils.py where i changed the functions whiten(s). First I slice the string s into UnsignedInt8 items into a list sa (as done in the original source code). Then I map a function to this list and it results in 16 bit items of the new list z. When I try to use z.tostring() method it doesn't work. The str(z) function also gives wrong results. How can I join this 16bit items to one string? the number of elements in z is variable. And the resulting string should be slices in a new function into UnsignedInt8 or Int16 intems. I could not find anything in the python docs and tutorials that resolves my problem. Thanks for any advice, Luis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FSK with TX-RX in ISM-band 433 Mhz
Hi Thomas, nice to see someone in the gnuradio world treating with the same problems. In my case the cc1k send 5 preamble bytes (0x) followed by a synchronisation sequence of 0x. After this comes the header and my data. The synchronisation sequence of 0x is the chip pattern of transmition what represents a bit pattern of 0x33. Could you sent me some of your code to see how you realised the synchronisation detection and the manchester decoding? Did you use bit padding as in gmsk2? Thank you in advance, Luis --- Luis Simoes Department of Wireless Networks RWTH Aachen On Wednesday 22 March 2006 20:44, you wrote: Hi Luis, I have the code to decode mica2 motes. It is not perfect yet since I still use the correlator and I would like to move over to the gmsk way with proper synchronisation. But it works ;) In my case, the cc1k sends a synchronisation sequence of 0x99 to which I synchronize the correlator. Then, I feed the found softsymbols into the sos_packet_sink. You have to note that I use SOS as an operating system on the mica2s. SOS adds a sync sequence just before the message starts (tinyos does the same). The sos_packet_sink then finds that sequence in the soft symbols which allows us to get byte synchronisation. Then, we can look at the packet header and read the whole message. Once parsed, the messages get added to a msg_queue. From the message queue, they get to the registered callback. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re: [Discuss-gnuradio] FSK with TX-RX in ISM-band 433 Mhz
Hi Thomas, nice to see someone in the gnuradio world treating with the same problems. In my case the cc1k send 5 preamble bytes (0x) followed by a synchronisation sequence of 0x. After this comes the header and my data. The synchronisation sequence of 0x is the chip pattern of transmition what represents a bit pattern of 0x33. Could you sent me some of your code to see how you realised the synchronisation detection and the manchester decoding? Did you use bit padding as in gmsk2? Thank you in advance, Luis --- Luis Simoes Department of Wireless Networks RWTH Aachen On Wednesday 22 March 2006 20:44, you wrote: Hi Luis, I have the code to decode mica2 motes. It is not perfect yet since I still use the correlator and I would like to move over to the gmsk way with proper synchronisation. But it works ;) In my case, the cc1k sends a synchronisation sequence of 0x99 to which I synchronize the correlator. Then, I feed the found softsymbols into the sos_packet_sink. You have to note that I use SOS as an operating system on the mica2s. SOS adds a sync sequence just before the message starts (tinyos does the same). The sos_packet_sink then finds that sequence in the soft symbols which allows us to get byte synchronisation. Then, we can look at the packet header and read the whole message. Once parsed, the messages get added to a msg_queue. From the message queue, they get to the registered callback. Thomas --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FSK with TX-RX in ISM-band 433 Mhz
Hi all, I am a novice in gnuradio and after searching in a lot of forums I put my USRP working and my Gnuradio running. Some FM and AM reception with and without GUI are working fine. Now I have some problems in FSK. I try to receive in ISM 433 MHZ some data packets with a data rate of 38.4 kbaud. The data is manchester encoded. To do this I followed the way in the gnuradio examples (fsk_rx.py) with a channel filter and the simple correlator. To do the correct manchester decoding I changed the correlator block in according to my needs and build the new block howto_manchester_correlator. The difference between my manchester_correlator and the simple correlator is the packit function and the sync bytes (instead of using GRSF_SYNC I use MAN_SYNC= 0x, these are the preamble and syncronization bits). Now when I start my application gnuradio starts receiving some data that is written to a file, but my transmitting module is switched off and the data is complete nonsense. When I switch on the transmitter the result is the same. This occurs also when I ran the application with the simple correlator. The seqno where in random order, but there should be nothing because I didn't send anything in the simple_framer format. Now I think the correlators are working well but the problem can be on the radio part. My system is working on Linux-kernel 2.6 (Linux 9.3) and the CPU is AMD Athlon XP 2400+ I have tried to adjust all parameters with no result. I am very grateful for any kind of help or advice. Luis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
