[Discuss-gnuradio] Need help with LFRX
Hi all ! I am interested in observing spectrum around 200kHz and tried the following command : ./usrp_fft.py -R A:0 -f 20 -d 112 with a coil antenna connected to RX-A input of LFRX daughterboard. Should it work ? If so, does it mean that there is something wrong with my antenna ? Regards, Pawel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] microtune RF TUNER MODULE query
Hi, I'm doing some tests on the microtune 4937 DI5 RF TUNER MODULE (3x7702) to determine the modules gain sensitivity. Essentially, i'd like to reproduce the IF AGC and RF AGC graphs, shown in the modules datasheet. I intend on using the _set_rfagc and _set_ifagc methods in the db_tv_rx.py module to set the gain but am not able to determine the actual RF and IF Levels from the amps on the module. Does anyone know how I can access these values, from within the GNU Radio modules Thanks, Aadil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Reducing resolution and packing samples in FPGA firmware problem
Hello, one task of the project I have been working on is to collect raw 4-bit samples from two input to a basic RX daughterboard (RXA, RXB) connected to two IF signals. We have been working on reducing the number of bits per sample taken from within the rx_buffer.v file. In that file we are choosing the 4 MSB from channel 0 and channel 1 (outputs of DDC0) to get a byte of I and Q samples in the buffer. We are then waiting for the next clock sample to fill the buffer with the next 4 bit I and Q samples until the 512 byte is stored where then this is forwarded to the USB buffer. When we load this modified firmware to the FPGA and we do some data collection (using usrp_rx_cfile.py), reading the output data as a signed 4 bit integer, using the fact that we have I and Q samples alternating each of them represented as a signed 4-bit integer, the results show that almost every other value is a zero!!! So we think that there is some kind of zero-padding in our data although we are actually configuring the USRP to represent each sample as a 16-bit word, (without using the -8 flag ) and using a decimation rate of 4. My understanding of the system is that as soon as the 512 bytes are stored in the FPGA buffer, then this is moved as a packet to the USB which is then controlled by the USRP_Source_S.c before it is written to the file, but since we have not been using the -8 flag, I cannot really see why there should be any zero padding in the host software. Can you please help me out, I am stuck at this point for some time now trying to configure the system differently in order to get an understanding of what is going on. I can provide with the rx_bufer.v file and with some data output to anyone that can help. Thank you all Rigas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] why two switches and two Rx in RFX series daughter boards?
zhifeng chen wrote: I am wondering why there are two switches in the RFX series daughter from schematics. It seems their purposes is different: one for switch between Tx and Rx, another switch between Rx and Rx2. So, my questions as: 1. we may use one tx and rx enough, why need to use two Rx? The RX2 port is for those people using external amplifiers who need RX and TX on separate ports. 2.I follow the python code into usrp.pick_rx_subdevice(u) and the return value is side and subdev. Since there are two rx there, how may I know subdev refer to rx or rx2? The subdev is not used on this board. The select rx antenna function is used to choose between the 2 antennas. 3. if we call set_auto_tr(), it refer to which switch? It controls all switches. I also test usrp_fft.py and find both Tx/Rx and Rx2 have signal input (by using the same usrp_siggen.py), while input from Tx/Rx is stronger than Rx2. Since Tx/Rx is followed by a filter, it should be less than Rx2, so, what happens here? The RX2 signal is weaker by about 25dB because it is disconnected. The switches don't have infinite blocking. I use two sets of USRP with RFX900 to test a FDD( frequency devision duplex) by cable connection. According to my experience, the cable loss should be less than 0.5-1 db, right? (which come with RFX900) So, If I set the same gain for two RFX900 tx, say -a 100, the received signal is much smaller than the coupled signal from itself, whatever the different frenquency is. So, why there are both input signal? it is coupled signal or intentionally designed? I think it is intentional designed, and since the tx signal is routed to Rx2 directly, so it is much stronger than come from its peer end, is it right? You should NEVER connect the TX output to an RX input without a lot of attenuation in between. You should also not be using RX2 in your situation. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems with Mueller Mueller clock recovery; not very reliable in my system
Christian Sokolowski wrote: I expect that assert(imu =0); is not very robust for synchronising the signal for some unknown reason. Have you tried commenting that out and seeing what happens? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] File source woes
John Bratteli wrote: I'm attempting to write a script, based on usrp_fft.py, that will read a file of gr_complex and display it. It works, except that it plays back much faster than it was recorded. Insert a gr.throttle() instance after the file source to reduce the stream item rate. throttle = gr.throttle(itemsize, items_per_second) -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] File source woes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is a gr_throttle block that you can use to rate-limit your data. I think the only rate-limiting going on here is CPU time. - -Dan John Bratteli wrote: I'm attempting to write a script, based on usrp_fft.py, that will read a file of gr_complex and display it. It works, except that it plays back much faster than it was recorded. For example, I recorded a five second file and gave it to my script. It looked to be correct data, but it finished playback in less than a second. Here's the essential code: self.input = gr.file_source(gr.sizeof_gr_complex, options.filename, options.loop) adc_freq = 64e6 #inherent to USRP decim_rate = float(options.decim) #whatever decimation rate used in recording input_rate = adc_freq / decim_rate self.scope = fftsink.fft_sink_c(self, panel, fft_size=1024, sample_rate=input_rate) self.connect(self.input, self.scope) self._build_gui(vbox) * Any help would be greatly appreciated. John Bratteli TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. http://tv.yahoo.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjTYUy9GYuuMoUJ4RAtmXAKCZ5DF9IoFsySeGQnCqVrfvu+5uQACgvvLE 4PanFN6JXiX5Bi56H/MrYYg= =nCEo -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] File source woes
Well, that was easy. Thanks guys! John --- Johnathan Corgan [EMAIL PROTECTED] wrote: John Bratteli wrote: I'm attempting to write a script, based on usrp_fft.py, that will read a file of gr_complex and display it. It works, except that it plays back much faster than it was recorded. Insert a gr.throttle() instance after the file source to reduce the stream item rate. throttle = gr.throttle(itemsize, items_per_second) -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] File source woes
Dan Halperin wrote: There is a gr_throttle block that you can use to rate-limit your data. I think the only rate-limiting going on here is CPU time. Correct. The GNU Radio runtime scheduler will always execute signal processing blocks at the fastest rate possible given data availability. With real sources like the USRP, the flowgraph usually becomes rate-limited by the data production rate of the USRP. Sometimes it's the data sink that does the rate limiting, like an audio sink. In the OP's flowgraph, there is nothing holding up the scheduler other than the hosts CPU speed, memory bandwidth, or hard disk controller. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] File source woes
I'm attempting to write a script, based on usrp_fft.py, that will read a file of gr_complex and display it. It works, except that it plays back much faster than it was recorded. For example, I recorded a five second file and gave it to my script. It looked to be correct data, but it finished playback in less than a second. Here's the essential code: self.input = gr.file_source(gr.sizeof_gr_complex, options.filename, options.loop) adc_freq = 64e6 #inherent to USRP decim_rate = float(options.decim) #whatever decimation rate used in recording input_rate = adc_freq / decim_rate self.scope = fftsink.fft_sink_c(self, panel, fft_size=1024, sample_rate=input_rate) self.connect(self.input, self.scope) self._build_gui(vbox) * Any help would be greatly appreciated. John Bratteli TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. http://tv.yahoo.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] why two switches and two Rx in RFX
Message: 2 Date: Thu, 05 Jul 2007 10:10:15 -0700 From: Matt Ettus [EMAIL PROTECTED] Subject: Re: [Discuss-gnuradio] why two switches and two Rx in RFX ... I use two sets of USRP with RFX900 to test a FDD( frequency devision duplex) by cable connection. According to my experience, the cable loss should be less than 0.5-1 db, right? (which come with RFX900) So, If I set the same gain for two RFX900 tx, say -a 100, the received signal is much smaller than the coupled signal from itself, whatever the different frenquency is. So, why there are both input signal? it is coupled signal or intentionally designed? I think it is intentional designed, and since the tx signal is routed to Rx2 directly, so it is much stronger than come from its peer end, is it right? You should NEVER connect the TX output to an RX input without a lot of attenuation in between. You should also not be using RX2 in your situation. Matt Question. What is a lot of attenuation (ballpark?) I have a RFX1800 transmitting at 20 going into (cabled) a dbsrx with gain 40. Between the transmitter and receiver I have 40dB worth of attenuators... Would you suggest any different? I learnt the hard way on the first dbsrx :) Thanks Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] delay in tx chain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've asked a similar question before, so please try and bear with me :). Is there a way to calculate the delay of all blocks after yours in a chain? It might be as easy as summing up the histories of all of the blocks... As an illustration of why we need this, consider that the filter blocks often set_history equal to the number of taps. This means that as soon as a single sample gets sent through, they can begin emitting data. However, the data that they emit isn't useful -- not until the filter block is full of samples. If we're streaming, this is fine, a minor delay. However, packet-based applications send a message and then switch back to RX mode. The upshot of this is that the ends of packets will get stuck in the filters and not get pushed out until the next data packet comes through. This (not end-of-packet-ISI) is why we have to append at least one nonsense byte to the end of a packet in order to make the CRCs match, and why that end-of-packet error is deterministic rather than random. A fix seems to be to appending a number of additional samples (maybe zero samples) equal to the total pipeline delay to a message in a message_source. Do we have the facility to do this? Other suggestions? Comments? - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjUNoy9GYuuMoUJ4RAkRhAJ4+duozGplcFxHmiz+qNP7N7m/0CACdGGQ7 Zz8uuwOFeA57mKvf+fy4on8= =irgt -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with udp-sink/source over a network
Hello all, I've been working with the udp-sink and source blocks to try and get a usrp working from a remote location. Everything I've tried seems to be working fine when I test on a local machine, but I'm getting an odd error once I move to a remote test. I used the vector_source.py and vector_sink.py as examples for what I have so far, and going back to them it seems like they don't work for me remotely either. I get the following error when attempting to connect my own application and vector_source.py to a remote computer: socket connect: Invalid argument terminate called after throwing an instance of 'std::runtime_error' what(): can't connect to socket Aborted I can't for the life of me figure out what the invalid argument going to connect() might be. I've attempted to use gdb as per the recommendations in How to Write a Block, but after attaching to the process gdb is unable to figure out where it is, and stepping through the code doesn't work at all. If anyone could try running vector_source/sink.py on remote systems, I would greatly appreciate any help getting this working. Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with udp-sink/source over a network
Dev Ramudit wrote: socket connect: Invalid argument terminate called after throwing an instance of 'std::runtime_error' what(): can't connect to socket Aborted You must have the remote listener already running before running the sender script. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mode S and ADS-B
Eric A. Cottrell wrote: Hello, I finally checked in the infamous Mode Select code to branches/developers/wb1hbu/wip and I am glad this portion is done. I spent a couple of days cleaning the code up a little. I also added some features. Likely I missed using a few neat gnuradio functions. There is a usrp_oscope_ms.py program that displays the Mode Select signal, Reference Level, and Attributes. Triggering off of channel 2 (Reference Level) allows the display of Mode Select waveforms. I made the attributes go negative so they are more visible. I was surprised at the results. The usrp_mode_s_logfile.py program outputs Mode Select frame information to a log file. It does no decoding of the data. It logs the data bits and other attributes of the signal and error correction. It is a good program to run if you are in a heavy air traffic area and want to generate megabytes of text within an hour. Hi Eric, I tried out your code. Does it run on your machine in realtime? I have a dual-core athlon X2 3800 and both processor go to 100 % when I run it. (I didn't know gnuradio could use both processors , I though we still had the single-threaded-scheduler) This gives me a lot of USRP overruns (UoUoUo) so it doesn't work very well this way. Does mode-s really need a samplerate of 800 Another question. I know 1090 Mhz is the frequency they use in the US. I googled for info on frequencies for mode-s and ads-b and it seems multiple frequencies could be used. Does anyone know of an overview of the actual frequencies in use, at which places. (I live in the netherlands) Greetings, Martin I tried increasing the decimation but then the code refuses to run (requires 800 sps) 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mode S and ADS-B
Martin Dvh wrote: Hi Eric, I tried out your code. Does it run on your machine in realtime? Yes. It works quite well on my Core 2 Duo. I have a dual-core athlon X2 3800 and both processor go to 100 % when I run it. (I didn't know gnuradio could use both processors , I though we still had the single-threaded-scheduler) This gives me a lot of USRP overruns (UoUoUo) so it doesn't work very well this way. Does mode-s really need a samplerate of 800 The methods I used to implement the code do require 800 and that is the slower rate with 1000 the preferred rate. I may be wasting some CPU cycles. One thing to try is to use the scope program to set the threshold. The default is low for alot of front ends including the DBSRX. The DBSRX tends to be deaf. Also I find a gain setting of 32 to 36 seems to work best for the DBSRX. If the threshold is set too low I find that so much data is being processed that even my Core 2 Duo will start UoUoUo a little. I set the threshold so that most of the noise is below the threshold value. Try a gain of 32 and a threshold of 75 to start. If you set the scope to sync on channel 2 going negative you should see Mode Select frames of various amplitudes. Getting the antenna up in the clear is important. A discone will work if you have a good receiver but I found building a simple 1/4 wave ground plane on an N connector beats out the discone. I had good results using my AOR 5000 as a front end. I used the wideband IF output through a 20 dB amplifier to the LFRX board. I have tried other receivers with tapped IF outputs and did not get good results. I think it is the combination of the low noise front end of the AOR 5000 and being able to turn off AGC. I am experimenting with antennas and want to find a GAsFet preamp that covers the band here in the US. Another question. I know 1090 Mhz is the frequency they use in the US. I googled for info on frequencies for mode-s and ads-b and it seems multiple frequencies could be used. Does anyone know of an overview of the actual frequencies in use, at which places. (I live in the netherlands) 1090 MHz is the international frequency. You may be thinking about UAT for smaller private aircraft. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mode S and ADS-B
Eric A. Cottrell wrote One thing to try is to use the scope program to set the threshold. The default is low for alot of front ends including the DBSRX. The DBSRX tends to be deaf. Also I find a gain setting of 32 to 36 seems to work best for the DBSRX. The DBSRX typically has a noise figure around 3-5dB. I wouldn't call that deaf. You are connecting a discone to a wide open front end without a filter, so it is far more likely that you are experiencing desense from the thousands of other signals you are picking up. Also, raising the gain above 32 would reduce the noise figure you see. Getting the antenna up in the clear is important. A discone will work if you have a good receiver but I found building a simple 1/4 wave ground plane on an N connector beats out the discone. Probably because it is more frequency selective than the discone, thus reducing the strong interferers. When you set up a discone on the DBSRX you need to understand that you are picking up multiple cellphone bands, the pager bands, 2 ISM bands, microwave ovens, radars, etc, in addition to the nice weak signals you are looking for. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] why two switches and two Rx in RFX
Question. What is a lot of attenuation (ballpark?) I have a RFX1800 transmitting at 20 going into (cabled) a dbsrx with gain 40. Between the transmitter and receiver I have 40dB worth of attenuators... Would you suggest any different? I learnt the hard way on the first dbsrx :) The RFX boards can put out as much as 26 dBm. The RF inputs can be damaged by 0dBm. So use at least 30dB. But the frontend isn't linear unless you go even lower. I get this question a lot, and I don't understand it. Attenuators are cheap and they don't charge per dB. Why not just throw 40 or 50dB in there and be safe? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] why two switches and two Rx in RFX series daughter boards?
Hi Matt, Thanks a lot! So, you means I just need connect between Tx/Rx and leave Rx2 unused for RFX 900. But I want to implement FDD (frequency division duplex), it should use Rx2. Do I need to make change to hardware? how? Thank you! 2007/7/6, Matt Ettus [EMAIL PROTECTED]: zhifeng chen wrote: I am wondering why there are two switches in the RFX series daughter from schematics. It seems their purposes is different: one for switch between Tx and Rx, another switch between Rx and Rx2. So, my questions as: 1. we may use one tx and rx enough, why need to use two Rx? The RX2 port is for those people using external amplifiers who need RX and TX on separate ports. 2.I follow the python code into usrp.pick_rx_subdevice(u) and the return value is side and subdev. Since there are two rx there, how may I know subdev refer to rx or rx2? The subdev is not used on this board. The select rx antenna function is used to choose between the 2 antennas. 3. if we call set_auto_tr(), it refer to which switch? It controls all switches. I also test usrp_fft.py and find both Tx/Rx and Rx2 have signal input (by using the same usrp_siggen.py), while input from Tx/Rx is stronger than Rx2. Since Tx/Rx is followed by a filter, it should be less than Rx2, so, what happens here? The RX2 signal is weaker by about 25dB because it is disconnected. The switches don't have infinite blocking. I use two sets of USRP with RFX900 to test a FDD( frequency devision duplex) by cable connection. According to my experience, the cable loss should be less than 0.5-1 db, right? (which come with RFX900) So, If I set the same gain for two RFX900 tx, say -a 100, the received signal is much smaller than the coupled signal from itself, whatever the different frenquency is. So, why there are both input signal? it is coupled signal or intentionally designed? I think it is intentional designed, and since the tx signal is routed to Rx2 directly, so it is much stronger than come from its peer end, is it right? You should NEVER connect the TX output to an RX input without a lot of attenuation in between. You should also not be using RX2 in your situation. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
