[Discuss-gnuradio] Changing to next fails?
Hi, Maybe a stupid question...am I doing smth. wrong, or has there been some change? When doing a git checkout next and trying to build next, it still build master. Even completely deleting the gnuradio folder does not help. Also I get some error message when doing git checkout next, git branch next gives no error, but again it build master. Ralph. -- Ralph A. Schmid Mondstr. 10 90762 Fürth +49-171-3631223 ra...@schmid.xxx http://www.bclog.de/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Changing to next fails?
On Mon, Apr 1, 2013 at 10:11 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx wrote: Hi, Maybe a stupid question...am I doing smth. wrong, or has there been some change? When doing a git checkout next and trying to build next, it still build master. Even completely deleting the gnuradio folder does not help. Also I get some error message when doing git checkout next, git branch next gives no error, but again it build master. The code hasn't changed for days and it builds fine so yes, you are probably doing something wrong. Without knowing what you do after the checkout it's hard to guess what it could be. ALex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] macport switching between gnuradio and gnuradio-devel ports with installed gr-osmosdr?
Hi Mike - You're (all) welcome for the gr-osmosdr port. Seems like it is pretty well used as well as kept up, and so is a good candidate for being in MacPorts. That's a great suggestion! I'm doing a port selfupdate right now to get the latest of everything, and when that is done I will fix this issue. I'll post back here when it's ready; should be later this morning (US/ET). - MLD On Mar 31, 2013, at 2:26 PM, Michael L Kornegay m...@mlksys.atlanta.ga.us wrote: Thanks for adding the gr-osmosdr package to macports. Hopefully there is a simple way to install it so that it can work with either gnuradio or gnuradio-devel when switching back and forth. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Changing to next fails?
The code hasn't changed for days and it builds fine so yes, you are probably doing something wrong. Without knowing what you do after the checkout it's hard to guess what it could be. I have done what I have described :) But the other tip seems to help, git pull origin... ALex Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] More GSoC opportunities
Hopefully these guys get accepted also: http://www.parallella.org/ideas/ See the GNU Radio ideas. As some of you know, I have a similar idea on the GNU Radio page for Xilinx Zynq systems. If both of these projects are accepted into GSoC there should be considerable overlap in the part of the solution that interfaces with the GNU Radio data buffers. I am pretty certain the core GNU Radio developers do not want to say two different approaches for interfacing closely coupled co-processors into GNU Radio. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Source block for the funcube pro plus
Hi Volker, You Wrote: I tested against 3.6.4, gentoo 64 bit. I'm not very familiar with cmake, so perhaps the cmake code may be improved. Can you send me the error message ? I think it was just my set of multiple/semi broken trees of various 3.6.x branches, precog etc that was confusing cmake et al. A pristine gnuradio build from 3.6.4, and it builds perfectly, and I can see the new block in grc. However, when trying to run a flow graph, I get the following: Set Frequency to: 144700 KHz, corrected to: 144700 Khz audio_alsa_source[plughw:1,0]: snd_pcm_hw_params failed: Input/output error Traceback (most recent call last): File /home/iain/FlowGraphs/top_block.py, line 73, in module tb.Run(True) File /opt/gnuradio-3.6.4/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py, line 76, in Run self.start() File /opt/gnuradio-3.6.4/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, line 97, in start self._tb.start(max_noutput_items) File /opt/gnuradio-3.6.4/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py, line 3063, in start return _gnuradio_core_runtime.gr_top_block_sptr_start(self, max_noutput_items) RuntimeError: check topology failed on audio_alsa_source(11) using ninputs=0, noutputs=2 Curiously, I got similar error when a few months ago I tried to use the FCDPP just as a raw ALSA device, so I guess the error is truly within the ALSA subsystem rather than your code, but any ideas ? 73s Iain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Changing to next fails?
Ralph, git branch next just moves you over to the next branch but doesn't pull anything down. If there was an error doing git pull next, then just moving to that branch wouldn't have any effect. This seems to be the problem, as usually git checkout xxx did the job. Also, you mentioned an error. When asking for help and you have an error, it makes it much easier for us to help you if you tell us what the error is. Of course, but in this case I assumed some basic problem, and I was right :) The problem is that I usually do email from Windows, not from Linux, so it takes a second attempt to exactly copy the error and paste it. Finally, while next hasn't changed for a couple of days, we did a pretty big change last week in our move to full 3.7 form. We removed gnuradio-core and now have a gnuradio-runtime. This is probably the cause of your issues. I know this change, and that exactly is the reason that I wanted to give it a try. Now next is building while I ride a train from Munich to Nuremburg with 300 km/h and sipping a beer. Tom Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Source block for the funcube pro plus
On 31/03/13 23:29, Alexandru Csete wrote: On Thu, Mar 28, 2013 at 11:41 AM, Volker Schroer dl1...@gmx.de wrote: Just for your information: In imitation of the gr-fcd source I set up a gnuradio source for the funcube pro+ ( linux only) . To avoid the crashes depending on libusb I used the hidraw driver. The source and an example can be found on https://github.com/dl1ksv/gr-fcdproplus.git Comments are welcome. Enjoy it Hi Volker, Nice work. Agreed, Very appreciated work as well. I would recommend letting the user specify the device string and only use auto-detection if string is empty. I agree here, but would also add one more request. Specify the frequency in Hz, kHz is a pain to convert in the head, and Hz can be bad enough by itself! (You would not believe the number of times my flowgraphs have ended up on 1.4GHz rather than 144MHz...) Other similar blocks (eg UHD, FCD) also specify in Hz, and it would be good to have compatibility, if only to let me switch between inputs with a selector block, and not needing a /1000 variable in there as well :) 73s Iain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] macport switching between gnuradio and gnuradio-devel ports with installed gr-osmosdr?
This is taking longer than I expected, because I have to modify something other than the Portfile in order to get the functionality I need. I have to run that change past the MacPorts powers that be; they are usually pretty responsive, usually within a day or so. I'll post back when the change is in place. - MLD On Apr 1, 2013, at 8:54 AM, Michael Dickens m...@alum.mit.edu wrote: You're (all) welcome for the gr-osmosdr port. Seems like it is pretty well used as well as kept up, and so is a good candidate for being in MacPorts. That's a great suggestion! I'm doing a port selfupdate right now to get the latest of everything, and when that is done I will fix this issue. I'll post back here when it's ready; should be later this morning (US/ET). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] macport switching between gnuradio and gnuradio-devel ports with installed gr-osmosdr?
Hi Michael, thank you very much for your great job with the gnuradio* and gr-osmosdr stuff in Macports, even keeping us updated about the progress! Just a comment: I've found that the gnuradio-next @3.7.0_20130326_0+python27+uhd build fails in my system. It didn't happen with previous versions. It's a dwarf in my computer, or someone else has experienced the same? Do I better wait for that forthcoming release? Best regards, Carles On Mon, Apr 1, 2013 at 6:16 PM, Michael Dickens m...@alum.mit.edu wrote: This is taking longer than I expected, because I have to modify something other than the Portfile in order to get the functionality I need. I have to run that change past the MacPorts powers that be; they are usually pretty responsive, usually within a day or so. I'll post back when the change is in place. - MLD On Apr 1, 2013, at 8:54 AM, Michael Dickens m...@alum.mit.edu wrote: You're (all) welcome for the gr-osmosdr port. Seems like it is pretty well used as well as kept up, and so is a good candidate for being in MacPorts. That's a great suggestion! I'm doing a port selfupdate right now to get the latest of everything, and when that is done I will fix this issue. I'll post back here when it's ready; should be later this morning (US/ET). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] error building next on osx
Carles points out that the next branch is failing on OSX (via the gnuradio-next port). Here's the error log. Ideas? - MLD [ 6%] Building CXX object gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/gr_basic_block.cc.o cd /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/gnuradio-runtime/lib /usr/bin/clang++ -DALIGNED_MALLOC=0 -DENABLE_GR_LOG -DHAVE_ARPA_INET_H -DHAVE_COSF -DHAVE_GETPAGESIZE -DHAVE_GETTIMEOFDAY -DHAVE_LOG4CPP -DHAVE_MMAP -DHAVE_NANOSLEEP -DHAVE_NETDB_H -DHAVE_NETINET_IN_H -DHAVE_POSIX_MEMALIGN -DHAVE_PTHREAD_SIGMASK -DHAVE_SELECT -DHAVE_SIGACTION -DHAVE_SIGNAL_H -DHAVE_SINF -DHAVE_SNPRINTF -DHAVE_SYSCONF -DHAVE_SYS_IPC_H -DHAVE_SYS_MMAN_H -DHAVE_SYS_RESOURCE_H -DHAVE_SYS_SELECT_H -DHAVE_SYS_SHM_H -DHAVE_SYS_SOCKET_H -DHAVE_SYS_TIME_H -DHAVE_SYS_TYPES_H -DHAVE_UNISTD_H -DTRY_SHM_VMCIRCBUF -Dgnuradio_runtime_EXPORTS -pipe -Os -arch x86_64 -O3 -DNDEBUG -arch x86_64 -fPIC -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/gnuradio-runtime/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/lib -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/gnuradio-runtime/lib/../include -I/opt/local/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gruel/src/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/gruel/src/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gruel/src/swig -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/gruel/src/swig -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/volk/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/volk/include -o CMakeFiles/gnuradio-runtime.dir/gr_basic_block.cc.o -c /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/lib/gr_basic_block.cc In file included from /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/lib/gr_basic_block.cc:27: /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include/gr_basic_block.h:63:53: error: no member named 'comperator' in namespace 'pmt'; did you mean 'operator'? typedef std::mappmt::pmt_t , msg_handler_t, pmt::comperator d_msg_handlers_t; ~^ /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include/gr_basic_block.h:67:50: error: no member named 'comperator' in namespace 'pmt'; did you mean 'operator'? typedef std::mappmt::pmt_t, msg_queue_t, pmt::comperatormsg_queue_map_t; ~^ /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include/gr_basic_block.h:68:50: error: no member named 'comperator' in namespace 'pmt'; did you mean 'operator'? typedef std::mappmt::pmt_t, msg_queue_t, pmt::comperator::iterator msg_queue_map_itr; ~^ /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include/gr_basic_block.h:68:63: error: non-friend class member 'iterator' cannot have a qualified name typedef std::mappmt::pmt_t, msg_queue_t, pmt::comperator::iterator msg_queue_map_itr; ~~^ /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include/gr_basic_block.h:68:63: error: typedef declarator cannot be qualified typedef std::mappmt::pmt_t, msg_queue_t, pmt::comperator::iterator msg_queue_map_itr; ~~^ /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include/gr_basic_block.h:68:71: error: expected ';' at end of declaration list typedef std::mappmt::pmt_t, msg_queue_t,
Re: [Discuss-gnuradio] error building next on osx
On Mon, Apr 1, 2013 at 12:44 PM, Michael Dickens m...@alum.mit.edu wrote: Carles points out that the next branch is failing on OSX (via the gnuradio-next port). Here's the error log. Ideas? - MLD Is this the current HEAD on the next branch? As we've said, we're going through a lot of major changes on next right now as the last steps to 3.7. One huge change I've just recently finished was removing gruel and putting all of it's functionality into gnuradio-runtime. That could either fix this problem or make it worse... Regardless, I'm not inclined to spend too much time right now debugging it until we're more fully settled on the structure in 'next.' For now, I'd go back before the major gnuradio-runtime changes. I think this commit should work: 40ab0030dbe821c9ed475a0b73898040f4af581c I might bug you for some help on OSX issues in a few days when we think that we're ready. Thanks, Tom [ 6%] Building CXX object gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/gr_basic_block.cc.o cd /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/gnuradio-runtime/lib /usr/bin/clang++ -DALIGNED_MALLOC=0 -DENABLE_GR_LOG -DHAVE_ARPA_INET_H -DHAVE_COSF -DHAVE_GETPAGESIZE -DHAVE_GETTIMEOFDAY -DHAVE_LOG4CPP -DHAVE_MMAP -DHAVE_NANOSLEEP -DHAVE_NETDB_H -DHAVE_NETINET_IN_H -DHAVE_POSIX_MEMALIGN -DHAVE_PTHREAD_SIGMASK -DHAVE_SELECT -DHAVE_SIGACTION -DHAVE_SIGNAL_H -DHAVE_SINF -DHAVE_SNPRINTF -DHAVE_SYSCONF -DHAVE_SYS_IPC_H -DHAVE_SYS_MMAN_H -DHAVE_SYS_RESOURCE_H -DHAVE_SYS_SELECT_H -DHAVE_SYS_SHM_H -DHAVE_SYS_SOCKET_H -DHAVE_SYS_TIME_H -DHAVE_SYS_TYPES_H -DHAVE_UNISTD_H -DTRY_SHM_VMCIRCBUF -Dgnuradio_runtime_EXPORTS -pipe -Os -arch x86_64 -O3 -DNDEBUG -arch x86_64 -fPIC -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/gnuradio-runtime/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/lib -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/gnuradio-runtime/lib/../include -I/opt/local/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gruel/src/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/gruel/src/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gruel/src/swig -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/gruel/src/swig -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/volk/include -I/opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/build/volk/include -o CMakeFiles/gnuradio-runtime.dir/gr_basic_block.cc.o -c /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/lib/gr_basic_block.cc In file included from /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/lib/gr_basic_block.cc:27: /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include/gr_basic_block.h:63:53: error: no member named 'comperator' in namespace 'pmt'; did you mean 'operator'? typedef std::mappmt::pmt_t , msg_handler_t, pmt::comperator d_msg_handlers_t; ~^ /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include/gr_basic_block.h:67:50: error: no member named 'comperator' in namespace 'pmt'; did you mean 'operator'? typedef std::mappmt::pmt_t, msg_queue_t, pmt::comperator msg_queue_map_t; ~^ /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include/gr_basic_block.h:68:50: error: no member named 'comperator' in namespace 'pmt'; did you mean 'operator'? typedef std::mappmt::pmt_t, msg_queue_t, pmt::comperator::iterator msg_queue_map_itr; ~^ /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-next/work/gnuradio-3.7.0_20130329/gnuradio-runtime/include/gr_basic_block.h:68:63: error: non-friend class
Re: [Discuss-gnuradio] real time airplane data
Hi Bill, I hope you're doing well since your visit to the office. I've recently done some development on similar lines to demonstrate a multi-function transceiver (COM/NAV, ILS, GPS, ADS-B, etc.). I originally had the idea to integrate such a device, probably based on an embedded-series USRP, in a Cozy MK IV http://en.wikipedia.org/wiki/Cozy_MK_IV I am building. However, the Cozy is on hold since I don't have any space to build here in Silicon Valley. So, I've been falling back to some experiments in tin cans with Balint Seeber. http://www.youtube.com/watch?v=tz18voOrU1c. http://wiki.spench.net/wiki/Spectrum_Recording I was actually thinking about submitting a proposal to Air Venture myself. I'd be interested in collaborating with you. Of course, Nick Foster is also a guru of ADS-B reception. -John On Mon, Apr 1, 2013 at 8:51 AM, cw...@yahoo.com wrote: I am a former Navy Test pilot, ham, and experimental airplane enthusiast. We found GNUradio last year as part of a course I teach on airborne software and Avionics. We have access to packet streams, RS-232 and ARINC-429 in two experimental airplanes. The data includes all the parameters sent to Electronic Flight Info Systems (EFIShttp://grtavionics.com) displays. Examples are: flight instruments display for air data and attitude/heading, GPS moving map with terrain, obstructions, weather, and traffic and engine and system monitoring. I believe we could port these real time streams into GNUradio companion. Many ideas are exiting when you consider linking dynamic airplane data to GNUradio. Certainly all aviaonics functions could be reproduced. It might make a very interesting forum at EAA Airventure at Oshkosh in July. Thanks Bill Miller ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error building next on osx
This is 007b401cf14fcfc067d11f5e4d2ca1730407803b, which according to my git-foo is the latest commit to (aka HEAD of) this branch. Fixing it right now is not a big deal IMHO: I just keep the gnuradio-next branch up to date and if it works that's great and if it does not then (as the description states) use the current gnuradio-next install and check back in a few days and hopefully the build will have been fixed. I'm going to leave this port where it is, and I'll just continue to update it as commits are merged. Please do feel free to ping me about OSX stuff if/when you need/want to. - MLD On Apr 1, 2013, at 12:53 PM, Tom Rondeau t...@trondeau.com wrote: On Mon, Apr 1, 2013 at 12:44 PM, Michael Dickens m...@alum.mit.edu wrote: Carles points out that the next branch is failing on OSX (via the gnuradio-next port). Here's the error log. Ideas? - MLD Is this the current HEAD on the next branch? As we've said, we're going through a lot of major changes on next right now as the last steps to 3.7. One huge change I've just recently finished was removing gruel and putting all of it's functionality into gnuradio-runtime. That could either fix this problem or make it worse... Regardless, I'm not inclined to spend too much time right now debugging it until we're more fully settled on the structure in 'next.' For now, I'd go back before the major gnuradio-runtime changes. I think this commit should work: 40ab0030dbe821c9ed475a0b73898040f4af581c I might bug you for some help on OSX issues in a few days when we think that we're ready. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] terminating benckmark_rx.py after TIMEOUT
If you are running ofdm benchmark_rx, then the TIMEOUT comes from digital_ofdm_sampler.cc. I think the timeout occurs, if the sampler does not get another preamble even after 1000 (this is the value set currently) symbols, then it declares TIMEOUT and enters STATE_PREAMBLE. thanks and regards --Anirudh Sahoo Advanced Network Technology Div. National Institute of Standards and Technology (NIST) 100 Bureau Drive, Gaithersburg, MD - 20878 Room - B230, bldg.- 222 Phone- 301-975-4439 -Original Message- From: discuss-gnuradio-bounces+anirudha.sahoo=nist@gnu.org [mailto:discuss-gnuradio-bounces+anirudha.sahoo=nist@gnu.org] On Behalf Of sumitstop Sent: Thursday, March 28, 2013 9:45 PM To: Discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] terminating benckmark_rx.py after TIMEOUT How can I terminate benchmark_rx.py after a certain number of TIMEOUTS. I have observed two things 1. When I dump Tx data using --to-file option and then demod them using benchmark_rx , benchmark_rx terminates after demod. No waiting ! 2. When I use benchmark_rx for OTA reception with USRP, and once the Tx stops sending data, it keeps waiting for data and give TIMEOUTS but never stops. My application wants to get it terminated automatically after a certain number of timeouts. I tried digging a lot about where this TIMEOUT is coming from but no help so far. Any pointers. -- View this message in context: http://gnuradio.4.n7.nabble.com/terminating-benckmark-rx-py-after-TIMEOUT-tp40406.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error building next on osx
On Mon, Apr 1, 2013 at 1:26 PM, Michael Dickens m...@alum.mit.edu wrote: This is 007b401cf14fcfc067d11f5e4d2ca1730407803b, which according to my git-foo is the latest commit to (aka HEAD of) this branch. Fixing it right now is not a big deal IMHO: I just keep the gnuradio-next branch up to date and if it works that's great and if it does not then (as the description states) use the current gnuradio-next install and check back in a few days and hopefully the build will have been fixed. I'm going to leave this port where it is, and I'll just continue to update it as commits are merged. Please do feel free to ping me about OSX stuff if/when you need/want to. - MLD Got it. That sounds good. I'll let you know when things change. Tom On Apr 1, 2013, at 12:53 PM, Tom Rondeau t...@trondeau.com wrote: On Mon, Apr 1, 2013 at 12:44 PM, Michael Dickens m...@alum.mit.edu wrote: Carles points out that the next branch is failing on OSX (via the gnuradio-next port). Here's the error log. Ideas? - MLD Is this the current HEAD on the next branch? As we've said, we're going through a lot of major changes on next right now as the last steps to 3.7. One huge change I've just recently finished was removing gruel and putting all of it's functionality into gnuradio-runtime. That could either fix this problem or make it worse... Regardless, I'm not inclined to spend too much time right now debugging it until we're more fully settled on the structure in 'next.' For now, I'd go back before the major gnuradio-runtime changes. I think this commit should work: 40ab0030dbe821c9ed475a0b73898040f4af581c I might bug you for some help on OSX issues in a few days when we think that we're ready. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Shifted samples from USRP1
Hi, I'm using the USRP1 and the UHD driver together with gnuradio. Often, especially at high sample rates (8MHz), the spectrum observed in the fftsink becomes distorted after a while. It becomes almost mirrored. Typically it happens after a couple of overruns. I have tried finding out the reason for this and I suspect it is because the samples from the USRP1 are shifted so that what the computer thinks is the I1 sample is actually the Q0 sample. (When the samples are interleaved like this: I0 Q0 I1 Q1 I2 Q2 I3 Q3 I4 Q4 I5 Q5 ...) I have tried modifying the FPGA image so that the FPGA sends a constant positive sine wave to the computer and the same things happens also in this case. This narrows down the problem quite a lot... I have also tried modifying rx_buffer.v so that the I-channel is delayed one clock cycle more than the Q-channel. This causes the same distortion to be apparent immediately when starting the USRP. I wonder if you guys have any ideas about what may cause this and how it can be fixed? Ruben (I'm using the git version of uhd and gnuradio as of today) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] (no subject)
I have some questions regarding the coastas loop implemented, does it also consider the snr estimate too? like a Maximum Likelihood loop(tanh* snr). Also can you suggest me any interpolator for timing recovery and also polyphase bandedge filters implementation. This would be really helpful to me.As there is very little material available online, also as you are experts in these fields your guidance will be very useful ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Changing to next fails?
I meant that trying to build next after a checkout was bit vague given that there are 5 steps to be executed after a checkout. Well, what are those steps to the book? sudo make uninstall, git checkout xxx, cd xxx, cmake .., make. Did I miss something? AS I have mentioned, until now it did work this way, so I assumed that either something had changed or I simply missed something, and before it worked by coincidence. Alex Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pktno ??!!
i get what you meant now..will give a try and let you know about it.. thanks. - Manjusha -- View this message in context: http://gnuradio.4.n7.nabble.com/pktno-tp40416p40480.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Changing to next fails?
Oh, by the way, at 72 % building fails. Some unspecified error 2 or smth like that, no further information. Again I am in Windows now, can give the exact message when I boot Linux again, but I am afraid it said nothing more. Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SWIG issue with next
Hi, the most up-to-date 'next' fails to compile on my Ubuntu 12.10 (32 bit). Is this the same issue as http://gnuradio.org/redmine/issues/529 ? (gr_ctrlport has been disabled due to an unfortunate issue with GCC 4.7 and the pre-packaged ICE in Ubuntu; otherwise the same config that I use for the master. No remains of previous master builds etc.) [ 34%] Building CXX object gr-blocks/swig/CMakeFiles/_blocks_swig.dir/blocks_swigPYTHON_wrap.cxx.o /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:7188:22: error: redefinition of ‘struct swig::traitsunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:6180:22: error: previous definition of ‘struct swig::traitsunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:7192:23: error: redefinition of ‘struct swig::traits_asvalunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:6184:23: error: previous definition of ‘struct swig::traits_asvalunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:7198:23: error: redefinition of ‘struct swig::traits_fromunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:6190:23: error: previous definition of ‘struct swig::traits_fromunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:7208:22: error: redefinition of ‘struct swig::traitsstd::vectorunsigned int ’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:6200:22: error: previous definition of ‘struct swig::traitsstd::vectorunsigned int ’ make[2]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig.dir/blocks_swigPYTHON_wrap.cxx.o] Error 1 Peter ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pktno ??!!
Hi, I put the following code in packet_utils.py n=0 while len(pkt)!= : print make_packet: len(pkt) =,len(payload) # n=n+1 print pktno,n n=n+1 what it did is ,it kept incrementing until i stop it.Although i connect the usrp to the computer or not,it keeps incrementing. How can we know the correct number of packets tranmitted from this.The packet numbers i get are in any way right??!! Thanks.. - Manjusha -- View this message in context: http://gnuradio.4.n7.nabble.com/pktno-tp40416p40483.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG issue with next
On Mon, Apr 1, 2013 at 5:35 PM, Peter Horvath ejcs...@gmail.com wrote: Hi, the most up-to-date 'next' fails to compile on my Ubuntu 12.10 (32 bit). Is this the same issue as http://gnuradio.org/redmine/issues/529 ? Well, as I've said before, during these (hopefully) last few days of us working to get to the 3.7 release, you can't necessarily trust anything on the next branch. When we make a new next branch, it's in a state of well, it works for me but isn't getting full testing coverage, yet. But I appreciate you reporting errors that we might have missed. In this case, I believe I have fixed these issues on a current development branch we're working on that puts gruel into gnuradio-runtime. This should be merged into next soon. I've been testing this branch on both a 64-bit and 32-bit system to make sure these issues get resolved when they appear. (gr_ctrlport has been disabled due to an unfortunate issue with GCC 4.7 and the pre-packaged ICE in Ubuntu; otherwise the same config that I use for the master. No remains of previous master builds etc.) Yes, this is a known bug with Ice and GCC 4.7. ICE has patched it, but it's not in any of the standard repos, yet (I'm not even sure if it's going to be part of a patch release or if we just have to wait or hand-install a new version of ICE). Personally, I just downgraded to GCC 4.6 on my Ubuntu 12.10 installations. Tom [ 34%] Building CXX object gr-blocks/swig/CMakeFiles/_blocks_swig.dir/blocks_swigPYTHON_wrap.cxx.o /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:7188:22: error: redefinition of ‘struct swig::traitsunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:6180:22: error: previous definition of ‘struct swig::traitsunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:7192:23: error: redefinition of ‘struct swig::traits_asvalunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:6184:23: error: previous definition of ‘struct swig::traits_asvalunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:7198:23: error: redefinition of ‘struct swig::traits_fromunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:6190:23: error: previous definition of ‘struct swig::traits_fromunsigned int’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:7208:22: error: redefinition of ‘struct swig::traitsstd::vectorunsigned int ’ /x/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:6200:22: error: previous definition of ‘struct swig::traitsstd::vectorunsigned int ’ make[2]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig.dir/blocks_swigPYTHON_wrap.cxx.o] Error 1 Peter ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] (no subject)
On Mon, Apr 1, 2013 at 2:46 PM, vamshi krishna dodla vamshikrishna.do...@gmail.com wrote: I have some questions regarding the coastas loop implemented, does it also consider the snr estimate too? like a Maximum Likelihood loop(tanh* snr). Hi Vamshi, No, the Costas loop does not account for SNR. This is among a series of improvements that I'd like to see happen. We have an SNR estimator block that sends tags and one that we can easily outfit to send messages. We would then use this to send a message to blocks like this so they can adjust their behavior based on current SNR estimates. I wouldn't want to recalculate the SNR every time its needed. Also can you suggest me any interpolator for timing recovery and also polyphase bandedge filters implementation. This would be really helpful to me.As there is very little material available online, also as you are experts in these fields your guidance will be very useful Take a look at gr-digital/lib/fll_band_edge_cc for a frequency locked loop. There's a lot of debate over the merits of using just the band edge information to do timing recovery, since you'd be throwing away information by not taking the information in the entire symbol (also effects of multipath and adjacent channel interference). Implementations are very welcome, though. One thing we can do well in GNU Radio is pit algorithms against each other under real signal conditions to see how they work. For timing recovery, look at gr-digital/lib/pfb_clock_sync_ccf. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Data flow end up?
Hi, I have build up a transmitter which transmits frequencies to radio. I can swtich OFF and ON the transmitter. When flow graph runs the data is transmitted in the air by usrp and RF400 daughter board. The audio is a wav file saved on host or by direct input from mic. If i switched off the transmitter then where does the data ends up because data is still coming to input of UHD sink. Best Regards, SAJJAD SAFDAR___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Radio frequency range description list?
Hi, In the absence of any existing solution I am interested in trying to put something together, possibly as a GitHub project? Although a Wiki could be used, my focus is on a solution that is machine parsable, so any application could make use of it. I am not sure the best file format to use, but currently three come to mind: - xml - json - csv From looking at some documents that list frequency allocations, I figure that the files would be split into individual files, that cover the allocation by ITU region, country and other group, with the footnotes being in files separate to the allocation list, so that they could eventually be localised if need be. Something like: frequency-allocations/ itu_region1.txt itu_region2.txt eu.txt uk.txt us.txtfootnotes/ ca.txt us.txtrules/ us.txtThe fields I am thinking of are, at this point - frequency range - footnotes - rules - service type - service category - data format This is a first stab, so any feedback would be useful. One thing that I seem to be struggling with is how best to specify information that would make it clear which data encoder/decoder to be using. For example, I can imagine an application detecting that you have selected a frequency range that corresponds to GPS and brings a view that shows the GPS data in a human readable form or that you are in a range that represents broadcasts TV and brings up a view that shows the broadcast data. It may also be useful to have a list of channels, according to service type? Please let me know what you think. Andre From: aj...@bell.net To: discuss-gnuradio@gnu.org Date: Mon, 1 Apr 2013 01:13:17 + Subject: [Discuss-gnuradio] Radio frequency range description list? Hi, Has anyone created a machine parsable file that lists radio frequencies and what is covered by that range? At the simplest level I am thinking of something that would include country code, a frequency range and the identifier to what that range is, and possibly a string indicating typical data encoding. The idea being when using a UI, such as Gqrx you would be able to have a label identifying what sort of data you should be seeing and in other cases use this information for automatically loading the right configuration(s) for handling that frequency range. Andre ___Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
