[Discuss-gnuradio] Failure to build GNU Radio on various Ubuntu builds
Hello, After trying to install GNU Radio over the past few days I’vebeen unsuccessful due to various failures of GNU Radio to build. The latest error is as follows:- Segmentation fault (core dumped)gr-blocks/swig/CMakeFiles/blocks_swig5_swig_doc.dir/build.make:177:recipe for target 'gr-blocks/swig/blocks_swig5_doc.i' failedmake[2]: *** [gr-blocks/swig/blocks_swig5_doc.i] Error 139CMakeFiles/Makefile2:3254: recipe for target'gr-blocks/swig/CMakeFiles/blocks_swig5_swig_doc.dir/all' failedmake[1]: ***[gr-blocks/swig/CMakeFiles/blocks_swig5_swig_doc.dir/all] Error 2Makefile:147: recipe for target 'all' failedmake: *** [all] Error 2make failedExiting Gnu Radio build/install As mentioned, this is the latest error of a series ofmany other errors occurring during previous install/build attempts but whichwould be too numerous to mention here. I’ve tried installing using Marcus’s script from the ShirleyBay server but the install fails near the end when attempting to build asmentioned above. I modified Marcus’s script at one point to get the install torun more successfully although eventually even that modification to a line inthe script fails to lead to a successful overall build but it does appear tobuild further doing that. On this occasion, I’ve tried various distro’s of Ubuntu(12.04 LTS, 14.04 LTS – 32 bit and 15.04 64 bit) but none accommodate theinstall of GNU Radio without some error or other. I feel I have installed prerequisites and so forth andprerequisites from various suggestions in the various threads on other sitesdiscussing the install of GNU Radio on Ubuntu. I should say that I’ve installed GNURadio successfully manytimes in the past, using 12.04 LTS and installing GNU Radio on Windows 7 andthis has been great to use with my Ettus USRP B100 (using UHD) at the time.However, today, some two years later I want to use GNU Radio a lot more andhopefully write modules and develop a SDR UI for my Ettus device but I don’tappear to be having any success at the GNU Radio install which is frustrating. I’ve used so much time up trying to overcome the variousissues, I’m now turning to ask for help as I feel I’ve exhausted every approachI can try with my present knowledge level. All help and guidance is very much appreciated and manythanks in advance. Mark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Runtime error - Empty Device Address in GRC Flowgraph build
Hello, After installing GRC into Ubuntu 15.05 64bit I get the following error when trying to run a GRC flow graph example:- --- RuntimeError: LookupError: KeyError: No devices found for -> Empty Device Address --- A uhd_find_device command successfully returns the serial number from my USRP B100 in TERMINAL. However, as I say, the flowgraph wont build as it doesn’t appear to be able to locate my USRP B100 via its USB connection. "uhd_images_downloader.py" successfully runs and running uhd-usrp.rules to moves rule file to /etc/udev/rules.d/ carries out ok too. However, again, I'm still unable to build a successful GRC flowgraph with my B100. I leave the device address empty in the GRC UHD USRP Source block but again, GRC wont build the flowgraph and returns the above error message. Please help as I've spent days trying to get GRC to install and operate successfully. Many thanks in advance, Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Follow up: Failure to build GNU Radio on various Ubuntu builds
I managed to resolve a problem with the install. Commands, find_usrp_devices and uhd_usrp_probe failed to get my B100 to respond with the model and daughter board and FPGA information. Yet at other times it would work, albeit very briefly. Whilst trying to keep this follow up mail brief, the problem was caused by the USB lead I was using. Although a new lead and just 2m in length, it must be unable to handle the bus communications between the USRP and my PC. However, for the past few months it's been fine when using my B100 on Windows 8.1 when casually running SDR# or HDSDR. Whilst working in Ubuntu, when I ran the lsusb command, the USRP was listed. This was puzzling, for me anyway, as beyond that the USRP would not function or rather I could not get it to intermittently communicate with my PC, as mentioned above. Whilst switching back to my Windows partition, I checked the USB lead with known working applications in Windows 10; HDSDR and SDR#, since by this time I felt my USRP B100 may have been faulty. My USRP wouldn't work in those applications either, though it had previously worked perfectly well on the same now suspect USB lead. The commands, find_usrp_devices and uhd_usrp_probe on a Windows platform (from Command line) wouldn't work with the suspect faulty cable attached (the command, uhd_usrp_probe,being particularly problematic in returning runtime errors). Again, without going into more tests and irregular driver responses in Windows 10, with the UHD driver throwing up errors, I changed the USB cable with another cable in desperation and the whole system came alive and has remained so over the past day or so. I swapped the cable with a 1.5m filtered USB cable I've owned for years and this confirmed the problem. I swapped it back again, to the suspect cable, and the irregular functions reoccurred. However, the suspect USB lead works fine with any other equipment I have such as printer and an USB expansion port. I wasn't using an expansion USB device when these errors were occurring BTW, just the suspect one USB lead between the PC and the USRP B100. All it is left for me to do is now go back to my Ubuntu partition and try to reinstall GNURadio again on a fresh install of Ubuntu (as I have done so many times this past week trying to get it to work) and hopefully get some more positive results. I will start with Ubuntu 12.04 LTS 64 bit as that was the last known Ubuntu distro that worked two years ago when running many successful installs of GNURadio on my other PC's and laptop. This includes successfully installing GNURadio on Windows 7 at the time. However, in terms of Ubuntu, I will again use Marcus's excellent build-gnuradio script, as I did two years ago and work on from there. I'm hoping Marcus's script will fetch the required dependencies and build to a successful outcome this time around again. Else, if you can advise on any other approach to installing GNURadio, on more recent Ubuntu distro's, so that it will also reliably work with my B100 USRP, I should be grateful again for your help. I really want to learn and work with GNURadio so that I can better understand its function since with various academic commitments I have had so little time over the past couple of years and more since investing in the Ettus USRP concept back in 2012. Again, your patient help is very much appreciated. Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Grid/Coordinate placement ('GUI hint' QY/WX) control query
This is perhaps a trivial query about the use of QT (or WX) GUI controls when trying to design widgets (GUI controls) to position themselves on the runtime workspace in GNU Radio. For example, if I try to place a QT button control at 'GUI hint' coordinates 0,0,1,1, I can never seem to get the button to span just a small width - the button spans the take up the entire column workspace at runtime. Furthermore when placing other widgets, despite trying to use the 'GUI Hint' correctly, the placement and width of controls appear to interfere with one another and get displaced into unexpected areas of the workspace when the flow graph is executed at runtime. I've tried to follow what little has been published about how the GUI Hint function is suppose to work, but the widgets still appear to give odd behaviours. I shouldn't compare this with say developing GUI's in Visual Studio etc; but it seems to me that despite being me being able to design flowcharts that result in fully functional radio systems with GNU Radio and my USRP, I find the frustration of working with 'GUI Hint' problematic when trying to design a usable user interface from scratch. Maybe there is no hard and fast rule how to use the 'GUI Hint' function but if anyone can spare time to offer more detailed guidance on the 'GUI Hint 'function and its usage then I should be very grateful for the clarification. Thank you if you are able to help, Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Grid/Coordinate placement ('GUI hint' QY/WX) control query
Thank you for your reply Marcus, I'm very grateful for your time. I've been away from GNU Radio for a couple of years. On returning, I was pleased and excited to see the development of new powerful processing blocks available in GNU Radio but at the same time I was disappointed to see that the GUI aspect of GNU Radio had not been developed further. However, I understand this is not the prime purpose of GNU Radio - to produce polished visualisations with GUI's. I see that others have used GNU Radio as a 'core engine' to provide their Qt-based GUI designs with the power to do their work. For example, Alexandru Csete's (OZ9AEC) 'Gqrx SDR application'. Whereas I'd visualised developing from the same approach as Alexandru, I'd hoped that GNU Radio would have provided this level of design functionality 'natively', so to speak, without the need to design the GUI in a separate application. However, again, I understand this is not the prime function of GNU Radio, except to provide a flexible and powerful means by which to experiment with signals through software. I will return to my original plan, to develop my own GUI, based on Qt etc; and to sit that on top of GNU Radio functionality. Once again, I'm grateful for your advice and thanks again. Mark M0XMH ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Grid/Coordinate placement ('GUI hint' QY/WX) control query
Thank you, Marcus. C++, yes! 'Looking forward to working with Hakon's implementation. All the best, Mark M0XMH ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Grid/Coordinate placement ('GUI hint' QY/WX) control query
I'm relieved to hear it isn't too arduous, Marcus. I tried to begin GUI development today but appear to have got nowhere, just yet. Mark M0XMH -Original Message- From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: 24 August 2018 17:24 . . .Years and years ago, before GRC existed, I developed a GUI based on XForms that used Gnu Radio underneath. It wasn't horrid as a process . . . ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Quick & Dirty for Beginners
Thank you Sumit. I very much appreciated your excellent resource. Many thanks again, Mark cid:image001.png@01CD5F92.9D5CA1D0 mark G. Hopewell RGN; BSc (Hons) 785-458-6100 (m) CQ - M0XMH <https://markhopewell.wordpress.com/> https://markhopewell.wordpress.com/ <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using PCI DAS4020/12 with the example program provided
Hi, I have the PCI DAS4020/12 installed on my PC. I am attempting to run the FM demodulator example provided in the gnuradio examples (in gnuradio-examples-0.3). I have two questions. 1. What input frequency ranges is the program looking for? 2. When I run the program inputing 104 as the input freq, I get the following error: /dev/parport0: permission denied. Aborted. Is anyone using the PCI DAS4020/12 and able the run the FM demodulator example provided? I have installed the mc4020 module as well. Thanks for any help. Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fm_demod.py
Hi, I am executing the FM demodulator example provided in the gnuradio examples (gnuradio-examples-0.3) and have three questions. 1. Does the program require two input frequencies or one? 2. If I type ./fm_demod.py 97.5 94.5 does this mean that signal between 97.5MHz and 94.5MHz will be demodulated? Will this then demodulate 96.5MHz. 3. If I type ./fm_demod.py 104.7 does this mean that signal at 104.7 will be demodulated? Thanks for the advice, Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Build installation on Ubuntu
Hello the camp, I'm struggling with an installation on Ubuntu 16.04. Note that apt-get does install a working GNUradio stack and UHD works with a USRP2. However, my goal is to install a build environment. For my 1st effort I used git to clone the uhd driver directory and was able to get a clean build from the source and the make test all worked correctly. After make install uhd_usrp_probe finds the USRP2. However, on connecting a GRC uhd source to waterfall sink the run fails. The problem is that the UHD driver is newer than the apt-get installation of gnuradio so the two are incompatible. Also, the gnuradio install doesn't seem to have the source for a build environment either. So next effort is to try to use pybombs to install into a prefix directory. Having all the source and being able to modify it and run in a local sandbox is exactly what I'm after. Used apt-get to remove uhd and gnuradio. But I'm finding pybombs difficult to use. After a few emails from Martin at Ettus and a great deal of tinkering with permissions I can do the following: $ pybombs recipes add gr-recipes git+ https://github.com/gnuradio/gr-recipes.git $ pybombs recipes add gr-etcetera git+ https://github.com/gnuradio/gr-etcetera.git $ pybombs prefix init ~/gnuradio/src/prefix -R gnuradio-default This will init my prefix directory and start the installation and compile of a sandbox. However, it doesn't finish. It get to bladeRF and aborts with "Unable to fetch recipe bladeRF". Whats *much* more frustrating is that I can't get any other form of a pybombs command line to run and give me information about the prefix install. I just get the "usage" statement. And the init won't run after the first time, I get a: PyBombs.prefix - ERROR - Ignoring. A prefix already exists in `/home/napierm/gnuradio/src/prefix' So if I run: rm -rf gnuradio/src/prefix/* rm -rf gnuradio/src/prefix/.* Then I can start over. PyBOMBS is supposed to be able to show what is installed and manage/add modules. Any ideas what to try next? Thank you very much in advance, Mark Napier ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build installation on Ubuntu
So tried cleaning yet again, reinstalling recipes, and running init again. This time it finished. Everything is working out of a sandbox. This is like macports: a monumental labor of love by many talented programmers. I'm sure it will get more stable with time. Would still very much like to know how to make the other commands in pybombs work: the OOT modules and managing the ones already installed. Cheers, Mark Napier On Sun, May 29, 2016 at 10:24 AM, Mark Napier wrote: > Hello the camp, > > I'm struggling with an installation on Ubuntu 16.04. Note that apt-get > does install a working GNUradio stack and UHD works with a USRP2. However, > my goal is to install a build environment. > > For my 1st effort I used git to clone the uhd driver directory and was > able to get a clean build from the source and the make test all worked > correctly. After make install uhd_usrp_probe finds the USRP2. However, on > connecting a GRC uhd source to waterfall sink the run fails. The problem > is that the UHD driver is newer than the apt-get installation of gnuradio > so the two are incompatible. Also, the gnuradio install doesn't seem to > have the source for a build environment either. > > So next effort is to try to use pybombs to install into a prefix > directory. Having all the source and being able to modify it and run in a > local sandbox is exactly what I'm after. Used apt-get to remove uhd and > gnuradio. But I'm finding pybombs difficult to use. > > After a few emails from Martin at Ettus and a great deal of tinkering with > permissions I can do the following: > > $ pybombs recipes add gr-recipes git+ > https://github.com/gnuradio/gr-recipes.git > $ pybombs recipes add gr-etcetera git+ > https://github.com/gnuradio/gr-etcetera.git > $ pybombs prefix init ~/gnuradio/src/prefix -R gnuradio-default > > This will init my prefix directory and start the installation and compile > of a sandbox. However, it doesn't finish. It get to bladeRF and aborts > with "Unable to fetch recipe bladeRF". Whats *much* more frustrating is > that I can't get any other form of a pybombs command line to run and give > me information about the prefix install. I just get the "usage" > statement. And the init won't run after the first time, I get a: > > PyBombs.prefix - ERROR - Ignoring. A prefix already exists in > `/home/napierm/gnuradio/src/prefix' > > So if I run: > > rm -rf gnuradio/src/prefix/* > rm -rf gnuradio/src/prefix/.* > > Then I can start over. PyBOMBS is supposed to be able to show what is > installed and manage/add modules. Any ideas what to try next? > > Thank you very much in advance, > > Mark Napier > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CPFSK mod/demod + strange behavior
Hello Olivier, I'm also pretty useless on GNUradio, I'm a hardware guy. However, I did get simulations going in Matlab/Simulink for a few variations of the UAT Rx/Tx. Let me say that this is not a channel for the faint of heart. The dump978 code manages to do a Rx with marvelous simplicity. I see a few places in the code I think could be optimized, esp. the RS decode, but that's picking nits. It is very well done given the limited BW of the RTL-SDR. The thing you are missing about the RRC filter is that it isn't used here. A root-Nyquist filter is done for phase/amplitude modulation where you wanted a matched filter at the RX/TX and want a RC response over the channel. That doesn't appy to FSK. What *is* done is that the bits are converted to +-1 at the (25/24) MHz bit rate, or baseband sample rate. Then those samples have to be up-converted to the rate of your NCO. Lets say for instance 6.25Msps since that is factor of 16 to the 100Msps DAC rate of an N210. So at the bit sample instant you want the signal into the NCO to have a value that will give a 312 kHz. Note there will be some over/under-shoot at anything other than the sample instant: that is the nature of the signal. Then that is used to frequency modulate the complex NCO running at 6.25Msps. So here is where the RC filter comes in. You need to up-sample by 6. The output of the complex NCO needs to meet the frequency mask shown in the spec. One way to do that is with an RC filter for interpolation. Garmin says they are using an RC filter with an alpha = 0.5. It does work. I come up with a different scheme since I am using CIC filters for interpolation. The result is the same: the output frequency band meets the mask. Also, on the RX side the pulses have been shaped so that there is little ISI. There are measurements in the UAT compliance tests for that too. In the setup for the instrument there is mention of an RC with alpha = 0.5, but that sets up the instrument. The RX FSK signal is *not* being filtered in the time domain with an RC or RRC filter. FSK modulation really isn't a linear process. I have the simulations to prove it. The advice others have given is right: get the modulation working dumping into a file and post process to see what you have. Get that right 1st and then battle the UHD. Have fun, Mark Napier Message: 8 Date: Thu, 9 Jun 2016 15:24:37 -0400 From: Olivier Goyette To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] CPFSK mod/demod + strange behavior Message-ID: Content-Type: text/plain; charset="utf-8" My flowgraph is based on what I've read throughout the different forums on the internet because : 1- I'm a newbie to GRC and GNUradio in general 2- It's my first time trying to develop a telecomm application 3- I'm using a RRC filter because it's a requirement stated in the documentation I have about UAT. Take a look at the references I joined. Those are every links I've been through trying to understand what is FSK and all the process behind. Maybe you will be able to tell me what' wrong ?! 2016-06-09 15:04 GMT-04:00 Achilleas Anastasopoulos : > Why are you using the RRC filters? > > I hope you are realizing that filtering a CPFSK signal is not the same as > filtering its instantaneous frequency (which is a PAM signal with > rectangular pulses). > As a result, the next question is why in your poly-phase filter you are > using RRC filter taps? > > Achilleas > > ___ > 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] CPFSK mod/demod + strange behavior
Hey Olivier, I hoped you pulled that file back off quickly. By publicly posting the file and password you violated the crap out of the license agreement to RTCA and linked your name to the act. Mark *From*: Olivier Goyette *Subject*: Re: [Discuss-gnuradio] CPFSK mod/demod + strange behavior *Date*: Fri, 10 Jun 2016 09:16:47 -0400 -- As promised, I'm giving the documentation I talked about yesterday and hop it will clarify some of the things we discussed earlier. https://www.dropbox.com/s/1blrausidm66tg4/DO-282B%20with%20Corrigendum%201_bx87er.pdf?dl=0 the password is bx87er on page 23, you will find what the transmission spectrum should look like on page 91, what the receiver should be made of on page 95, what is the decoding process on page 256, what the spectrum should look like and on appendix H3, the section talking about RRC hope it will help you understand thank you Olivier ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] vintage hardware support: tvrx rev 1 - MT4937DI5 3X7702
Hey Chuck, I have one of these rev 1 tvrx daughter boards too. Thanks for the effort! Will you please post your code? I tried the same trick at first, changed the dboard ID: no joy so changed it back. Found the code and data sheet same as you and then struggled to set up a working build environment. By the time that was finally done I totally forgot about the 1st task. Plus my son's cat died in his room. Ugh, the smell. We've stripped out the carpet and are painting and putting in hardwood floor. I really hate cats at this point. Back on point, I think I see how to add another dboard object with code correction, ID = 0x03, and named "TVRX Rev1" if I can just get to it. Then contribute back to the UHD code base so it will be supported by default in the future. Cheers, Mark Napier Date: Sat, 11 Jun 2016 22:10:15 -0400 From: Chuck Swiger To: Discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] vintage hardware support: tvrx rev 1 - MT4937DI5 3X7702 Message-ID: <1465697415.2044.19.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" My own personal summer of code project (1st of hopefully many) was to restore support for my old TVRX Rev1 daughter board (id 0x0003 in the current uhd code and was not TOO hard. Comparing the schematic http://files.ettus.com/schematics/tvrx/tvrx.pdf with the board matches. Looking at the MT4937DI5 datasheet http://swigerco.com/4937_DI5_MicroTune_TVRXr_DSA00488550.pdf that covers both the old 3X7702 with the 2nd downconverted to 5.75e6 AND another model with the 43.75e6 IF like the newer tvrx (id 0x0040) still supported inuhd/host/lib/usrp/dboard/db_tvrx.cpp Gain charts in db_tvrx.cpp match that manual, i2c commands sent out for set_freq match the registers, etc. Just changing the board id gets it recognized but just gets static, barely can make out a strong local fm station. There's another tvrx id hiding in an evil hack in uhd/host/lib/usrp/usrp1/dboard_iface.cpp that needs to be changed. Just changing the tvrx_if_freq won't work, as that really is the IF - we just have to compensate for the 2nd converter and that's appearently done in the value returned by set_freq(double freq) - this works: comment out the if (tvrx_if_freq >= codec_rate/2) block as the DAC never sees that IF, and return _lo_freq - tvrx_if_freq + tvrx_2ndif_freq; Now it can get FM just fine, plus make fft plots like this again: http://swigerco.com/tvrx_atsc.jpg Which reminds me the rev 3 turners have to compensate for inverted spectrum (being at 44.75Mhz with a 64Mhz clock). Have to fix that next. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Load Preset parameters in block
Hello, Is there a way to load preset default parameters in a block. For example, I have a channel model block that takes several parameters, such as the doppler spread, path delays, path gains, doppler spectrum, etc., and I want to have presets that will auto-populate the parameters in the GRC block for pre-defined channel models. I can make a drop-down menu that has the pre-defined channel models, but I don't know how to change the values that populate in the other parameters. I would like to do this using the xml file. Is there a way to put a conditional parameter in the tags that would depend on the setting in the drop down menu (It seems conditionals can be used in the and tags, but not inside the tags)? Is there a way to do it using the tags? Is there a list of valid options and what they do anywhere? It seems the val:XXX <\opt> tags might do it, but I can't seem to get any of them to work. Although I could pass in a preset parameter to the C++ function and simply override everything coming from the GUI, I'd rather have it populate the parameters in the block, but still let them be changed. This way, if someone wanted to load the settings for a "Channel X" preset, except with a different Doppler spread, it could be done easily. Note this is a similar problem as posted here: https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00016.html, but it doesn't appear the previous question was ever answered. Thank you in advance for your help. Mark Arlinghaus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Load Preset parameters in block
Hi Marcus, Thank you for your quick response. Sorry I wasn't clear. I'm actually talking about GRC construction. Once the code is running the parameters won't need to be changed. If we need to change the parameters, stopping the flowgraph is acceptable. It's really just meant to make the block slightly easier/faster to set up by the user. I'm hoping that this makes the solution simpler!? Mark From: Discuss-gnuradio [discuss-gnuradio-bounces+marlinghaus=girdsystems@gnu.org] on behalf of Marcus D. Leech [mle...@ripnet.com] Sent: Monday, June 20, 2016 3:09 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Load Preset parameters in block On 06/20/2016 02:15 PM, Mark Arlinghaus wrote: Hello, Is there a way to load preset default parameters in a block. For example, I have a channel model block that takes several parameters, such as the doppler spread, path delays, path gains, doppler spectrum, etc., and I want to have presets that will auto-populate the parameters in the GRC block for pre-defined channel models. I can make a drop-down menu that has the pre-defined channel models, but I don't know how to change the values that populate in the other parameters. I would like to do this using the xml file. Is there a way to put a conditional parameter in the tags that would depend on the setting in the drop down menu (It seems conditionals can be used in the and tags, but not inside the tags)? Is there a way to do it using the tags? Is there a list of valid options and what they do anywhere? It seems the val:XXX <\opt> tags might do it, but I can't seem to get any of them to work. Although I could pass in a preset parameter to the C++ function and simply override everything coming from the GUI, I'd rather have it populate the parameters in the block, but still let them be changed. This way, if someone wanted to load the settings for a "Channel X" preset, except with a different Doppler spread, it could be done easily. Note this is a similar problem as posted here: https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00016.html, but it doesn't appear the previous question was ever answered. Thank you in advance for your help. Mark Arlinghaus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio It's not clear whether you're talking about *runtime* or during GRC construction. For runtime, I'd write a little Python module that contains a function for each parameter: setter_function(configfilename, command-line-parameter, widget-control-value) You then have logic in the function to determine the priority of what gets returned: config-->command-line-->widget-control-value I've done that in the past. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Load Preset parameters in block
Maybe "defaults" is not the correct word to describe what I am trying to accomplish. The parameter values that pop up when you first drop the block down onto a flowgraph aren't necessarily important. But once the user double clicks the block to open the properties dialog, I want them to be able to select from a drop down menu list of presets that will auto-fill the rest of the parameters according to which option was selected. Note that I would like the user to still be able to change the values that were "auto-filled" previously, so they can enter a setup that deviates slightly from the preset without having to enter all of the parameters manually. I can add all of the necessary info in the xml file. I just don't know how to set the parameters to the proper values based on the selected option. It seems like there should be some mechanism to do it because I can hide or show parameters based on the selected options (conditional statements seem to work inside of tags), so there must be some callback mechanism in place. But no way to change the values of the parameters based on a selected option? Mark From: Marcus D. Leech [mle...@ripnet.com] Sent: Monday, June 20, 2016 3:49 PM To: Mark Arlinghaus; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Load Preset parameters in block On 06/20/2016 03:17 PM, Mark Arlinghaus wrote: Hi Marcus, Thank you for your quick response. Sorry I wasn't clear. I'm actually talking about GRC construction. Once the code is running the parameters won't need to be changed. If we need to change the parameters, stopping the flowgraph is acceptable. It's really just meant to make the block slightly easier/faster to set up by the user. I'm hoping that this makes the solution simpler!? Mark Defaults for block parameters in GRC are defined in the .xml description of the block, but there's no way to override what ever is in the .xml when you first instantiate a block in GRC. From: Discuss-gnuradio [discuss-gnuradio-bounces+marlinghaus=girdsystems@gnu.org] on behalf of Marcus D. Leech [mle...@ripnet.com] Sent: Monday, June 20, 2016 3:09 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Load Preset parameters in block On 06/20/2016 02:15 PM, Mark Arlinghaus wrote: Hello, Is there a way to load preset default parameters in a block. For example, I have a channel model block that takes several parameters, such as the doppler spread, path delays, path gains, doppler spectrum, etc., and I want to have presets that will auto-populate the parameters in the GRC block for pre-defined channel models. I can make a drop-down menu that has the pre-defined channel models, but I don't know how to change the values that populate in the other parameters. I would like to do this using the xml file. Is there a way to put a conditional parameter in the tags that would depend on the setting in the drop down menu (It seems conditionals can be used in the and tags, but not inside the tags)? Is there a way to do it using the tags? Is there a list of valid options and what they do anywhere? It seems the val:XXX <\opt> tags might do it, but I can't seem to get any of them to work. Although I could pass in a preset parameter to the C++ function and simply override everything coming from the GUI, I'd rather have it populate the parameters in the block, but still let them be changed. This way, if someone wanted to load the settings for a "Channel X" preset, except with a different Doppler spread, it could be done easily. Note this is a similar problem as posted here: https://lists.gnu.org/archive/html/discuss-gnuradio/2015-02/msg00016.html, but it doesn't appear the previous question was ever answered. Thank you in advance for your help. Mark Arlinghaus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio It's not clear whether you're talking about *runtime* or during GRC construction. For runtime, I'd write a little Python module that contains a function for each parameter: setter_function(configfilename, command-line-parameter, widget-control-value) You then have logic in the function to determine the priority of what gets returned: config-->command-line-->widget-control-value I've done that in the past. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Broken Pybombs install, stuck again.
Had a little time to work on the TVRX again.
Have a build of gnuradio installed with pybombs in ~/gnuradio/src/prefix.
Very happy to *finally* have a complete source tree and working compile
environment to experiment with.
Modified two source files:
~/gnuradio/src/prefix/src/uhd/host/lib/usrp/usrp1/dboard_iface.cpp
~/gnuradio/src/prefix/src/uhd/host/lib/usrp/dboard/db_tvrx.cpp
Went into "~/gnuradio/src/prefix/src/uhd/host/build" and did a make. The
files compile cleanly. "make test" works with 100% passing. Then "sudo
make install".
The files are installed into
/home/napierm/gnuradio/src/prefix/bin.
uhd_usrp_probe now correctly finds and identifies the rev.1 TVRX board.
Try to run gnuradio and it can't find "liblog4cpp.so.5". And yes, I have
run the ~/gnuradio/src/prefix/setup_env.sh first.
Well, this a virtual machine so I revert to a backup from a couple of days
ago. Everything works. Change the two files, follow same steps. Broken
the same way.
Anyone know the answer?
FWIW, I've attached the two files but since I have no way to test anything
I doubt I have the return value right for the Rev. 1 board.
Does anyone have a good methodology to set up a machine with a working
UHD/gnuradio build/run environment? I'm pretty frustrated at the amount of
time I've wasted on this; there just has to be a better way.
Thanks in advance,
Mark Napier
>>> Before compile:
napierm@napierm-virtual-machine:~/gnuradio/grc$ gnuradio-config-info
Program options: gnuradio-config-info [options]:
-h [ --help ] print help message
--prefix print GNU Radio installation prefix
--sysconfdir print GNU Radio system configuration directory
--prefsdirprint GNU Radio preferences directory
--userprefsdirprint GNU Radio user preferences directory
--prefs print GNU Radio preferences
--builddate print GNU Radio build date (RFC2822 format)
--enabled-components print GNU Radio build time enabled components
--cc print GNU Radio C compiler version
--cxx print GNU Radio C++ compiler version
--cflags print GNU Radio CFLAGS
-v [ --version ] print GNU Radio version
>>> After compile and install:
napierm@napierm-virtual-machine:~/gnuradio/grc$ gnuradio-config-info
gnuradio-config-info: error while loading shared libraries:
liblog4cpp.so.5: cannot open shared object file: No such file or directory
napierm@napierm-virtual-machine:~/gnuradio/grc$ gnuradio-companion &
[2] 25876
napierm@napierm-virtual-machine:~/gnuradio/grc$ Traceback (most recent call
last):
File "/home/napierm/gnuradio/src/prefix/bin/gnuradio-companion", line 29,
in
from gnuradio.grc.main import main
File
"/home/napierm/gnuradio/src/prefix/lib/python2.7/dist-packages/gnuradio/grc/main.py",
line 21, in
from gnuradio import gr
File
"/home/napierm/gnuradio/src/prefix/lib/python2.7/dist-packages/gnuradio/gr/__init__.py",
line 41, in
from runtime_swig import *
File
"/home/napierm/gnuradio/src/prefix/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
line 28, in
_runtime_swig = swig_import_helper()
File
"/home/napierm/gnuradio/src/prefix/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_runtime_swig', fp, pathname, description)
ImportError: liblog4cpp.so.5: cannot open shared object file: No such file
or directory
^C
[2]+ Exit 1 gnuradio-companion
napierm@napierm-virtual-machine:~/gnuradio/grc$
//
// Copyright 2010-2012 Ettus Research LLC
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program. If not, see <http://www.gnu.org/licenses/>.
//
// No RX IO Pins Used
// RX IO Functions
//ADC/DAC functions:
//DAC 1: RF AGC
//DAC 2: IF AGC
//min freq: 50e6
//max freq: 860e6
//gain range: [0:1dB:115dB]
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
using namespace uhd;
using namespace uhd::usrp;
using namespace boost::assign;
/***
* The tvrx constants
*
Re: [Discuss-gnuradio] new user
Hey Darin, If you just want the GNU Radio environment up and don't plan on doing any UHD development then my vote for you is the MacBookPro using MacPorts. Be aware, none of these flows are trouble free. Over the last couple of months I've tried Mac, Ubuntu, and Windows 7. Macports gives (for me at least) the nicest final environment to work in. The thing with MacPorts is that all the dependancies are constantly in flux. So sign up as a MacPorts user so you can post problems. When you install gnuradio one or more of the dependancies is likely fail. Try installing the failing one alone and see if it will finish, be sure to get the specific version right. Sometime this requires going through the "verbose" log file to get the right name. You may have to uninstall a few and try again. Be prepared to burn a *lot* of time. Seems to be the nature of the beast. Often something is broken and you have to post the problem to MacPorts to the owner of the particular package. It usually is turned around in a day or so; remarkable really considering that this is all done gratis. If this sounds like a pain it is; but it gets you a recent release of GNU Radio that is compiled for your machine. I'm pretty much in awe at the amount of work put in by the MacPorts team and by the GNU Radio developers. I installed the fosphor waterfall display for grc and that is truly stunning on the Mac. Hard to think that it is open source. Best of luck, Mark Napier Date: Mon, 04 Jul 2016 09:52:25 -0500 From: Darin Decker To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] new user Message-ID: <31d96c07-115a-4935-9a0c-ae03cdda7...@mac.com> Content-Type: text/plain; charset=utf-8 Good morning, I have been trying to get Gnuradio up and and running all weekend on either a Macbook Pro or a System 76 Ubuntu 12.04 machine but have not had any success. If I understand correctly, Ubuntu 12.04 is not supported so I have not pursued that much but focused on the Macbook Pro. When I try to run gnuradio-companion on the Mac, I initially get 'The xterm executable ? is missing?. When I search for gnu radio.conf, the file doesn?t seem to be on the computer. Then when I run a simple flow(RTL-SDR Source -> WX GUI FFT Sink), i get a python error of no module named osmosdr. Then I tried the Live DVD. Trying both from DVD and from USB Flashdrive. On both the System 76 and the Mac hardware, I get the same issue. I have an RTL-SDR device and I believe the program is recognizing the device because it says Rafael Tuner 820; however, it then says PLL won?t lock. I have tried multiple FM broadcast frequencies; as well as, AM broadcast frequencies. On the FM, I?m inputting values of 101.1e06 for example. On the AM I input 108e04 as an example(1080 on am dial is the intended target in that case). I also have a SDRplay but can?t get that to connect at all. Looks like if you don?t have a Windows machine, that doesn?t seem to work well yet. Guessing drivers or something on SDRplay side. Any help is greatly appreciated. For right now, I?m just wanting to get it up and running in any way possible. Darin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Macports Patch File
Hello, With help from Michael I've made up a patch file for the db_tvrx.cpp and dboard_iface.cpp. Next step would be to apply the patch, recompile, and install the UHD to test it using macports. Google is not finding the recipe. Anyone know how to do this? Thank you much, Mark Napier ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: Broken Pybombs install, stuck again
-- Forwarded message -- From: Mark Napier Date: Mon, Jul 4, 2016 at 8:13 PM Subject: Re: Broken Pybombs install, stuck again To: Marcus Müller Hello Marcus, Thank you for the reply. Yes, I sourced the script before the compile by typing ". ./setup_env.sh". No, I haven't installed *anything* in that virtual machine since I got that one clean PyBOMBS install to run. Again, I can restore the virtual machine to where it was two days ago and the PyBOMBS install works correctly. So I need to recompile GNU Radio against the UHD that was compiled with PyBOMBS in the first place? It doesn't seem likely but I'm sure willing to try it. How? I mean, what do I type to do the recompile? Thank you much, Mark Napier Message: 9 Date: Mon, 4 Jul 2016 17:28:50 +0200 From: Marcus M?ller To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Broken Pybombs install, stuck again. Message-ID: <577a80b2.1090...@ettus.com> Content-Type: text/plain; charset="windows-1252" Hi Mark, as far as I can tell, you've recompiled UHD, but you did not recompile GNU Radio to link against that UHD (I don't know if you've updated UHD since your last compilation of GNU Radio, so this might pose a problem). >And yes, I have run the ~/gnuradio/src/prefix/setup_env.sh first. Does that mean you've /run/ it, or did you /source/ it? The first wouldn't have an effect, because it would set up the correct paths for the duration of the script running ? and that script immediately exits. Sourcing the file, however, would make the changes permanent to your shell. Also, it's important that you did the sourcing before compiling UHD ? otherwise, the build process might use system libraries that it shouldn't use. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FSK4 Demodulator - some guidance?
Hello Team, I am attempting to set up an FSK4 Demodulator. I have downloaded OP25 from git://op25.osmocom.org/op25.git, however cmake is returning the following error messages: *--* Checking for module 'gnuradio-runtime' Package 'gnuradio-runtime' not found Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_LIBRARIES) GnuRadio Runtime required to compile op25 *--* I can see "libgnuradio-runtime" in /usr/local/lib64/ and the cmake file includes this path. 1) Before I spend too much time trying to get this working, can anyone give me guidance on if I am heading down the right path? OR 2) Does anyone know of an FSK4 Demodulator that might work out of the box with GNURadio 3.7.10.1 ? Thank you in advance for your help - and best wishes for the festive season !! Regards, Mark Phillips - VK4AW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FSK4 Demodulator - some guidance?
Hello Team, Apologies for reposting this. My first attempt received a lot of e-mail bounces due to my strict e-mail security settings. I have now switched these off :-) Message Hello Team, I am attempting to set up an FSK4 Demodulator. I have downloaded OP25 from git://op25.osmocom.org/op25.git, however cmake is returning the following error messages: *--* Checking for module 'gnuradio-runtime' Package 'gnuradio-runtime' not found Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_LIBRARIES) GnuRadio Runtime required to compile op25 *--* I can see "libgnuradio-runtime" in /usr/local/lib64/ and the cmake file includes this path. 1) Before I spend too much time trying to get this working, can anyone give me guidance on if I am heading down the right path? OR 2) Does anyone know of an FSK4 Demodulator that might work out of the box with GNURadio 3.7.10.1 ? Thank you in advance for your help - and best wishes for the festive season !! Regards, Mark Phillips - VK4AW ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about reverse-engineering a new mode
This is a bit of an idle question, but I'm hoping some knowledgable folks on here can offer advice. Mostly I'm trying to understand better what I don't know, and the size of the challenge, before jumping in to a project: I'd like to try decoding some AVL traffic in the 700-MHz band (GPS locations broadcast by transit vehicles to a central collector, where predictors are used to generate the ETAs displayed on electronic bus-stop signs). The modulation is 4-FSK, similar to P25 except wider with a higher symbol rate, emission designator 20K0F1D. The particular frequency(s) should be easy enough to discover. Transmissions are short packets on shared channels with some kind of slotted aloha or CSMA MAC. A rate-3/4 convolutional code is used. The preceding is public information gleaned from the web. I haven't captured any signals yet. The known unknowns: preambles and framing stuff, symbol mapping, the particular rate-3/4 code used (only a couple of candidates though), and, the scrambler (whitener) and its initialization. AFAIK there is no encryption per se. The payload is supposed to be TCP/IP, so there could be some sort of header compression. My question, then, is given this information, are there reasonable odds of success? I have some digital comms background from grad school but little to no practical experience. Wondering if this might be an excuse to pick up a HackRF etc. and learn GNU Radio, or if it's likely to be a dead end. Thanks, Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio IIR Filter Taps
Keyur Parikh [kpari...@gmail.com] wrote: > I'm in fm_emph.py and can see the taps listed as > > btaps = [b0, b1] > ataps = [1, a1] This looks like "MATLAB form". If so, the difference equation should be y(n) = b0*x(n) + b1*x(n) - a1*y(n-1) Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio IIR Filter Taps
Sorry, you're right, it should be b1*x(n-1). --Mark Keyur Parikh [kpari...@gmail.com] wrote: > Thanks for your reply. Quick question: the second term isn't b1*x(n-1)? > > On Fri, May 22, 2015 at 10:30 AM, Mark Haun wrote: > > Keyur Parikh [kpari...@gmail.com] wrote: > > > I'm in fm_emph.py and can see the taps listed as > > > > > > btaps = [b0, b1] > > > ataps = [1, a1] > > > > This looks like "MATLAB form". If so, the difference equation should be > > y(n) = b0*x(n) + b1*x(n) - a1*y(n-1) > > > > Mark > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about reverse-engineering a new mode
Thanks everyone for your responses. The funny thing is, I already concluded the way to go was to hook up an RTL-SDR dongle and start poking around. Should be here this week. I know the frequencies (based on FCC license search) and the hardware manufacturer (IPMN). AFAICT there are a variety of technologies available for AVL, so any given transit agency is likely using something different. I see no insurmountable barriers getting to the point of successful Viterbi decodes. After that, it seems quite difficult. First I have to guess the whitening polynomial and its initialization, then figure out packet framing, and possible source coding. And all of this assumes nothing is intentionally encrypted... Mark Andrew Clegg [andrew_w_cl...@hotmail.com] wrote: > Sounds like an interesting project. I'd like to know more about the spectrum > aspect -- do you know which band segments in 700 MHz are used for this in the > U.S.? Me and my spectrum analyzer want to know :) > Andy > Date: Tue, 26 May 2015 06:28:44 -0700 > From: martin.br...@ettus.com > To: rwmcgw...@gmail.com > CC: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Question about reverse-engineering a new mode > > > > On 26 May 2015 03:28, "Robert McGwier" wrote: > > > > > > [...] > > > That said, hackers (the good definition) live for this, and I encourage it. > Just wanted to emphasise this. Go for it! Worst case, you learn a lot of > interesting things. > Cheers, > > M > > > > > Bob > > > > > > > > > On Tue, May 19, 2015 at 3:04 PM, Mark Haun wrote: > > >> > > >> This is a bit of an idle question, but I'm hoping some knowledgable folks > >> on > > >> here can offer advice. Mostly I'm trying to understand better what I > > >> don't know, and the size of the challenge, before jumping in to a project: > > >> > > >> I'd like to try decoding some AVL traffic in the 700-MHz band (GPS > >> locations > > >> broadcast by transit vehicles to a central collector, where predictors are > > >> used to generate the ETAs displayed on electronic bus-stop signs). The > > >> modulation is 4-FSK, similar to P25 except wider with a higher symbol rate, > > >> emission designator 20K0F1D. The particular frequency(s) should be easy > > >> enough to discover. Transmissions are short packets on shared channels > >> with > > >> some kind of slotted aloha or CSMA MAC. A rate-3/4 convolutional code is > > >> used. The preceding is public information gleaned from the web. I haven't > > >> captured any signals yet. > > >> > > >> The known unknowns: preambles and framing stuff, symbol mapping, > > >> the particular rate-3/4 code used (only a couple of candidates though), > >> and, > > >> the scrambler (whitener) and its initialization. AFAIK there is no > > >> encryption per se. The payload is supposed to be TCP/IP, so there could be > > >> some sort of header compression. > > >> > > >> My question, then, is given this information, are there reasonable odds of > > >> success? I have some digital comms background from grad school but little > > >> to no practical experience. Wondering if this might be an excuse to pick > >> up > > >> a HackRF etc. and learn GNU Radio, or if it's likely to be a dead end. > > >> > > >> Thanks, > > >> > > >> Mark > > >> > > >> ___ > > >> Discuss-gnuradio mailing list > > >> Discuss-gnuradio@gnu.org > > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > > > > > > > -- > > > Bob McGwier > > > Co-Founder and Technical Director, Federated Wireless, LLC > > > Research Professor Virginia Tech > > > Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY > > > Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) > > > > > > ___ > > > 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 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] Fast, Single-Sample Phase Rotation
Traditionally this was a job for CORDIC. I don't know what the tradeoffs look like on a modern processor, though. If a significant part of your algorithm operates in phase/magnitude, might you consider a rect->polar conversion? John Malsbury [jmalsbury.perso...@gmail.com] wrote: > I have a complex phase rotation function that uses a pre-generated sin/cos > LUT and some basic multiple/adds. > > As it turns out, the rotation calc, which uses "straight" C/C++ math is > still the bottleneck in a demod. > > I was wondering, is there some uber-efficient rotation block/class I should > be using? I notice there is a volk kernel for the job and gr_rotator. > But I also should mention that the phase rotation operation must happen one > sample at a time. This is due to the sequential nature of the algorithm - > ie. I can't align and call a kernel with hundreds of nicely-aligned > samples. > > Any advice? > > -John > ___ > 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] Control Port Thrift Issues
I am seeing an error during “Make” and it has to do with the controlport and thrift….not sure what is going on. Any help would be appreciated. Thanks Mark After running “Make” I see the following error: [ 11%] Building CXX object gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/controlport/thrift/rpcserver_booter_thrift.cc.o /usr/local/truearrow_6_0_0_0/deploypkg/target/src/gnuradio/gnuradio-runtime/lib/controlport/thrift/rpcserver_booter_thrift.cc: In member function ‘bool thrift_application_base::application_started()’: /usr/local/truearrow_6_0_0_0/deploypkg/target/src/gnuradio/gnuradio-runtime/lib/controlport/thrift/rpcserver_booter_thrift.cc:117:78: error: ‘class apache::thrift::transport::TServerSocket’ has no member named ‘getPort’ int used_port = ((apache::thrift::transport::TServerSocket*)thetransport)->getPort(); ^ make[2]: *** [gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/controlport/thrift/rpcserver_booter_thrift.cc.o] Error 1 make[1]: *** [gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/all] Error 2 make: *** [all] Error 2 I don’t get any errors during cmake, my ouput is below. -- ## -- # Gnuradio enabled components -- ## -- * python-support -- * testing-support -- * volk -- * doxygen -- * sphinx -- * gnuradio-runtime -- * gr-ctrlport -- * * thrift -- * gr-blocks -- * gnuradio-companion -- * gr-fec -- * gr-fft -- * gr-filter -- * gr-analog -- * gr-digital -- * gr-dtv -- * gr-atsc -- * gr-audio -- * * alsa -- * * oss -- * gr-channels -- * gr-noaa -- * gr-pager -- * gr-qtgui -- * gr-trellis -- * gr-uhd -- * gr-utils -- * gr-video-sdl -- * gr-vocoder -- * gr-fcd -- * gr-wavelet -- * gr-wxgui -- * gr-zeromq -- -- ## -- # Gnuradio disabled components -- ## -- * gr-comedi -- -- Using install prefix: /usr/local/truearrow_6_0_0_0/deploypkg/target -- Building for version: 3.7.10.1 / 3.7.10.1 -- Configuring done -- Generating done -- Build files have been written to: /usr/local/truearrow_6_0_0_0/deploypkg/target/src/gnuradio/build ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Control Port Thrift Issues
Hi Marcus,
I do believe I need control ports active. I am using GNUradio as the framework
for some code that I believe uses control ports.
Mark
On 9/14/17, 3:10 AM, "Discuss-gnuradio on behalf of
discuss-gnuradio-requ...@gnu.org"
wrote:
Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-requ...@gnu.org
You can reach the person managing the list at
discuss-gnuradio-ow...@gnu.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. How to create uhd's time_spec_t from Python (Piotr Krysik)
2. Re: Control Port Thrift Issues (Marcus M?ller)
3. Re: How to create uhd's time_spec_t from Python (Marcus M?ller)
4. Re: Synchronisation (John Shields)
5. [SOCIS '17] GRC C++ Output: Week 7 (H?kon V?gsether)
6. Time sinks out of sync after adding and removing noise in
simple FSK simulation (James Wanga)
--
Message: 1
Date: Wed, 13 Sep 2017 19:08:36 +0200
From: Piotr Krysik
To: GNURadio Discussion List
Subject: [Discuss-gnuradio] How to create uhd's time_spec_t from
Python
Message-ID: <7edcc791-5aa7-908a-58ae-3e306580c...@o2.pl>
Content-Type: text/plain; charset=utf-8
Hi All,
time_spec_t is a class representing time in UHD. It uses time_t (long
int) for representing full seconds and double for parts of a second.
This format of time is usable to tell USRPs when to do certain tasks. It
is also very usable for operations on time without loosing precision.
In c++ time_spec_t can be constructed from time represented by a double
(not precise if number of full seconds is large) or from time_t and
double. Both constructors are exposed by SWIG in Python.
When I construct time_spec from double everything is fine:
>>> from gnuradio import uhd
>>> uhd.time_spec(10)
But when I construct from int and float I get an error:
>>> uhd.time_spec(10,0.1)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
1576, in __init__
this = _uhd_swig.new_time_spec_t(*args)
NotImplementedError: Wrong number or type of arguments for overloaded
function 'new_time_spec_t'.
Possible C/C++ prototypes are:
uhd::time_spec_t::time_spec_t(double)
uhd::time_spec_t::time_spec_t(time_t,double)
uhd::time_spec_t::time_spec_t(time_t,long,double)
Somehow Python's integer is not recognized as compatible with time_t
parameter in the second constructor
(uhd::time_spec_t::time_spec_t(time_t,double) ).
My question:
Is there a way to use time_spec_t's constructor
uhd::time_spec_t::time_spec_t(time_t,double) from Python interface
exposed by GNU Radio? In my opinion there should be, otherwise why to
expose it through SWIG.
--
Best Regards,
Piotr Krysik
--
Message: 2
Date: Wed, 13 Sep 2017 19:54:47 +0200
From: Marcus M?ller
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Control Port Thrift Issues
Message-ID: <26b13e91-3b19-c721-4f0c-ae6c16856...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Mark,
We can look at that in-depth, but in spirit of keeping this as
time-effective as possible for you: Do you *need* controlport (it's a
system to remotely access statistics and specifics knobs and levers in
GNU Radio)? Many (most) users don't really.
Best regards,
Marcus
On 09/13/2017 04:41 PM, Mark Koenig wrote:
>
> I am seeing an error during ?Make? and it has to do with the
> controlport and thrift?.not sure what is going on. Any help would be
> appreciated.
>
>
>
> Thanks
>
>
>
> Mark
>
>
>
>
>
> After running ?Make? I see the following error:
>
>
>
> [ 11%] Building CXX object
>
gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/controlport/thrift/rpcserver_booter_thrift.cc.o
>
>
/usr/local/truearrow_6_0_0_0/deploypkg/target/src/gnuradio/gnuradio-runtime/lib/controlport/thrift/rpcserver_booter_thrift.cc:
> I
Re: [Discuss-gnuradio] Control Port Thrift Issues
Marcus, I am using CentOS 7.2, Thrift 0.9.2 and GNU 3.7.11. Mark On 9/15/17, 12:02 PM, "Discuss-gnuradio on behalf of discuss-gnuradio-requ...@gnu.org" wrote: Send Discuss-gnuradio mailing list submissions to discuss-gnuradio@gnu.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.gnu.org/mailman/listinfo/discuss-gnuradio or, via email, send a message with subject or body 'help' to discuss-gnuradio-requ...@gnu.org You can reach the person managing the list at discuss-gnuradio-ow...@gnu.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Discuss-gnuradio digest..." Today's Topics: 1. Re: Control Port Thrift Issues (Marcus M?ller) 2. Tonight: Cyberspectrum Software Defined Radio Meetup (San Diego, Thu Sept 14th, 6:30PM PT) (Balint Seeber) 3. Re: Time sinks out of sync after adding and removing noise in simple FSK simulation (James Wanga) 4. Re: Recent change in destructor behavior? (Dmitry Kramarev) -- Message: 1 Date: Thu, 14 Sep 2017 19:31:36 +0200 From: Marcus M?ller To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Control Port Thrift Issues Message-ID: <25f98175-1668-5048-eff8-ce4460f1d...@ettus.com> Content-Type: text/plain; charset=windows-1252 OK, so we'll tackle this headon :) So, we'll need to talk about the specific GNU Radio version you're compiling, the exact-as-possible thrift version. Maybe also the OS/distro version. Admittedly, I'm at GRCon right now, and it might be minimally non-trivial to just set up a container/VM to reproduce, but maybe looking at the code alone suffices! Best regards, Marcus On 09/14/2017 02:17 PM, Mark Koenig wrote: > Hi Marcus, > > I do believe I need control ports active. I am using GNUradio as the framework for some code that I believe uses control ports. > > Mark > > > On 9/14/17, 3:10 AM, "Discuss-gnuradio on behalf of discuss-gnuradio-requ...@gnu.org" wrote: > > Send Discuss-gnuradio mailing list submissions to > discuss-gnuradio@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > or, via email, send a message with subject or body 'help' to > discuss-gnuradio-requ...@gnu.org > > You can reach the person managing the list at > discuss-gnuradio-ow...@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Discuss-gnuradio digest..." > > > Today's Topics: > >1. How to create uhd's time_spec_t from Python (Piotr Krysik) >2. Re: Control Port Thrift Issues (Marcus M?ller) >3. Re: How to create uhd's time_spec_t from Python (Marcus M?ller) >4. Re: Synchronisation (John Shields) >5. [SOCIS '17] GRC C++ Output: Week 7 (H?kon V?gsether) >6. Time sinks out of sync after adding and removing noise in > simple FSK simulation (James Wanga) > > > -- > > Message: 1 > Date: Wed, 13 Sep 2017 19:08:36 +0200 > From: Piotr Krysik > To: GNURadio Discussion List > Subject: [Discuss-gnuradio] How to create uhd's time_spec_t from > Python > Message-ID: <7edcc791-5aa7-908a-58ae-3e306580c...@o2.pl> > Content-Type: text/plain; charset=utf-8 > > Hi All, > > time_spec_t is a class representing time in UHD. It uses time_t (long > int) for representing full seconds and double for parts of a second. > This format of time is usable to tell USRPs when to do certain tasks. It > is also very usable for operations on time without loosing precision. > > In c++ time_spec_t can be constructed from time represented by a double > (not precise if number of full seconds is large) or from time_t and > double. Both constructors are exposed by SWIG in Python. > > When I construct time_spec from double everything is fine: > > >>> from gnuradio import uhd > >>> uhd.time
[Discuss-gnuradio] sh: .//top_block.py: Permission denied
Any ideas for the Permission denied errors below? I get the following error on one host running 3.7.6: $ grcc -e -d . test.grc >>> Warning: This flow graph may not have flow control: no audio or RF hardware blocks found. Add a Misc->Throttle block to your flow graph to avoid CPU congestion. sh: .//top_block.py: Permission denied The same test.grc runs fine on another host running 3.7.10: $ grcc -e -d . test.grc >>> Warning: This flow graph may not have flow control: no audio or RF hardware blocks found. Add a Misc->Throttle block to your flow graph to avoid CPU congestion. Thanks. Mark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sh: .//top_block.py: Permission denied
Dangit. I should have thought of that. The executable bit is not set on the older version. Thanks. Mark. On Fri, Oct 6, 2017 at 5:12 AM, Marcus Müller wrote: > Hi Mark, > > I can't find the commit right now, but there was a change where we enabled > the setting of the executable bit for top_block files. Might have happened > in between these two versions. > > Can you check (ls -l top_block.py) whether the 'x' bit for the owner is > set? > > Best regards, > > Marcus > > On 10/06/2017 04:06 AM, Mark Christiansen wrote: > > Any ideas for the Permission denied errors below? > > I get the following error on one host running 3.7.6: > > $ grcc -e -d . test.grc > >>> Warning: This flow graph may not have flow control: no audio or RF > hardware blocks found. Add a Misc->Throttle block to your flow graph to > avoid CPU congestion. > sh: .//top_block.py: Permission denied > > The same test.grc runs fine on another host running 3.7.10: > > $ grcc -e -d . test.grc > >>> Warning: This flow graph may not have flow control: no audio or RF > hardware blocks found. Add a Misc->Throttle block to your flow graph to > avoid CPU congestion. > > Thanks. > Mark. > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Aim for brevity while avoiding jargon. ~ Edsger Dijkstra <https://about.me/markwc?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api> Mark Christiansen about.me/markwc <https://about.me/markwc?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using a Trigger Event to Process Subset of Samples in the Data Stream
Hello, I'm using a channel on an x310 to sample the analog receiver on a radar system and store the data continuously on a host PC running CentOS 7. The other channel on the x310 is used to collect timing signals (like a transmit trigger signal) via the GPIO header on a basic Rx daughterboard (with a modified FPGA load) I'd like to delay a fixed amount of time (say 2 ms) from the trigger signal on the GPIO to process a subset (about 100 us) of the receive signal and calculate RMS power during that interval. I'd like to do this on the Host PC and stream out the result as a UDP message. My question is this: What is my best bet in manipulating the data stream from the USRP block so that I can calculate the RMS power in that window of time delayed from the trigger? Stream to vector? Signal probe vector (I've read these are slow)? ZeroMQ? Thanks, Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Custom Block to Output Items that Meet Criteria
Is it possible to write a custom block that only copies items to the output buffer if they meet a certain criterion? I'm thinking of something like a "keep m of n" block but where there is no knowledge of the number of items that will be written to the output buffer when entering the work function. Thanks, Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Custom Block to Output Items that Meet Criteria
Thank you. Basically, I want to take something like the burst tagger block but copy the item from the 1st input to the output buffer only when a condition is met on the 2nd input rather than just append a tag to the stream. The number of times that condition is met will vary but should be between 100-1000 times per second. Mark On Wed, Mar 6, 2019 at 6:20 PM Nick Foster wrote: > Sure, no problem, use a gr::block. Just call consume() to tell the > scheduler how many items you consumed, and return the number of samples you > produced -- subject to the size of the output buffer. general_work() gets > the size of your input and output buffers from ninput_items and > noutput_items. Perfectly fine to return a smaller value than requested. > > Nick > > On Wed, Mar 6, 2019 at 5:43 PM Mark Gannet wrote: > >> Is it possible to write a custom block that only copies items to the >> output buffer if they meet a certain criterion? I'm thinking of something >> like a "keep m of n" block but where there is no knowledge of the number of >> items that will be written to the output buffer when entering the work >> function. >> >> Thanks, >> Mark >> ___ >> 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] UDP Sink Broadcast
Hi, Does anybody know of a way to broadcast to a UDP Sink block? A unicast works fine but setting the destination address to 172.168.255.255 always gives a permission denied error even when running as su. The firewall zone for all adapters is set to "trusted." Is there a way to set an SO_BROADCAST flag like you might do when creating a UDP socket from the Python socket module? Thanks, Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UDP Sink Broadcast
The make method in udp_sink doesn't allow for broadcast right? On Mon, Mar 18, 2019 at 1:38 PM Mark Gannet wrote: > Hi, > > Does anybody know of a way to broadcast to a UDP Sink block? A unicast > works fine but setting the destination address to 172.168.255.255 always > gives a permission denied error even when running as su. The firewall zone > for all adapters is set to "trusted." Is there a way to set an > SO_BROADCAST flag like you might do when creating a UDP socket from the > Python socket module? > > Thanks, > Mark > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] (no subject)
Hi, 1) I got my USRP 1 and RFX900 and 1800 daughterboards. The LED on the USRP flashes when its powered on. I wanted to test the USRP but when I ran the follwowing command >> ./usrp_probe or sudo ./usrp_probe I got the following error Traceback (most recent call last): File "./usrp_probe", line 114, in USRPProbeWindow() File "./usrp_probe", line 71, in __init__ vbox.pack_start(get_input(usrp_which_param), False) File "./usrp_probe", line 42, in get_input input = param.get_input() AttributeError: 'Param' object has no attribute 'get_input' I am using gnuradio 3.2 and Ubuntu(Lucid) 2) Also I got N210. How can I test it. Please help. Waiting for a quick response as I am worried. Any help in this regards is highly appreciated. Regards, Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP testing plesae help
Hi, 1) I got my USRP 1 and RFX900 and 1800 daughterboards. The LED on the USRP flashes when its powered on. I wanted to test the USRP but when I ran the follwowing command >> ./usrp_probe or sudo ./usrp_probe I got the following error Traceback (most recent call last): File "./usrp_probe", line 114, in USRPProbeWindow() File "./usrp_probe", line 71, in __init__ vbox.pack_start(get_input(usrp_which_param), False) File "./usrp_probe", line 42, in get_input input = param.get_input() AttributeError: 'Param' object has no attribute 'get_input' I am using gnuradio 3.2 and Ubuntu(Lucid) 2) Also I got N210. How can I test it. Please help. Waiting for a quick response as I am worried. Any help in this regards is highly appreciated. Regards, Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Subject: Re: USRP testing plesae help
>You may have a version mismatch between the installed python modules in lib and installed python scripts in bin. Either that, or its a very old bug. Whatever the case, I recommend you nuke your gr install(s) and grab a recent release. First of all bundle of thanks. Last post did help me alot. I installed a fresh gnruadio 3.4.0. Connected the USRP1 and usrp_probe ran successfully. Both the boards were detected. :) When I tried to connect DBSRX2 to RXB or RXA the it wasn't detected. I mean when I ran usrp_probe the model shown was 'unkown' and frequency range was from -900.0 to 9.00. Any help what I need to do in order to check the DBSRX2 ? > 2) Also I got N210. How can I test it. Please help. > > Waiting for a quick response as I am worried. Any help in this regards > is highly appreciated. > What do you want to test? If you want connectivity, install UHD and the command uhd_usrp_probe will tell you all the USRP devices connected to your pc: http://code.ettus.com/redmine/ettus/projects/uhd/wiki If you want to test signal integrity, configure gnuradio with gr-uhd support. There is a very basic signal generator and analyzer display that comes with the component. uhd_siggen_gui.py uhd_fft.py I believe. Or make a quick flowgraph in gnuradio-companion :-) == I downloaded UHD from link above, then I did following. cd UHD. cd host mkdir build cd build cmake ../ make make install ldconfig But then when I ran uhd_find_devices I got following output: "Ignoring discovered device RuntimeError: Expected protocol compatibility number 9, but got 7: The firware build is not compatible with the host code build. No UHD Devices Found" Lights D and F are on the N210. No other lights. Another question what is minimum speed required for LAN(Etherenet) interface on PC ? 100Mbps or 1000Mbps ? Regards, Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Subject: Re: USRP testing plesae help
Thanks for the response, I did sudo make and sudo make install when I was installing the UHD. My UHD folder is in my home directory. Sorry, I am not getting you with your last post because I am not very good at Linux. Any help further is highly appreciated. Regards, Smith On Sat, Jan 14, 2012 at 7:12 PM, LRK wrote: > On Sat, Jan 14, 2012 at 05:33:17PM +0500, smith mark wrote: > > > > I downloaded UHD from link above, then I did following. > > cd UHD. > > cd host > > mkdir build > > cd build > > cmake ../ > > make > > make install > > ldconfig > > You can install in userspace but then you need to be sure PYTHONPATH > and maybe LD_LIBRARY_PATH are pointing to your install. Most users > do 'sudo make install' to install in /usr/local. > > ldconfig will not find things in userspace and elf-ld can't figure out > that a program in /something/bin might have libraries in /something/lib. > > After you do cmake, the Makefile should be able to clean out old > stuff with 'make uninstall' and 'make clean' before the new make and > sudo make install. > > > -- > LRK > gr-user . ovillatx.sytes.net > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Debian package grc_setup_freedesktop problems
I am trying to build a gnuradio debian package in ubuntu 12.04, but have been having some issues with the postinst and prerm scripts trying to call grc_setup_freedesktop. Looking at grc/freedesktop/CMakeLists.txt, grc_setup_freedesktop is only installed if you have xdg-utils installed. However, the postinst and prerm scripts attempt to run it whether xdg-utils is installed or not. The other issue is that even when xdg-utils is installed, grc_setup_freedesktop is installed to /usr/libexec, but the postinst and prerm scripts are looking for it in /usr/local/libexec. Am I doing something wrong here or is the cmake config slightly wrong for this stuff? Thanks, Mark -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Installation on Ubuntu 12.04 LTS
Hi all, I am facing problem in gnuradio installation, process stuck on following line: . Checking for package libqwtplot3d-qt4-dev Checking for package pyqt4-dev-tools Checking for package python-qwt5-qt4 Checking for package cmake Checking for package git-core Checking for package wget Checking for package libxi-dev Checking for package python-docutils Checking for package gtk2-engines-pixbuf Checking for package r-base-dev Checking for package python-tk Checking for package liborc-0.4-0 Checking for package libasound2-dev Checking for package python-gtk2 | I am running following command: wget http://www.sbrac.org/files/build-gnuradio && chmod a+x ./build-gnuradio && ./build-gnuradio Also, I am o VM machine, Ubuntu12.04.. Any help! -- Regards, Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Installation on Ubuntu 12.04 LTS
>it's >probably not "stuck", it's just that after that point, it goes off and >uses apt-get to load all of the pre-requisites, which can take a *long* >time, and is done silently, unless you use the --verbose option. Thanks! That was the case. -- Regards, Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] File Sources In Win32 Build
Hi, I have noticed that all the file sources in the latest stable and unstable Win32 builds are broken. It appears that the file path is not escaped properly. Is there any news on a fix for this? Regards, Mark McCarron ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Calculating the delay of TCP link.
Calculating delay is complex. If you just want to know the average time between hosts on an IP network, then use the Ping command. It has a RTT value in ms. Just remember that on a packet switched network, this can vary but is typically under 1ms in a local environment. Similar delays exist throughout the receive chain and processor, which are virtually impossible to measure accurately. Accurate measurements like for radar, or bearings are impossible without some form of time-stamp at the receiver and that would require an atomic clock chip. Regards, Mark McCarron Date: Mon, 29 Apr 2013 12:01:57 -0700 From: engrsajjadsaf...@yahoo.com To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Calculating the delay of TCP link. Hi,I am sending audio at 50 kHz sample rate via TCP sink from host A to other host B. The host B is connected via router in same network. How can i calculate the time delay from host A to host B via this TCP link. Best Regards,SAJJAD SAFDAR ___ 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] Calculating the delay of TCP link.
The MTU will only tell you if there is fragmentation. In packet switched networks, there can be delays for any number of reasons that are not entirely predictable. For example, assume someone is watching a video, using VOIP, downloading, etc. These can place heavy load on a switch, router or hub and saturate buffers delaying your packets and reducing throughput. Other factors such as QoS or traffic shaping can alter things. Then you have cosmic rays, bad wires, failing circuitry, etc. Then on a PC the network stack itself can be a source of delays as this is implemented in software a dependent on the scheduler and what else is happening in the machine. Trying to monitor all this, only places additional load on these systems a skews your results. The best you can do is attempt to define an average and identify the worst case scenario. Aiming between these two figures will normally provide you with a robust service that exceeds expectation. Regards, Mark McCarron Date: Tue, 30 Apr 2013 12:40:07 -0700 From: engrsajjadsaf...@yahoo.com Subject: Re: [Discuss-gnuradio] Calculating the delay of TCP link. To: mark.mccar...@live.co.uk Hi,Is it any way to calculate using the MTU size of TCP packet and the sampling rate, like a mathematical approach using formulas. Best Regards,SAJJAD SAFDAR From: Mark McCarron To: Sajjad Safdar Sent: Tuesday, April 30, 2013 12:33 AM Subject: RE: [Discuss-gnuradio] Calculating the delay of TCP link. Calculating delay is complex. If you just want to know the average time between hosts on an IP network, then use the Ping command. It has a RTT value in ms. Just remember that on a packet switched network, this can vary but is typically under 1ms in a local environment. Similar delays exist throughout the receive chain and processor, which are virtually impossible to measure accurately. Accurate measurements like for radar, or bearings are impossible without some form of time-stamp at the receiver and that would require an atomic clock chip. Regards, Mark McCarron Date: Mon, 29 Apr 2013 12:01:57 -0700 From: engrsajjadsaf...@yahoo.com To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Calculating the delay of TCP link. Hi,I am sending audio at 50 kHz sample rate via TCP sink from host A to other host B. The host B is connected via router in same network. How can i calculate the time delay from host A to host B via this TCP link. Best Regards,SAJJAD SAFDAR ___ 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] Calculating the delay of TCP link.
Its not quite that simple and the other factors are not negligible by any means. The recommended approach would be to download Wireshark, capture the traffic and analyse it in the Throughput Graph. You can adapt the Wireshark setup from this: http://www.dslreports.com/faq/15888 Regards, Mark McCarron Date: Thu, 2 May 2013 11:17:45 -0700 From: engrsajjadsaf...@yahoo.com Subject: Re: [Discuss-gnuradio] Calculating the delay of TCP link. To: mark.mccar...@live.co.uk Actually i want to calculate the delay using the formula like Assuming all other factors as negligible.Here we have 1500 byte tcp header, which in bits is 1500*8/50KHz. Here the R is in kHz but to use this formula we have to have R in Bits per second. Is my way of calculating is right from this approach or not? Best Regards,SAJJAD SAFDAR From: Mark McCarron To: Sajjad Safdar Sent: Wednesday, May 1, 2013 12:51 AM Subject: RE: [Discuss-gnuradio] Calculating the delay of TCP link. The MTU will only tell you if there is fragmentation. In packet switched networks, there can be delays for any number of reasons that are not entirely predictable. For example, assume someone is watching a video, using VOIP, downloading, etc. These can place heavy load on a switch, router or hub and saturate buffers delaying your packets and reducing throughput. Other factors such as QoS or traffic shaping can alter things. Then you have cosmic rays, bad wires, failing circuitry, etc. Then on a PC the network stack itself can be a source of delays as this is implemented in software a dependent on the scheduler and what else is happening in the machine. Trying to monitor all this, only places additional load on these systems a skews your results. The best you can do is attempt to define an average and identify the worst case scenario. Aiming between these two figures will normally provide you with a robust service that exceeds expectation. Regards, Mark McCarron Date: Tue, 30 Apr 2013 12:40:07 -0700 From: engrsajjadsaf...@yahoo.com Subject: Re: [Discuss-gnuradio] Calculating the delay of TCP link. To: mark.mccar...@live.co.uk Hi,Is it any way to calculate using the MTU size of TCP packet and the sampling rate, like a mathematical approach using formulas. Best Regards,SAJJAD SAFDAR From: Mark McCarron To: Sajjad Safdar Sent: Tuesday, April 30, 2013 12:33 AM Subject: RE: [Discuss-gnuradio] Calculating the delay of TCP link. Calculating delay is complex. If you just want to know the average time between hosts on an IP network, then use the Ping command. It has a RTT value in ms. Just remember that on a packet switched network, this can vary but is typically under 1ms in a local environment. Similar delays exist throughout the receive chain and processor, which are virtually impossible to measure accurately. Accurate measurements like for radar, or bearings are impossible without some form of time-stamp at the receiver and that would require an atomic clock chip. Regards, Mark McCarron Date: Mon, 29 Apr 2013 12:01:57 -0700 From: engrsajjadsaf...@yahoo.com To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Calculating the delay of TCP link. Hi,I am sending audio at 50 kHz sample rate via TCP sink from host A to other host B. The host B is connected via router in same network. How can i calculate the time delay from host A to host B via this TCP link. Best Regards,SAJJAD SAFDAR ___ 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] A few questions about subclassing gr_block
Hello, I am trying to create a block that detects sync patterns at baseband tagging the first sample of the pattern using stream tags, then using the tags down stream as part of demodulation. I have made a few assumptions about how gnuradio works that I would like to validate: - a sync pattern could span two blocks of samples passed to general_work - I need to keep SYNC_PATTERN_LENGTH - 1 samples to get around this, so I should be able to use a general block and not output all of the items - you can't tag historic samples (i.e. samples obtained using set_history), so I can't use that are these all reasonable? Currently I have an implementation of the block, but I am having trouble understanding the relationship between ninput_items and noutput_items. When I feed the block from a file source consisting of 720 samples, I get ninput_items[0] = 720 and noutput_items = 512. Does this value for noutput_items mean I can only consume and copy 512 of the input samples? And do I need to implement forecast if I want to output more? Thanks in advance for any help, Mark -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] WX GUI FFT Sink Performance
I have been using the WX GUI FFT Sink for a while now and I notice, regardless of the power of the machine, setting an FFT above 4096 causes it to effectively grind to a halt and UI become grey. Is this a python thing? Or is there a way to accelerate this block??? Regards, Mark McCarron ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
I figured that one out, but why is the performance so poor? In other applications, I can push over half a million samples without causing issues. Regards, Mark McCarron Date: Sat, 11 May 2013 15:51:56 -0400 From: mle...@ripnet.com To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance I have been using the WX GUI FFT Sink for a while now and I notice, regardless of the power of the machine, setting an FFT above 4096 causes it to effectively grind to a halt and UI become grey. Is this a python thing? Or is there a way to accelerate this block??? Regards, Mark McCarron ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Try cranking the frame-rate down to 5. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ 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] WX GUI FFT Sink Performance
Marcus,
Sorry for the late reply on this, I've been upgrading my hardware and I'm just
catching up. Here is my issue, in Spectrum lab if I provide a FFT Input length
of 65536 on a 192Ksps stream, I get the following characteristics:
Effect of FFT settings with fs= 192.000 kHz:
Width of one FFT-bin: 2.92969 Hz
Equiv. noise bandwidth: 4.39453 Hz
Max freq range: 0.0 Hz .. 96. kHz
FFT window time: 0.341 s
Overlap from scroll interval: 98.4 %
It runs quite fast. If I provide the same FFT size to WX GUI FFT sink, it
basically hangs. Do you know why?
Regards,
Mark McCarron
Date: Sat, 11 May 2013 15:59:18 -0400
From: mle...@ripnet.com
To: mark.mccar...@live.co.uk; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
I figured that one out, but why is the performance
so poor?
In other applications, I can push over half a million samples
without causing issues.
Regards,
Mark McCarron
Your OpenGL implementation may suck.
What sample rate are you using?
If it's quite a low rate, then with a large number of bins, there
may be no way to achieve the given frame rate, given the sample
rate, and FFT size.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Marcus,
I have run some tests and it looks like the WX GUI FFT Sink stops responding
with any settings above 4096@15 FPS.
I've upgrade my video card drivers and they work fine with everything else.
Processor usage is fine, nothing in the event logs.
Regards,
Mark McCarron
From: mark.mccar...@live.co.uk
To: discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] WX GUI FFT Sink Performance
Date: Thu, 16 May 2013 06:21:34 +0100
Marcus,
Sorry for the late reply on this, I've been upgrading my hardware and I'm just
catching up. Here is my issue, in Spectrum lab if I provide a FFT Input length
of 65536 on a 192Ksps stream, I get the following characteristics:
Effect of FFT settings with fs= 192.000 kHz:
Width of one FFT-bin: 2.92969 Hz
Equiv. noise bandwidth: 4.39453 Hz
Max freq range: 0.0 Hz .. 96. kHz
FFT window time: 0.341 s
Overlap from scroll interval: 98.4 %
It runs quite fast. If I provide the same FFT size to WX GUI FFT sink, it
basically hangs. Do you know why?
Regards,
Mark McCarron
Date: Sat, 11 May 2013 15:59:18 -0400
From: mle...@ripnet.com
To: mark.mccar...@live.co.uk; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
I figured that one out, but why is the performance
so poor?
In other applications, I can push over half a million samples
without causing issues.
Regards,
Mark McCarron
Your OpenGL implementation may suck.
What sample rate are you using?
If it's quite a low rate, then with a large number of bins, there
may be no way to achieve the given frame rate, given the sample
rate, and FFT size.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Marcus,
Thanks, that would explain the slow updates that I was seeing. Perhaps an
overlapped FFT would be useful for interactive scenarios. Has one been
implemented?
This, however, does not explain why my windows are not responding. After about
8 seconds, the window turns to grey and the GUI of the FFT becomes frozen.
Regards,
Mark McCarron
Date: Thu, 16 May 2013 09:49:59 -0400
From: mle...@ripnet.com
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Marcus,
Sorry for the late reply on this, I've been upgrading my
hardware and I'm just catching up. Here is my issue, in
Spectrum lab if I provide a FFT Input length of 65536 on a
192Ksps stream, I get the following characteristics:
Effect of FFT settings with fs= 192.000 kHz:
Width of one FFT-bin: 2.92969 Hz
Equiv. noise bandwidth: 4.39453 Hz
Max freq range: 0.0 Hz .. 96. kHz
FFT window time: 0.341 s
Overlap from scroll interval: 98.4 %
It runs quite fast. If I provide the same FFT size to WX GUI
FFT sink, it basically hangs. Do you know why?
Regards,
Mark McCarron
Because apparently SpectrumLab is using an overlapped FFT
implementation. The one in wXGUI doesn't. Further, the wxGUI
implmentation has far
too much Python involved in processing samples, so trying to
process 65536 samples at a time is likely sluggish, to the point
that it can't keep
up in real time.
The underlying FFT implementation itself is very fast--Gnu Radio
uses FFTW.
I've regularly built FFT filters with 250e3 taps, and they are able
to run in real time with sample rates into the many Msps.
So, if you do the math, a non-overlapped FFT implementation of 65536
bins at 192Ksps means 2.92 FFTs/second. If the display update rate
is
more than that, there's no way to actually produce an update rate
faster than 2 per second under those circumstances, with a
non-overlapped
FFT.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
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] WX GUI FFT Sink Performance
Marcus, Thanks for highlighting the limitations of the current implementation. It explains a lot. Personally, I would like to see a little more emphasis on useful GUI elements, not just accurate GUI elements. In regards to the WX GUI FFT window not responding. I have tested it with a very simple flow-graph. A USRP source and the WX FFT GUI block. If the settings are at 4096@15fps, it works fine, try anything higher and the windows greys out. So, I don't really see where the issue is. Regards, Mark McCarron Date: Thu, 16 May 2013 11:59:33 -0400 From: mle...@ripnet.com To: mark.mccar...@live.co.uk; Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance Marcus, Thanks, that would explain the slow updates that I was seeing. Perhaps an overlapped FFT would be useful for interactive scenarios. Has one been implemented? I think they're implementing an overlapped-FFT option for the QtGUI sinks for "next". Not sure. The thing about overlapped display FFTs is that you're trading (sometimes significant) temporal accuracy of the estimate for display-update-rate. Further, given that your display is only probably 1280 pixels wide, I fail to see how you expect to extract any more "useful" information from a 65536-bin FFT that must necessarily *lose* information when it's mapped to a narrow display. The wxGUI tools don't support scrolled FFT windows, so they necessarily drop bins to satisfy the display requirement. There are three common "strategies" for mapping a many-binned FFT into a smaller display window: o drop bins o select peak o average bins All of those options lose information in the display. Internally, of course, for signal processing and data recording purposes, you can have FFTs that are very wide. The other thing to consider is that ALL the GUI widgets that are "wired in" to Gnu Radio were designed *primarily* for debugging/instrumentation purposes--akin to sticking a voltmeter or oscilloscope on your circuit board. The problem is that they're *just barely* "good enough" to construct applications with, and so there's a natural expectation that they implement all the GUI thingies you might even want to attach to a signal-processing stream. There is *zero* requirement that you use the built-in GUI widgets. Lots of applications have been built that use the Gnu Radio signal-processing path, and completely-different approaches to providing a GUI--GQRX is one such example, and my own IRA software uses an XFORMS based GUI, with a Gnu Radio signal flow underneath. The QtGUI widgets in "next" are, I understand, substantially enhanced over the current set in "master", so perhaps we can see some more elegant applications written with the Gnu Radio built-in GUI bits. This, however, does not explain why my windows are not responding. After about 8 seconds, the window turns to grey and the GUI of the FFT becomes frozen. That's generally because your flow-graph has some structural problem that is causing the GUI thread to fail to get any cycles. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Marcus, Accurate output is great when doing analysis, but if you just want to create a quick interface that will allow you to see a little more detail, then overlapping or duplicating the stream is fine. The error in the output is always within a given tolerance and that can be suitable for a lot of applications. By no means am I suggesting to eliminate the accurate GUI elements, just that an alternative should be offered. I tested your sample and that works fine on my machine. I have updated it to a refresh rate of 30 and this is when it becomes unresponsive. I ran perfmon and the resources seem fine, but I do see a massive spike in page faults and transition faults when executing a flow graph. That, in itself may not be an issues, but I have checked all the usual bottlenecks and they are barely being touched. I'm running the latest Windows build of this on a quad core Win2012 server with 16GB ram. It seems like a bug in the build. Regards, Mark McCarron Date: Thu, 16 May 2013 13:02:09 -0400 From: mle...@ripnet.com To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance On 05/16/2013 12:41 PM, Mark McCarron wrote: Marcus, Thanks for highlighting the limitations of the current implementation. It explains a lot. Personally, I would like to see a little more emphasis on useful GUI elements, not just accurate GUI elements. So, you'd rather see fast updates of near-complete-nonsense, than slow updates of accurate data? :) :) In regards to the WX GUI FFT window not responding. I have tested it with a very simple flow-graph. A USRP source and the WX FFT GUI block. If the settings are at 4096@15fps, it works fine, try anything higher and the windows greys out. So, I don't really see where the issue is. Works for me with the latest Gnu Radio on F14. You may just be running out of computational steam in Python land, since the wxGUI FFT sink does wy too much of its "stuff" in Python land. Python runs up to about 100 times slower than equivalent native code. I've attached a simple test that works just fine here. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ 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] Question about UHD driver
I am wondering if the UHD driver has the ability to create multiple copies of the stream in memory??? Let's say I have a flow-graph that has two branches, the first pushes complex data to an FFT, whereas the second demodulates a portion of that data into AM. Does the driver supply a single stream, which is then copied by the application? Or does it create two copies of the stream and allow each branch of the flow-graph to manipulate the data via pointers? I'm digging into DMA to see if this is possible, I would be surprised if there was a limitation here. Regards, Mark McCarron ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
I don't really care which GUI framework is used, just that it works. Regards, Mark McCarron Date: Thu, 16 May 2013 13:56:51 -0400 Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance From: hilbert3...@gmail.com To: mark.mccar...@live.co.uk CC: discuss-gnuradio@gnu.org One of the beauties of open-source software is that if you don't like the way something works, or think it should be enhanced, you can take care of that yourself, and, hopefully, share the results with the community. If you don't have the necessary skils to do so, then you make your desires known, and hope that the developers will, at some point, consider your needs, and decide whether it's worth implementing them, and putting said implementation on the schedule. I think Marcus had previously stated that the GUI elements in Gnu Radio itself were primarily designed as an aid to instrumenting and debugging flow-graphs, and that only secondarily are they useful for building real applications. It would be useful for Tom to chime in here about the features of the QtGUI stuff in "next". Nobody is actively working to make the wxGUI side of things "lovely" at this point, because energy is going into, as far as I know, the QtGUI side. On Thu, May 16, 2013 at 1:36 PM, Mark McCarron wrote: Marcus, Accurate output is great when doing analysis, but if you just want to create a quick interface that will allow you to see a little more detail, then overlapping or duplicating the stream is fine. The error in the output is always within a given tolerance and that can be suitable for a lot of applications. By no means am I suggesting to eliminate the accurate GUI elements, just that an alternative should be offered. I tested your sample and that works fine on my machine. I have updated it to a refresh rate of 30 and this is when it becomes unresponsive. I ran perfmon and the resources seem fine, but I do see a massive spike in page faults and transition faults when executing a flow graph. That, in itself may not be an issues, but I have checked all the usual bottlenecks and they are barely being touched. I'm running the latest Windows build of this on a quad core Win2012 server with 16GB ram. It seems like a bug in the build. Regards, Mark McCarron Date: Thu, 16 May 2013 13:02:09 -0400 From: mle...@ripnet.com To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance On 05/16/2013 12:41 PM, Mark McCarron wrote: Marcus, Thanks for highlighting the limitations of the current implementation. It explains a lot. Personally, I would like to see a little more emphasis on useful GUI elements, not just accurate GUI elements. So, you'd rather see fast updates of near-complete-nonsense, than slow updates of accurate data? :) :) In regards to the WX GUI FFT window not responding. I have tested it with a very simple flow-graph. A USRP source and the WX FFT GUI block. If the settings are at 4096@15fps, it works fine, try anything higher and the windows greys out. So, I don't really see where the issue is. Works for me with the latest Gnu Radio on F14. You may just be running out of computational steam in Python land, since the wxGUI FFT sink does wy too much of its "stuff" in Python land. Python runs up to about 100 times slower than equivalent native code. I've attached a simple test that works just fine here. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ 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 -- Hilbert (Godamn) Transform hilbert3...@gmail.com Purveyor of fine Hilbert (Godamn) Transforms since 2013 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Marcus,
I have tested this under the Ubuntu LiveUSB on a couple of machine and the same
problem occurs every time.
Regards,
Mark McCarron
Date: Thu, 16 May 2013 13:48:01 -0400
From: mle...@ripnet.com
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
On 05/16/2013 01:36 PM, Mark McCarron wrote:
Marcus,
Accurate output is great when doing analysis, but if you just
want to create a quick interface that will allow you to see a
little more detail, then overlapping or duplicating the stream
is fine. The error in the output is always within a given
tolerance and that can be suitable for a lot of applications.
By no means am I suggesting to eliminate the accurate GUI
elements, just that an alternative should be offered.
I tested your sample and that works fine on my machine. I have
updated it to a refresh rate of 30 and this is when it becomes
unresponsive. I ran perfmon and the resources seem fine, but I
do see a massive spike in page faults and transition faults when
executing a flow graph. That, in itself may not be an issues,
but I have checked all the usual bottlenecks and they are barely
being touched. I'm running the latest Windows build of this on
a quad core Win2012 server with 16GB ram.
It seems like a bug in the build.
Regards,
Mark McCarron
More likely a bug in the Windows wxGUI implementation, which is
known to have lots of flaws.
I assumed you were running this on Linux, which is the primary
development platform for Gnu Radio.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
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] WX GUI Chooser
Can't find this info anywhere, does anyone know the format for the 'labels' section of this control? Regards, Mark McCarron ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about UHD driver
There is a performance issue with this. If your program needs to manipulate the raw data, but at the same time provide that raw data to another branch(es), a copy much be made. If this is the case, then it would make more sense to duplicate the data in parallel as it enters the system. This should be more efficient than memcopy. I am looking into DMA to see if this is possible. Regards, Mark McCarron From: m...@ettus.com Date: Thu, 16 May 2013 20:51:32 -0700 Subject: Re: [Discuss-gnuradio] Question about UHD driver To: mark.mccar...@live.co.uk CC: discuss-gnuradio@gnu.org There is no need to create multiple copies. The consuming blocks are each given a pointer to the same data, and the memory is not freed until all the consuming blocks indicate they are done with it. Matt On Thu, May 16, 2013 at 11:00 AM, Mark McCarron wrote: I am wondering if the UHD driver has the ability to create multiple copies of the stream in memory??? Let's say I have a flow-graph that has two branches, the first pushes complex data to an FFT, whereas the second demodulates a portion of that data into AM. Does the driver supply a single stream, which is then copied by the application? Or does it create two copies of the stream and allow each branch of the flow-graph to manipulate the data via pointers? I'm digging into DMA to see if this is possible, I would be surprised if there was a limitation here. Regards, Mark McCarron ___ 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] Question about UHD driver
Matt, My area of research is DSP and massive parallelism. Given the structure of GNU Radio, it is possible to know what data is required upfront. This opens up the possibility of a performance boost. I know how GNURadio works, it was discussed earlier when I raised this question. There is a different way though. Lets assume we have two branches coming from the source. The first is going to an FFT, the second to some form of flow-graph that performs functions on the IQ stream. Also, we don't want the changes we make to the IQ stream to be reflected in the FFT. Now, we can approach this several ways: 1. Serial - Send the data first to FFT, then to the second portion of the flow-graph. 2. Parallel (memcopy) - Copy the data in memory, provide one to the FFT and the other to the IQ flow-graph. 3. Parallel (DMA/Driver) - Driver duplicates the data in memory according to the needs of the program. This is not a memcopy, but a true parallel creation as the stream is extracted from the wire. The last approach allows us to lighten the load on the application and CPU by off-loading initial memory allocation to DMA controllers. This way, we don't need to manage FIFO streams within the app in relation to the initial input. As I said, I am still checking if this is possible, but when working with multiple branches that require independent copies of the data this would be best performing way to deliver the data. Regards, Mark McCarron From: m...@ettus.com Date: Thu, 16 May 2013 21:11:42 -0700 Subject: Re: [Discuss-gnuradio] Question about UHD driver To: mark.mccar...@live.co.uk CC: discuss-gnuradio@gnu.org Are you saying that it is better to always make copies of the data rather than just make copies when you need them? In any case, I think you misunderstand both how GNU Radio works and how UHD interacts with it. UHD provides a single copy of data to GNU Radio for two reasons -- first, that is the most efficient thing to do, and second, UHD can't possibly know what GNU Radio plans to do with the data. GNU Radio passes pointers of the data to every block that needs it. Blocks are not allowed to modify their inputs, only their outputs. This is fundamental to how GNU Radio operates. Matt On Thu, May 16, 2013 at 9:02 PM, Mark McCarron wrote: There is a performance issue with this. If your program needs to manipulate the raw data, but at the same time provide that raw data to another branch(es), a copy much be made. If this is the case, then it would make more sense to duplicate the data in parallel as it enters the system. This should be more efficient than memcopy. I am looking into DMA to see if this is possible. Regards, Mark McCarron From: m...@ettus.com Date: Thu, 16 May 2013 20:51:32 -0700 Subject: Re: [Discuss-gnuradio] Question about UHD driver To: mark.mccar...@live.co.uk CC: discuss-gnuradio@gnu.org There is no need to create multiple copies. The consuming blocks are each given a pointer to the same data, and the memory is not freed until all the consuming blocks indicate they are done with it. Matt On Thu, May 16, 2013 at 11:00 AM, Mark McCarron wrote: I am wondering if the UHD driver has the ability to create multiple copies of the stream in memory??? Let's say I have a flow-graph that has two branches, the first pushes complex data to an FFT, whereas the second demodulates a portion of that data into AM. Does the driver supply a single stream, which is then copied by the application? Or does it create two copies of the stream and allow each branch of the flow-graph to manipulate the data via pointers? I'm digging into DMA to see if this is possible, I would be surprised if there was a limitation here. Regards, Mark McCarron ___ 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about UHD driver
Marcus, I have been running into that issue as well. It seems that we are in a transition period with the introduction of multi-core processors and OpenCL. Bus design has not been modified to cope with the parallel duplication of data from high speed serial streams. This has implications for the performance of DSP, as well as other fields, on traditional computing platforms. It looks like the entire architecture of the PC needs a solid rethink at this point. As far as I can tell, the current architecture choices are cost related and manufacturers are attempting to software-define all transfers or incorporate SoC solutions. It means that we are saturating the CPUs with unnecessary tasks and creating bottlenecks as a result. Until manufacturers start offloading data again, it looks like there will be some hard limits to software defined radio that will make hardware defined solutions more cost effective. Regards, Mark McCarron > Date: Fri, 17 May 2013 16:53:07 +0200 > From: master.of.knowle...@gmail.com > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Question about UHD driver > > Hi Mark, > > for currently available UHD devices with high bandwidth, data comes into > the host computer via a gigabit ethernet controller (or USB). > UHD basically talks to the kernel and uses the data provided by the > network card driver/network stack; therefore, UHD specifies a layer > built upon hardware drivers, it does not copy the data from the NIC itself. > (Same applies for USB controllers) > So unless you start rewriting Gigabit Ethernet card hardware drivers, > there's no way to get the same hardware data into the host system via > multiple DMA calls with the same origin. > > Greetings, > Marcus > > Am 17.05.2013 06:40, schrieb Mark McCarron: > > Matt, > > > > My area of research is DSP and massive parallelism. Given the structure > > of GNU Radio, it is possible to know what data is required upfront. > > This opens up the possibility of a performance boost. I know how > > GNURadio works, it was discussed earlier when I raised this question. > > > > There is a different way though. Lets assume we have two branches > > coming from the source. The first is going to an FFT, the second to > > some form of flow-graph that performs functions on the IQ stream. Also, > > we don't want the changes we make to the IQ stream to be reflected in > > the FFT. > > > > Now, we can approach this several ways: > > > > 1. Serial - Send the data first to FFT, then to the second portion of > > the flow-graph. > > 2. Parallel (memcopy) - Copy the data in memory, provide one to the FFT > > and the other to the IQ flow-graph. > > 3. Parallel (DMA/Driver) - Driver duplicates the data in memory > > according to the needs of the program. This is not a memcopy, but a > > true parallel creation as the stream is extracted from the wire. > > > > The last approach allows us to lighten the load on the application and > > CPU by off-loading initial memory allocation to DMA controllers. This > > way, we don't need to manage FIFO streams within the app in relation to > > the initial input. > > > > As I said, I am still checking if this is possible, but when working > > with multiple branches that require independent copies of the data this > > would be best performing way to deliver the data. > > > > Regards, > > > > Mark McCarron > > > > > > From: m...@ettus.com > > Date: Thu, 16 May 2013 21:11:42 -0700 > > Subject: Re: [Discuss-gnuradio] Question about UHD driver > > To: mark.mccar...@live.co.uk > > CC: discuss-gnuradio@gnu.org > > > > > > Are you saying that it is better to always make copies of the data > > rather than just make copies when you need them? > > > > In any case, I think you misunderstand both how GNU Radio works and how > > UHD interacts with it. UHD provides a single copy of data to GNU Radio > > for two reasons -- first, that is the most efficient thing to do, and > > second, UHD can't possibly know what GNU Radio plans to do with the > > data. GNU Radio passes pointers of the data to every block that needs > > it. Blocks are not allowed to modify their inputs, only their outputs. > > This is fundamental to how GNU Radio operates. > > > > Matt > > > > > > > > > > On Thu, May 16, 2013 at 9:02 PM, Mark McCarron > <mailto:mark.mccar...@live.co.uk>> wrote: > > > > T
Re: [Discuss-gnuradio] Question about UHD driver
I would tend to agree, but if we do not outline what we require from manufacturers, we will never get it. I would seriously suggest writing a specification and submitting it to Intel, AMD, etc. Regards, Mark McCarron > Date: Fri, 17 May 2013 18:04:37 +0200 > From: master.of.knowle...@gmail.com > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Question about UHD driver > > Hi Mark, > > as interesting as your point is, that's not something that > can be fixed within the scope of GNU Radio or even UHD... > > Anyhow, I'm not really convinced that multiple DMA transfers are always > faster than copying data using memcpy - at least if those DMA transfers > copy only a few kilobytes, as is the case with packets from network devices. > The fact that packets are of limited size is not really a problem of > current computing architectures - it's a consequence of having packet > networks. Of course, it would be nice if your hardware would be able to > actually stream data into your userland, that somehow has the (zero > overhead) capability to tell the hardware to send the next sample - but > in reality, hardware-to-cpu-transfers usually happen en block, and that > is just fine for most applications, since there is little use of having > samples one after another; therefore, some buffering is always necessary > (and will always be). > For the sake of adaptivity, hardware supplied data most probably won't > be written to copy device data to multiple RAM addresses, since the data > from the device usually needs some processing (hence the driver). > So in effect, in most imaginable cases a device will do a single > DMA transfer to RAM. > > Greetings, > Marcus > > ___ > 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] Question about UHD driver
I think you are missing the point. In order to support massive parallelism, data must be duplicated as it comes of the wire and into memory. Not duplicated in FIFO streams in an application. The latter is a software implementation of a hardware task and is consuming resources. It requires hardware and architecture changes to implement properly. Regards, Mark McCarron > Date: Fri, 17 May 2013 18:44:51 +0200 > From: master.of.knowle...@gmail.com > To: mark.mccar...@live.co.uk > Subject: Re: [Discuss-gnuradio] Question about UHD driver > > > I would tend to agree, but if we do not outline what we require from > > manufacturers, we will never get it. I would seriously suggest writing > > a specification and submitting it to Intel, AMD, etc. > What you want from device manufacturers will never change how networks > function (by exchanging packeted data with headers and checksums), as > well as it will never change that latency on a memory bus makes it > reasonable to always exchange chunks of data; Intel can't do anything > about that, it's physics... > An FFT works on a block of samples, so having samples on a > sample-per-sample-basis won't make it faster. > However, if you design a DSP program to work on a dedicated chip that > does *nothing else* than the processing of samples that come directly > from the ADC, you can of course minimize latency. Sadly, this eliminates > all reconfigurability, and is not very likely to provide solutions for > current DSP problems. > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about UHD driver
Guys, This places a limit on the performance of GNURadio that can be avoid through a push for a more modern type of DMA. The ideal scenario is to never copy data and it is achievable, to a degree, through proper planning. If you look at your argument, you are essentially saying that it is better to copy than to have a pointer. I can't agree with that. Regards, Mark McCarron From: johnat...@corganlabs.com Date: Fri, 17 May 2013 10:06:08 -0700 Subject: Re: [Discuss-gnuradio] Question about UHD driver To: mark.mccar...@live.co.uk CC: discuss-gnuradio@gnu.org On Fri, May 17, 2013 at 9:55 AM, Mark McCarron wrote: In order to support massive parallelism, data must be duplicated as it comes of the wire and into memory. Not duplicated in FIFO streams in an application. There is no duplication of buffer contents in GNU Radio. To elaborate on what Matt Ettus described earlier, GNU Radio blocks are connected via single-producer, multi-consumer FIFOs. Upstream blocks (including hardware source blocks) write into the FIFO, and multiple concurrently running downstream-connected blocks have read-only access to its contents, while writing the output of their individual DSP functions into new FIFOs for the next stages of the pipeline. There is no need to pre-copy the data into different memory areas for multiple consumers to access, and no need to worry that processing in one block has any side effects on processing in another block. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about UHD driver
Marcus, I was writing the Windows driver for Per Vices Corporation (Phi/Noctar) last year, I know how drivers work. I should have mentioned that earlier. What you are missing is the fact that the DMA must occur first before anything can get to a cache. So, if we are writing to memory in parallel, it is always going to be faster as this happens long before data gets to the CPU. Also, just to correct some things, the whole point of DMA is to take the CPU out of the loop, so the CPU is not used to conduct transfers. It can take part in scheduling, but the data goes from the device into memory and a pointer is returned. The FIFO buffer in an app makes use of this pointer. Regards, Mark McCarron Date: Fri, 17 May 2013 20:23:34 +0200 Subject: Re: [Discuss-gnuradio] Question about UHD driver From: master.of.knowle...@gmail.com To: mark.mccar...@live.co.uk CC: discuss-gnuradio@gnu.org > The ideal scenario is to never copy data and it is achievable, to a degree, > through proper planning. I have to strongly disagree with that. You have to realize what a /driver/ is. And why it is needed: A driver takes whatever ressources a piece of hardware offers and makes these ressources usable to actual application software. Thus: A driver is /necessary/ to convert and transfer data from "the wire" to something a program can access without having to know how this particular piece of hardware works. This conversion _has_ to happen using the CPU power of the host. Therefore, you either have to let the driver do its work on all copies of the device data in RAM, or you just do it once, and then copy the data using the CPU. Which is way more intelligent, flexible, well-performing... and what is done in current architectures. > If you look at your argument, you are essentially saying that it is better > to copy than to have a pointer. In many cases it is. Example? You have an arbitrary computer architecture with external memory (this is desirable unless you want to be limited to microcontrollers): RAM---memory bus---cpu Gigabytes of RAM aren't easy to produce cheaply, and are even harder to access with low latency. Therefore, modern CPUs have caches: RAM --- memory bus --- Cache --- CPU Those caches are designed to be fast, but are of limited size (for reasons aforementioned). Now take your DMA transfer: You instruct the memory controller to write data from your device to RAM. That automatically invalidates the cache for this RAM region,if that happens to be cached, which is likely, because we're in a scenario where we constantly use data from the device. Now assume that this data is relevant to the system. (otherwise we wouldn't argue over performance, would we?) So, in the next few microseconds, someone is going to access that newly written data. Whether the cache/dma/memory controller updated the cache or not, there will be one valid copy in the cache soon. Now, copying that data from RAM address to RAM address is usually a lot faster than a DMA - because 1) the cache can "hide" the copying by reading from the original address as long as no writes on either original or copy take place, 2) access to dma'ed memory only present in RAM is as fast as access to the cache _at best_. Therefore, zero copy is not always preferable above having a RAM copy - especially for stuff that fits into L2 cache multiple times; for ethernet packets in special. Hope that mail explained my point of view well enough :) Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Question about UHD driver
I don't know if I agree with this. I don't usually have issues with the memory bus. Every problem I have encountered, in terms of bottlenecks, is nearly always related to I/O. The CPU is useless at this and that's why we have DMA. With constant streams of real-time data, there is a fixed window in which to get all the processing done. Thus each stage needs to be optimized and that begins with I/O. We really should have some performance metrics for each block, so that when they are combined we have estimate of the total end-to-end time. Regards, Mark McCarron Date: Fri, 17 May 2013 14:52:09 -0400 From: hilbert3...@gmail.com To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Fwd: Question about UHD driver This was actually supposed to go to the list as well. -- Forwarded message -- From: Hilbert Transform Date: Fri, May 17, 2013 at 2:48 PM Subject: Re: [Discuss-gnuradio] Question about UHD driver To: Mark McCarron Mark: First, it's "copies are bad", then it's "copies are good". Make up your mind, laddy. :) The critical resource here, which drives the need to reduce memcpy-like operations isn't CPU, but memory bandwidth. That memory bandwidth gets chewed up whether it's the CPU doing it, or the DMA controller. There's no magic on the bus. It doesn't care who is doing transactions. In the land of multi-core CPUs, it's rather silly to say "but the CPU has beter things to do than X". So, those CPUs should perhaps spend their time playing Zork? Or surfing porn? Again, the "drive" to reduce memory-to-memory copy traffic is to reduce pressure on memory bus bandwidth, not save those oh-so-precous, I only have eight 'of 'em, CPUs. Since most modern CPUs have microcoded memory-to-memory copy instructions, the CPU burden is relatively small. We aren't back in the dark days of "optimized" memcpy operations being a series of word-wise copies, followed by a byte-wise "mop up". Your argument could well be extended, reducto-ad-absurdium to "the CPU has better things to do than anything you might want to do in a flow-graph" which is clearly absurd. One might re-cast the problem as "any memory-to-memory operation should have non-zero 'work' applied while doing the copy". So, a memcpy is a "no useful work" motion of data from one place to another. Other types of "data motion" have useful work applied as the data are in motion. This is roughly how Gnu Radio works. It doesn't leverage as many "zero copy" opportunities as perhaps it should, and Josh Blum's GRAS work is a step in the direction of leveraging zero-copy opportunities wherever possible. But again, getting the data out of the hardware, while an important problem, usually constitutes a small fraction of the overall CPU and memory-bandwidth costs of any kind of non-trivial SDR signal flow. In the era of multi-core CPUs (with 'multi' starting to scale to "absurd"), the notion of "the CPU shouldn't be spending it's precious time doing that" is a decreasingly-defensible position to take. On Fri, May 17, 2013 at 2:36 PM, Mark McCarron wrote: Marcus, I was writing the Windows driver for Per Vices Corporation (Phi/Noctar) last year, I know how drivers work. I should have mentioned that earlier. What you are missing is the fact that the DMA must occur first before anything can get to a cache. So, if we are writing to memory in parallel, it is always going to be faster as this happens long before data gets to the CPU. Also, just to correct some things, the whole point of DMA is to take the CPU out of the loop, so the CPU is not used to conduct transfers. It can take part in scheduling, but the data goes from the device into memory and a pointer is returned. The FIFO buffer in an app makes use of this pointer. Regards, Mark McCarron Date: Fri, 17 May 2013 20:23:34 +0200 Subject: Re: [Discuss-gnuradio] Question about UHD driver From: master.of.knowle...@gmail.com To: mark.mccar...@live.co.uk CC: discuss-gnuradio@gnu.org > The ideal scenario is to never copy data and it is achievable, to a degree, > through proper planning. I have to strongly disagree with that. You have to realize what a /driver/ is. And why it is needed: A driver takes whatever ressources a piece of hardware offers and makes these ressources usable to actual application software. Thus: A driver is /necessary/ to convert and transfer data from "the wire" to something a program can access without having to know how this particular piece of hardware works. This conversion _has_ to happen using the CPU power of the host. Therefore, you either have to let the driver do its work on all copies of the device data
Re: [Discuss-gnuradio] Question about UHD driver
So, you think the penalty of processing in the stack, outweighs the performance gained by having duplicate streams? You do realise they are being processed in parallel in the stack??? By the time you would start the copy, my modified DMA would be ready under all scenarios. Regards, Mark McCarron Date: Fri, 17 May 2013 22:35:25 +0200 Subject: Re: [Discuss-gnuradio] Question about UHD driver From: master.of.knowle...@gmail.com To: mark.mccar...@live.co.uk CC: discuss-gnuradio@gnu.org Hi Mark, I wasn't assuming you didn't know what a driver is - I was just hoping you'd try to realize more clearly, that especially for something like network packets, you need a hardware driver (and the network stack of the os) to make use of your dma'ed data. You're totally right that data from a device needs to be transferred somewhere before it can be used. However, I don't think you're right in respect to a parallel DMA always making your system faster - your second version of the data still has to be processed by driver/stack (and therefore by the cpu), so that having it copied into RAM while your machine is processing the first version is not necessarily faster than copying the processed version. In fact, under my caching asumptions, that would even be slower on a single core system. On Fri, May 17, 2013 at 8:36 PM, Mark McCarron wrote: Marcus, I was writing the Windows driver for Per Vices Corporation (Phi/Noctar) last year, I know how drivers work. I should have mentioned that earlier. What you are missing is the fact that the DMA must occur first before anything can get to a cache. So, if we are writing to memory in parallel, it is always going to be faster as this happens long before data gets to the CPU. Also, just to correct some things, the whole point of DMA is to take the CPU out of the loop, so the CPU is not used to conduct transfers. It can take part in scheduling, but the data goes from the device into memory and a pointer is returned. The FIFO buffer in an app makes use of this pointer. Regards, Mark McCarron Date: Fri, 17 May 2013 20:23:34 +0200 Subject: Re: [Discuss-gnuradio] Question about UHD driver From: master.of.knowle...@gmail.com To: mark.mccar...@live.co.uk CC: discuss-gnuradio@gnu.org > The ideal scenario is to never copy data and it is achievable, to a degree, > through proper planning. I have to strongly disagree with that. You have to realize what a /driver/ is. And why it is needed: A driver takes whatever ressources a piece of hardware offers and makes these ressources usable to actual application software. Thus: A driver is /necessary/ to convert and transfer data from "the wire" to something a program can access without having to know how this particular piece of hardware works. This conversion _has_ to happen using the CPU power of the host. Therefore, you either have to let the driver do its work on all copies of the device data in RAM, or you just do it once, and then copy the data using the CPU. Which is way more intelligent, flexible, well-performing... and what is done in current architectures. > If you look at your argument, you are essentially saying that it is better > to copy than to have a pointer. In many cases it is. Example? You have an arbitrary computer architecture with external memory (this is desirable unless you want to be limited to microcontrollers): RAM---memory bus---cpu Gigabytes of RAM aren't easy to produce cheaply, and are even harder to access with low latency. Therefore, modern CPUs have caches: RAM --- memory bus --- Cache --- CPU Those caches are designed to be fast, but are of limited size (for reasons aforementioned). Now take your DMA transfer: You instruct the memory controller to write data from your device to RAM. That automatically invalidates the cache for this RAM region,if that happens to be cached, which is likely, because we're in a scenario where we constantly use data from the device. Now assume that this data is relevant to the system. (otherwise we wouldn't argue over performance, would we?) So, in the next few microseconds, someone is going to access that newly written data. Whether the cache/dma/memory controller updated the cache or not, there will be one valid copy in the cache soon. Now, copying that data from RAM address to RAM address is usually a lot faster than a DMA - because 1) the cache can "hide" the copying by reading from the original address as long as no writes on either original or copy take place, 2) access to dma'ed memory only present in RAM is as fast as access to the cache _at best_. Therefore, zero copy is not always preferable above having a RAM copy - especially for stuff that fits into L2 cache multiple times; for ethernet packets in
Re: [Discuss-gnuradio] Noise levels from a RTL dongle
Replace the low pass filter with a band pass filter. The low pass filter is not extracting the signal at the center frequency, but the first 70KHz of the 1MHz bandwidth. Also, the decimation and interpolation chosen in the resampler will destroy all information in the channel. At the chosen values, the interpolation would be essentially inventing the signal, rather than upsampling it. Regards, Mark McCarron Date: Fri, 24 May 2013 15:40:39 -0700 From: alankeithwoodw...@gmail.com To: Discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Noise levels from a RTL dongle Hi, I am new to Gnu radio but have it working on Mac OS X 10.8 and am using a E4000 tuner in a usb dongle. I have been experimenting with a Gqrx as well as GRC and am getting mixed results, with Gqrx I can get reasonable quality FM reception on 89.31 Mhz (radio 2 in the UK) with the wide band FM (mono) receiver and a 70Khz filter band. I have tried to replicate this in GRC as I want access to the demodulated signal as a live file (to be fed into a std unix pipe) for onward processing, however, the quality is significantly worse than Gqrx. Can anyone help with my GRC graph. Details are on my site, Woodstercorp.com Any help gratefully received. Alan View this message in context: Noise levels from a RTL dongle 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] Bins smaller than pixels. was: WX GUI FFT Sink Performance
I think the best approach is just to include every possible method in GNURadio. This can only make the platform more versatile. I make use of overlapping a lot because computation times are a pain. The trade-off in resolution is acceptable to me because it has limits that I can work around. This allows me to work with weak signals that would otherwise go unnoticed without some heavy computation. I typically work at resolutions of over 1 million to examine narrow-band signals. The other method is to have a system setup to record the spectrum to a file, then allow another computer to do the FFT at different resolutions. SETI do the same thing with the BOINC platform, only on a far greater scale. Regards, Mark McCarron > Date: Tue, 28 May 2013 13:36:19 -0400 > From: j...@febo.com > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Bins smaller than pixels. was: WX GUI FFT > Sink Performance > > On 5/28/2013 1:28 PM, Simon IJskes wrote: > > On 17-05-13 02:22, Marcus D. Leech wrote: > >> > >> Again, given the fact that your display geometry is likely less than > >> 1280 wide, you'll simply lose information for FFTs larger than that. > > > > I one is looking for weak CW signals, in a waterfall, wouldn't a wide > > bin, make this signal invisible in among the noise? If more bins fit in > > one pixel, there could be a mode where the bin with the most power is > > displayed. If this is complete non-sense, how would you implement > > looking for faint cw carriers, in like EME applications? > > Take a look at the "rosenfell" or "normal" detector used in spectrum > analyzers -- I think it's a way to deal with this question. There's a > good discussion in the Agilent spectrum analysis basics app note: > http://cp.literature.agilent.com/litweb/pdf/5952-0292.pdf > > John > > ___ > 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] flowgraph with async messaging hangs on calling wait()
Hello all, I have written a sync block that takes in samples and outputs messages (similar to tagged_stream_to_pdu), but when writing a test for the block I found that when I called top_block.run(), the test never finished, as it appears to be hanging on the call to top_block.wait(). The flow graph for the test is as follows: non-repeating file source -> my block -> message_debug is hanging the expected behaviour? I can work around it by counting the number of items written by the file source, but it would be nice to have it terminate of its own accord. Thanks, Mark -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to use USRP to detect and collect weak satellite signals
The majority of thermal noise enterimg the receiver is from the antenna and the path to the LNA. Freeze the antenna and this path, then you may be able to see GPS. Lookup the formula for MDS and it will give you an idea of the temperature you need. Then select a coolant. Thermal noise is bandwidth dependent, so you may need multiple receivers. I don't know of any single chip solutions available to the public. Tom Rondeau wrote: >On Wed, Sep 4, 2013 at 4:45 AM, Nemanja Savic >wrote: >> After installing 3.6.5.1 there is a problem while when running >flowgraph. >> Flowgraph won't start, and the error is following: >> >> Using Volk machine: avx_64_mmx >> -- Loading firmware image: >/usr/local/share/uhd/images/usrp1_fw.ihx... done >> -- Opening a USRP1 device... >> -- Loading FPGA image: /usr/local/share/uhd/images/usrp1_fpga.rbf... >done >> -- Using FPGA clock rate of 64.00MHz... >> *** glibc detected *** /usr/bin/python2.6: malloc(): memory >corruption: >> 0x05661000 *** >> *** glibc detected *** /usr/bin/python2.6: malloc(): memory >corruption: >> 0x05661000 *** >> >> Is this problem due to python 2.6 maybe? >> >> Cheers > >Shouldn't be. I believe that I've tested 3.7 using Python 2.5 and 2.6. > >How about just starting gnuradio-companion and seeing if you can run a >simple flowgraph without any hardware? > >Did ctest (or 'make test') pass? > > >-- >Tom >Visit us at GRCon13 Oct. 1 - 4 >http://www.trondeau.com/grcon13 > > >> -- >> Nemanja Savić > >___ >Discuss-gnuradio mailing list >Discuss-gnuradio@gnu.org >https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowgraph with async messaging hangs on calling wait()
Hi Tom, I spent a while playing around with this, including adding a bunch of debug output to tpb_thread_body::tpb_thread_body, and found that when a block is done, the DONE state should propagate through the flow graph as tpb_detail::notify_neighbours is called (as I'm sure you're aware). The problem is, tpb_detail::notify_neighbours only notifies blocks that that have input or output buffers (which as far as I can tell, blocks with only message inputs or outputs don't), so blocks like message_debug will block on tpb_detail::input_cond forever (on line 110 of tpb_thread_body.cc) and can never be notified (as it has no input buffers, so notify downstream does nothing). Johnathan contacted me r.e. this and I sent him a patch which fixed the problem for me (attached to this message), but I don't think he has had time to look at it yet. The gist of it is that it uses pmt::PMT_EOF to indicate that message blocks should transition to done and notify neighbours. Please feel free to correct me on any of what I said above, this was my first foray into the scheduler so I could have it completely wrong. Thanks, Mark On Thu, Sep 12, 2013 at 3:56 AM, Tom Rondeau wrote: > On Thu, Aug 22, 2013 at 10:44 PM, Mark Cottrell > wrote: > > Hello all, > > > > I have written a sync block that takes in samples and outputs messages > > (similar to tagged_stream_to_pdu), but when writing a test for the block > I > > found that when I called top_block.run(), the test never finished, as it > > appears to be hanging on the call to top_block.wait(). > > > > The flow graph for the test is as follows: > > non-repeating file source -> my block -> message_debug > > > > is hanging the expected behaviour? I can work around it by counting the > > number of items written by the file source, but it would be nice to have > it > > terminate of its own accord. > > > > Thanks, > > Mark > > > Mark, > > No, that's not expected behavior. When the file sink finishes, it > should set the DONE stage in the scheduler that should indicated to > every down stream block that they are also done. > > Make sure that there isn't something happening where your block isn't > getting stuck in 'work' at this point. > > -- > Tom > Visit us at GRCon13 Oct. 1 - 4 > http://www.trondeau.com/grcon13 > -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. -- async_message_stopping3.patch Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] possible bug with hier_block2_detail::msg_disconnect
Hello all, I am working with gnuradio 3.7.2git-28-g639e154d and I have a hierarchical block with a message output that I have been using as part of a larger flowgraph. Yesterday I found that whenever I call msg_disconnect on the top block with the hier block as the source, I get an error logged about it having no subscribers. I verified this by printing out the subscribers in calls to message_port_sub and message_port_unsub. It seems that when you call msg_connect, the call to message_port_sub is not made until the flowgraph has been flattened, so the subscription does not belong to the hier block, it belongs to the block inside the hier block that has the message output. However, when you call msg_disconnect, it simply attempts to call message_port_unsub on on the hier block, which fails, as the hier block has no subscriptions. To get around this, I simply commented out the call to message_port_unsub in msg_disconnect, but this isn't ideal and won't fix the problem in all cases. So my question is, is this a bug? If so, is it known about, and if not can an issue please be raised to track it? Thanks, Mark -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] possible bug with hier_block2_detail::msg_disconnect
Hi Johnathan, I would be happy to raise an issue if someone could give me access (my username is markcottrell), otherwise, I have attached a script that reproduces the issue. I have also attached a patch that seems to fix the issue for me. There are some unit tests in the patch, but they aren't very comprehensive as they only really test for the absence of an exception, rather than the message port actually having been disconnected and the subscriptions cleared. Thanks, Mark On Sun, Oct 13, 2013 at 7:06 AM, Johnathan Corgan wrote: > On 09/29/2013 09:27 PM, Mark Cottrell wrote: > > > I am working with gnuradio 3.7.2git-28-g639e154d and I have a > > hierarchical block with a message output that I have been using as part > > of a larger flowgraph. Yesterday I found that whenever I call > > msg_disconnect on the top block with the hier block as the source, I get > > an error logged about it having no subscribers. I verified this by > > printing out the subscribers in calls to message_port_sub and > > message_port_unsub. > > > > It seems that when you call msg_connect, the call to message_port_sub is > > not made until the flowgraph has been flattened, so the subscription > > does not belong to the hier block, it belongs to the block inside the > > hier block that has the message output. However, when you call > > msg_disconnect, it simply attempts to call message_port_unsub on on the > > hier block, which fails, as the hier block has no subscriptions. > > > > To get around this, I simply commented out the call to > > message_port_unsub in msg_disconnect, but this isn't ideal and won't fix > > the problem in all cases. > > > > So my question is, is this a bug? If so, is it known about, and if not > > can an issue please be raised to track it? > > (Sorry for the delay in getting to this.) > > This indeed sounds like a bug. Can you create a ticket for this on the > gnuradio.org website, and attach a script that creates the error for you? > > -- > Johnathan Corgan, Corgan Labs > SDR Training and Development Services > http://corganlabs.com > -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. -- hier_block_msg_disconnect.patch Description: Binary data hier_msg_disconnect_issue.py Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Weird malloc/free crash in pm_remez.cc
On Mon, Nov 25, 2013 at 3:03 PM, Josh Myer wrote: > Hi all, > > I’ve got an annoying crash in the current head of gnuradio. It’s > reproducible with the GRC file up at: > > http://www.joshisanerd.com/am_demod_crash.grc > > Does this crash for anyone else? If nobody else can repro, this is > probably something that’s hosed in my environment. Until someone else can > confirm this, it’s probably not worth looking into for anyone else. > > For me, the crash is at pm_remez.cc:698, the free(Grid) call in the error > handler. (It’s coming from an error code of -2, which is probably due to > my putting in totally insane parameters or some such.) > > The odd thing is that it doesn’t look like it should be crashing in this > code path. The pointer it’s freeing is totally fine when I step through > with gdb: the same as the malloc’d value, and no intervening free() calls, > yet it’s still crashing when it gets free()’d. When I move the free(Grid) > line around, the crash follows it. It doesn’t look like anything else is > getting screwed up, so I don’t know what to make of this. > > (FWIW, my goal is to poke around at decoding RDS. I’ve removed a lot of > stuff to get down to this minimal program that shows the problem. I’ve > gotten the AM demod stuff sorta working in ipython, and am now trying to > port it back to gnuradio… pointers on anything that’s clearly wrong with my > design there would be appreciated.) > — > /jbm > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > I was able to reproduce your problem with the linked grc file. I'm running gnuradio 3.7.2git-171-g362b0fb6 in debian jessie, and I have absolutely no idea what would be causing it, sorry. At least now it seems as though it isn't isolated to a problem with your environment. -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error 28
On Thu, Dec 5, 2013 at 12:04 PM, Paul B. Huter wrote: > I have a USRP source going direct to a file sink, and it runs really well, > except for an error. Does anyone know what the following means?: > > thread[thread-per-block[1]: ]: file_sink write failed > with error 28 > it means that you're out of space ( http://www.virtsync.com/c-error-codes-include-errno) on the device > > I am writing to a RAMDisk, if that helps with a solution. > > Thank you. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] The USRP2 is not recognized by the computer.
Hi all I am new to gnuradio and Ubuntu. I am trying to install the GNU Radio and am following the procedure in gnuradio.org. I am at the point where I am checking to see if the USRP2 is recognized by the computer. When I enter the command: ls -lR /dev/bus/usb | grep usrp I don't get a response. Please Help. Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Need Tx/Rx loopback test for USRP2 with a wbx daughter board
Hi I now have a USRP2 with a wbx daughter board up and working under Ubuntu ( usrp2_fft.py ). I would like to perform a transmit / receive loopback test to verify transmit as well as receive. Is there a program or utitility which may perform this function? gnuradio newbie mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Burning SD Memory cards
I am trying to burn additional SD memory cards using usrp2_card_burner.py. I burned both the fpga and firmware images. In both cases the binaries seemed to burn properly and passed verification, however, when I tried to power up the USRP2 only light F was lit. Thanks for the help. Images fpga -> u2_rev3_20100603.bin and firmware -> txrx_wbx_raw_eth_20100608.bin SD cards 2GB Kingston Technology Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: A Humble Request....for allowing to copy Circuit into PCB
On Wed, Jan 12, 2011 at 7:17 AM, Moeller wrote: > You need a critical mass of developers to start a GNU-like open hardware. > Anybody interested? > It's a lot of work for a single person, but not so much in a shared effort. I absolutely agree. Production costs may be high for an individual trying to build a USRP equivalent, but I don't see why it couldn't be shared. PCB printing in particular can be done in batches, or locally by anyone with reasonable skill. The USRP has become a standard for SDR, and it would be good to get something comparable and open source. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Yet another kick at the cheap-hardware can
On Wed, Jan 19, 2011 at 11:23 PM, Marcus D. Leech wrote: > If the answer to the above is "yes", then the next question is: is > there a community of interested > volunteers to bring the project to fruition? Such an interested > community would involve: > > o High-level hardware design > o Detailed schematic capture and PCB layout > o FPGA firmware design > o Host-interface (FX2?) firmware design > o Host driver software design and implementation > o Small-scale financial investment for initial PCBs, components, etc > I have no knowledge of radio design beyond block diagrams, but I'm very interested in this project as the sort of device every community workshop or school should be able to get hold of. I'm happy to prototype PCBs and devices locally and help on the software interfacing side. Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MSISDN Proximity Project
On Tue, Apr 5, 2011 at 4:39 AM, Cristian Rougier wrote: > Hello, > > I'm looking for a way to do a software that can retreive the IMSI of > proximity devices > and later the MSISDN (phone number) associated. > > In a short i need to see the phone numbers of the proximity gsm devices. > > I need to know if anybody can help me on this, or say me about the right > way to start. > > I trust you have the co-operation of the GSM operator, or understand the privacy implications of not having it. An approach for mapping a number to a device on a specific cell is discussed in Karsten Nohl's talk[1]. Basically, you send empty messages in a particular pattern, and watch as the phone receives (and discards) them. This doesn't make it easy to do on a large scale. >From a hardware perspective, while you may get some success with a USRP, you're probably better off looking at the Osmocombb project. Mark [1] http://events.ccc.de/congress/2010/Fahrplan/attachments/1783_101228.27C3.GSM-Sniffing.Nohl_Munaut.pdf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gnuradio and Uhd on windows, installation problem.
Hi everyone, I have an USRP1 and trying to get it work under Win environment. I read some informations from http://www.joshknows.com/gnuradio_port and from this forum according to that I downloaded everything from http://www.ettus.com/downloads/gnuradio/ (dependencies, ) and installed them. I installed libusb and the http://www.ettus.com/downloads/uhd_drivers/erllc_uhd_winusb_driver.zip, too? I installed the latest UHD image http://www.ettus.com/downloads/uhd_releases/003_000_001/UHD-003.000.001-win32.exe. I set all environment variables but when trying the uhd_find_devices.exe and uhd_usrp_probe.exe nothing works. Initially I installed everything under Ubuntu Linux, but no success, anyway I would like to work under windows. Could anybody tell me what I've done wrong? Thanks. Mark.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gnuradio and Uhd on windows,
Hi Marcus, yes you are right, anyway it was my first post :). So regarding the USRP1 and UHD. As I wrote before I installed everything I found on http://www.ettus.com/downloads/gnuradio/. When I run from command line the uhd_find_devices.exe nothing happend, no error, nothing. If it would receive some error messages maybe I could solve it, but nothing, the situation is the same for the uhd_usrp_probe.exe. I don't know what could be wrong with it, anyway I will write down in a few points what I have done: 1. Install gnuradio_deps-b1_44_r0-win32.exe 2. Install gnuradio-v3.3.1git-993-g082e85a-win32.exe 3. Install UHD-003.000.001-win32.exe 4. Unrar libusb_2010.10.06.7z 5. Unrar swigwin-2.0.1.zip 6. Unrar fftw-3.2.2.pl1-dll32.zip 7. Unrar cppunit-1.12.1.tar.gz 8. Install gsl-1.8.exe 9. Unrar and install erllc_uhd_winusb_driver.zip 10. Install python-2.7.1.msi 11. Install pygtk-all-in-one-2.22.6.win32-py2.7.msi 12. Install numpy-1.5.1-win32-superpack-python2.7.exe 13. Install PyQt4.Qwt5-5.2.1.win32-py27.exe 14. Install PyQt-Py2.7-x86-gpl-4.8.2-1.exe 15. Install setuptools-0.6c11.win32-py2.7.exe 16. I got the usrp1_fpga.rbf and usrp1_fw.ihx, both are placed into a folder. Each of these are installed or unrared into a folder named USRP1Env, in separate subfolders. I set in User Variables the following values. In PATH variable I set: 1. ...\USRP1Env\fftw-3.2.2.pl1-dll32\ 2. ...\USRP1Env\gnuradiodeps\lib\ - it containes cppunit_dll, qwt5, boost libraries, libfftw3l-3, libgsl, libusb-1.0 3. ...\USRP1Env\libusb\MS32\dll\ 4. ...\USRP1Env\gnuradio33\lib\ 5. ...\USRP1Env\gsl18\bin\ 6. ...\USRP1Env\Python27\Lib 7. ...\USRP1Env\UHD\lib in the PYONPATH variable I set: 1. ...\USRP1Env\Python27\Lib\site-packages. When I connect my USRP1 to PC I can see it in Device Manager as "Ettus Research LLC USRP1", but when trying the uhd_find_devices.exe and uhd_usrp_probe.exe nothing happend. Could you tell me please if there is anything missing or not set as needed, or maybe I didn't understood perfectly how this whole UHD, GNURADIO, USRP thing is working. Anyway there is any good tutorial or something similar for this, where is presented step by step the whole installation process and the first configuration of an example. Maybe for people like you there's no problem to install all these development tools and to make interesting projects but for me and others who are starting to use UHD, GNURADIO it's quite difficult. If there were such kind of tutorial this whole forum wouldn't be full of questions from begginers related to different installation issues. Thank you very very much for your answer. Mark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio and Uhd on windows,
Hi Josh, >> From your email, it looks like you did those things. When you run >>uhd_find_devices, the driver will actually load a firmware image >> >>and reset the USRP (if this is the first time it was powered up). You should >>see >>the device disconnect and connect when this happens. >> >>Anything like that happening? I downloaded the image and I put the usrp1_fw.ihx and usrp1_fpga.rbf into a directory named image and I set the PATH to that image directory. When I power up the USRP1 it shows in the DeviceManager the LibUSB-Win32 Devices -> USRP filter (VID=FFFE; PID=0004), but when running the uhd_find_devices there's no change, the device is not disconnected and reconnected, I don't get any error message, nothing; from ...\UHD\bin>uhd_find_devices.exe comes back to ...\UHD\bin>. I have Win XP installed on my laptop, no virtual machine. Really I don't know what's wrong (UHD is installed, image PATH is set) with it and what could I do with it to make it run. >> FYI, I uploaded a new gnuradio installer for windows, and added >> >> instructions >>which can be found here: >> >>http://www.joshknows.com/gnuradio_port#windows_binary_install I downloaded and installed it as you described it, when trying to run that gnuradio\bin\gnuradio-companion.py I received an error message "Cannot import gnuradio. Are your PYTHONPATH and LD_LIBRARY_PATH set correctly?" even if I set PYTHONPATH and PATH correctly, I checked and double-checked it (I'm using the Rapid Environment Editor). Thanks, Mark.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio and Uhd on windows,
Hi Don W, thank you very much, I uninstalled the old one and installed the new one version 1.0, but unfortunatelly it doesn't change anything. I can see in DeviceManager the libusb (WinUSB) devices -> Ettus Research LLC USRP1 (VID=FFFE; PID=0002; REV=0004). If I run uhd_find_devices.exe the result is the same as before, no error, from ...\UHD\bin>uhd_find_devices.exe comes back to ...\UHD\bin>, so it's a situation of everything is installed but nothing works. Anyway thank you very much for the information. Have a nice day. Best regards, Mark. From: Don Ward To: Mark Colin Cc: discuss-gnuradio@gnu.org Sent: Thu, April 14, 2011 3:56:45 PM Subject: Re: [Discuss-gnuradio] Gnuradio and Uhd on windows, Mark Colin wrote: > When I power up the USRP1 it shows in the DeviceManager the LibUSB-Win32 Devices -> USRP filter (VID=FFFE; PID=0004 Isn't LibUSB-Win32 the old libusb 0.1 driver? What happens if you uninstall the driver in the device manager and reinstall with the libusb 1.0 driver? -- Don W.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio and Uhd on windows,
Hi Josh,
> Just to verify things, I decided to try this out on an old XP laptop. I
>installed uhd and set my UHD_IMAGE_PATH, updated the driver to the
>WinUSB. The probe and find devices worked just fine.
>I recommend you try a different computer, a different usb cable, or a
>different os. Just to eliminate the variables. You only need to install
>uhd to test this.
I tried it on a different PC I installed UHD, when I wanted to try the
uhd_find_devices.exe (previously I set the UHD_IMAGE_PATH in the SYSTEM
VARIABLES not USER VARIABLES as Markus mentioned in one of his posts) it told
me
that can't find MSVCP100.dll, after I downloaded the MSVCP100.dll it asked for
MSVCR100.dll, after that it started with some error saying that it wasn't able
to locate an entry point into MSVCR100.dll. So, unfortunatelly it's not working.
I tried to check if gnuradio is OK, yes I have the most recent installer. I
have tested python.exe -c "from gnuradio import gr" and python.exe -c "from
gnuradio import uhd". It can't find the path to the DLL file (like the problem
of Ryan van den Bergh in one of these posts) even if I changed theyr path from
User Variables Path to System Variables Path.
d:\Docs\Code\Python27>python.exe -c "from gnurad
io import gr"
Traceback (most recent call last):
File "", line 1, in
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\gr\__init__.py", line 43, in
from gnuradio_core import *
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\gr\gnuradio_core.py", line 23, in
from gnuradio_core_runtime import *
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\gr\gnuradio_core_runtime.py", line 25, in
_gnuradio_core_runtime = swig_import_helper()
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\gr\gnuradio_core_runtime.py", line 21, in swig_import_helper
_mod = imp.load_module('_gnuradio_core_runtime', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.
d:\Docs\Code\Python27>python.exe -c "from gnurad
io import uhd"
Traceback (most recent call last):
File "", line 1, in
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\uhd\__init__.py", line 87, in
_prepare_uhd_swig()
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\uhd\__init__.py", line 26, in _prepare_uhd_swig
import uhd_swig
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\uhd\uhd_swig.py", line 24, in
_uhd_swig = swig_import_helper()
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\uhd\uhd_swig.py", line 20, in swig_import_helper
_mod = imp.load_module('_uhd_swig', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.
I checked files with Dependency walker and it reports that can't find file. To
tell you the truth I don't know why it can't find DLL files, I'm making
softwares for more than 5 years but only once or twice happend to have some
problems with paths, anyway that's not a good practice to use hardcoded things
into the application, maybe this is why it can't find the DLL files.
Thanks you very much Josh.
Best regards,
Mark.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio and Uhd on windows,
Hi Josh, excuse me, right now I checked your website and read about MSVC redistributable package from microsoft and the recomandation to install it to c:\program files (x86). I will check if it's working with these changes. Thanks, Best regards, Mark.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error when using UHD, GRC
Hi, I installed latest UHD (on a WinXP SP3 OS) but when I'm trying to run the uhd_find_devices.exe I receive this error: C:\program files (x86)\uhd\bin>uhd_find_devices Win32; Microsoft Visual C++ version 10.0; Boost_104400; UHD_003.000.001-release Device discovery error: An existing connection was forcibly closed by the remote host -- -- UHD Device 0 -- Device Address: type: usrp1 name: serial: 4bd1fd09 when I try the uhd_usrp_probe.exe I receive the following error message: C:\program files (x86)\uhd\bin>uhd_usrp_probe Win32; Microsoft Visual C++ version 10.0; Boost_104400; UHD_003.000.001-release Error: An existing connection was forcibly closed by the remote host Could anybody explain me why I'm getting this error? I would like to ask a second question, maybe I don't understand it well. I installed UHD, GNURadio latest versions, Python and many dependencies, but when I'm trying to make a simple flowgraph in Gnuradio companion (a Signal source connected to a NULL sink) it says that I don't have installed grc_wxgui, the error is: Traceback (most recent call last): File "D:\TestProjects\Test\top_block.py", line 12, in from grc_gnuradio import wxgui as grc_wxgui ImportError: cannot import name wxgui It means GRC when parsing schematic writes in source code that it requires wxgui, but WXGUI is not ported as I saw on joshknows.com. Could anybody tell me what the problem could be? Thank you very much. Best regards, Mark.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error when using UHD, GRC
Hi, regarding my previous question I checked GRC and saw that WX GUI or QT GUI can be choosed, for some example I added some sliders for variables from QT GUI Widgets and I received some other error: Traceback (most recent call last): File "D:\TestProjects\Test\dial_tone.py", line 17, in import PyQt4.Qwt5 as Qwt File "D:\Environment\Python27\lib\site-packages\PyQt4\Qwt5\__init__.py", line 32, in from Qwt import * RuntimeError: the PyQt4.QtCore module is version -1 but the PyQt4.Qwt5.Qwt module requires version 0 I tried to find any explanation to this error but no success. Why it requires other version? I installed latest versions from each installer. Thanks, Best regards, Mark.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error when using UHD, GRC
Hi Josh, I have an USRP1 working on USB therefore it shouldn't give such kind of errors like "Error: An existing connection was forcibly closed by the remote host"? It has nothing to do with firewalls (I'm not opening UDP sockets, it's not a USRP2 or newer device) therefore the big question is why it's not working as intended. It recognized my USRP1, but nothing more. What is the order of finding devices. I suppose it starts to look around for USB devices after that other devices on other interfaces, so when running uhd_usrp_probe it should start to do it's job with USB devices, NO? therefore I should see results from uhd_usrp_probe and after thet this error. I'll have to check the source code for these examples. Thank you very much. Best regards, Mark.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error when using UHD, GRC
Hi, OK, the uhd_find_devices --args="type=usrp1" is working, there's no device discovery error message, but when I tried to run the uhd_usrp_probe --args="type=usrp1" the uhd_usrp_probe broke down giving a nice error message: "uhd_usrp_probe.exe has encountered a problem and needs to close. We are sorry for the inconvenience." If I disconnect from the Internet (I have internet connection on PPPOE) then I don't get any error when running uhd_find_devices.exe instead when I run uhd_usrp_probe.exe I get the mentioned error. I even tried to disable Local Area Network, and VirtualBox Network, but the error is there. I tried many packet sniffer (TCP, UDP) programs but there's no data transfer (I couldn't find any packet sent by UHD) when running uhd_usrp_probe --args="type=usrp1" therefore it might be some error in the test program uhd_usrp_probe before sending out any packet. What could be the problem? Thank, Best Regards, Mark. From: Josh Blum To: Mark Colin Cc: Discuss-gnuradio@gnu.org Sent: Wed, April 27, 2011 3:13:39 AM Subject: Re: Error when using UHD, GRC On 04/26/2011 04:59 PM, Mark Colin wrote: > Hi Josh, > >I have an USRP1 working on USB therefore it shouldn't give such kind of > errors like "Error: An existing connection was forcibly closed by the remote > host"? > Sorry, I missed that it was a USB based USRP. Even though its USB, the discovery logic still tries to send out broadcast packets to your network interfaces. (I am assuming that this error is a network issue.) I think if you add these arguments, the discovery logic wont attempt to search the network. uhd_find_devices --args="type=usrp1" uhd_usrp_probe --args="type=usrp1" It still might be worth it to fix the issue. Maybe disable a few extra network interfaces (or virtual ones like VPN). I have no idea, so I am curious as to what might cause this. -josh I assume you did do this: http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Windows-USB-driver ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error when using UHD, GRC
Hi Josh, thanks for your answer. Anyway if the UHD makes trouble because of the USRP2 than I decided to build my own UHD.dll from source code with MSVC 2008. I set in CMake environment that I don't want to include USRP2 stuff into the UHD driver (it won't look for USRP2 devices only for USRP1 devices on USB). I installed BOOST. I compiled the UHD, I got the DLL and utils files (uhd_usrp_probe and uhd_find_devices), I copied the DLL to location C:\program files (x86)\uhd\bin and the LIB file to location C:\program files (x86)\uhd\lib (both from D:\uhd\host\build\lib\Release\) but it's not working, so the problem is due to paths. I downloaded UHD source code to D:\uhd. Maybe I set wrong some parameters in CMake. Do you have any idea regarding this? Thanks, Mark. From: Josh Blum To: Mark Colin Cc: Discuss-gnuradio@gnu.org Sent: Thu, April 28, 2011 9:05:44 AM Subject: Re: Error when using UHD, GRC On 04/27/2011 02:34 PM, Mark Colin wrote: > Hi, > > OK, the uhd_find_devices --args="type=usrp1" is working, there's no >device > > discovery error message, but when I tried to run the uhd_usrp_probe > --args="type=usrp1" the uhd_usrp_probe broke down giving a nice error message: > > "uhd_usrp_probe.exe has encountered a problem and needs to close. We are > sorry > > for the inconvenience." > The last time I saw this, was when I learned that the libusb callbacks needed to be defined w/ a different calling convention. If you got UHD from this installer then I don't know the problem: http://www.ettus.com/downloads/uhd_releases/003_000_001/UHD-003.000.001-win32-with-LIBUSB_CALL-fix.exe > If I disconnect from the Internet (I have internet connection on PPPOE) then > I > don't get any error when running uhd_find_devices.exe instead when I > run uhd_usrp_probe.exe I get the mentioned error. I even tried to disable > Local > > Area Network, and VirtualBox Network, but the error is there. > If I read your message right, then it seems that the interaction between PPPOE and UHD may be the culprit. But it wasnt consistent between find and probe? but I would expect them to behave identically. > I tried many packet sniffer (TCP, UDP) programs but there's no data transfer > (I > > couldn't find any packet sent by UHD) when running uhd_usrp_probe > --args="type=usrp1" therefore it might be some error in the test > program uhd_usrp_probe before sending out any packet. > It may be the act of opening up a socket on that interface for broadcast. > > What could be the problem? > Windows is that nosey neighbor who always manages to get into your house at those awkward moments; even though you know you locked the door. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] benchmark OFDM Question
Hi everyone,
I am working on OFDM in gnuradio. I ran the benchmark_ofdm.py file.
Everything worked well, I want to ask one thing that I didn't see the last
packet on the terminal.
I set the packet size to 400 bytes and total number of bytes to be
transmitted to 1600. I should see 4 packets but i see only 3 packets. Where
is the problem??
Portion of the code is given blelow:
nbytes = int(1600 * 1) //line that I changed
n = 0
pktno = 0
pkt_size = int(400) //line that I changed
while n < nbytes:
pkt_contents = struct.pack('!H', pktno) + (pkt_size - 2) * chr(pktno & 0xff)
send_pkt(pkt_contents)
n += pkt_size
pktno += 1
-
Output is shown below:
>>> gr_fir_ccf: using SSE
>>> gr_fir_ccc: using SSE
>>> gr_fir_fff: using SSE
ok: True pktno: 0 n_rcvd: 1 n_right: 1
ok: True pktno: 1 n_rcvd: 2 n_right: 2
0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101
ok: True pktno: 2 n_rcvd: 3 n_right: 3
0202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202
Why fourth packet is not sent ? Or if it is sent then why it is not
displayed in the output. I am using gnuradio 3.3.0. Please help me in this.
Regards
Smith
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] trellis help please
Hi everyone, I want to implement convolutional coding using the trellis block. I don't want to use any modulation scheme or anything else after the encoder. The flow graph I want is shown below vector source>trellis encoder> viterbi or any decoder--->sink Part of the code is shown below src_d = (1,0,1,0,0,0,1,1,0,0,1) sorc = gr.vector_source_b (src_d) //source encoder = trellis.encoder_bs(f,0)//encoder s2f= gr.short_to_float() dec=trellis.viterbi_s(f,len(src_d),0,-1) //decoder dst = gr.vector_sink_s () //sink tb.connect (sorc,encoder,s2f,dec,dst) return(dst.data()) When I run the above flow graph I get nothing just empty, ( ), list. I am using "awgn1o2_4.fsm" file. I got the correct result after encoder. I can't use the trellis.metric or trellis.viterbi_combined_X to implement decoder as I am not using any modulation :( . Can anybody please help me in this ?? Regards Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Please Help in trellis gnuradio
Hi Thanks Achilleas, after doing this I got the desired result. One more question please What if I want to simulate a noisy channel? If my flow graph is like the one shown below: vector source>trellis encoder> channel noise>viterbi or any decoder--->sink Do I have to make any further changes or the previous solution 'll work? Thanks again, Regards Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
