Re: [Discuss-gnuradio] GNU Radio meetup at the 2010 SDR Technical Conference, Washington, DC
Tom: Thanks for organizing this. I would REALLY like to attend the conference and also this meeting, but I already have commitments for that week that I can't re-schedule. But I am planning on going next year. Is the conference run every year? Is it always held in Washington D.C.? So I had another idea I'd like to propose to the community. Would anyone be interested in attending informal and regular GNU Radio User Group (GRUG) meetings, similar to the Linux User Group (LUG) meetings that are held regularly in cities all over the world? I am located in Boston, so if there's some interest, I'd be willing to organize an initial meeting in mid-January in Boston/Cambridge. With any luck, we could hold such meetings every other month or once per quarter. Please let me know if anyone would be interested. Steve McMahon --- On Thu, 10/21/10, Tom Rondeau trondeau1...@gmail.com wrote: From: Tom Rondeau trondeau1...@gmail.com Subject: [Discuss-gnuradio] GNU Radio meetup at the 2010 SDR Technical Conference, Washington, DC To: GNURadio Discussion List discuss-gnuradio@gnu.org Date: Thursday, October 21, 2010, 7:22 PM GNU Radio community, We will be holding a GNU Radio meetup at the SDR Technical Conference on Wednesday, December 1 at 7:30 in the Hyatt Regency Crystal City. Meeting room TBA. For those of you who made it last year, it will be a similar event. Matt Ettus and myself will be there with Ettus Research, LLC sponsoring food and beverages. This is a time for people involved in the community to get to know each other a bit better and share their work and ideas. I'll take some time to provide everyone present with some of our ideas for the future of the project and Matt will be sharing some of his plans for Ettus Research. Importantly, though, I would really love to hear back from all of you about what work you're doing as well as thoughts on the project. We will have 1.5 hours for discussion, including some time at the beginning for food and some informal introductions. For the bulk of it, I would really like to get some good discussion going about GNU Radio and its applications. So please come prepared to share! We will likely head out to a local bar for around 9PM to continue the discussions over beer. This year, we are going to be more formally a part of the SDR Conference, and as such, the organizers of the conference have asked for people to register. You have a few options for registering, including the free option. I will be attending all week and have a presentation on Tuesday as part of an Open Source Software panel session put together by Phil Balister as well as a tutorial on GNU Radio on Thursday. Matt will be there as an exhibitor during the entire conference. That's just to let you know some of the activities going on during the full conference. You can find more here: http://conference.wirelessinnovation.org/ To register, you can see the different options here: http://conference.wirelessinnovation.org/mc/page.do?sitePageId=118975orgId=s1 I apologize for the timing of this email. I realize now that I should have gotten it out sooner since tomorrow is the cut-off of the early registration deadline. Anyway, the organizers are asking people to register, even if that's just the Exhibitors and Exhibits Only Attendee, which is free for pre-registration or $50 for on-site registration. Location information: For those not familiar with the DC area, Crystal City is just south of DC (technically in Arlington, VA) on Rt. 1. Here's the map: http://goo.gl/maps/itPK The bar we will most likely be going to is Bailey's Sports Grill (or The Fox and Hound, depending on where you look). It's a decent pub with a large selection of beer, and I think we all had a pretty good time there last year. Note that this is the one on Crystal City Dr, not Wilson Blvd. http://goo.gl/maps/uaXi RSVP: It's not necessary to tell me that you're coming, but it would help us to get a feel for the amount of food we should plan on. Thanks! And I look forward to seeing many of you there! 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
[Discuss-gnuradio] build error
I am trying a new build from the source tree on fedora 12. Configure gives the result shown at the end of the email. Make and make check complete fine, but sudo make install completes with the message: *** Post-Install Message *** Warning: python could not find the gnuradio module. Make sure that /usr/local/lib64/python2.6/site-packages is in your PYTHONPATH make[3]: Leaving directory `/home/anastas/gnuradio_trunk' make[2]: Leaving directory `/home/anastas/gnuradio_trunk' make[1]: Leaving directory `/home/anastas/gnuradio_trunk I know the PYTHONPATH is set appropriately, since I can import gnuradio from within python... Also grc is not installed in /usr/local/bin Any ideas, Achilleas '* The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp2-firmware These components will not be built. * The following GNU Radio components have been successfully configured: config gruel gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio-alsa gr-audio-oss gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi These components will not be built. Configured GNU Radio release v3.3.1git-92-gdd74b98a for build. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build error
On Sun, Oct 24, 2010 at 10:48 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: I am trying a new build from the source tree on fedora 12. Configure gives the result shown at the end of the email. Make and make check complete fine, but sudo make install completes with the message: *** Post-Install Message *** Warning: python could not find the gnuradio module. Make sure that /usr/local/lib64/python2.6/site-packages is in your PYTHONPATH make[3]: Leaving directory `/home/anastas/gnuradio_trunk' make[2]: Leaving directory `/home/anastas/gnuradio_trunk' make[1]: Leaving directory `/home/anastas/gnuradio_trunk I know the PYTHONPATH is set appropriately, since I can import gnuradio from within python... If you can import gnuradio, can you also run GNU Radio applications? This might be a misunderstanding during the install but not an actual problem. Tom Also grc is not installed in /usr/local/bin Any ideas, Achilleas '* The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp2-firmware These components will not be built. * The following GNU Radio components have been successfully configured: config gruel gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio-alsa gr-audio-oss gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi These components will not be built. Configured GNU Radio release v3.3.1git-92-gdd74b98a for build. ___ 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] build error
yes, i can run all the tests in the different example directories. However i cannot find/run grc Achilleas On Sun, Oct 24, 2010 at 11:08 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Sun, Oct 24, 2010 at 10:48 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: I am trying a new build from the source tree on fedora 12. Configure gives the result shown at the end of the email. Make and make check complete fine, but sudo make install completes with the message: *** Post-Install Message *** Warning: python could not find the gnuradio module. Make sure that /usr/local/lib64/python2.6/site-packages is in your PYTHONPATH make[3]: Leaving directory `/home/anastas/gnuradio_trunk' make[2]: Leaving directory `/home/anastas/gnuradio_trunk' make[1]: Leaving directory `/home/anastas/gnuradio_trunk I know the PYTHONPATH is set appropriately, since I can import gnuradio from within python... If you can import gnuradio, can you also run GNU Radio applications? This might be a misunderstanding during the install but not an actual problem. Tom Also grc is not installed in /usr/local/bin Any ideas, Achilleas '* The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp2-firmware These components will not be built. * The following GNU Radio components have been successfully configured: config gruel gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio-alsa gr-audio-oss gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi These components will not be built. Configured GNU Radio release v3.3.1git-92-gdd74b98a for build. ___ 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] build error
On Sun, Oct 24, 2010 at 11:35 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: yes, i can run all the tests in the different example directories. However i cannot find/run grc Achilleas grc was changed a bit back to gnuradio-companion because of a naming conflict. Is that available? Tom On Sun, Oct 24, 2010 at 11:08 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Sun, Oct 24, 2010 at 10:48 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: I am trying a new build from the source tree on fedora 12. Configure gives the result shown at the end of the email. Make and make check complete fine, but sudo make install completes with the message: *** Post-Install Message *** Warning: python could not find the gnuradio module. Make sure that /usr/local/lib64/python2.6/site-packages is in your PYTHONPATH make[3]: Leaving directory `/home/anastas/gnuradio_trunk' make[2]: Leaving directory `/home/anastas/gnuradio_trunk' make[1]: Leaving directory `/home/anastas/gnuradio_trunk I know the PYTHONPATH is set appropriately, since I can import gnuradio from within python... If you can import gnuradio, can you also run GNU Radio applications? This might be a misunderstanding during the install but not an actual problem. Tom Also grc is not installed in /usr/local/bin Any ideas, Achilleas '* The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp2-firmware These components will not be built. * The following GNU Radio components have been successfully configured: config gruel gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio-alsa gr-audio-oss gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi These components will not be built. Configured GNU Radio release v3.3.1git-92-gdd74b98a for build. ___ 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] build error
On Sun, 2010-10-24 at 11:35 -0400, Achilleas Anastasopoulos wrote: yes, i can run all the tests in the different example directories. However i cannot find/run grc Achilleas GRC is now called gnuradio-companion due to a naming conflict with an existing program. --n On Sun, Oct 24, 2010 at 11:08 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Sun, Oct 24, 2010 at 10:48 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: I am trying a new build from the source tree on fedora 12. Configure gives the result shown at the end of the email. Make and make check complete fine, but sudo make install completes with the message: *** Post-Install Message *** Warning: python could not find the gnuradio module. Make sure that /usr/local/lib64/python2.6/site-packages is in your PYTHONPATH make[3]: Leaving directory `/home/anastas/gnuradio_trunk' make[2]: Leaving directory `/home/anastas/gnuradio_trunk' make[1]: Leaving directory `/home/anastas/gnuradio_trunk I know the PYTHONPATH is set appropriately, since I can import gnuradio from within python... If you can import gnuradio, can you also run GNU Radio applications? This might be a misunderstanding during the install but not an actual problem. Tom Also grc is not installed in /usr/local/bin Any ideas, Achilleas '* The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp2-firmware These components will not be built. * The following GNU Radio components have been successfully configured: config gruel gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio-alsa gr-audio-oss gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi These components will not be built. Configured GNU Radio release v3.3.1git-92-gdd74b98a for build. ___ 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio Mode S project released
What would be involved in running this with a USRP2 and WBX? Thanks, Al - Original Message - From: Nick Foster n...@ettus.com To: discuss-gnuradio@gnu.org Sent: Saturday, October 23, 2010 9:52 PM Subject: [Discuss-gnuradio] Gnuradio Mode S project released Hi all, I finally got around to cleaning up my Mode S receiver enough for public release. The following is a short description of the software: The Gnuradio Mode S project implements a Mode S/ADS-B receiver. Mode S is the latest aircraft transponder technology, primarily used in commercial aircraft. Probably 30% of those aircraft currently broadcast their position via ADS-B (more in Europe, less in the US), which is a protocol that uses Mode S extended squitters as the transport layer. By 2020 all aircraft operating in controlled US airspace will be required to broadcast ADS-B. The receiver demodulates and decodes the 1090MHz PPM-modulated Mode S transmissions using industry-standard techniques to mitigate FRUIT (transmissions on top of one another) and correct multiple bit errors. Using a USRP with a DBSRX + LNA + SAW filter, ranges of 220 miles have been regularly seen. The WBX should allow similar ranges without the filter and LNA, although I haven't really tested WBX much. It is of course line-of-sight, making antenna site selection important. TL;DR: Follow airplanes around from 200 miles with your USRP. The receiver allows interfacing to a number of output formats, including KML for Google Earth. Screenshots of the Google Earth interface can be found here: http://nerdnetworks.org/~bistromath/photos/adsb/ There is also a TCP port 30003 interface to use with PlanePlotter, a third-party application to view aircraft data. PlanePlotter isn't free, and I haven't tested it at all, so while it should work, YMMV. If you do test it, let me know. There are definitely still bugs in it -- one thing that comes to mind is that a very few aircraft seem to produce data which uses correct headers for position packets but which contains non-position data. This causes impossible aircraft positions. Luckily it seems to be pretty rare. Future developments for the receiver include implementation of networked multilateration using the VRT timestamps of USRP2. Multilateration allows the time-based triangulation of aircraft which use Mode S but which do not broadcast ADS-B. Three or more networked USRP2s should allow position determination to a reasonable degree of accuracy. Clone the Git repository to build the software with the usual bootstrap/configure/make/make install rigmarole; it should compile on anything you have Gnuradio installed on, although with a 4Msps data rate it does require a bit of CPU power. In order to use the KML output you will have to have libsqlite3 and python-sqlite installed, although since those are Python dependencies it will still compile without them. I think that's it for the dependencies. Oh, it uses UHD, so you should finally get around to building UHD and gr-uhd to use this software. git clone git://github.com/bistromath/gr-air-modes.git There is also a CGRAN page with corresponding SVN repo, which is a mirror of the Github repo: https://www.cgran.org/wiki/gr-air-modes/ The Python executable is src/python/uhd_modes.py. Best, Nick ___ 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] Gnuradio Mode S project released
On Sun, 2010-10-24 at 12:15 -0400, Allen Vinegar wrote: What would be involved in running this with a USRP2 and WBX? Download, compile, run. You should plug an antenna in at some point in the process. If you aren't using UHD yet, you'll have to download and install UHD and gr-uhd as well as burn a new SD card image. Instructions for that process are here: http://code.ettus.com/redmine/ettus/projects/uhd/wiki --n Thanks, Al - Original Message - From: Nick Foster n...@ettus.com To: discuss-gnuradio@gnu.org Sent: Saturday, October 23, 2010 9:52 PM Subject: [Discuss-gnuradio] Gnuradio Mode S project released Hi all, I finally got around to cleaning up my Mode S receiver enough for public release. The following is a short description of the software: The Gnuradio Mode S project implements a Mode S/ADS-B receiver. Mode S is the latest aircraft transponder technology, primarily used in commercial aircraft. Probably 30% of those aircraft currently broadcast their position via ADS-B (more in Europe, less in the US), which is a protocol that uses Mode S extended squitters as the transport layer. By 2020 all aircraft operating in controlled US airspace will be required to broadcast ADS-B. The receiver demodulates and decodes the 1090MHz PPM-modulated Mode S transmissions using industry-standard techniques to mitigate FRUIT (transmissions on top of one another) and correct multiple bit errors. Using a USRP with a DBSRX + LNA + SAW filter, ranges of 220 miles have been regularly seen. The WBX should allow similar ranges without the filter and LNA, although I haven't really tested WBX much. It is of course line-of-sight, making antenna site selection important. TL;DR: Follow airplanes around from 200 miles with your USRP. The receiver allows interfacing to a number of output formats, including KML for Google Earth. Screenshots of the Google Earth interface can be found here: http://nerdnetworks.org/~bistromath/photos/adsb/ There is also a TCP port 30003 interface to use with PlanePlotter, a third-party application to view aircraft data. PlanePlotter isn't free, and I haven't tested it at all, so while it should work, YMMV. If you do test it, let me know. There are definitely still bugs in it -- one thing that comes to mind is that a very few aircraft seem to produce data which uses correct headers for position packets but which contains non-position data. This causes impossible aircraft positions. Luckily it seems to be pretty rare. Future developments for the receiver include implementation of networked multilateration using the VRT timestamps of USRP2. Multilateration allows the time-based triangulation of aircraft which use Mode S but which do not broadcast ADS-B. Three or more networked USRP2s should allow position determination to a reasonable degree of accuracy. Clone the Git repository to build the software with the usual bootstrap/configure/make/make install rigmarole; it should compile on anything you have Gnuradio installed on, although with a 4Msps data rate it does require a bit of CPU power. In order to use the KML output you will have to have libsqlite3 and python-sqlite installed, although since those are Python dependencies it will still compile without them. I think that's it for the dependencies. Oh, it uses UHD, so you should finally get around to building UHD and gr-uhd to use this software. git clone git://github.com/bistromath/gr-air-modes.git There is also a CGRAN page with corresponding SVN repo, which is a mirror of the Github repo: https://www.cgran.org/wiki/gr-air-modes/ The Python executable is src/python/uhd_modes.py. Best, Nick ___ 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] RAM consumption
I am running some Zigbee code from UCLA with some modifications of my own... When I run the (modified) code, RAM is slowly (but surely) consumed with high CPU usage. After about half an hour, the CPU/RAM monitor shows 100% RAM usage and then operation stalls and CPU usage drops down once again to quiescent levels, with RAM remaining tied up until the program is ended (ctrl-C). Until the stall, program operation appears to be correct. I have reviewed the code by hand for memory leaks and also used some of the tools available for detecting memory leaks without any results. Has anyone else had similar problems and, if so, how did they debug them? Is this kind of inexorable creep of system memory usage symptomatic of anything else? Within GnuRadio, is there any method for quickly determining how program memory (heap space) or data memory is being consumed? / David Knox -- View this message in context: http://old.nabble.com/RAM-consumption-tp30041914p30041914.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] build error
Da! thanks Achilleas On Sun, Oct 24, 2010 at 11:54 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Sun, Oct 24, 2010 at 11:35 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: yes, i can run all the tests in the different example directories. However i cannot find/run grc Achilleas grc was changed a bit back to gnuradio-companion because of a naming conflict. Is that available? Tom On Sun, Oct 24, 2010 at 11:08 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Sun, Oct 24, 2010 at 10:48 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: I am trying a new build from the source tree on fedora 12. Configure gives the result shown at the end of the email. Make and make check complete fine, but sudo make install completes with the message: *** Post-Install Message *** Warning: python could not find the gnuradio module. Make sure that /usr/local/lib64/python2.6/site-packages is in your PYTHONPATH make[3]: Leaving directory `/home/anastas/gnuradio_trunk' make[2]: Leaving directory `/home/anastas/gnuradio_trunk' make[1]: Leaving directory `/home/anastas/gnuradio_trunk I know the PYTHONPATH is set appropriately, since I can import gnuradio from within python... If you can import gnuradio, can you also run GNU Radio applications? This might be a misunderstanding during the install but not an actual problem. Tom Also grc is not installed in /usr/local/bin Any ideas, Achilleas '* The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp2-firmware These components will not be built. * The following GNU Radio components have been successfully configured: config gruel gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio-alsa gr-audio-oss gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi These components will not be built. Configured GNU Radio release v3.3.1git-92-gdd74b98a for build. ___ 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] Gnuradio Mode S project released
Thanks for quick answer! Al - Original Message - From: Nick Foster n...@ettus.com To: Allen Vinegar tok...@myranch.com Cc: discuss-gnuradio@gnu.org Sent: Sunday, October 24, 2010 12:18 PM Subject: Re: [Discuss-gnuradio] Gnuradio Mode S project released On Sun, 2010-10-24 at 12:15 -0400, Allen Vinegar wrote: What would be involved in running this with a USRP2 and WBX? Download, compile, run. You should plug an antenna in at some point in the process. If you aren't using UHD yet, you'll have to download and install UHD and gr-uhd as well as burn a new SD card image. Instructions for that process are here: http://code.ettus.com/redmine/ettus/projects/uhd/wiki --n Thanks, Al - Original Message - From: Nick Foster n...@ettus.com To: discuss-gnuradio@gnu.org Sent: Saturday, October 23, 2010 9:52 PM Subject: [Discuss-gnuradio] Gnuradio Mode S project released Hi all, I finally got around to cleaning up my Mode S receiver enough for public release. The following is a short description of the software: The Gnuradio Mode S project implements a Mode S/ADS-B receiver. Mode S is the latest aircraft transponder technology, primarily used in commercial aircraft. Probably 30% of those aircraft currently broadcast their position via ADS-B (more in Europe, less in the US), which is a protocol that uses Mode S extended squitters as the transport layer. By 2020 all aircraft operating in controlled US airspace will be required to broadcast ADS-B. The receiver demodulates and decodes the 1090MHz PPM-modulated Mode S transmissions using industry-standard techniques to mitigate FRUIT (transmissions on top of one another) and correct multiple bit errors. Using a USRP with a DBSRX + LNA + SAW filter, ranges of 220 miles have been regularly seen. The WBX should allow similar ranges without the filter and LNA, although I haven't really tested WBX much. It is of course line-of-sight, making antenna site selection important. TL;DR: Follow airplanes around from 200 miles with your USRP. The receiver allows interfacing to a number of output formats, including KML for Google Earth. Screenshots of the Google Earth interface can be found here: http://nerdnetworks.org/~bistromath/photos/adsb/ There is also a TCP port 30003 interface to use with PlanePlotter, a third-party application to view aircraft data. PlanePlotter isn't free, and I haven't tested it at all, so while it should work, YMMV. If you do test it, let me know. There are definitely still bugs in it -- one thing that comes to mind is that a very few aircraft seem to produce data which uses correct headers for position packets but which contains non-position data. This causes impossible aircraft positions. Luckily it seems to be pretty rare. Future developments for the receiver include implementation of networked multilateration using the VRT timestamps of USRP2. Multilateration allows the time-based triangulation of aircraft which use Mode S but which do not broadcast ADS-B. Three or more networked USRP2s should allow position determination to a reasonable degree of accuracy. Clone the Git repository to build the software with the usual bootstrap/configure/make/make install rigmarole; it should compile on anything you have Gnuradio installed on, although with a 4Msps data rate it does require a bit of CPU power. In order to use the KML output you will have to have libsqlite3 and python-sqlite installed, although since those are Python dependencies it will still compile without them. I think that's it for the dependencies. Oh, it uses UHD, so you should finally get around to building UHD and gr-uhd to use this software. git clone git://github.com/bistromath/gr-air-modes.git There is also a CGRAN page with corresponding SVN repo, which is a mirror of the Github repo: https://www.cgran.org/wiki/gr-air-modes/ The Python executable is src/python/uhd_modes.py. Best, Nick ___ 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] RAM consumption
On Sun, Oct 24, 2010 at 09:19:25AM -0700, David Knox wrote: I am running some Zigbee code from UCLA with some modifications of my own... When I run the (modified) code, RAM is slowly (but surely) consumed with high CPU usage. After about half an hour, the CPU/RAM monitor shows 100% RAM usage and then operation stalls and CPU usage drops down once again to quiescent levels, with RAM remaining tied up until the program is ended (ctrl-C). Until the stall, program operation appears to be correct. I have reviewed the code by hand for memory leaks and also used some of the tools available for detecting memory leaks without any results. Has anyone else had similar problems and, if so, how did they debug them? Is this kind of inexorable creep of system memory usage symptomatic of anything else? Within GnuRadio, is there any method for quickly determining how program memory (heap space) or data memory is being consumed? 99% of the base code distributed with GNU Radio (runtime + blocks) allocates NO MEMORY once the flow graph has started (see below for exceptions). DO NOT use a vector_sink for anything other than QA code that produces a small amount of output. The vector_sink will allocate an unbounded amount of memory if you keep writing to it. It is also possible to consume memory by sending an unbounded number of messages into a message queue (gr.msg_queue) that doesn't have a queue size limit and has a slow (or compute bound) reader. If there's a GUI of any kind involved, or python code that's being executed beyond initialization time, look there for problems. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem in using trellis Error correction en- and decoder
please change the prefix variable in this grc graph to the absolute path of your gnuradio tree. Eg, in my machine it is /home/anastas/gnuradio_trunk/ Also, you might want to put a throttle somewhere. Achilleas On Sat, Oct 23, 2010 at 3:19 PM, Francisco Llaryora fllary...@gmail.com wrote: Hello Achilleas. Forgiveness for mysticism about the example. is interference_cancellation.grc (GNU Radio Companion 3.2.2) http://pastebin.com/N61P7tiP /usr/share/gnuradio/examples/grc/trellis/interference_cancellation.grc the error: [error] Loading: /usr/share/gnuradio/examples/grc/trellis/interference_cancellation.grc Done Showing: /usr/share/gnuradio/examples/grc/trellis/interference_cancellation.grc Generating: /usr/share/gnuradio/examples/grc/trellis/int_cancellation.py Warning: This flow graph may not have flow control: no audio or usrp blocks found. Add a Misc-Throttle block to your flow graph to avoid CPU congestion. Generating: /usr/share/gnuradio/examples/grc/trellis/int_cancellation.py Warning: This flow graph may not have flow control: no audio or usrp blocks found. Add a Misc-Throttle block to your flow graph to avoid CPU congestion. Executing: /usr/share/gnuradio/examples/grc/trellis/int_cancellation.py terminate called after throwing an instance of 'std::runtime_error' what(): fsm::fsm(const char *name): file open error Done [/error] i change the path to absolute path, but don't work. the file exist in this directory. i no try to add a Throttle block. i do not care if the example doesn't work, be cause i don't get this error in my work. I must have to go now. sorry. thanks for the fast reply. 2010/10/23 Achilleas Anastasopoulos anas...@umich.edu: Can you be more specific as to WHICH example in the gr-trellis directory does not work. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dynamic range of USRP2-XCVR2450
Hello, I am trying to find out the minimum/maximun input power of the ADC LTC2284. I know that the maximum input voltage is 1 Volt, 0.707Vrms, but what is the input impedance? so that I can calculate the maximum input power as: minimum input power (SNR ADC) = Maximun input power ( [(0.707)/(2^14))^2]/Rin) + 72.4 dB = Maximun input power Am I right? Many thanks, Jorge On 19 October 2010 19:18, Marcus D. Leech mle...@ripnet.com wrote: On 10/19/2010 12:21 PM, Jorge Miguel wrote: Hi Marcus! How do you get the 85 dB value? Is the Intermodulation distorsion of the page 3 ADC datasheet? In the features list for the LTC2284: 72.4dB SNR, 88dB SFDR SFDR is spur-free dynamic range. I am not an expecienced engineer (I am recent graduated) but I was thinking about the maximun and minimum input powers to be linearly detected in the USRP receiver. I thought the ADC as a good point to start with and then see what is going on in the XCVR2450 transceiver At the ADC point, it is said that is has 2volts p-p dynamic range. This value can give us the maximun power input at the ADC provided the input impedance.(Good question. What is the input impedance? I cannot see it in the ADC datasheet) P=(V^2)/R Is it right? In other post I can read:*ADC's datasheet, we need 2Vp-p to fully utilise its dynamic range. The input impedance of the ADC is around 220ohms so this is equal to an input signal level of about 6dBm. If you go above this you will get saturation.* I do the calculations and it doesn't match!!! The LTC2284 can be configured for either 1VP-P or 2VP-P. I believe the USRP2 uses 1VP-P configuration. Generally, with ADCs, you ascribe roughly 6dB of dynamic range per bit, this is a 14-bit A/D. Before the ADC is the XCVR2450, with all RF components. Each one of then has its Noise figure and some of them gain such us the power amplifier or the Maxim. You said that *The XCVR2450 does have gain control, but it is solely under control of the host software*. Besides the ones I mentioned, is there any other place with gain? The MAX2829 has roughly 93dB of RX gain-control range--that's right on the data sheet, and is exposed to the API inside Gnu Radio. When you create a source, you can specify the gain (actually, you can change it dynamically as well). Is it the correct way of calculating the dynamic range? I really need help. Thanks, Jorge. The LTC2284 A/D is a 14-bit A/D. The maximum input voltage the way it's configured is 0.707Vrms. Divide that by the 2^14, and that's roughly your minimum input voltage. In general, though you take a little bit off the top and add a little bit onto the bottom of the range. Google is your friend. I'd suggest looking up ADC noise floor dynamic range. Plenty of articles out there. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio Mode S project released
Nick, is it thinkable to operate the decoder at a lower sample rate ? (e.g. at 2 MS/s or even less) *am* - Andrea Montefusco iw0hdvhttp://www.montefusco.com tel: +393356992791 fax: +390623318709 - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dynamic range of USRP2-XCVR2450
On 10/24/2010 01:07 PM, Jorge Miguel wrote: Hello, I am trying to find out the minimum/maximun input power of the ADC LTC2284. I know that the maximum input voltage is 1 Volt, 0.707Vrms, but what is the input impedance? so that I can calculate the maximum input power as: minimum input power (SNR ADC) = Maximun input power ( [(0.707)/(2^14))^2]/Rin) + 72.4 dB = Maximun input power Am I right? Many thanks, Jorge I believe that it's a 100ohm balanced input. But the daughtercards all take a 50-ohm input, and convert to a balanced output just before the A/D. With the exception of the Basic_RX and LFRX, the maximum input power for any of the other daughtercards is below -10dBm. The BASIC_RX and LFRX have a maximum input power of about +10dBm. -- 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] Dynamic range of USRP2-XCVR2450
Hi Marcus, -10dBm corresponds to 100µW. With an input impedance of 100Ohms, since Pmax rms= (Vmax rms)^2 / R, -- Vmax rms= 0.1 volt So, if I am right the maximum theoretical voltage at the input of the ADC, if 0 dB gain is set in the transceiver (XCVR2450 in my case) and noise figure of all components were 0 dB, is 0.1 volt However the gain of the transceiver is set to increase this [0 - 0.1] volt range to [0 - 1] volt range at the input of the ADC. Is it right ? Regarding the value of the ADC SNR (72.4dB), why is it important if it doesn´t depend on the input range? (SNR= 6.02*N + 1.76) There is something I miss..grr ! Many thanks. Jorge. On 24 October 2010 19:57, Marcus D. Leech mle...@ripnet.com wrote: On 10/24/2010 01:07 PM, Jorge Miguel wrote: Hello, I am trying to find out the minimum/maximun input power of the ADC LTC2284. I know that the maximum input voltage is 1 Volt, 0.707Vrms, but what is the input impedance? so that I can calculate the maximum input power as: minimum input power (SNR ADC) = Maximun input power ( [(0.707)/(2^14))^2]/Rin) + 72.4 dB = Maximun input power Am I right? Many thanks, Jorge I believe that it's a 100ohm balanced input. But the daughtercards all take a 50-ohm input, and convert to a balanced output just before the A/D. With the exception of the Basic_RX and LFRX, the maximum input power for any of the other daughtercards is below -10dBm. The BASIC_RX and LFRX have a maximum input power of about +10dBm. -- 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] Gnuradio Mode S project released
On Sun, 2010-10-24 at 19:22 +0200, Andrea Montefusco wrote: Nick, is it thinkable to operate the decoder at a lower sample rate ? (e.g. at 2 MS/s or even less) Mode S operates at 1Mbit/s bit rate, and being pulse-position-modulated the data rate is effectively 2Mchips/s. In order to guarantee at least one sample falls reasonably close to the center of the chip you have to sample multiple points per chip. If you could ensure somehow that your samples were aligned with the chip centers, you could sample at 2Msps. Nick *am* - Andrea Montefusco iw0hdvhttp://www.montefusco.com tel: +393356992791 fax: +390623318709 - ___ 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] Gnuradio Mode S project released
On 10/24/2010 07:22 PM, Andrea Montefusco wrote: is it thinkable to operate the decoder at a lower sample rate ? (e.g. at 2 MS/s or even less) I found this reference http://www.tech-software.net/adsb_decode1.php in a Eric A. Cottrell message that explains why we need an high sample rate: [...] I thought that the USRP and DVB tuner board could also receive ADS-B and Mode S. I did not know if my discone and long coax run would work. So I did some experiments. I used the fft and oscilloscope programs to check for activity. I did see activity on 1090 MHz. I then modified the oscilloscope program to do AM detection with the gr.complex_to_mag() function. I saw various pulse trains that look correct. There were some short ones that look like old transponders and longer ones that look like Mode S. I found the range of good gain settings was narrow (31 to 35) with 33 to be the best. I found the decimation of 16 gave good pulse shapes. The pulse timings are in 500 nS units so you need 250 nS sample times at least. [...] So, I believe there is no hope to decode this stuff with HAM SDR hardware. *am* - Andrea Montefusco iw0hdvhttp://www.montefusco.com tel: +393356992791 fax: +390623318709 - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnu radio
gunay_omer_7...@hotmail.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dynamic range of USRP2-XCVR2450
On 10/24/2010 04:27 PM, Jorge Miguel wrote: I will have a look at the white papers from that manufacturers. From your words, I imagine that the noise generated by the ADC will set a limit in the noise floor at the input of the ADC, isn´t it? Yes. The total signal power arriving at the A/D (signal+noise) must exceed the effective noise floor of the A/D by enough margin to allow demodulation of your signal of interest. Where demodulation is very loosely defined. Each modulation technique has its own SNR requirements. I do radio astronomy, where there's no demodulation, per se. In fact, most of the time my signals are *below* the total noise floor of the receiving system. But I have the very great advantage of being able to maximize bandwidth and integration time in order to see those below-the-noise-floor signals. -- 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] RAM consumption
Eric Blossom wrote:
99% of the base code distributed with GNU Radio (runtime + blocks)
allocates NO MEMORY once the flow graph has started (see below for
exceptions).
DO NOT use a vector_sink for anything other than QA code that
produces a small amount of output. The vector_sink will allocate an
unbounded amount of memory if you keep writing to it.
It is also possible to consume memory by sending an unbounded number
of messages into a message queue (gr.msg_queue) that doesn't have a
queue size limit and has a slow (or compute bound) reader.
If there's a GUI of any kind involved, or python code that's being
executed beyond initialization time, look there for problems.
Eric
Thanks for such a quick response. I am modifying C++ code, rather than
Python code. There is no GUI (just an XTERM accessed via std::cout
statements). I am using std::queue data structures and the push and pop to
these queues occurs in the same routine (see below).
I think that your vector sink comments refer to the Python construct, don't
they? What is the C++ equivalent of your 'DO NOT DO THIS' statement? Does
this mean I have to access the queue in a critical section or using explicit
thread-safe methods? My output seems to be sequenced just fine and there
are no duplicates or the like.
My C++ implementation is:
.
if ( (int)queue.size() = MAX) { queue.pop() }
queue.push(value)
.
It is possible that the CPU is not able to keep up with the emptying task,
but then I'd expect the queue size to be growing beyond MAX and it isn't...
based on std::cout output anyway. I suppose that this output could be also
lagging further and further behind, but the output all appears to complete
properly as each of my relatively rare test events occur (~1 second apart).
Is there something specific that I must do inside the C++ code to avoid
GnuRadio run-time memory allocation issues? I have not specifically added
any new malloc/dalloc/calloc statements to the existing code myself. Could
declaring data structures (e.g. scalars, arrays, std::queue) inside or
external to subroutines have this kind of side effect? Would I be better
off implementing the queue using an array/circular buffer or std::vector of
my own, rather than using the one from the std:: library?
My overall objective is that I want to be able to capture and print off
samples from the ADC on a specific trigger characteristic of the sample
values (e.g. magnitude). So, I need to remember (either print out to the
XTERM or store to a file) small subsets of contiguous ADC samples that
occurred just prior to my trigger condition. Once they are printed, I want
to 'forget' them entirely and start looking for my trigger again. In my
testing, this amounts to printing about 50 lines every second or so, but I
am consuming RAM at a steady rate of about 3 MB/s.
/ David Knox
--
View this message in context:
http://old.nabble.com/RAM-consumption-tp30041914p30043424.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] Gnuradio Mode S project released
Hello, Articles I read say that a 10MSPS rate gives better performance that a 8MSPS rate. I used the 8MSPS rate and still got good performance. The oversampling is used in determining if the pulse is valid or part of interference. Some receivers use a huge ROM lookup table to convert all the sample values of the PPM slot into a one or zero. 73 Eric - Start Original Message - Sent: Sun, 24 Oct 2010 20:40:18 +0200 From: Andrea Montefusco andrea.montefu...@gmail.com To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Gnuradio Mode S project released On 10/24/2010 07:22 PM, Andrea Montefusco wrote: is it thinkable to operate the decoder at a lower sample rate ? (e.g. at 2 MS/s or even less) I found this reference http://www.tech-software.net/adsb_decode1.php in a Eric A. Cottrell message that explains why we need an high sample rate: [...] I thought that the USRP and DVB tuner board could also receive ADS-B and Mode S. I did not know if my discone and long coax run would work. So I did some experiments. I used the fft and oscilloscope programs to check for activity. I did see activity on 1090 MHz. I then modified the oscilloscope program to do AM detection with the gr.complex_to_mag() function. I saw various pulse trains that look correct. There were some short ones that look like old transponders and longer ones that look like Mode S. I found the range of good gain settings was narrow (31 to 35) with 33 to be the best. I found the decimation of 16 gave good pulse shapes. The pulse timings are in 500 nS units so you need 250 nS sample times at least. [...] So, I believe there is no hope to decode this stuff with HAM SDR hardware. *am* - Andrea Montefusco iw0hdvhttp://www.montefusco.com tel: +393356992791 fax: +390623318709 - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio - End Original Message - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RAM consumption
On Sun, Oct 24, 2010 at 02:28:04PM -0700, David Knox wrote:
Eric Blossom wrote:
99% of the base code distributed with GNU Radio (runtime + blocks)
allocates NO MEMORY once the flow graph has started (see below for
exceptions).
DO NOT use a vector_sink for anything other than QA code that
produces a small amount of output. The vector_sink will allocate an
unbounded amount of memory if you keep writing to it.
It is also possible to consume memory by sending an unbounded number
of messages into a message queue (gr.msg_queue) that doesn't have a
queue size limit and has a slow (or compute bound) reader.
If there's a GUI of any kind involved, or python code that's being
executed beyond initialization time, look there for problems.
Eric
Thanks for such a quick response. I am modifying C++ code, rather than
Python code. There is no GUI (just an XTERM accessed via std::cout
statements). I am using std::queue data structures and the push and pop to
these queues occurs in the same routine (see below).
Is there only a single thread that manipulates the queue, or is one
for example inside of a GNU Radio block, and one is outside of the
block?
I think that your vector sink comments refer to the Python construct, don't
they? What is the C++ equivalent of your 'DO NOT DO THIS'
statement?
They map 1:1 from Python to C++:
gr.msg_queue - gr_msg_queue
gr.vector_sink_* - gr_vector_sink_*
Does this mean I have to access the queue in a critical section or using
explicit
thread-safe methods?
As in any multithreaded programming, if there is more than one thread
involved, and you are accessing a shared data structure from more than
one thread, and somebody else isn't already handling the critical
section for you, you WILL have to implement a critical section.
STL containers are not inherently thread-safe.
My output seems to be sequenced just fine and there
are no duplicates or the like.
My C++ implementation is:
.
if ( (int)queue.size() = MAX) { queue.pop() }
queue.push(value)
.
It is possible that the CPU is not able to keep up with the emptying task,
but then I'd expect the queue size to be growing beyond MAX and it isn't...
based on std::cout output anyway. I suppose that this output could be also
lagging further and further behind, but the output all appears to complete
properly as each of my relatively rare test events occur (~1 second apart).
Is there something specific that I must do inside the C++ code to avoid
GnuRadio run-time memory allocation issues?
No.
I have not specifically added
any new malloc/dalloc/calloc statements to the existing code myself. Could
declaring data structures (e.g. scalars, arrays, std::queue) inside or
external to subroutines have this kind of side effect?
Of course they could. If you're using some kind of container, you
need to know what it's worst case running time and memory usage is.
Would I be better
off implementing the queue using an array/circular buffer or std::vector of
my own, rather than using the one from the std:: library?
It all depends.
Have you written a new C++ block for GNU Radio?
If so, have you written any QA code for it?
If you've written a block, and you replace the guts of your work or
general_work method with:
return noutput_items; // turn block into a NOP
does the memory increase stop?
If you haven't written a new block, how are you getting access to the
samples?
My overall objective is that I want to be able to capture and print off
samples from the ADC on a specific trigger characteristic of the sample
values (e.g. magnitude). So, I need to remember (either print out to the
XTERM or store to a file) small subsets of contiguous ADC samples that
occurred just prior to my trigger condition. Once they are printed, I want
to 'forget' them entirely and start looking for my trigger again. In my
testing, this amounts to printing about 50 lines every second or so, but I
am consuming RAM at a steady rate of about 3 MB/s.
Seems simple enough. Instead of us trying to guess what you're actually
doing, can you post a link to the code including an example that
exercises it?
/ David Knox
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] GNU Radio meetup at the 2010 SDR Technical Conference, Washington, DC
Tom, I have to agree with Steve. I wanted to go to SDR10 in DC but I am afraid the registration fee kept me from making it. I also would love to offer my center as a location for a possible meeting. We are in Albuquerque. We are walking distance from the airport and have many very inexpensive hotels near us. Craig Craig J. Kief Deputy Director craig.k...@cosmiac.org 505.934.1861 cell (preferred) 505.242.0339 office 2350 Alamo Avenue SE, Ste. 100 Albuquerque, NM 87106 -Original Message- From: discuss-gnuradio-bounces+craig.kief=cosmiac@gnu.org [mailto:discuss-gnuradio-bounces+craig.kief=cosmiac@gnu.org] On Behalf Of Steve Mcmahon Sent: Sunday, October 24, 2010 12:14 AM To: Tom Rondeau Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] GNU Radio meetup at the 2010 SDR Technical Conference, Washington, DC Tom: Thanks for organizing this. I would REALLY like to attend the conference and also this meeting, but I already have commitments for that week that I can't re-schedule. But I am planning on going next year. Is the conference run every year? Is it always held in Washington D.C.? So I had another idea I'd like to propose to the community. Would anyone be interested in attending informal and regular GNU Radio User Group (GRUG) meetings, similar to the Linux User Group (LUG) meetings that are held regularly in cities all over the world? I am located in Boston, so if there's some interest, I'd be willing to organize an initial meeting in mid-January in Boston/Cambridge. With any luck, we could hold such meetings every other month or once per quarter. Please let me know if anyone would be interested. Steve McMahon --- On Thu, 10/21/10, Tom Rondeau trondeau1...@gmail.com wrote: From: Tom Rondeau trondeau1...@gmail.com Subject: [Discuss-gnuradio] GNU Radio meetup at the 2010 SDR Technical Conference, Washington, DC To: GNURadio Discussion List discuss-gnuradio@gnu.org Date: Thursday, October 21, 2010, 7:22 PM GNU Radio community, We will be holding a GNU Radio meetup at the SDR Technical Conference on Wednesday, December 1 at 7:30 in the Hyatt Regency Crystal City. Meeting room TBA. For those of you who made it last year, it will be a similar event. Matt Ettus and myself will be there with Ettus Research, LLC sponsoring food and beverages. This is a time for people involved in the community to get to know each other a bit better and share their work and ideas. I'll take some time to provide everyone present with some of our ideas for the future of the project and Matt will be sharing some of his plans for Ettus Research. Importantly, though, I would really love to hear back from all of you about what work you're doing as well as thoughts on the project. We will have 1.5 hours for discussion, including some time at the beginning for food and some informal introductions. For the bulk of it, I would really like to get some good discussion going about GNU Radio and its applications. So please come prepared to share! We will likely head out to a local bar for around 9PM to continue the discussions over beer. This year, we are going to be more formally a part of the SDR Conference, and as such, the organizers of the conference have asked for people to register. You have a few options for registering, including the free option. I will be attending all week and have a presentation on Tuesday as part of an Open Source Software panel session put together by Phil Balister as well as a tutorial on GNU Radio on Thursday. Matt will be there as an exhibitor during the entire conference. That's just to let you know some of the activities going on during the full conference. You can find more here: http://conference.wirelessinnovation.org/ To register, you can see the different options here: http://conference.wirelessinnovation.org/mc/page.do?sitePageId=118975orgId= s1 I apologize for the timing of this email. I realize now that I should have gotten it out sooner since tomorrow is the cut-off of the early registration deadline. Anyway, the organizers are asking people to register, even if that's just the Exhibitors and Exhibits Only Attendee, which is free for pre-registration or $50 for on-site registration. Location information: For those not familiar with the DC area, Crystal City is just south of DC (technically in Arlington, VA) on Rt. 1. Here's the map: http://goo.gl/maps/itPK The bar we will most likely be going to is Bailey's Sports Grill (or The Fox and Hound, depending on where you look). It's a decent pub with a large selection of beer, and I think we all had a pretty good time there last year. Note that this is the one on Crystal City Dr, not Wilson Blvd. http://goo.gl/maps/uaXi RSVP: It's not necessary to tell me that you're coming, but it would help us to get a feel for the amount of food we should plan on. Thanks! And I look forward to seeing many of you there! Tom
[Discuss-gnuradio] Question GNU Radio swig Path
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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
