[Discuss-gnuradio] use of pulseaudio -- some parameters to call?
Opensuse 11.3 uses pulseaudio as a standard audio-io. Gnuradio 3.3.x offers alsa audiosink and audiosource. When I put pulse as parameter for the device_name in GRC, with verbose in the ~/.gnuradio/config.conf I got information about samplerate and other parameters (see below) -- in my case: the format S32LE is selected. -- How can I change to use S16LE? How can I change these audio parameters in GRC? What other parameters can be changed in ~/.gnuradio/config.conf or by call? I like to reduce the audio samplerate down to 1000 Hz or up to 192 kHz -- is there any limit to do this when the hardware supports it? Are there any changes to do in the pulseaudio default.pa or by pactl / pacmd? Where can I find some more infomation on that? -- doxygen does not show enough information even the audio_alsa_sink.h which is given in the doxygen object. Thanks for reading and thinking on answers Michael By the way -- I made a newer rpm SPEC-file for gnuradio 3.3.0 and 3.3.1-git -- anybody interested obtaining this? my config.conf is: --8- [audio_alsa] default_input_device = pulse default_output_device = pulse verbose = true --8-- the verbose output in terminal window of grc is --8-- PCM name: pulse Access types: MMAP_INTERLEAVED NO MMAP_NONINTERLEAVED NO MMAP_COMPLEX NO RW_INTERLEAVED YES RW_NONINTERLEAVEDNO Formats: U8 YES S16_LE YES S16_BE YES S32_LE YES S32_BE YES FLOAT_LE YES FLOAT_BE YES MU_LAW YES A_LAWYES Number of channels min channels: 1 max channels: 32 1 channelsYES 2 channelsYES 3 channelsYES 4 channelsYES 5 channelsYES 6 channelsYES 7 channelsYES 8 channelsYES 9 channelsYES 10 channelsYES 11 channelsYES 12 channelsYES 13 channelsYES 14 channelsYES 15 channelsYES 16 channelsYES Sample Rates: min rate: 1 (dir = 0) max rate: 192000 (dir = 0) 8000 YES 16000 YES 22050 YES 32000 YES 44100 YES 48000 YES 96000 YES 192000 YES audio_alsa_source[pulse]: using S32_LE audio_alsa_source[pulse]: sample resolution = 32 bits --8-- M. Hartje -- Dr.-Ing. Michael Hartje Labor Hochspannungstechnik / Labor elektrische Messtechnik Neustadtswall 30; D-28199 Bremen Germany ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] use of pulseaudio -- some parameters to call?
Hi Michael, Unfortunately I do not have any good answers to your questions, but I have added some comments below that might help. On Wed, Sep 1, 2010 at 12:09 PM, Michael Hartje har...@etech.hs-bremen.de wrote: Opensuse 11.3 uses pulseaudio as a standard audio-io. Gnuradio 3.3.x offers alsa audiosink and audiosource. I believe all linux distributions have been using pulseaudio for many years now, but pulseaudio is built on top of alsa drivers so we have both systems. When I put pulse as parameter for the device_name in GRC, with verbose in the ~/.gnuradio/config.conf I got information about samplerate and other parameters (see below) -- in my case: the format S32LE is selected. -- How can I change to use S16LE? Can you actually get usable audio in and out when you use pulse for device? I use Ubuntu 9.10 and 10.04 and none of my computers are able to work with that setting. Using the default alsa devices, i.e. leaving it empty, works quite all right. According to the pulseaudio docs, alsa applications will automatically be routed through pulseaudio via the alsa-plugin. How can I change these audio parameters in GRC? What other parameters can be changed in ~/.gnuradio/config.conf or by call? I like to reduce the audio samplerate down to 1000 Hz or up to 192 kHz -- is there any limit to do this when the hardware supports it? The sample rate in GNU Radio is a parameter for the audio source and sink - I think you can enter any value there. Are you sure your hardware actually supports all those sample rates? I suspect the reported sample rates are software rates from the mixer and not native rates of the hardware. I have hardware that only supports 44.1 and 48 kHz yet I get the same list as you get. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] No response when using self-compiled FPGA code
Hi List, I compiled the newest fpga code from the uhd-repository (u2_rev3) with Xilinx' ISE 12.2. I also used the newest firmware which is available online (20100901) and also tried some other versions but the USRP2 does not send a response to arp requests or icmp ping messages. So uhd_usrp_probe and uhd_find_devices does not work anymore. Is there a known issue on using self-compiled fpga binaries? Do I need any arguments to make? I just compiled the code by running make and it finished successfully and generated the u2_rev3.bin. Some more informations: Firmware starts normally and receives ethernet arp packets (debugged via serial port - eth_pkt_inspector becomes called when the arp package is received). The HW seems to be ok because the uhd images from ettus' website work fine for me. Cheers, Matthias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 and external RF tuner
Hi all, I am working with a usrp2+BasicRx and an external tuner with a 21.4 MHz IF output and a bandwidth of about 20 MHz. The same setup but with usrp1 (instead of usrp2) it's working well. Now I am injecting a tone at 21.45 MHz (-60 dBm) at the input of the BasicRX and set the usrp2 freq at 21.4MHz (with set_rx_freq() UHD API). The problem is that: a) with sample rate of about 3.125M I have 2 strong spuriouses. The first in the middle of the FFT (FFTDIM/2) and the second one at about the middle of the second half of the FFT b) with a sample rate =3.125 the second spurious disappear but the first at FFTDIM/2 is still present. In both case I can also see the tone at 21.45MHz. To compute the spectrum I use matlab [10*log10(|fftshift(fft(signal*window))|^2)]. Am I doing mistakes or someone have the same problem ? Suggestions ? Thanks in advance Luca ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Two different rxpath in one top_block, how to switch between them when the program is running?
hi all, recently, i want to put two different rxpath in one top_block, and switch them when the program is running, but i failed : class my_top_block(gr.top_block): def __init__(self, ..): gr.top_block.__init__(self) self.txpath = usrp_transmit_path.usrp_transmit_path(.) self.rxpath = usrp_receive_path.usrp_receive_path(.) self.connect(self.rxpath) self.connect(self.txpath) . if(..): tb.rxpath = usrp_another_rxpath() # usrp_receive_path() and usrp_another_rxpath have completely different blocks connected but the same usrp_souce it seems that the rxpath can not be changed when the top_block is running, or maybe i did it in a wrong way, could anyone tell me how to do it right?( how and when to switch the two rxpath?) any help will be appreciated! sincerely, shanki___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
You are using a very old RFX2400 which is configured with its own onboard oscillators instead of using the master oscillator from the motherboard. You can reconfigure it to work with USRP2 by following the directions under Synchronizing all daughterboard LOs here: http://gnuradio.org/redmine/wiki/1/USRPClockingNotes Matt On 08/31/2010 05:37 PM, Joseph Wamicha wrote: Hi, - I'm now using the uhd firmware and fpga code (txrx_uhd_20100706.bin and u2_rev3_uhd_20100706.bin images). - I get some interesting results; when running the examples, it appears that the daughterboard can not be recognized and is unknown. - I'm not sure if this in any way will affect the results but due to firmware/fpga incompatibilities between the host machine code and the firmware fpga code (Error: Expected fpga compatibility number 1, but got 0:), I changed USRP2_FPGA_COMPAT_NUM and USRP2_FW_COMPAT_NUM to 0 and 5 from 1 and 6 in host/lib/usrp/usrp2/fw_common.h. I was then able to run the host/examples code. The code is straight out of the repository. Please find the results below: r...@astrodonius:git-uhd/host/examples# ./benchmark_rx_rate Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application notes on buffer resizing. Warning: unknown dboard-id or dboard-id combination: unknown (0x0007) - defaulting to the unknown board type Warning: unknown dboard-id or dboard-id combination: unknown (0x000b) - defaulting to the unknown board type RX samples per packet: 362 TX samples per packet: 363 Recv pirate num frames: 89 Using Device: Simple USRP: Device: usrp2 device Mboard: usrp2 mboard0 - rev 4:0 RX DSP: usrp2 ddc0 RX Dboard: usrp2 dboard (rx unit) RX Subdev: Unknown - unknown (0x0007) TX DSP: usrp2 duc0 TX Dboard: usrp2 dboard (tx unit) TX Subdev: Unknown - unknown (0x000b) OTesting receive rate 0.50 Msps (10.00 second run) Received packets: 13813 Received samples: 5000306 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 0.50 Msps Testing receive rate 1.00 Msps (10.00 second run) Received packets: 27625 Received samples: 1250 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 1.00 Msps Testing receive rate 2.00 Msps (10.00 second run) Received packets: 55249 Received samples: 2138 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 2.00 Msps Testing receive rate 4.00 Msps (10.00 second run) Received packets: 110498 Received samples: 4276 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 4.00 Msps Testing receive rate 8.33 Msps (10.00 second run) Received packets: 230203 Received samples: 8486 Lost samples: 0 Lost packets: 0 (approximate) Sustained receive rate: 8.33 Msps Testing receive rate 16.67 Msps (10.00 second run) Received packets: 460190 Received samples: 166588780 Lost samples: 78192 Lost packets: 216 (approximate) Sustained receive rate: 16.658847 Msps Testing receive rate 25.00 Msps (10.00 second run) ./lib/usrp/usrp2/fw_common.h Received packets: 683928 Received samples: 247581936 Lost samples: 2418160 Lost packets: 6680 (approximate) Sustained receive rate: 24.758184 Msps Done! r...@git-uhd/host/examples# ./rx_timed_samples Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application notes on buffer resizing. Warning: unknown dboard-id or dboard-id combination: unknown (0x0007) - defaulting to the unknown board type Warning: unknown dboard-id or dboard-id combination: unknown (0x000b) - defaulting to the unknown board type RX samples per packet: 362 TX samples per packet: 363 Recv pirate num frames: 89 Using Device: Simple USRP: Device: usrp2 device Mboard: usrp2 mboard0 - rev 4:0 RX DSP: usrp2 ddc0 RX Dboard: usrp2 dboard (rx unit) RX Subdev: Unknown - unknown (0x0007) TX DSP: usrp2 duc0 TX Dboard: usrp2 dboard (tx unit) TX Subdev: Unknown - unknown (0x000b) Setting RX Rate: 6.25 Msps... Actual RX Rate: 6.25 Msps... Setting device timestamp to 0... Begin streaming 1000 samples, 3 seconds in the future... OGot packet: 362 samples, 3 full secs, 0.00 frac secs Got packet: 362 samples, 3 full secs, 0.58 frac secs Got packet: 276 samples, 3 full secs, 0.000116 frac secs Done! r...@astrodonius:git-uhd/host/examples# ./tx_timed_samples Creating the usrp device with: ... Target recv sock buff size: 5000 bytes Actual recv sock buff size: 131071 bytes Warning: The recv buffer is smaller than the requested size. The minimum recommended buffer size is 5000 bytes. See the USRP2 application notes on
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
I'll need to do some re-soldering and burn-db-eeprom with USRP1 and hopefully this should fix the problem: http://gnuradio.org/redmine/wiki/1/USRPClockingNotes Also, since you use UHD, you can change the daughterboard ID of a daughterboard on a USRP2 from your host PC using: prefix/share/uhd/utils/uhd_burn_db_eeprom An example of changing the DBID for a DBSRX is show here: http://www.ettus.com/uhd_docs/manual/html/dboards.html#id1 Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
On 09/01/2010 12:51 PM, Jason Abele wrote: I'll need to do some re-soldering and burn-db-eeprom with USRP1 and hopefully this should fix the problem: http://gnuradio.org/redmine/wiki/1/USRPClockingNotes Also, since you use UHD, you can change the daughterboard ID of a daughterboard on a USRP2 from your host PC using: prefix/share/uhd/utils/uhd_burn_db_eeprom An example of changing the DBID for a DBSRX is show here: http://www.ettus.com/uhd_docs/manual/html/dboards.html#id1 Jason So, Jason, is this because the older FLEX-series boards used an on-board clock that is *different* than the one supplied by the USRP2, and the driver code (either Classic or UHD) assumes a different clock rate than the one that was previously on-board, and thus is mis-programming the PLL? If the two clocks are the same frequency, then I don't understand why changing from clock supplied on-board to clock supplied by USRP2 would fix the problem. Inquiring minds want to know... -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2-FLEX2400 Transmit and Receive problems
On Wed, Sep 01, 2010 at 03:08:53PM -0400, Marcus D. Leech wrote: On 09/01/2010 12:51 PM, Jason Abele wrote: I'll need to do some re-soldering and burn-db-eeprom with USRP1 and hopefully this should fix the problem: http://gnuradio.org/redmine/wiki/1/USRPClockingNotes Also, since you use UHD, you can change the daughterboard ID of a daughterboard on a USRP2 from your host PC using: prefix/share/uhd/utils/uhd_burn_db_eeprom An example of changing the DBID for a DBSRX is show here: http://www.ettus.com/uhd_docs/manual/html/dboards.html#id1 Jason So, Jason, is this because the older FLEX-series boards used an on-board clock that is *different* than the one supplied by the USRP2, and the driver code (either Classic or UHD) assumes a different clock rate than the one that was previously on-board, and thus is mis-programming the PLL? If the two clocks are the same frequency, then I don't understand why changing from clock supplied on-board to clock supplied by USRP2 would fix the problem. Inquiring minds want to know... There are two problems: 1. When daughterboards were built with onboard oscillators, they were all 64MHz (presumably to play nicely with the USRP1 64MHz oscillator), but the USRP2 uses a 100MHz reference. Thus, when the daughterboard driver tunes the synthesizer, it is presuming a 100MHz reference on the USRP2 (actually, the UHD daughterboard drivers ask the motherboard what clock reference frequencies it can provide, and then chooses the best option), thus it would misconfigure the RFX synthesizer because it would not know that the reference frequency was 64MHz. 2. Actually, it never gets to mistuning the synthesizer because we used the daughterboard id to separate the MIMO B version of the RFX (ie. uses refclock from USRP motherboard) from the non-MIMO versions (with oscillator on board). However, the USRP2 (using either raw ethernet or UHD drivers) does not implement the daughterboard control for the non-MIMO versions. Hence why the burn_db_eeprom command is needed to change the daughterboard id. I put an issue in our issue tracker to add a warning to the UHD code and some notes in the daughterboard documentation to let users know about converting non-MIMO versions of the RFX to MIMO versions, I expect the fix will roll into one of the next few releases. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP, GNURADIO, WINDOWS, APPLICATION HELP
Hi everybody, I would like to ask some questions regarding USRP. I really need some help. I got my USRP with a WBX and LP0410. I work on a computer running Windows XP. After I read many thing about how to install the GNU Radio in Windows environment I could install it using MingW. I used the gnuinstall.py python script like many others but when I tried to run my first script in python I got an error message ImportError: No module named gnuradio. I don't know what is the problem, the gnuradio is installed, the latest one GNU Radio 3.3.0. Could anybody help me with some ideas, how to make it work, and what I'm missing. The second question would be. I would like to use the GNU Radio for a real application. I want to make a .NET application with Delphi Prism and to be able to get data from USRP an set data. There are many informations out there to emulate python (there are even DLL files) to be able to run python scripts from a .NET application. What I want is to exchange data with some devices running on 2 ISM bands (433 and 868). I will make an application with Visual Studio 2010 and I would like to be abel to read data through python script, interprete data and display in the form as some value or a therometer showing the value sent by a device. Wireless devices will have ASK, OOK modulation, some simple stuff. Anybody have made something like this and could help me to start it, I'll make all the work but I need some help from those who already made something like this. Do you have any other idea how could I implement this, what other solution do exists? A alternative would be to use LabView but there are problems, too. No documentation or some help. It would be very good to have some DLL files that would implement functions and interface to the USB data, but even if I was searching for a long time, I couldn't find anything. I'm opened to any suggestion, because right now I'm stuck, I don't have any idea. Thank you very much for any idea. I wish everybody a nice day. Best regards, Sam Evans. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp ets-inband repo
I have forked the Ettus github repo (usrp-fpga-mirror) and added a branch with my alternate rx-buffer / timestamp fixes. git://github.com/etschneider/usrp-fpga-inband.git Use the 'ets-inband' branch, I'm leaving master to follow the Ettus upstream. If anyone uses it, please let me know. --Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Newbie question on USRP2, synchronization done by the FPGA?
Hi, Sorry if this is a simple question. I'm trying to figure out what synchronization is done by the FPGA on the USRP2. Does it perform both phase and freq synch? If I want to implement a simple digital modulation tx-rx, do I just need to do timing synchronization? Is there a simple example of basic digital modulation that is a good reference? thanks, -Sam P.S. Sorry if this is a re-post, I can't tell if the other email went thru ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Newbie question on USRP2, synchronization done by the FPGA?
On 09/01/2010 06:47 PM, Sam Keene wrote: Hi, Sorry if this is a simple question. I'm trying to figure out what synchronization is done by the FPGA on the USRP2. Does it perform both phase and freq synch? If I want to implement a simple digital modulation tx-rx, do I just need to do timing synchronization? Is there a simple example of basic digital modulation that is a good reference? thanks, -Sam P.S. Sorry if this is a re-post, I can't tell if the other email went thru ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio I'm not sure what you're asking for, but I'll take a stab at guessing :-) I'll describe what the USRP2 does on the receiver side: o Complex samples the input (which is complex, that is I + Q, baseband, typically) at 100Msps o Filters and decimates that complex sample stream down to whatever sample rate/bandwidth you wish to appear across the 1GiGe interface (and hence into your Gnu Radio application). Your Gnu Radio application then does whatever it does with than complex-sampled stream. That stream is a time-series with fixed and uniform timing, so any discrete-time-series math you want to do on that stream will work. o Both the sample clock and synthesizer clocks can be synchronized to an external source, via the 10MHz SMA inputs, or via the so-called mimo bus. o The FPGA assists in the programming of the various daughter-cards programmable elements, like the PLL synthesizers and variable-gain elements in the gain chain. The transmit side is the logical reverse, with the D/A sampling at 200Msps, and the FPGA interpolating your application data stream as appropriate, and presenting it as a complex sampled baseband stream to the D/A. From there, it is presented to complex mixers on the daughtercard to produce the desired final RF signal. I don't know if this even comes close to answering your question. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Newbie question on USRP2, synchronization done by the FPGA?,
Hi, Thanks for the reply. I guess I am just trying to better understand this diagram: http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/073/7319/7319f3.inline.jpg I understand what the decimating filters are doing, but I'm a little unclear about the NCO. Does this component phase and frequency lock for me, or will I have to code that myself? thanks, -Sam ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Newbie question on USRP2, synchronization done by the FPGA?,
On Wed, Sep 1, 2010 at 8:52 PM, Sam Keene samke...@yahoo.com wrote: Hi, Thanks for the reply. I guess I am just trying to better understand this diagram: http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/073/7319/7319f3.inline.jpg I understand what the decimating filters are doing, but I'm a little unclear about the NCO. Does this component phase and frequency lock for me, or will I have to code that myself? thanks, -Sam No, there is no freq/phase lock in the USRP/USRP2. We have to do this in software. You can reference the dbpsk and dqpsk blocks that we have already written or the newer dbpsk2/dqpsk2 blocks that use newer techniques for the phase, frequency, and timing locks. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Newbie question on USRP2, synchronization done by the FPGA?,
Ok, thanks, One more question... So does that mean we control the NCO from the software? I will have a look at those blocks. thanks, -Sam --- On Wed, 9/1/10, Tom Rondeau trondeau1...@gmail.com wrote: From: Tom Rondeau trondeau1...@gmail.com Subject: Re: [Discuss-gnuradio] Newbie question on USRP2, synchronization done by the FPGA?, To: Sam Keene samke...@yahoo.com Cc: discuss-gnuradio@gnu.org Date: Wednesday, September 1, 2010, 9:03 PM On Wed, Sep 1, 2010 at 8:52 PM, Sam Keene samke...@yahoo.com wrote: Hi, Thanks for the reply. I guess I am just trying to better understand this diagram: http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/073/7319/7319f3.inline.jpg I understand what the decimating filters are doing, but I'm a little unclear about the NCO. Does this component phase and frequency lock for me, or will I have to code that myself? thanks, -Sam No, there is no freq/phase lock in the USRP/USRP2. We have to do this in software. You can reference the dbpsk and dqpsk blocks that we have already written or the newer dbpsk2/dqpsk2 blocks that use newer techniques for the phase, frequency, and timing locks. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Newbie question on USRP2, synchronization done by the FPGA?,
On Wed, Sep 1, 2010 at 9:15 PM, Sam Keene samke...@yahoo.com wrote: Ok, thanks, One more question... So does that mean we control the NCO from the software? I will have a look at those blocks. thanks, -Sam No, the NCO is free running. We compensate for it in software. Tom --- On *Wed, 9/1/10, Tom Rondeau trondeau1...@gmail.com* wrote: From: Tom Rondeau trondeau1...@gmail.com Subject: Re: [Discuss-gnuradio] Newbie question on USRP2, synchronization done by the FPGA?, To: Sam Keene samke...@yahoo.com Cc: discuss-gnuradio@gnu.org Date: Wednesday, September 1, 2010, 9:03 PM On Wed, Sep 1, 2010 at 8:52 PM, Sam Keene samke...@yahoo.comhttp://mc/compose?to=samke...@yahoo.com wrote: Hi, Thanks for the reply. I guess I am just trying to better understand this diagram: http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/073/7319/7319f3.inline.jpg I understand what the decimating filters are doing, but I'm a little unclear about the NCO. Does this component phase and frequency lock for me, or will I have to code that myself? thanks, -Sam No, there is no freq/phase lock in the USRP/USRP2. We have to do this in software. You can reference the dbpsk and dqpsk blocks that we have already written or the newer dbpsk2/dqpsk2 blocks that use newer techniques for the phase, frequency, and timing locks. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Newbie question on USRP2, synchronization done by the FPGA?,
That's no different than a straight analog receiver though, where LO phase is generally not coherent with carrier or modulation phase. So you use PLL or similar demodulators to recover carrier phase Amiright? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org On Sep 1, 2010, at 9:19 PM, Tom Rondeau trondeau1...@gmail.com wrote: On Wed, Sep 1, 2010 at 9:15 PM, Sam Keene samke...@yahoo.com wrote: Ok, thanks, One more question... So does that mean we control the NCO from the software? I will have a look at those blocks. thanks, -Sam No, the NCO is free running. We compensate for it in software. Tom --- On Wed, 9/1/10, Tom Rondeau trondeau1...@gmail.com wrote: From: Tom Rondeau trondeau1...@gmail.com Subject: Re: [Discuss-gnuradio] Newbie question on USRP2, synchronization done by the FPGA?, To: Sam Keene samke...@yahoo.com Cc: discuss-gnuradio@gnu.org Date: Wednesday, September 1, 2010, 9:03 PM On Wed, Sep 1, 2010 at 8:52 PM, Sam Keene samke...@yahoo.com wrote: Hi, Thanks for the reply. I guess I am just trying to better understand this diagram: http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/073/7319/7319f3.inline.jpg I understand what the decimating filters are doing, but I'm a little unclear about the NCO. Does this component phase and frequency lock for me, or will I have to code that myself? thanks, -Sam No, there is no freq/phase lock in the USRP/USRP2. We have to do this in software. You can reference the dbpsk and dqpsk blocks that we have already written or the newer dbpsk2/dqpsk2 blocks that use newer techniques for the phase, frequency, and timing locks. Tom ___ 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] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Malihe, The USRP2 drivers are designed to abstract the user from the device transport, and in normal use you shouldn't have to concern yourself with the transport layer at all. You provide a stream of data in gnuradio, and the USRP2 provides a stream of data out the device (or vice versa). All the magic that happens between should be transparent. To the user, there is no packetization at all on transmitted data -- discrete Ethernet data packets are buffered in the USRP2 and transmitted seamlessly by the device. If you are seeing gaps in signal when viewed on a scope, you are probably experiencing buffer underruns caused by running at a data rate too fast for your CPU to handle. Can you explain the problem you are seeing with your device? Nick Date: Wed, 1 Sep 2010 19:07:26 -0600 From: ahmad...@ualberta.ca To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA? Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe ___ 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] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
On Wed, Sep 01, 2010 at 07:07:26PM -0600, Malihe Ahmadi wrote: Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. The MICTOR debug connector, J301, has 32 uncommitted pins and 2 clks. It's currently configured as an output, but you can use it for whatever you like. Look in u2_rev3.v and/or u2_core.v. output [31:0] debug, output [1:0] debug_clk, That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC's graphical sinks performance issues
Hi there, I'm having trouble getting hardware acceleration to work with grc's graphical sinks. With the regular sinks the refresh rate is always choppy and sluggish until it eventually locks up completely. And when I tried the OpenGL sinks it turned out they're even slower than the regulars, especially the FFT Sink in which even the buttons can't be pressed with most my configurations, though I have to mention that with the OpenGL version the waveform in the middle of the sink's window is drawn fine, it's just that the buttons are unclickable. That's when I figured it's a graphics issue and not due to the cpu. All the other graphically intensive programs work fine on this machine, so I know I got the driver properly configured. Anyone having the same issues? Any help is appreciated P.S. - My configuration: I'm using the latest gnuradio source code along with a USRP2 and a WBX board, decimation is at 4, the FFT Sink's bin size is set at 2048 and its sampling rate is at 1,000,000. The computer is a Thinkpad X61s with a Core2Duo 1.6GHz processor and an Intel GM965 graphics controller. Regards, -- View this message in context: http://old.nabble.com/GRC%27s-graphical-sinks-performance-issues-tp29600609p29600609.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
P.S. - My configuration: I'm using the latest gnuradio source code along with a USRP2 and a WBX board, decimation is at 4, the FFT Sink's bin size is set at 2048 and its sampling rate is at 1,000,000. The computer is a Thinkpad X61s with a Core2Duo 1.6GHz processor and an Intel GM965 graphics controller. This is where your problem is. If you are using decimation of 4 then you are sending 25 million samples per second to the display. However, you are telling it that its sample rate is 1 Million. Thus you are giving it 25 times as many samples per second as it expects. Tell it to expect 25 MS/s and you won't have any problem. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC's graphical sinks performance issues
On 09/02/2010 12:52 AM, Matt Ettus wrote: This is where your problem is. If you are using decimation of 4 then you are sending 25 million samples per second to the display. However, you are telling it that its sample rate is 1 Million. Thus you are giving it 25 times as many samples per second as it expects. Tell it to expect 25 MS/s and you won't have any problem. Matt 25Msps with a 1.6GHz CPU, with default FFT display update rate? Aint gonna happen, in my experience. Smaller bandwidth, lower FFT update rate (5Hz, instead of the default which is much higher). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
