Re: [Discuss-gnuradio] Help : I am trying to know the grc.
On 18-03-11 23:40, Tachwali, Yahia wrote: Try (100,100) for window size Kind regards, Yahia Tachwali Is the trick here, to reduce the cpu load by decreasing the size of the window? Gr. Sim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help : I am trying to know the grc.
On Sat, Mar 19, 2011 at 12:00 PM, Sim IJskes wrote: > On 18-03-11 23:40, Tachwali, Yahia wrote: >> >> Try (100,100) for window size >> >> Kind regards, >> Yahia Tachwali >> > > Is the trick here, to reduce the cpu load by decreasing the size of the > window? If the hardware provides even just basic graphics acceleration the window size will not have much effect on CPU load. Reducing the FFT size and the frame rate often helps reducing CPU load. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 100 Msps FPGA code for USRP N210 - Gnu Spectrum analyzer
On Mar 18, 2011, at 3:58 PM, Moeller wrote: > Thanks for publishing. This is very impressive, using Gnuradio as a spectrum > analyzer. Thanks. It's been a fun project. > - What about compensating the spectral shape within the measurement bandwidth? Seems doable. I'm only now learning signal processing (I'm software guy by training and trade), so I'll do some investigation. If someone else wants to take it on, it's on my list to post the MATLAB code, too, but I need to do some polishing first. > - Movie: why do you have spectral lines walking in both directions? Good question. They also appear in the color plots as diagonals in opposite directions. Our hunch is that they're related to the DBSRX2's frequency synthesis and a function of the center frequency. > Can it be predicted and compensated? Seems likely. We've been playing with ways to isolate the components related to the baseband the those related to the center frequency. > - Can half of your scan speed be achieved by using original FPGA, > taking snapshots and do all processing on the PC? Or do you need some > special processing that needs a better timing within the FPGA? I'm sure that would work. The code that drives the scan and crunches the data doesn't really care what the sample rate is. The scan step for the plots I posted was 100 KHz. Lately we've been using 100MHz/1024 to be the same as the periodogram resolution, which makes horizontal steps and vertical steps in the periodogram matrix the same. The movie speed is a result of the 60 frames per second rate of the tools I used to make it. When viewing it in MATLAB, we usually use much higher frame rates. We didn't really start out to do a spectrum analyzer. We're working on a filter that needs to operate at 100 Msps in the FPGA so we wanted to see what the signal looks like right out of the ADCs. Then we noticed internal noise in the system and wanted to see the big picture so we could pick out a quiet place to do our testing and here we are. -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Spectrum Sensing Help, (variant for FunCube Dongle?)
On Fri, Mar 18, 2011 at 4:29 PM, Moeller wrote: > On 18.03.2011 18:10, devin kelly wrote: > > I have two problems with my data though. In the file attached is some TV > spectrum (left half) and noise (right half). > > My first question is this: why isn't the spectrum for the TV signal flat, > it seems to bob up and down. Note that each segment is from a different > > FFT, that is each FFT produces that oval shape. At first I thought this > had something to do with the window I was using but I've tried hamming, > > blackman-harris, and rectangular windows and they all have this effect. > > Why should it be flat? On the transmission side OFDM is quite flat. > Typically (NLOS conditions) you will receive multiple paths and they > interfere. > The "frequency selective fading" effect is very strong for wide-band > signals like DVB-T. > NB signals like GSM assume the "flat fading" model, by contrast. > > I suppose flat is the wrong word. If you look at the image I provided in the first email you'll find that all the FFT outputs have this hump shape to them. > > My second question is why isn't the transition between TV spectrum and > noise more smooth? It looks like it could be smooth but the gain seems to > jump > > for an FFT right after 566 MHz and then settle down again. I thought > this might be the AGC but I've tried different attack/decay rates, different > > reference levels, etc with the agc2_cc block but the problem remains. > > Can you switch off the AGC? AGC can destroy the whole spectrum measurement. > Single spikes could be spurious mixing products from the receiver itself. > I've only started using the AGC block very recently. I started using because I wanted some way to control the AGC. This makes me think of the question, is the AGC on by default? That is, if I don't have an AGC block will the AGC be doing anything? Also, in the first two or three ICs in the WBX there is a digitally controlled attenuator and an LNA, those are part of the AGC correct? > A global filtering shape is expected from the analog RF filters. > Of course, on the borders of FFT blocks you have incorrect transitions, > depending on the shape within the reception bandwidth. > I assume this could be compensated by scaling the FFT values. > This is going to be the next thing I try. > To get the spectrum more smooth, you have to capture longer signals > within the blocks of measurement bandwidth, for averaging the PSD estimate. > > > Any help with either of these questions would be appreciated, > > Devin > > Do you want to publish the program? I think it would be very interesting > for the examples section of Gnuradio. Surely, you will get support from > the Gnuradio community to improve the sensing function. > > Btw, did anybody try to write a spectrum sensor with the Funcube USB > dongle? > This would be a low-cost alternative. The measurement bandwidth is not > high, > but it can scan a broad range of the spectrum. > Possibly, after switching off AGC, compensating within the meas. bandwidth > and compensating the global filter shape, the result could be quite useful. > (if there are not too many spurious frequency components within the > receiver itself) > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > Thanks Again, Devin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Spectrum Sensing Help, (variant for FunCube Dongle?)
On 03/19/2011 11:06 AM, devin kelly wrote: I've only started using the AGC block very recently. I started using because I wanted some way to control the AGC. This makes me think of the question, is the AGC on by default? That is, if I don't have an AGC block will the AGC be doing anything? Also, in the first two or three ICs in the WBX there is a digitally controlled attenuator and an LNA, those are part of the AGC correct? There is no automatic gain control in the WBX hardware. The step attenuators are set when you set the hardware RF gain of the daughter-card. The AGC block within Gnu Radio simply applies a multiplicative coefficient to the data stream within Gnu Radio, based on smoothed historical signal power estimates. AGC is useful for certain types of signals, and not for others, which is why there's no automatic AGC in the hardware. Now various daughtercards have *manual* gain control, and you can certainly implement AGC that's distributed between software and hardware, but that's up to the software. In general, in SDR, you want the hardware to implement (borrowing from X11 for a second here) "mechanism, not policy". Consider precision RF measurement applications, for example. You don't want the hardware implementing an AGC policy of any kind. Just like you don't want the hardware implementing "the one, true demodulation mode". -- 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 Spectrum Sensing Help, (variant for FunCube Dongle?)
On Mar 19, 2011, at 10:34 AM, "Marcus D. Leech" wrote: > There is no automatic gain control in the WBX hardware. The step attenuators > are set when you set the hardware RF gain of the daughter-card. There's AGC on the WBX tx side, but not rx. -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Spectrum Sensing Help, (variant for FunCube Dongle?)
On 03/19/2011 12:50 PM, Marc Epard wrote: There's AGC on the WBX tx side, but not rx. -Marc Yes, that's true, and I should have clarified that I was talking about the RX side. -- 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] new feature work: qtgui support in grc
Hey Josh On 02/03/11 01:52, You wrote: I have been working on supporting PyQt widgets and the qtgui sinks in the Gnuradio Companion. Get the code on my wip/qtgui/grc branch on jblum.git http://gnuradio.org/cgit/jblum.git/log/?h=wip/qtgui/grc I finally got some time to take a look, but it looks like your WIP branch has disappeared ? Did the code go into the main git repo ? I see most of the qtgui grc blocks when starting the gunradio companion, [from the latest repo, 19-MAR-2011] but it looks like the plotter is missing ? Which is of course, the one I was really interestedx in testing... Best Regards Iain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new feature work: qtgui support in grc
On 03/19/2011 12:32 PM, Iain Young, G7III wrote: > Hey Josh > > On 02/03/11 01:52, You wrote: > >> I have been working on supporting PyQt widgets and the qtgui sinks in >> the Gnuradio Companion. Get the code on my wip/qtgui/grc branch on >> jblum.git http://gnuradio.org/cgit/jblum.git/log/?h=wip/qtgui/grc > > I finally got some time to take a look, but it looks like your WIP > branch has disappeared ? Did the code go into the main git repo ? I > see most of the qtgui grc blocks when starting the gunradio companion, > [from the latest repo, 19-MAR-2011] but it looks like the plotter is > missing ? Which is of course, the one I was really interestedx in > testing... > > Its all on the master branch of gnuradio.git -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 eth link issues
Hello, I recently starting having ethernet connectivity issues with our USRP2. Whenever I run "find_usrps", I get a no USRP2 found message. The USRP2 worked perfectly before without any issues on a Thinkpad T410 running Ubuntu 10.10 with a repo install of gnuradio, along with the latest corresponding FPGA and firmware (XCVR2450) images. I figured that the gnuradio environment had somehow become broken, so I decided to do a clean install of gnuradio and the corresponding packages/dependencies from repo (as well as reflashing the FPGA and firmware images on the old and a new SD card) on a new system to no avail. I next tried every suggestion I could find on the mailing list and forums. This included making sure that my network-manager and firewall were disabled, using ethtool to turn rx on, setting up networking according to the UHD - USRP2 and N Serial Application Notes (as well as using the USRP2 recovery tool to set the USRP2's IP address), monitoring my ethernet interface with tcpdump and Wireshark, and disconnecting the daughterboard card, all to no avail. When monitoring the network interface, I sometimes see the broadcast packet(s) sent by find_usrps, and very rarely actually get a response. When I do get a response, the connection seems to die immediately after, as find_usrps is unable to find the USRP2 when I ran again. All the lights on the front blink upon power up, LEDs D and F remain on afterward, I am using a gigabit interface and cable, and the fuse is okay. USRP2 and system/package info is listed below, as well as the output from serial and ethtool. The output from serial is most interesting, because the eth link speed changes to 1000 and then to 0 immediately after roughly every 3 seconds. Running find_usrps immediately (like a split second after, almost simultaneously) and only after the eth link speed changes to 1000 yields a proper response from the USRP2 momentarily. Has anyone seen this behavior before or have any other suggestions? --Ricky USRP2 Rev 4.0 XCVR2450 (Rev 753) $ cat /etc/issue Ubuntu 10.10 \n \l $ uname -a Linux gares-e5400 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:29 UTC 2011 i686 GNU/Linux $ dpkg -s gnuradio Package: gnuradio Status: install ok installed Priority: optional Section: comm Installed-Size: 40 Maintainer: Ubuntu Developers Architecture: all Version: 3.2.2.dfsg-1ubuntu3 Recommends: libgnuradio, libgnuradio-dev, gnuradio-doc, python-gnuradio, gnuradio-utils, gnuradio-examples, gnuradio-apps Description: The GNU Software Radio Toolkit This is a virtual package that installs the entire GNU Radio and USRP software set. Original-Maintainer: Bdale Garbee -- find_usrps output (when it actually works, which is very rarely) $ find_usrps 00:50:c2:85:32:c3 hw_rev = 0x0400 -- ethtool output $ sudo ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: Unknown Supports Wake-on: g Wake-on: g Current message level: 0x00ff (255) Link detected: yes -- Serial output (after running "sudo ethtool -A eth0 rx on," otherwise ethernet flow control set to none) $ screen /dev/tty.usbserial-A700eBUj 230400 TX dbid: 0x60 Rx dbid: 0x61 TxRx-NEWETH 00:50:C2:85:32:C3 ethernet flow control: WE_TX Speed set to 1000 eth link changed: speed = 1000 eth link changed: speed = 0 ethernet flow control: WE_TX Speed set to 1000 eth link changed: speed = 1000 eth link changed: speed = 0 ethernet flow control: WE_TX Speed set to 1000 eth link changed: speed = 1000 eth link changed: speed = 0 ethernet flow control: WE_TX Speed set to 1000 eth link changed: speed = 1000 eth link changed: speed = 0 ethernet flow control: WE_TX Speed set to 1000 eth link changed: speed = 1000 eth link changed: speed = 0 ethernet flow control: WE_TX Speed set to 1000 eth link changed: speed = 1000 eth link changed: speed = 0 ethernet flow control: WE_TX Speed set to 1000 eth link changed: speed = 1000 eth link changed: speed = 0 the eth link speed continuos to alternate indefinitely, and every 3 seconds the eth link speed changes to 1000, and then to 0 immediately after smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.o
Re: [Discuss-gnuradio] USRP2 eth link issues
Hi Marcus, On the USRP2 side, the green LED turns on when the link speed changes to 1000, and goes off once the speed goes to 0, showing a solid green for about 4/10s of a second, and no activity on the orange or yellow light unless I run find_usrps as soon as the speed changes to 1000, as I described before, at which point I'll see an orange flash on the USRP2 side and a proper response on the host machine. --Ricky On Mar 19, 2011, at 6:27 PM, Marcus D. Leech wrote: > > Ricky: > > When the link is rapidly cycling between 1000 and 0, what is the green LED on > the GigE interface RJ-45 doing? Is it on solidly, or does it > go on and off? Does the yellow/orange lamp on the same RJ-45 connector > flash with traffic? > > On 03/19/2011 07:18 PM, Ricky A. Melgares wrote: >> >> Hello, >> >> I recently starting having ethernet connectivity issues with our USRP2. >> Whenever I run "find_usrps", I get a no USRP2 found message. The USRP2 >> worked perfectly before without any issues on a Thinkpad T410 running Ubuntu >> 10.10 with a repo install of gnuradio, along with the latest corresponding >> FPGA and firmware (XCVR2450) images. I figured that the gnuradio environment >> had somehow become broken, so I decided to do a clean install of gnuradio >> and the corresponding packages/dependencies from repo (as well as reflashing >> the FPGA and firmware images on the old and a new SD card) on a new system >> to no avail. I next tried every suggestion I could find on the mailing list >> and forums. This included making sure that my network-manager and firewall >> were disabled, using ethtool to turn rx on, setting up networking according >> to the UHD - USRP2 and N Serial Application Notes (as well as using the >> USRP2 recovery tool to set the USRP2's IP address), monitoring my ethernet >> interface with tcpdump and Wireshark, and disconnecting the daughterboard >> card, all to no avail. >> >> When monitoring the network interface, I sometimes see the broadcast >> packet(s) sent by find_usrps, and very rarely actually get a response. When >> I do get a response, the connection seems to die immediately after, as >> find_usrps is unable to find the USRP2 when I ran again. All the lights on >> the front blink upon power up, LEDs D and F remain on afterward, I am using >> a gigabit interface and cable, and the fuse is okay. USRP2 and >> system/package info is listed below, as well as the output from serial and >> ethtool. The output from serial is most interesting, because the eth link >> speed changes to 1000 and then to 0 immediately after roughly every 3 >> seconds. Running find_usrps immediately (like a split second after, almost >> simultaneously) and only after the eth link speed changes to 1000 yields a >> proper response from the USRP2 momentarily. >> >> Has anyone seen this behavior before or have any other suggestions? >> >> --Ricky >> >> USRP2 Rev 4.0 >> XCVR2450 (Rev 753) >> >> $ cat /etc/issue >> Ubuntu 10.10 \n \l >> >> $ uname -a >> Linux gares-e5400 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:29 UTC >> 2011 i686 GNU/Linux >> >> $ dpkg -s gnuradio >> Package: gnuradio >> Status: install ok installed >> Priority: optional >> Section: comm >> Installed-Size: 40 >> Maintainer: Ubuntu Developers >> Architecture: all >> Version: 3.2.2.dfsg-1ubuntu3 >> Recommends: libgnuradio, libgnuradio-dev, gnuradio-doc, python-gnuradio, >> gnuradio-utils, gnuradio-examples, gnuradio-apps >> Description: The GNU Software Radio Toolkit >> This is a virtual package that installs the entire GNU Radio and USRP >> software >> set. >> Original-Maintainer: Bdale Garbee >> >> -- >> find_usrps output (when it actually works, which is very rarely) >> >> $ find_usrps >> 00:50:c2:85:32:c3 hw_rev = 0x0400 >> >> -- >> ethtool output >> >> $ sudo ethtool eth0 >> Settings for eth0: >> Supported ports: [ TP ] >> Supported link modes: 10baseT/Half 10baseT/Full >> 100baseT/Half 100baseT/Full >> 1000baseT/Half 1000baseT/Full >> Supports auto-negotiation: Yes >> Advertised link modes: 10baseT/Half 10baseT/Full >> 100baseT/Half 100baseT/Full >> 1000baseT/Half 1000baseT/Full >> Advertised pause frame use: No >> Advertised auto-negotiation: Yes >> Speed: 1000Mb/s >> Duplex: Full >> Port: Twisted Pair >> PHYAD: 1 >> Transceiver: internal >> Auto-negotiation: on >> MDI-X: Unknown >> Supports Wake-on: g >> Wake-on: g >> Current message level: 0x00ff (255) >> Link detected: yes >> >> -- >> Serial output (after running "sudo ethtool -A eth0 rx on," otherwise >> ethernet flow control set to none) >> >> $ screen /dev/tty.usbserial-A700eBUj 230400 >> TX dbid: 0x60 >> Rx dbid: 0x61 >> >> TxRx-NEWETH >> 00:50:C2:85:32:C3 >> ethernet flow control: WE_TX >> Speed set to 1000 >> >> eth link changed: speed = 1000 >> >
Re: [Discuss-gnuradio] USRP2 eth link issues
On Sat, Mar 19, 2011 at 06:18:18PM -0500, Ricky A. Melgares wrote: > > The output from serial is most interesting, because the eth link speed > changes to 1000 and then to 0 immediately after roughly every 3 > seconds. Hey, Ricky. This behavior is typical of gigabit ethernet with a bad cable or other physical layer problem. Have you swapped the cable? Make sure you are using a cable with eight conductors, not just four. Have you tested the laptop with a gigabit switch? Have you tested the USRP2 with another host? I recommend checking the jacks to make sure they don't have any bent pins. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
