Re: [Discuss-gnuradio] Parameters for USRP (motherboard only) FM receiver
2007/6/19, Shane Clark [EMAIL PROTECTED]: I am using the DBSRX board. I have actually gotten the receiver working more or less through trial and error, but I have yet to do the FM demodulation in Python. Did you read the specifications for the DBSRX board? The frequency range of this daughter board is approx. 900 to 2400 MHz, which is outside the signal you are trying to receive. Regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FFT Spectral smoothing
Hi, i'd like to do spectral smoothing on an FFT in real time through GNU_RADIO. Is there a function that will allow me to do this in the GNU_RADIO modules? If not has anyone attempted it before, or have any suggestions as to how I should go about implementing it myself. Perhaps any ideas of cascading blocks that do exit. Thanks, Aadil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FFT Spectral smoothing
2007/6/21, Aadil Volkwin [EMAIL PROTECTED]: Hi, i'd like to do spectral smoothing on an FFT in real time through GNU_RADIO. Is there a function that will allow me to do this in the GNU_RADIO modules? If not has anyone attempted it before, or have any suggestions as to how I should go about implementing it myself. Perhaps any ideas of cascading blocks that do exit. Thanks, Aadil From what I can find, spectral smoothing is not an unambiguous term. Could you please elaborate the problem, preferably the mathematical definition of what you are trying to accomplish. Best regards, -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Tx/Rx in the 144 MHz (2m) band
I'm sure this has been previously discussed on the list, but I can't find the discussion in the archives... I want to transmit and receive in the 144 MHz (2m) band, but there isn't a daughterboard available for that band. 144 MHz will alias to 16 MHz with a 64 MHz sampling frequency. So, sub-nyquist sampling will work on receive. However, I'm not sure how to achieve 144 MHz on transmit. (By the way, I need to be coherent between transmit and recieve.) Any advice on the simplest course of action? Thanks, -Lee ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help on editing a usrp1_source_c.cc file
Hi, In the '../gr-usrp/src/usrp1_source_c.cc' file there is a function 'copy_from_usrp_buffer'. I would like to analyze the complex signal converted from 16-bit interleaved I and Q signal. I have changed the 'usrp1_source_c.cc' file to open a file using fstream class and copy the complex signal onto this file. I have implemented this in the function 'copy_from_buffer'. I built GNU radio software again after the changes. I assumed this would work. But it is not. I am sure to be missing something. Debug prints say that this file is not being opened while this file can be opened by any other C++ program that is not part of GNU software. Or is there anything that I have to change in .i file as well? Thanks for any and all help. Meenaktchi Venkatachalam ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help on editing a usrp1_source_c.cc file
On 6/21/07, Meenaktchi Venkatachalam [EMAIL PROTECTED] wrote: Hi, In the '../gr-usrp/src/usrp1_source_c.cc' file there is a function 'copy_from_usrp_buffer'. I would like to analyze the complex signal converted from 16-bit interleaved I and Q signal. You can try ../gnuradio-examples/python/usrp/usrp_rx_cfile.py for this purpose. I have changed the 'usrp1_source_c.cc' file to open a file using fstream class and copy the complex signal onto this file. I have implemented this in the function 'copy_from_buffer'. I built GNU radio software again after the changes. I assumed this would work. But it is not. I am sure to be missing something. Debug prints say that this file is not being opened while this file can be opened by any other C++ program that is not part of GNU software. Or is there anything that I have to change in .i file as well? IT depends, how would you like to call your object from Python. As long as you dont need to call it from Python, change in .i-file is not required. So far, its not clear whether you are controlling your file from outside/Python or its part of general_work function. PS: Next time you update your gnuradio from svn, possibly the changed file will be replaced. Thanks for any and all help. Meenaktchi Venkatachalam ~Tarun ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bug in wfm_rcv_pll and fix, who has stereo FM specs/info and noise and gain issues
Hew How Chee wrote: Hi, This document might be useful. RECOMMENDATION ITU-R BS.450-3 Transmission standards for FM sound broadcasting at VHF Is it downloadable somewhere? I already found that this is the standard I need, but could not find a place where I could download it. Greetings, Martin Regards, Hew --- Martin Dvh [EMAIL PROTECTED] wrote: can you give me a link to more info or the stereo FM specs on this. Greetings, Martin Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC ___ 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
[Discuss-gnuradio] ATSC at the code repository
Hello, beside trying to solve my still existing problem to build wxgui I tried to set up the atsc transmitter/receiver as listed in the README.signal_flow, but I'm not able to find several blocks. I couldn't find GRWeaverModHead VSB modulator and GRWeaverModTail VSB modulator. The following question is, if I can use the standard mapping block from gnuradio, or there is a special block for atsc. Searching the mailing list I found a thread discussing to port the stuff to version 2.x/3.x. Did that happen? Can anybody help? Benedikt _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help on editing a usrp1_source_c.cc file
Thanks Tarun, this helped. Is there anyway to do the opposite? I have 16-bit I and Q data, I would like to send this data to USRP and transmit Thanks Meenaktchi On 6/21/07, Tarun Tiwari [EMAIL PROTECTED] wrote: On 6/21/07, Meenaktchi Venkatachalam [EMAIL PROTECTED] wrote: Hi, In the '../gr-usrp/src/usrp1_source_c.cc' file there is a function 'copy_from_usrp_buffer'. I would like to analyze the complex signal converted from 16-bit interleaved I and Q signal. You can try ../gnuradio-examples/python/usrp/usrp_rx_cfile.py for this purpose. I have changed the 'usrp1_source_c.cc' file to open a file using fstream class and copy the complex signal onto this file. I have implemented this in the function 'copy_from_buffer'. I built GNU radio software again after the changes. I assumed this would work. But it is not. I am sure to be missing something. Debug prints say that this file is not being opened while this file can be opened by any other C++ program that is not part of GNU software. Or is there anything that I have to change in .i file as well? IT depends, how would you like to call your object from Python. As long as you dont need to call it from Python, change in .i-file is not required. So far, its not clear whether you are controlling your file from outside/Python or its part of general_work function. PS: Next time you update your gnuradio from svn, possibly the changed file will be replaced. Thanks for any and all help. Meenaktchi Venkatachalam ~Tarun ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help on editing a usrp1_source_c.cc file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Meenaktchi Venkatachalam wrote: Thanks Tarun, this helped. Is there anyway to do the opposite? I have 16-bit I and Q data, I would like to send this data to USRP and transmit Thanks Meenaktchi To log data from the USRP: usrp.source_c - gr.file_sink(complex) To replay data to the USRP: gr.file_source(complex) - usrp.sink_c - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeuVSy9GYuuMoUJ4RAgi+AJ0SW+l/dlQYVpqHm/T3cbZuMym2hQCfTMDF o9zq9y2gdBX/L5iE1NXm4Sg= =V91g -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help on editing a usrp1_source_c.cc file
usrp_rx_cfile.py logs data using gr.file_sink and the output file is a binary file. Can I have a .dat output file? I guess for replaying data using the gr.file_source - usrp.sink_c, the gr.file_source would be reading from a .dat file Thanks for all help Meenaktchi On 6/21/07, Dan Halperin [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Meenaktchi Venkatachalam wrote: Thanks Tarun, this helped. Is there anyway to do the opposite? I have 16-bit I and Q data, I would like to send this data to USRP and transmit Thanks Meenaktchi To log data from the USRP: usrp.source_c - gr.file_sink(complex) To replay data to the USRP: gr.file_source(complex) - usrp.sink_c - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeuVSy9GYuuMoUJ4RAgi+AJ0SW+l/dlQYVpqHm/T3cbZuMym2hQCfTMDF o9zq9y2gdBX/L5iE1NXm4Sg= =V91g -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] offset at input of LF_RX
Hi all- can anybody explain why the USRP/ LF_RX would seem to introduce a DC bias or offset to a signal generated by a function generator? I have a function generator configured to produce a 1 kHz .1 V P-P signal into a 50 Ohm load. I have a Lecroy digital oscilloscope configured with the input at high-impedance to monitor the signal. When I connect the signal to the USRP, I see the trace on the Lecroy gets shifted UP by about .06 volts, ie I have to add a -0.06 V offset at the function generator to zero the bias. Oddly enough, usrp_oscope.py doesn't show any DC bias whatsoever, regardless of what offset I put into the function generator. Maybe it's removed inside the flow-graph? Any thoughts on either of these questions? thanks. eric Eric H. Matlis, Ph.D. Aerospace Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
On Thu, 21 Jun 2007, Matt Ettus wrote: [EMAIL PROTECTED] wrote: Hi all- can anybody explain why the USRP/ LF_RX would seem to introduce a DC bias or offset to a signal generated by a function generator? I have a function generator configured to produce a 1 kHz .1 V P-P signal into a 50 Ohm load. I have a Lecroy digital oscilloscope configured with the input at high-impedance to monitor the signal. When I connect the signal to the USRP, I see the trace on the Lecroy gets shifted UP by about .06 volts, ie I have to add a -0.06 V offset at the function generator to zero the bias. Are you sure everything is on the same ground? Disconnect everything but leave it powered up, and measure the voltage on the ground of the scope, lfrx, usrp power supply, and sig gen. Then reconnect things and do the same. Using the ground of the USRP power supply as a reference, I saw a maximum of 0.005 volts difference between the grounds of the scope, the function generator, and the inputs to the LF-RX boards. When I check continuity, all the grounds save that of the sig gen are connected (the sig gen has a battery isolation). Obviously, when I connect everything back up those grounds are all on the same plane. So to sum up. With the sig gen configured for .1 V p-p with 50 Ohm impedance, when I connect only the Lecroy (configured for 50 Ohm impedance) the signal is .1 V p-p centered about zero as expected. When I then switch the Lecroy to high impedance and connect the USRP, the signal now is roughly .1 V p-p but centered about roughly 0.06 V, ie shifted up by slightly more than half scale. Just to confirm that the problem is not my function generator, instead of the USRP I connected a second Lecroy configured also with 50 Ohm impedance (the other Lecroy at high impedance) and verified that the signal is as expected, ie .1 V p-p centered about zero. Oddly enough, usrp_oscope.py doesn't show any DC bias whatsoever, regardless of what offset I put into the function generator. Maybe it's removed inside the flow-graph? DC offset is automatically removed in hardware, but you can turn that feature off. Can you explain that in more detail, please? Do you have a capacitor is series with the signal flow to remove any dc? thanks, eric Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
On Thu, 21 Jun 2007, Don Ward wrote: - Original Message - From: [EMAIL PROTECTED] To: discuss-gnuradio@gnu.org Sent: Thursday, June 21, 2007 5:22 PM Subject: [Discuss-gnuradio] offset at input of LF_RX Hi all- can anybody explain why the USRP/ LF_RX would seem to introduce a DC bias or offset to a signal generated by a function generator? I have a function generator configured to produce a 1 kHz .1 V P-P signal into a 50 Ohm load. I have a Lecroy digital oscilloscope configured with the input at high-impedance to monitor the signal. When I connect the signal to the USRP, I see the trace on the Lecroy gets shifted UP by about .06 volts, ie I have to add a -0.06 V offset at the function generator to zero the bias. Oddly enough, usrp_oscope.py doesn't show any DC bias whatsoever, regardless of what offset I put into the function generator. Maybe it's removed inside the flow-graph? Any thoughts on either of these questions? From looking at the schematic, it appears that the LFRX requires a 50 ohm input resistance (at DC) to bias it for zero output. Does your function generator do this? Yes, the function generator has two modes; high impedance output and 50 ohm load output. It's a switch that seems to basically just multiply the setting on the amplitude by a factor of 2 to account for the voltage divider created by the 50 ohm load. -- Don W. thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
Oddly enough, usrp_oscope.py doesn't show any DC bias whatsoever, regardless of what offset I put into the function generator. Maybe it's removed inside the flow-graph? DC offset is automatically removed in hardware, but you can turn that feature off. Can you explain that in more detail, please? Do you have a capacitor is series with the signal flow to remove any dc? It is done digitally. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
On Thu, 21 Jun 2007, Matt Ettus wrote: Oddly enough, usrp_oscope.py doesn't show any DC bias whatsoever, regardless of what offset I put into the function generator. Maybe it's removed inside the flow-graph? DC offset is automatically removed in hardware, but you can turn that feature off. Can you explain that in more detail, please? Do you have a capacitor is series with the signal flow to remove any dc? It is done digitally. Is there a software flag in the code I can switch off? If so, where? Matt thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
On Thu, 21 Jun 2007, Matt Ettus wrote: Oddly enough, usrp_oscope.py doesn't show any DC bias whatsoever, regardless of what offset I put into the function generator. Maybe it's removed inside the flow-graph? DC offset is automatically removed in hardware, but you can turn that feature off. Can you explain that in more detail, please? Do you have a capacitor is series with the signal flow to remove any dc? It is done digitally. If there is no dc-removing capacitor in the circuitry , then should I not expect that for a board using a single (positive) supply, that the signal is always above zero? Matt thanks, eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
On 6/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is there a software flag in the code I can switch off? If so, where? http://gnuradio.org/trac/wiki/UsrpFPGA Under Common Registers: 15 FR_DC_OFFSET_CL_EN DC offset control loop enable Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Recommendations for USB 2.0 add-on PCI Cards
I'm running GNU Radio on a Dell Precision 530MT workstation under Ubuntu. Unfortunately, the system only has USB 1.0 ports. I installed an 6-port USB 2.0 add-on PCI card, but I only get a maximum transfer rate of 16 Mbps when I run benchmark_usb.py from gnuradio-examples/python/usrp. I also ran test_usrp_standard_tx and test_usrp_standard_rx from usrp/host/apps. The transmit part worked fine, but I got a lot of over-runs on receive. My add-on card is based on the NEC chipset, which I gather is not capable of achieving a maximum rate of 32 Mbps with the USRP. Are there other cards and/or chipsets that achieve 32 Mbps? It's hard to come across a card that isn't based on the NEC chipset. Matt Ettus mentioned that the Zonet PCMCIA card based on the VIA chipset works good. Is there one in the PCI form-factor that works as well? Any suggestions are appreciated. Thank you. Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
gnuradio.org appears to be down. Where can I find that flag, and how do I disable it? However, my surmise of the last post seems to be correct. When I substitute a regular Basic RX for the LF RX unit, the upwards shift goes away. This is I'm guessing because, as I hinted to in my previous post, the the LF-RX is dc-coupled to the input signal, and because the USRP board is single supply no negative voltages can be represented. The Basic RX, however, is AC-coupled through an input tranformer and as such any dc bias is automatically removed. At least, that's my theory. Any takers care to correct me on that one? thanks all. eric On Thu, 21 Jun 2007, Brian Padalino wrote: On 6/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is there a software flag in the code I can switch off? If so, where? http://gnuradio.org/trac/wiki/UsrpFPGA Under Common Registers: 15 FR_DC_OFFSET_CL_EN DC offset control loop enable Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] offset at input of LF_RX
If there is no dc-removing capacitor in the circuitry , then should I not expect that for a board using a single (positive) supply, that the signal is always above zero? No, you can put a negative voltage in, as long as it doesn't go below -3.33V. You need to look at the schematics -- the 8132 is a differential opamp with a common mode output set at 3.3V/2. Basically, the differential amps will clip if you go outside the range of -3.3V to +3.3V. You will also damage the differential amp if you go below -3.3V. The ADC will clip if you go outside the range -2V to +2V when set for minimum gain. Back to the subject of what your signal generator is doing, I don't know. If you measure the voltage on the sma connector with nothing connected, you will see that it is 0. If you connect a 1 V source through a 50 ohm resistor, you will see that there is 0.5V at the connector. If you connect -1 V through a 50 ohm resistor, you will see -0.5V at the connector. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A rfx2400 is down, which chip on the borad is broken?
Hello all, Just update the status of our broken boards. Now they are fixed up. :) We replaced the amplifier chip, U4 MGA82563, with a new one. Then everything works now. Good luck HUANG Lin 2007/6/6, Lin HUANG [EMAIL PROTECTED]: I'd like to report to all of you our investigation results. At least, the TX side works now. But for the RX side, I think it is absolutely broken and I give up to repair it. I changed the resistors R40, R42, R46, R130, R132, R136 to be 1k ohms. This prevents the RX side influencing the TX side. And I connected the 6V power of TX side with the power pin of the control part (U203), because the power of RX is not normal. Then the TX side can work. Thanks a lot for Ettus's help.~ HUANG Lin 2007/5/30, Lin HUANG [EMAIL PROTECTED]: I continued checking these broken boards recent days. I found for the TX side, the graph stops as soon as it starts. It seems the daughter board gives some signal to stop the motherboard to load data from PC. I read the .sch file in the subversion repository and the defination of the interface between db and mb. IOUTN_B IOUTP_B IOUTP_A IOUTN_A the analog IF signal mb--db clock the db is synchronous with mb mb--db I2C_A0 I2C_A1 TX/RX RX1/RX switch control signal mb--db SCLK SDA R/W interface to E2PROM mb--db IO0~IO15 for debug usage. mb--db Which pin will give a wrong signal to motherboard and disable the board? IO? We never used u_write_oe. So it may be as a input? Thanks for Eric and Nikhil's help before. Hope you are continously interested in my bug investigation. Thank you. :) HUANG Lin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
