Re: [Discuss-gnuradio] SDR/USRP devices
the features are not important for me now Then you can literally buy a rock. It has pretty bad reception, and all receivers built with rocks have a 50% bit error rate. (just kidding) SDR peripherals are technical equipment. There has to be *some* specification of what you need. Like Bandwidth. Make yourself acquinted with the parameters I listed in my last email, and what they mean. Then you will surely come to some conclusion of what you need. I just want to simulate a Cognitive Radio without a lot of details CR doesn't specify what you actually want to do at all, technically. For simulation you'd not need any hardware at all - so maybe you'd want to specify more closely what you want to do! Antony asked about this on Ruby Forum For people finding this later on via Google: This is NOT ruby forum. Ruby forum is nothing but a *bad* interface to the GNU Radio mailing list archives, which you can find at lists.gnu.org, and an even worse implementation of a mailing list client. You're doing it right by using email to communicate with us! Also, there's a lot of Mails going through this mailing list, so I don't know which Antony or which email you are referring to. Best regards, Marcus On 17.08.2015 20:42, Pedro Gabriel Adami wrote: Marcus, Below $120 is okay for me. Actually, the features are not important for me now, because I just want to simulate a Cognitive Radio without a lot of details. I just wanna see it working to study and learn about this process. Like I said, it's important to have a receiver port and be compatible with Gnuradio. I saw that Antony asked about this on Ruby Forum (it seems he has the same interests, but no one could help him, so I came here to the mailing list). Thanks for any help. Cheers, Pedro Gabriel Adami 2015-08-17 15:27 GMT-03:00 Marcus Müller marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com: Hi Pedro, You will, as for any device, need to figure out what you need, specification-wise. I'm obviously a bit biased, but no one else might even be able to help you unless you wrote some numbers: frequencies you're interested in, bandwidth you want to sample at once, stability, available interfaces, cost range etc. Best regards, Marcus Am 17. August 2015 20:13:38 MESZ, schrieb Pedro Gabriel Adami pedrogabriel.ad...@gmail.com mailto:pedrogabriel.ad...@gmail.com: Hello, I've been searching a lot about SDR and USRP devices to purchase. All I need is a board with a receiver port (transmitter is not important for now) and it's necessary to be compatible with Gnuradio. There are some options, but I don't have experiency or enough knowledge to choose one of them (I don't know the brands, if they are reliable, etc). I found RTL2838U/R820T2. Is it good? What are the other boards that you know? Sorry about the questions, but I'm kind of new here. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Atenciosamente, Pedro Gabriel Adami ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with QPSK receiver
Hi all, First time posting here, so hello everyone:) I am trying to build this pair of GNUradio flow graph for QPSK signal transmitting and receiving over the air through USRP. Now the transmitter side is straight forward, only a random number generator and QPSK modulator plus a multiplier. The receiver side is as attached. The problem is, I can get well separated constellation points after synchronizations, however the they are not correct. For example, if I set the transmitter side to modulate and send symbol '33...', the symbols after demodulation at receiver side is suppose to be '33'. instead, I get '01320132...' repeatedly. It seems that my constellation is constantly rotated with some frequency. I am not using differential modulation or demodulation, so it is some thing else rotating my constellation. My guess is that my synchronization is not good enough, there is a slight frequency offset which move the phase backward(forward?) from time to time. Any comments or suggestion are really appreciated. Howe Attachments: http://www.ruby-forum.com/attachment/11033/forum_question.png -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RX/TX transceiver
Hi All, I have some issues when using UHD sink and source blocks in same flow graph. When I transmit data with UHD sink, I use tx_sob and tx_eob. I don't get any underflow error. But, the problem is that I can see all data sent by the TX path, in the RX path. I don't understand how this can be possible because when I use tx_sob and tx_eob, I can't be in RX and TX mode in same time. I use a N210 USRP with a WBX daugtherboard. Thanks. Marius -- *CACHELIN Marius* *Ingénieur Systèmes, Réseaux et Télécommunications* marius.cache...@gmail.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.7.8 build problem 'cannot find -lcblas'
Ping? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Experience with Ubuntu 15.04 and Gnuradio 3.7.8
GNURadio 3.7.8 works well on ubuntu 15.04. I used PyBOMBS to install it. On Mon, Aug 17, 2015 at 11:54 AM, Neel Pandeya neel.pand...@ettus.com wrote: Hello John: Ubuntu 15.04 uses the new GCC 5. I haven't yet tried building UHD and GNU Radio with it myself, but maybe there are issues?? Otherwise, I think you should be fine. --Neel On 17 August 2015 at 11:11, John Petrich petr...@u.washington.edu wrote: All, I am considering updating to Ubuntu 15.04 from 14.04 and want to continue with GRC 3.7.8. Anyone with experience using new Ubuntu release and Gnuradio? Regards, John Petrich ___ 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 -- GDB has a 'break' feature; why doesn't it have 'fix' too? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to change PSK roll-off during runtime (or an arbitrary parameter)
Matthias, I can see how this would be a pretty cool demo. Off the top off my head, some thoughts: - The RRC is implemented as a FIR in C++ (a pfb_arb_resampler_ccf, to be precise). But this doesn't have a method to update the taps :/ - An update-able filter would be interesting, though. If you want to take a crack at it, people here would surely be interested. - You'd need to consider how to handle history (what happens when you change the number of filter taps?). Not sure what the best way is here. M On 17.08.2015 07:38, Matthias Weber wrote: Hi all! Thank you for contributing to gnuradio and providing new users like me with help. I have read and worked through some of the guided tutorials. However I come to a point now where it seems that own Python code has to be written. Unfortunately I am more like a C++ guy and would appreciate it if someone could give me some advice. Let us please take a look at the QPSK transmitter example of tutorial 6 [1]. It gives a nice example and you can play around with the parameters of the PSK Mod block in gnuradio-companion. What we would like to do is to change the roll-off factor during runtime using a Qt GUI Range element (i.e. a slider control) to demonstrate its effect. As the associated parameter is not underlined in the properties dialogue I wonder how this can be done during runtime. When looking at the generated sourcecode it can be seen that an instance of `digital.psk.psk_mod` is created in `__init__` method and stored in element `self.digital_psk_mod_0`. I tried to add code in the slider's callback function `def set_excess_bw_slider(self, excess_bw_slider)`. But it does not show changes in constellation and spectrum plot though printing debug messages like `RRC roll-off factor: 0.15` on the command line. I tried: - to access the excess_bw property of the digital.psk.psk_mod directly to be modified - to create a new instance of digital.psk.psk_mod in the callback function and overwriting the original one (in C++ this would be bad practice probably leading to memory leaks and might be the same for Python) I did not really find the documentation of the digital.psk.psk_mod class, except at [2]. And in the sources themselves [3]. A short hint where to take a closer look would be great! Thank you in advance Matthias [1] https://raw.githubusercontent.com/gnuradio/gr-tutorial/master/examples/tutorial6/gr-tutorial-qpsk-tx.grc [2] http://www.reynwar.net/gnuradio/sphinx/digital/blocks.html [3] http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-digital/python/digital/psk.py ___ 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] SDR/USRP devices
Hi Pedro, Buy a RTL dongle, since they're almost free. If it doesn't do what you want, then you'll know more about what you want. Jeff On 08/17/2015 03:09 PM, Marcus Müller wrote: the features are not important for me now Then you can literally buy a rock. It has pretty bad reception, and all receivers built with rocks have a 50% bit error rate. (just kidding) SDR peripherals are technical equipment. There has to be *some* specification of what you need. Like Bandwidth. Make yourself acquinted with the parameters I listed in my last email, and what they mean. Then you will surely come to some conclusion of what you need. I just want to simulate a Cognitive Radio without a lot of details CR doesn't specify what you actually want to do at all, technically. For simulation you'd not need any hardware at all - so maybe you'd want to specify more closely what you want to do! Antony asked about this on Ruby Forum For people finding this later on via Google: This is NOT ruby forum. Ruby forum is nothing but a *bad* interface to the GNU Radio mailing list archives, which you can find at lists.gnu.org, and an even worse implementation of a mailing list client. You're doing it right by using email to communicate with us! Also, there's a lot of Mails going through this mailing list, so I don't know which Antony or which email you are referring to. Best regards, Marcus On 17.08.2015 20:42, Pedro Gabriel Adami wrote: Marcus, Below $120 is okay for me. Actually, the features are not important for me now, because I just want to simulate a Cognitive Radio without a lot of details. I just wanna see it working to study and learn about this process. Like I said, it's important to have a receiver port and be compatible with Gnuradio. I saw that Antony asked about this on Ruby Forum (it seems he has the same interests, but no one could help him, so I came here to the mailing list). Thanks for any help. Cheers, Pedro Gabriel Adami 2015-08-17 15:27 GMT-03:00 Marcus Müller marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com: Hi Pedro, You will, as for any device, need to figure out what you need, specification-wise. I'm obviously a bit biased, but no one else might even be able to help you unless you wrote some numbers: frequencies you're interested in, bandwidth you want to sample at once, stability, available interfaces, cost range etc. Best regards, Marcus Am 17. August 2015 20:13:38 MESZ, schrieb Pedro Gabriel Adami mailto:pedrogabriel.ad...@gmail.compedrogabriel.ad...@gmail.com: Hello, I've been searching a lot about SDR and USRP devices to purchase. All I need is a board with a receiver port (transmitter is not important for now) and it's necessary to be compatible with Gnuradio. There are some options, but I don't have experiency or enough knowledge to choose one of them (I don't know the brands, if they are reliable, etc). I found RTL2838U/R820T2. Is it good? What are the other boards that you know? Sorry about the questions, but I'm kind of new here. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Atenciosamente, Pedro Gabriel Adami ___ 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] Help with building GNU Radio for Android
I am trying to build GNU Radio for Android and am having issues with the build process. I first tried building GNU Radio for Android on Mac OS X 10.10.4. I was able to follow the directions successfully until I had to build gr-grand. When I tried to build gr-grand I got this error (see error 1). I have tried searching for this error, but have not found any useful information from my search. I am not sure if this is an error with the build procedure, or if it is an error with the Android NDK and Python. I then tried building GNU Radio for Android in a Ubuntu 14.04 64 bit VM, but when trying to stage Boost (./b2) I get this output from Boost (see error 2) and get an error about -march=armv7-m not being a supported compiler flag when Boost starts compiling. I have tried adding the toolset=gcc-android to Boost but this did not fix the problem (I had to do this on Mac to get Boost to use the configuration in the user-config.jam file). I would like help getting this working, as I really want to get GNU Radio working on Android for me. Schuyler St. Leger Error 1: [ 80%] Building CXX object swig/CMakeFiles/_grand_swig.dir/grand_swigPYTHON_wrap.cxx.o In file included from /opt/android-toolchain/include/python2.7/Python.h:58:0, from /opt/grandroid/gr-grand/build/swig/grand_swigPYTHON_wrap.cxx:167: /opt/android-toolchain/include/python2.7/pyport.h:1029:2: error: #error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?). #error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?). ^ make[2]: *** [swig/CMakeFiles/_grand_swig.dir/grand_swigPYTHON_wrap.cxx.o] Error 1 make[1]: *** [swig/CMakeFiles/_grand_swig.dir/all] Error 2 make: *** [all] Error 2 Error 2: Performing configuration checks - 32-bit : no - 64-bit : no - arm : no - mips1: no - power: no - sparc: no - x86 : no - combined : no - has_icu builds : no - lockfree boost::atomic_flag : no ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ofdm mod error
Hi! I'm using gnuradio on ZedBoard and was trying a simple OFDM Mod system just like in this video https://www.youtube.com/watch?v=LZDWfnrxo6c the flowgraph just looks like this... random sourceshort to floatofdm modthrottlewx gui fft sink and this comes up... Generating: /home/analog/Documents/top_block.py Executing: /home/analog/Documents/top_block.py Fontconfig warning: ignoring C.UTF-8: not a valid language tag Using Volk machine: neon_hardfp Traceback (most recent call last): File /home/analog/Documents/top_block.py, line 101, in module tb = top_block() File /home/analog/Documents/top_block.py, line 62, in __init__ verbose=None, File /usr/lib/python2.7/dist-packages/gnuradio/digital/ofdm.py, line 95, in __init__ constel = psk.psk_constellation(arity) File /usr/lib/python2.7/dist-packages/gnuradio/digital/psk.py, line 77, in psk_constellation constellation = digital_swig.constellation_psk(points, pre_diff_code, m) AttributeError: 'module' object has no attribute 'constellation_psk' Done I have no idea what to do next... THANKS! :) -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help with building GNU Radio for Android
I am trying to build GNU Radio for Android and am having issues with the build process. I first tried building GNU Radio for Android on Mac OS X 10.10.4. I was able to follow the directions successfully until I had to build gr-grand. When I tried to build gr-grand I got this error (see error 1). I have tried searching for this error, but have not found any useful information from my search. I am not sure if this is an error with the build procedure, or if it is an error with the Android NDK and Python. I then tried building GNU Radio for Android in a Ubuntu 14.04 64 bit VM, but when trying to stage Boost (./b2) I get this output from Boost (see error 2) and get an error about -march=armv7-m not being a supported compiler flag when Boost starts compiling. I have tried adding the toolset=gcc-android to Boost but this did not fix the problem (I had to do this on Mac to get Boost to use the configuration in the user-config.jam file). I would like help getting this working, as I really want to get GNU Radio working on Android for me. Schuyler St. Leger Error 1: [ 80%] Building CXX object swig/CMakeFiles/_grand_swig.dir/grand_swigPYTHON_wrap.cxx.o In file included from /opt/android-toolchain/include/python2.7/Python.h:58:0, from /opt/grandroid/gr-grand/build/swig/grand_swigPYTHON_wrap.cxx:167: /opt/android-toolchain/include/python2.7/pyport.h:1029:2: error: #error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?). #error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?). ^ make[2]: *** [swig/CMakeFiles/_grand_swig.dir/grand_swigPYTHON_wrap.cxx.o] Error 1 make[1]: *** [swig/CMakeFiles/_grand_swig.dir/all] Error 2 make: *** [all] Error 2 Error 2: Performing configuration checks - 32-bit : no - 64-bit : no - arm : no - mips1: no - power: no - sparc: no - x86 : no - combined : no - has_icu builds : no - lockfree boost::atomic_flag : no ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Enveloping a transmit amplifier
Hello, I'm transmitting a fairly bursty, irregularly timed signal. I attach a stream tag to the sample that has the start of the burst (tx_sob). I also have a PA that I can turn on and off that's inbetween my USRP B210 and antenna. I'd like to be able to turn the PA on and off synchronously, say 50 ms before tx_sob is to be transmitted. Is there any way to do this? I'm thinking I could add a new tag that's 50 ms before my transmission but then how would I synchronously turn on the PA? Is there something like a callback function I can use? Does the UHD or the UHD block have this functionality? Thanks for any help, Devin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Implementing a FIR Filter
Hi all, Would someone please recommend a good starting point in C++ source code that demonstrates how one uses the kernel::fir_filter. I started following the pfb_clock_sync method of implementing it, but then realized this had been customized a bit for the polyphase approach. I'm not doing anything fancy, I'm building a modulator and need to pass symbols through a shaping filter. The shaping filter is what I need the FIR filter for. Appreciated, Rich ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.7.8 build problem 'cannot find -lcblas'
Install blas, lapack or something that supplies the missing library. Philip On 08/18/2015 12:54 AM, Barry Jackson wrote: Ping? ___ 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] Implementing a FIR Filter
Rich, hilbert_fc.cc and filter_delay_fc both use kernel::fir_filter in a relatively easy to understand way. Jeff On 08/18/2015 04:26 PM, Richard Bell wrote: Hi all, Would someone please recommend a good starting point in C++ source code that demonstrates how one uses the kernel::fir_filter. I started following the pfb_clock_sync method of implementing it, but then realized this had been customized a bit for the polyphase approach. I'm not doing anything fancy, I'm building a modulator and need to pass symbols through a shaping filter. The shaping filter is what I need the FIR filter for. Appreciated, Rich ___ 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] Follow up: Failure to build GNU Radio on various Ubuntu builds
I have had similar problems with cheap USB cables that work for low-speed devices, but utterly fail for higher-speed transfers. You might as well update to at least Ubuntu 14.04 or even 15.04, Gnu Radio (via build-gnuradio) is known to work in that environment. On 2015-08-18 10:42, Mark wrote: 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] 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
Re: [Discuss-gnuradio] RX/TX transceiver
There's enough leakage between the TX and RX paths (inevitable) that your RX will see your TX side transmissions. On 2015-08-18 03:26, Marius Cachelin wrote: Hi All, I have some issues when using UHD sink and source blocks in same flow graph. When I transmit data with UHD sink, I use tx_sob and tx_eob. I don't get any underflow error. But, the problem is that I can see all data sent by the TX path, in the RX path. I don't understand how this can be possible because when I use tx_sob and tx_eob, I can't be in RX and TX mode in same time. I use a N210 USRP with a WBX daugtherboard. Thanks. Marius -- CACHELIN MARIUS _Ingénieur Systèmes, Réseaux et Télécommunications_ marius.cache...@gmail.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] Links: -- [1] 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] Gradual loss of amplitude as flowgraph runs
Take a look at the phase rotator in the frequency translating FIR filter. Is it done with sine/cos lookups or is it a rotating phasor? Rotating phasors can lose amplitude due to finite precision effects. Matt On Fri, Aug 14, 2015 at 1:57 PM, John Ackermann N8UR j...@febo.com wrote: Still working with the polyphase channelizer program. While everything works, there is something very strange: the output amplitude slowly drops the longer the program runs. As near I can tell, this happens in or following the frequency translating FFT block. To test, I stripped the flowgraph down to the bare minimum and put a frequency display at the output of the UHD block, and another at the output of the fx fft block. By using the max hold feature of the display, I can easily monitor amplitude drop during the program run. I'm using a signal generator to feed the USRP a known signal level (162.475 MHz at -70dBm). In the attached screenshot, the left display is the UHD output, and the right is the fx fft output. The flowgraph had been running for about 5 minutes. The signal out of the fx fft has dropped 20+ dB while the UHD signal level remains the same. The longer the program runs, the further the fx fft output drops. I'm not seeing any error messages on the console to indicate overrun, underrun, or other issues. Due to size limits, I attach only the fft screenshot, but here are all the relevant files: http://www.febo.com/pages/gr-projects/amplitude_loss_test.grc http://www.febo.com/pages/gr-projects/amplitude_loss_test.py http://www.febo.com/pages/gr-projects/amplitude_loss_test_fft.png http://www.febo.com/pages/gr-projects/amplitude_loss_test_flowgraph.png Any idea what could lead to this kind of problem? It seems like some sort of accumulating error, but I'm lost as to what. Thanks, 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
Re: [Discuss-gnuradio] ofdm mod error
Patrcia, try the new OFDM blocks. I suggest starting with the example ofdm_loopback.grc and working from there to see how things work, Cheers, Martin On 17.08.2015 22:39, Patrcia Wonder wrote: Hi! I'm using gnuradio on ZedBoard and was trying a simple OFDM Mod system just like in this video https://www.youtube.com/watch?v=LZDWfnrxo6c the flowgraph just looks like this... random sourceshort to floatofdm modthrottlewx gui fft sink and this comes up... Generating: /home/analog/Documents/top_block.py Executing: /home/analog/Documents/top_block.py Fontconfig warning: ignoring C.UTF-8: not a valid language tag Using Volk machine: neon_hardfp Traceback (most recent call last): File /home/analog/Documents/top_block.py, line 101, in module tb = top_block() File /home/analog/Documents/top_block.py, line 62, in __init__ verbose=None, File /usr/lib/python2.7/dist-packages/gnuradio/digital/ofdm.py, line 95, in __init__ constel = psk.psk_constellation(arity) File /usr/lib/python2.7/dist-packages/gnuradio/digital/psk.py, line 77, in psk_constellation constellation = digital_swig.constellation_psk(points, pre_diff_code, m) AttributeError: 'module' object has no attribute 'constellation_psk' Done I have no idea what to do next... THANKS! :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
