Re: [Discuss-gnuradio] weird interaction between start of burst and oscillator phase
On 10/25/2010 11:20 PM, Arun Pillai wrote: Hi folks, I am seeing a very bizarre problem. I am using the USRP2 to transmit a stream of packets interleaved with silence. Each USRP packet obviously spans multiple Ethernet packets. When I send each USRP packet as part of its own burst (i.e. start of burst = 1 on the first ethernet packet corresponding to a USRP packet, end of burst = 1 on the last ethernet packet corresponding to that USRP packet, immediate = 1 on all packets, and repeated for each USRP packet), the channel that I see at the receiver for each packet has a very different phase even after accounting for CFO. However, if I send all the USRP packets along with complex zeros for intervening silence as one burst, I see that the channel phase is as expected i.e. the change in channel phase from packet to packet corresponds to exactly the CFO. Any idea why this could be happening? Thanks, Arun. See line 61 of dsp_core_tx.v, which is the NCO. During a burst, "run" is asserted, so the NCO continues to turn. When run is deasserted (i.e. between bursts), the NCO is reset to 0. Alternative ways of handling this would be to either just freeze the NCO when run is deasserted, or allow it to run all of the time. There are various reasons why you might want one mode or another. If this behavior is not desired, you can easily change those lines to have the NCO run all the time. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] weird interaction between start of burst and oscillator phase
Hi folks, I am seeing a very bizarre problem. I am using the USRP2 to transmit a stream of packets interleaved with silence. Each USRP packet obviously spans multiple Ethernet packets. When I send each USRP packet as part of its own burst (i.e. start of burst = 1 on the first ethernet packet corresponding to a USRP packet, end of burst = 1 on the last ethernet packet corresponding to that USRP packet, immediate = 1 on all packets, and repeated for each USRP packet), the channel that I see at the receiver for each packet has a very different phase even after accounting for CFO. However, if I send all the USRP packets along with complex zeros for intervening silence as one burst, I see that the channel phase is as expected i.e. the change in channel phase from packet to packet corresponds to exactly the CFO. Any idea why this could be happening? Thanks, Arun. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Is there a way to send AM signal from a file?
I have a file with a number of 0's and 1's. And I want to send it via AM modulation But I couldn't find any SIMPLE AM modulation block Do I have to write a new AM mod block? -- Seokseong Jeon a.k.a., *Gee Songsong* combined course in ITCE (IT Convergence Engineering), POSTECH WCU program mail: gee.songs...@gmail.com phone: +82)10-8338-1229 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question GNU Radio swig Path
On Sun, Oct 24, 2010 at 10:37 PM, Matt Dunstan wrote: > Hi, > > i have a question related to GNU Radio installation. I followed all > steps described in http://gnuradio.org/redmine/wiki/1/MingwInstallMain, but > when I want to install gnuradio 3.3.0 it says that it can't find swig. It > finds python becasue it is decalred in Environment Variables under Path with > the value of "C:\Python26". Swig is installed under > C:\msys\1.0\local\swigwin-1.3.40, the problem is that I don't know how I > sould declare the swig path and where. I tried in the same place as Python > path but on GNU Radio installation it gives error that it can't find some > gr_vmcircbuf.cc file. Can anybody give some ideas regarding this problem? I > have bought the USRP 3 month ago and I could not try it because I couldn't > install GNU Radio under Windows XP using MinGW, and it starts to make me > very angry. Thank you very much for any help. > > Best regards, > Matt Dunstan. I'm afraid I've actually never installed GNU Radio on Windows, so I can't be of much help here. Windows, as you've probably gathered, is woefully under-supported by our community. One of these days I'll get around to trying it out in Windows... To attempt to help you out, Swig should just need to be in the PATH environmental variable. If it passes configure, it's found it. So if you've made it to the make part and that's where you're getting the gr_vmcircbuf.cc file, I'm not sure what to tell you. The file is in gnuradio-core/src/lib/runtime. Is there any way you can get a Linux installation up and running (even as a virtual machine)? Ubuntu's pretty easy to install and work with these days. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR Block Input Item Size
On Mon, Oct 25, 2010 at 12:36:13PM -0700, Andrew Fong wrote: > Hi, > > I want to create a block that requires 1 input items and > produces 1 output items on a single stream. However, I'm > getting the following message: sched: is > requesting more input data > than we can provide. > ninput_items_required = 1 > max_possible_items_available = 8191 > If this is a filter, consider reducing the number of taps. > > How do I get the block to operate as I want? I thought inheriting > from gr_sync_block with 1:1 input/output rate would work, but it > doesn't seems to be the case. > > Andrew If you require 10,000 input items at a time, you must call set_output_multiple(1) in your constructor. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] remark on custom block + python behavior on Beagleboard
On Mon, Oct 25, 2010 at 11:38:00AM -0400, Almohanad Fayez wrote: > Hi, sent an email a while back about what I thought was a scheduler > issue with gnuradio on the beagleboard. Basically I've been writing > custom GNU Radio block for the OMAP's DSP and running them on the > beagleboard. On occassions when I'm running multiple blocks, GNU > Radio would parse my flowgraph but then get lost and never starts > the flowgraph. I've always thought it was an issue with my code but > it turned out to be a python issue and I'm not sure if it's specific > to my platform or python in general. python basically generates > optimizied pre-interpred python files *.pyo and *.pyc. and as it > happens, some of these files are not refreshed when I make changes > to my python source file I managed to debug the issue where at the > point where gnuradio calls the c++ file that handles the swig call > handling "gnuradio_swig_py_runtime.cc". This file is able to detect > the python block so the "custom_blocks.cc" file generated by the > howto-write-a-custom-block auto tools. then there is a call placed > to the constructor "gr_basic_block.cc" and that's where gnuradio > gets lost into oblivion. > I was able to finally fix this problem by writing a script that > deletes all of the pyc and pyo files associated with my library and > flowgraph. my question is, is this a know python issue, an issue > with the custom gnuradio block, or an issue with the platform? I > managed to recreate this problem using the custom block 3.2.1 and > 3.2.2 templates and I was also able to recreate it by using the > original how to square a number example. > thanks. > > al Is there any chance that sometime you run the code as root, and sometimes as a non-root user? If so, depending on the details of your installation, you may have a situation where the non-root user cannot remove the old and out of date *.pyo and *.pyc files. I've never seen the problem you describe, thus I suspect that it may have to do with permissions on the files and/or directories involved. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] demo of a live fft plot running remotely through a ssh terminal
That's really cool. I could use something like that for a machine with a USRP2 that I sometimes control remotely. How did you get the FFT to display in ASCII text via an SSH terminal? Was it a modification of "usrp2_fft.py"? Or is it something you wrote custom for yourself? I made a little c++ header with 2 functions: - a log-power-dft (in case you dont want to link fftw) - a function to turn dft bins into a printable string http://pastebin.com/R6dS9xUj There is an example in uhd that uses this to make a live dft plotter. The app also uses a little bit of curses for clearing the screen and getting the terminal dimensions. See host/examples/rx_ascii_art_dft.cpp -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Creating a USRP2 sink and/or source
> I just started using the USRP2 with GNURadio. I have made a script > that uses the gnuradio library, but it does not try and interface with > the USRP2. > > How do you do this? Or alternatively is there a list of gnuradio > functions that I can look at that has how to set this up? I have > tried doing a google search for this, but it turns up nothing that I > have found to be helpful. > > > Thanks > Alex > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > Easiest way to gain quick experience is to use "grc" -- use the gnuradio-companion command. It will allow you to pick and connect various signal processing blocks, including all the usual Gnu Radio sources/sinks. Even if you don't ultimately use the resulting python code in your application, it can elucidate for you how the blocks are created and connected. -- 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
[Discuss-gnuradio] Creating a USRP2 sink and/or source
I just started using the USRP2 with GNURadio. I have made a script that uses the gnuradio library, but it does not try and interface with the USRP2. How do you do this? Or alternatively is there a list of gnuradio functions that I can look at that has how to set this up? I have tried doing a google search for this, but it turns up nothing that I have found to be helpful. Thanks Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] demo of a live fft plot running remotely through a ssh terminal
On 10/25/2010 03:45 PM, Steve Mcmahon wrote: > Josh: > > That's really cool. I could use something like that for a machine with a > USRP2 that I sometimes control remotely. How did you get the FFT to display > in ASCII text via an SSH terminal? Was it a modification of "usrp2_fft.py"? > Or is it something you wrote custom for yourself? > > Steve McMahon > Yes, that was cool. But what's wrong with simply using X forwarding over SSH? Works for me. -- 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] demo of a live fft plot running remotely through a ssh terminal
Josh: That's really cool. I could use something like that for a machine with a USRP2 that I sometimes control remotely. How did you get the FFT to display in ASCII text via an SSH terminal? Was it a modification of "usrp2_fft.py"? Or is it something you wrote custom for yourself? Steve McMahon --- On Mon, 10/25/10, Josh Blum wrote: > From: Josh Blum > Subject: [Discuss-gnuradio] demo of a live fft plot running remotely through > a ssh terminal > To: "Discuss-gnuradio@gnu.org" > Date: Monday, October 25, 2010, 8:28 AM > http://www.zshare.net/video/819531116687965a/ > > ___ > 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] GR Block Input Item Size
Hi, I want to create a block that requires 1 input items and produces 1 output items on a single stream. However, I'm getting the following message: sched: is requesting more input data than we can provide. ninput_items_required = 1 max_possible_items_available = 8191 If this is a filter, consider reducing the number of taps. How do I get the block to operate as I want? I thought inheriting from gr_sync_block with 1:1 input/output rate would work, but it doesn't seems to be the case. Andrew ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] shmat issue
Quoting Philip Balister (phi...@balister.org): > >On Wed, Oct 20, 2010 at 01:02:15PM -0400, Philip Balister wrote: > >>On 10/19/2010 10:51 PM, Eric Blossom wrote: > >>OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 * > >>PAGE_SIZE. Need to puzzle through this a little more. This is the > >>failing check in the kernel. > > > >OK. What's PAGE_SIZE on arm? > > PAGE_SIZE is still 4096, there is an additional restriction on the > address passed to shmat(). Is the additional restriction '4 * PAGE_SIZE'? If so, look in the circular_buffer.cc for kalibrate and change the line that reads: m_pagesize = getpagesize(); to m_pagesize = 4 * getpagesize(); It may be that easy. The rest of the logic should work. Alternatively, you can force the use of Posix shared memory and see if that works for kalibrate on your platform. (The easiest thing to do would be to look for D_HOST_OSX and make sure those #ifdef's are the ones that gets compiled.) Email me with your results and I'll add some code to make arm work in the next version of kal. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio_alsa: problem with "valve" at head of audio_alsa sink sub-graph
On 10/25/2010 11:25 AM, Almohanad Fayez wrote: > Marcus, this is a problem with the > gnuradio/gr-audio-alsa/src/audio_alsa_source.cc. I ran into a few > weeks ago and i managed to find a quick and dirty fix for. > > I'm assuming that you're stopping the flow graph and restarting it > again. if you look into the "check_topology" method. There's a FIXME > there, what I beleieve is happening, is that when you try to restart > the flowgraph after stopping it GNU Radio is trying to reset your > sound card and it thinks that it's in a corrupt state. > > My fix was to add a "static bool" variable that skips the > "snd_pcm_hw_params(d_pcm_handle, d_hw_params);" function call. the > flag is "static" just so you can detect your first entry. After that > run make and make install and things should work fine. > > > al > I'm not actually stopping/restarting the flow-graph. I'm simply opening a 'valve' block that's at the head of the sub-graph that feeds the audio sink. I'll look at the "check_topology' method as you suggest, though. This happens as soon as I "open" (stop data flow) the valve block. -- 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] RFX 1800 -> RFX 900
On 10/25/2010 10:31 AM, psolic wrote: Hey all, i did: burn-db-eeprom -A –force -t rfx900 You need to use rfx900_mimo_b Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RFX 1800 -> RFX 900
Hey all, i did: burn-db-eeprom -A –force -t rfx900 on my RFX1800 card. However, the application in 900 Mhz band seems to be weird. I started usrp_two_tone_loopback.grc with 900Mhz on transmitt (patched RFX1800) and receive(RFX900), but GRC says that its TX/RX (on patched RFX1800) cannot tune that freq. Anyone had similar problems ? BTW is there any software that can parse .py to .grc ? Many thanks for the answers. -- View this message in context: http://old.nabble.com/RFX-1800--%3E-RFX-900-tp30045336p30045336.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] cant open usrp
On Mon, Oct 25, 2010 at 11:15 AM, zhdiamond wrote: > > My USRP has something wrong when started. when i want to open USRP, I input > the command: usrp_fft.py -R B. but the system mentioned that: > RuntimeError: cant open usrp, failed to load fpga bitstream > /usr/share/usrp/rev4/std_2rxhb_2tx.rbf. > what 's wrong with my USRP? how can I fixed it? During the fpga load, one of the LEDs will turn on and stay on for the duration the loading process, which is about one second. If the LED never turns on, there is a problem occurring prior to the loading of the fpga. Otherwise, it is likely that the fpga load itself is failing. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Having firmware trouble in USRP2 - txrx_wbx_udp_20100507
You are running experimental images. You need matching experimental host code: http://gnuradio.org/cgit/jblum.git/log/?h=udp -josh On 10/25/2010 04:11 AM, Vladutzzz wrote: Hi everyone! I recently updated the USRP2 firmware to txrx_wbx_UDP_20100507.bin from http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries . I also downloaded and installed u2_rev3-udp-ise12-20100615.bin from the same link. These images are specifically designed for WBX with UDP. After putting the SD card into the USRP2, I've tried pinging the USRP2, the process ending unsuccessfully, which I've read somewhere it's expected since it doesn't have a fully implemented IP stack. But it doesn't reply to "find_usrps" nor "benchmark_tx" nor "usrp2_probe". How can I test to see if the firmware and fpga images are actually functioning and the board is operating properly? I am pretty stuck with this and would really appreciate any useful input. Thanks, Vlad. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] remark on custom block + python behavior on Beagleboard
On 10/25/2010 11:38 AM, Almohanad Fayez wrote: I was able to finally fix this problem by writing a script that deletes all of the pyc and pyo files associated with my library and flowgraph. my question is, is this a know python issue, an issue with the custom gnuradio block, or an issue with the platform? I managed to recreate this problem using the custom block 3.2.1 and 3.2.2 templates and I was also able to recreate it by using the original how to square a number example. Python is supposed to delete those .pyc and .pyo files whenever you ask it to run a matching .py file, _if_ the .py file is younger. Otherwise, it assumes you haven't changed the .py file, and saves a bit of time by jumping straight to the compiled files. One time where I've seen similar behaviour is when the .py is a symlink (link.py -> real.py, say). Opening and modifying link.py changes the modification time of real.py, but not link.py, so if you ask python to compile link.py, it still looks older than link.pyc that it created before you modified anything. It's possible there are other situations where this would happen, that's just the one time that I remember it happening to me. -- Patrick Yeon ThinkRF 613-369-5104 x418 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] remark on custom block + python behavior on Beagleboard
Hi, sent an email a while back about what I thought was a scheduler issue with gnuradio on the beagleboard. Basically I've been writing custom GNU Radio block for the OMAP's DSP and running them on the beagleboard. On occassions when I'm running multiple blocks, GNU Radio would parse my flowgraph but then get lost and never starts the flowgraph. I've always thought it was an issue with my code but it turned out to be a python issue and I'm not sure if it's specific to my platform or python in general. python basically generates optimizied pre-interpred python files *.pyo and *.pyc. and as it happens, some of these files are not refreshed when I make changes to my python source file I managed to debug the issue where at the point where gnuradio calls the c++ file that handles the swig call handling "gnuradio_swig_py_runtime.cc". This file is able to detect the python block so the "custom_blocks.cc" file generated by the howto-write-a-custom-block auto tools. then there is a call placed to the constructor "gr_basic_block.cc" and that's where gnuradio gets lost into oblivion. I was able to finally fix this problem by writing a script that deletes all of the pyc and pyo files associated with my library and flowgraph. my question is, is this a know python issue, an issue with the custom gnuradio block, or an issue with the platform? I managed to recreate this problem using the custom block 3.2.1 and 3.2.2 templates and I was also able to recreate it by using the original how to square a number example. thanks. al ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio_alsa: problem with "valve" at head of audio_alsa sink sub-graph
Marcus, this is a problem with the gnuradio/gr-audio-alsa/src/audio_alsa_source.cc. I ran into a few weeks ago and i managed to find a quick and dirty fix for. I'm assuming that you're stopping the flow graph and restarting itagain. if you look into the "check_topology" method. There's a FIXMEthere, what I beleieve is happening, is that when you try to restartthe flowgraph after stopping it GNU Radio is trying to reset yoursound card and it thinks that it's in a corrupt state. My fix was to add a "static bool" variable that skips the"snd_pcm_hw_params(d_pcm_handle, d_hw_params);" function call. theflag is "static" just so you can detect your first entry. After thatrun make and make install and things should work fine. al -Original Message- From: Marcus D. Leech To: Discuss-gnuradio Sent: Sat, Oct 23, 2010 4:17 pm Subject: [Discuss-gnuradio] audio_alsa: problem with "valve" at head of audio_alsa sink sub-graph In my application I have a sub-graph that terminates an an audio_alsa sink. At the "head" of this sub-graph, I've placed a valve, so that I can turn off data being copied to the audio_alsa sink. When this valve transitions from "closed" (data flowing) to "open" (data *not* flowing), it provokes the following error in audio_alsa_sink: audio_alsa_sink[plughw:0,0]: snd_pcm_hw_params failed: File descriptor in bad state terminate called after throwing an instance of 'std::runtime_error' what(): check topology failed on audio_alsa_sink(1) using ninputs=1, noutputs Am I being an idiot here? Should this work? If not, why not? Further, there's a "OK to block" parameter for an audio_alsa_sink. What does it do? -- 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How can I get the code in EEPROM of ＵＳＲＰ
I know that, the EEPROM stored the PID / VID and the initial program of AD9862. But where can I get this code? Is it in ＵＳＲＰ program? -- View this message in context: http://old.nabble.com/How-can-I-get-the-code-in-EEPROM-of-%EF%BC%B5%EF%BC%B3%EF%BC%B2%EF%BC%B0-tp30048920p30048920.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
[Discuss-gnuradio] cant open usrp
My USRP has something wrong when started. when i want to open USRP, I input the command: usrp_fft.py -R B. but the system mentioned that: RuntimeError: cant open usrp, failed to load fpga bitstream /usr/share/usrp/rev4/std_2rxhb_2tx.rbf. what 's wrong with my USRP? how can I fixed it? -- View this message in context: http://old.nabble.com/cant-open-usrp-tp30048854p30048854.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] USRP external clocking outdated documents
That is pretty much everything you need to do. I'm using a 60 MHz clock and calling set_fpga_master_clock() modifies the main master clock variable, which is used in the tuning of the DDC and also most (if not all) of the daughterboard drivers query this as well. I've tested this using BasicRX, LFRX and WBX. juha On Mon, Oct 25, 2010 at 10:47, Burak TUYSUZ wrote: > Hi, > > USRP external clocking documents are outdated so I could not find answer to > my questions. > I modified the USRP board for external clock input, but which parameters > should I change in the code for a different clock frequency (10MHz). > I guess in python I can set it by writing > > self.u.set_fpga_master_clock_freq(1000) > > but I guess more files should be edited(I am using basic rx). > I am having some hard times with this so if you could help I will really > appreciate it > Thank you in advance. > > > > > > > > ___ > 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] UDP driver
I also have a similar problem. It seams there is no firmware that can support WBX,and UDP, yet. If someone knows more about this please let us know. Also any other solutions to our predicament would also suffice. Thank you. Vlad. Marcus D. Leech wrote: > > On 10/20/2010 03:57 PM, Jorge Miguel wrote: >> Hello, >> >> I burned in my SD card the UDP FPGA image and the FIRMWARE of basic tx >> and rx for UDP >> >> http://code.ettus.com/redmine/ettus/attachments/74 >> http://ettus.com/u2bin/txrx_udp_20100507.bin >> >> After powering the USRP2, only the two leds of Image and FPGA and on, >> which is fine. >> >> My feeling was that I can be able to ping the USRP to 192.168.10.2 >> being my host computer 192.168.10.1 >> I cannot see the USRP. In fact running a sniffer I see nothing from >> the USRP. (Neither in Windows nor Ubuntu) >> >> I made sure that there is no firewall blocking the UDP traffic. >> >> What can be wrong? >> Many thanks, >> Jorge. >> >> > The "UDP Beta" firmware does *not* have a complete IP stack, and doesn't > reply to ICMP ECHO (ping) traffic. > > If you are heading down the UHD road (which you should be), then you'll > need the latest UHD Firmware/FPGA images: > > http://www.ettus.com/downloads/uhd_images/ > > -- > 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 > > -- View this message in context: http://old.nabble.com/UDP-driver-tp30013401p30020429.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
[Discuss-gnuradio] Having firmware trouble in USRP2 - txrx_wbx_udp_20100507
Hi everyone! I recently updated the USRP2 firmware to txrx_wbx_UDP_20100507.bin from http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries . I also downloaded and installed u2_rev3-udp-ise12-20100615.bin from the same link. These images are specifically designed for WBX with UDP. After putting the SD card into the USRP2, I've tried pinging the USRP2, the process ending unsuccessfully, which I've read somewhere it's expected since it doesn't have a fully implemented IP stack. But it doesn't reply to "find_usrps" nor "benchmark_tx" nor "usrp2_probe". How can I test to see if the firmware and fpga images are actually functioning and the board is operating properly? I am pretty stuck with this and would really appreciate any useful input. Thanks, Vlad. -- View this message in context: http://old.nabble.com/Having-firmware-trouble-in-USRP2---txrx_wbx_udp_20100507-tp30020320p30020320.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
[Discuss-gnuradio] USRP external clocking outdated documents
Hi, USRP external clocking documents are outdated so I could not find answer to my questions. I modified the USRP board for external clock input, but which parameters should I change in the code for a different clock frequency (10MHz). I guess in python I can set it by writing self.u.set_fpga_master_clock_freq(1000) but I guess more files should be edited(I am using basic rx). I am having some hard times with this so if you could help I will really appreciate it Thank you in advance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] demo of a live fft plot running remotely through a ssh terminal
http://www.zshare.net/video/819531116687965a/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
