Re: [Discuss-gnuradio] Help with building GNU Radio for Android
On Fri, Aug 21, 2015 at 9:20 AM, devin kelly dwwke...@gmail.com wrote: I found the section of code the python NDK is complaining about: #ifndef LONG_BIT #define LONG_BIT (8 * SIZEOF_LONG) #endif #if LONG_BIT != 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?). #endif So it looks like maybe SIZEOF_LONG is what's really not properly defined. I then found this python mailing list post: https://mail.python.org/pipermail/python-bugs-list/2004-November/026111.html The first poster says that this will limit python to only using glibc systems, which makes total sense here given that Android uses bionic not glibc. What I don't understand is that bionic seems to define LONG_BIT, SIZEOF_LONG etc correctly: https://github.com/android/platform_bionic/blob/d717b1a3e55db9b7625a46bec950e856cc107951/libc/include/sys/limits.h So what's it complaining about? Devin Thanks for that, Devin. I'm still not sure what's going wrong, but I wanted to say that, yes, our model for Android is to try to stay as well within the standard Android system and tools as possible, including using bionic and not an external C library. However, we are also using the GCC libstdc++ that comes with the SDKs. Schuyler, there might have been a change in something in Android (they really don't care about changing things between versions) when building the standalone SDK. Take a look at the options you passed when building that part of the project. Also, make sure you are using GCC 4.8 and NOT 4.9. We have other issues with 4.9. Tom On Thu, Aug 20, 2015 at 10:43 AM, Tom Rondeau t...@trondeau.com wrote: On Mon, Aug 17, 2015 at 7:28 PM, Schuyler St. Leger schuyler.st.le...@gmail.com wrote: 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. We'll have to spend some time looking into this. Most of use working on the Android stuff are using Linux -- generally Ubuntu, either 14.04 or 15.04 (I use both versions, depending on which machine I'm on). This could be a conflict with the installed Python and the one in the SDK, or possibly just a bug in the SDK. Although, now that I think about it, there's no reason to SWIG gr-grand. You'll never use that in Python on Android; we only use the c++ library out, and specifically the static libgnuradio-grand.a library. Maybe try adding the flag -DENABLE_PYTHON=False to the cmake line? 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). Are you sure you want armv7-m? Most of what we're using is armv7-a. But you might just try armv7 instead to use a more generic v7 architecture. Take a look at the gcc man page for a list of supported machines. This might be something you'll need to play around with. 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
Re: [Discuss-gnuradio] Filters in GNU Radio
Yes you will need history set yourself. Just look at how the actual existing FIR block does it ... Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DRM receiver
Thank you so much! On 08/21/2015 10:22 AM, Wang Kang wrote: Hi Marcus, The device is morphy richards drm and dab 27204 radio, and I just found out that amazon has already stopped selling this device. Photo: http://att.newsmth.net/nForum/att/Radio/46380/2256/large -- Wang Kang Blog: http://scateu.me Fingerprint: 011F 0492 97D6 5D75 8AC4 6458 D43F 3CE2 3353 B7BD On Fri, 21 Aug 2015, Marcus Müller wrote: Hi 王康, Do you have a link to an amazon product page? I wasn't able to find a receiver searching for digital radio mondiale on amazon.de or amazon.com. Best regards, Marcus On 20.08.2015 14:38, 王康 wrote: I tried DRM TX using gr-drm created by KIT about two years ago. And it did transmit the right DRM signal and demodulated by Dream software correctly. Then I made a gnuradio flow to feed IQ samples into a fifo using wav file sink, then Dream opened this fifo and demodulate. This method is pretty hacking, I think you can modify the source code of Dream directly, add libuhd support to it, then it can run standalone without gnuradio. Maybe you can buy a commercial DRM receiver from amazon, which will make debug process much more easy. Havard hav...@austad.tv mailto:hav...@austad.tv于2015 年8月20日 周 四20:04写道： Dear List! Does anyone have any experience with using GNURADIO as DRM receiver? Or using Dream as a library to gnuradio? Any help will be nice (= Best regards Havard Austad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] Enveloping a transmit amplifier
For anyone interested I took this to the USRP Users list and got the issue
resolved.
The gist of it was that none of the GPIO code got moved into any of the
releases until UHD 3.9.
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-August/015455.html
On Wed, Aug 19, 2015 at 2:44 PM, devin kelly dwwke...@gmail.com wrote:
I tried this out and I'm having some problems. I'm on GR 3.7.8 and UHD
3.8.5, both the newest as far as I know.
What I did was make a flowgraph with a signal generator source and a UHD
sink in GRC. It works before I made any modifications. There are a few
lines in top_block.py that set the sample rate, antenna, etc. At the end
of them I added this:
self.uhd_usrp_sink_0.set_gpio_attr(TXA, ATR_TX, 1, 0x10, 0)
It should set pin 4 high whenever I transmit (right?). I run my flowgraph
and get this traceback:
Traceback (most recent call last):
File top_block.py, line 76, in module
tb = top_block()
File top_block.py, line 55, in __init__
self.uhd_usrp_sink_0.set_gpio_attr(TXA, ATR_TX, 1, 0x10, 0)
File
/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py, line
4539, in set_gpio_attr
return _uhd_swig.usrp_sink_sptr_set_gpio_attr(self, bank, attr, value,
mask, mboard)
RuntimeError: LookupError: Path not found in tree:
/mboards/0/dboards/A/iface
I know I'm using the right banks because I can do this command:
$ python -c 'from gnuradio import uhd; usrp =
uhd.multi_usrp_sink(serial=removed, uhd.io_type.COMPLEX_FLOAT32, 1);
print usrp.get_gpio_banks(0)'
and get
('RXA', 'TXA')
I also run this command:
uhd_usrp_probe --args='serial=removed' --tree | grep -i iface
and get nothing. Without piping into grep I get 177 lines that all seem
to make sense to me.
Is that command I'm using correct or is there some other issue?
Thanks,
Devin
On Wed, Aug 19, 2015 at 8:09 AM, devin kelly dwwke...@gmail.com wrote:
Marcus,
Thanks for the advice, this seems to do exactly what I'm looking for. My
only question is that I've been under the impression that the UHD doesn't
yet support GPIO for the B210. I did recently upgrade to 3.8.5 though so
maybe things have changed?
Devin
On Wed, Aug 19, 2015 at 5:43 AM, Marcus Müller marcus.muel...@ettus.com
wrote:
Hi Devin,
You wanted to ramp up/down the external PA: Use the GPIO pins, and the
ATR registers [1] or timed commands issued over the message bus [2] to
change their state
Best regards,
Marcus
[1] http://files.ettus.com/manual/page_gpio_api.html#xgpio_fpanel_atr
[2] http://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
On 08/18/2015 09:17 PM, devin kelly wrote:
Hello,
0
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
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
--
http://alum.wpi.edu/~dkelly/
--
http://alum.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DECT voice channel decoding project
On Wed, Aug 19, 2015 at 1:16 PM, Pavel Yazev li...@ruby-forum.com wrote: Dear all, I was working on a project of real-time DECT voice channel decoding. I believe it might be useful for the community. So I have decided to share it. It is available on github with short installation and usage guide: https://github.com/pavelyazev/gr-dect2 -- Best Regards, Pavel Yazev Hi Pavel, I would suggest working to get this into PyBOMBS as a new recipe so we can find it on CGRAN: http://gnuradio.org/redmine/projects/pybombs/wiki http://cgran.org/ Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help with building GNU Radio for Android
I found the section of code the python NDK is complaining about: #ifndef LONG_BIT #define LONG_BIT (8 * SIZEOF_LONG) #endif #if LONG_BIT != 8 * SIZEOF_LONG /* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent * 32-bit platforms using gcc. We try to catch that here at compile-time * rather than waiting for integer multiplication to trigger bogus * overflows. */ #error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?). #endif So it looks like maybe SIZEOF_LONG is what's really not properly defined. I then found this python mailing list post: https://mail.python.org/pipermail/python-bugs-list/2004-November/026111.html The first poster says that this will limit python to only using glibc systems, which makes total sense here given that Android uses bionic not glibc. What I don't understand is that bionic seems to define LONG_BIT, SIZEOF_LONG etc correctly: https://github.com/android/platform_bionic/blob/d717b1a3e55db9b7625a46bec950e856cc107951/libc/include/sys/limits.h So what's it complaining about? Devin On Thu, Aug 20, 2015 at 10:43 AM, Tom Rondeau t...@trondeau.com wrote: On Mon, Aug 17, 2015 at 7:28 PM, Schuyler St. Leger schuyler.st.le...@gmail.com wrote: 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. We'll have to spend some time looking into this. Most of use working on the Android stuff are using Linux -- generally Ubuntu, either 14.04 or 15.04 (I use both versions, depending on which machine I'm on). This could be a conflict with the installed Python and the one in the SDK, or possibly just a bug in the SDK. Although, now that I think about it, there's no reason to SWIG gr-grand. You'll never use that in Python on Android; we only use the c++ library out, and specifically the static libgnuradio-grand.a library. Maybe try adding the flag -DENABLE_PYTHON=False to the cmake line? 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). Are you sure you want armv7-m? Most of what we're using is armv7-a. But you might just try armv7 instead to use a more generic v7 architecture. Take a look at the gcc man page for a list of supported machines. This might be something you'll need to play around with. 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 Yeah, when this is right, you should see 'yes' for 32-bit and arm. FYI, I should be getting a 64-bit ARM soon and will see what changes are necessary there. And if any of this helps and you do get it working, we should try to update the Android wiki page accordingly, either by fixing some of the instructions or with some side notes for these problems. Tom ___ 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] Install UHD on Windows 10 problem.
Hi, I have been trying to install the latest version of UHD on*Windows 10*. I successfully installed , I think, uhd_003.008.005-release_Win64_VS2013.exe. The HTML manual provides detailed instructions to install the USB 3 driver, from a zipped file erllc_uhd_winusb_driver.zip. When I try and install the ini file, using the project manager I get the error: ** Windows encountered a problem installing the driver software for your device Windows found driver software for your device but encountered an error while attempting to install it. Ettus Research LLC B200/B210 The third-party INF does not contain digital signature information. If you know the manufacture of your device, you can visit its website and check the support section for driver software. [Close] * I did not get this error with Windows 8 or even 8.1. Is there a way to install the driver any way as was possible with all previous versions of Windows? Is Microsoft hell bent on breaking all my hardware toys? If so I have no problem wiping out Windows 10 from my SSD. I do not need Windows, Cortana, or any Microsoft stuff. Sorry for the rant. Any suggestions are welcome. Rob javascript:void(0) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help with building GNU Radio for Android
Although, now that I think about it, there's no reason to SWIG gr-grand. You'll never use that in Python on Android; we only use the c++ library out, and specifically the static libgnuradio-grand.a library. Maybe try adding the flag -DENABLE_PYTHON=False to the cmake line? ENABLE_PYTHON is not an available option, and there is no option to disable Python or SWIG (the cmake user settable variables can be listed using -LAH). Are you sure you want armv7-m? Most of what we're using is armv7-a. But you might just try armv7 instead to use a more generic v7 architecture. Take a look at the gcc man page for a list of supported machines. This might be something you'll need to play around with. I made a mistake in copying the error, here is the correct error. Assembler messages: Fatal error: invalid -march= option: `armv7-a' I was able to get Boost to build. The problem is that when arm-linux-androideabi-g++ calls the assembler it looks in the path for as the problem with this is that the assembler for Android is named arm-linux-androideabi-as . To fix this I symlinked arm-linux-androideabi-as to as and android-toolchain/bin needs to be in your path (it should be from setting up the android toolchain). However this must be done after running bootstrap.sh or Boost will fail to build Boost.Build. Running hash -r may be required to get bash to find the correct assembler. The real problem here is that android-toolchain/arm-linux-androideabi/bin/ is empty and not symlinked to the tools in android-toolchain/bin/ like it normally is. I have tried rebuilding the toolchain multiple times, but it is not making the symlinks. I just copied the symlinks from OS X and it works on Ubuntu 14.04 (tested for FFTW). Yeah, when this is right, you should see 'yes' for 32-bit and arm. That is what I got when using OS X with Boost and specifying toolset=gcc-android . How hard would it be to get fosphor working on Android? Schuyler, there might have been a change in something in Android (they really don't care about changing things between versions) when building the standalone SDK. Take a look at the options you passed when building that part of the project. Also, make sure you are using GCC 4.8 and NOT 4.9. We have other issues with 4.9. I am using GCC 4.8. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm mod error
Patrcia, this looks more like you don't have GNU Radio properly installed -- these examples will work fine with a full installation of GNU Radio. Cheers, Martin On 19.08.2015 23:43, Patrcia Wonder wrote: Hi! I think I'm using the latest OFDM blocks. I then tried using the ofdm_loopback.grc and an error occured that is similar to the first one... Showing: /home/analog/Documents/ofdm_loopback.grc Generating: /home/analog/Documents/ofdm_loopback_example.py Executing: /home/analog/Documents/ofdm_loopback_example.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/ofdm_loopback_example.py, line 290, in module tb = ofdm_loopback_example() File /home/analog/Documents/ofdm_loopback_example.py, line 186, in __init__ scramble_bits=False File /usr/lib/python2.7/dist-packages/gnuradio/digital/ofdm_txrx.py, line 187, in __init__ crc = digital.crc32_bb(False, self.packet_length_tag_key) AttributeError: 'module' object has no attribute 'crc32_bb' Done ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OOT Module Attribute Error module object has no attribute 'blockname'
I see the following in the output of nm -C -u: U gr::ACK::Text_Sanitize_impl::forecast(int, std::vectorint, std::allocatorint ) This was the undefined symbol that was causing the module import to fail... as you have discovered yourself. Now that the module import has succeeded you are seeing a different error. This error is because of the following in the generated python file: self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize() Note that this will invoke Text_Sanitize::make which expects a char * message argument. That causes the error message below. For some reason GRC is not adding that parameter in the above statement. Did you add a declaration for that parameter in the XML file ? To verify that the XML file is the issue just try editing the generated python file and changing the above to: self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize(some string) and running it from the command line (run python top_block.py in a terminal window). --Patrick Date: Thu, 20 Aug 2015 11:08:56 -0500 From: lwas...@ostatemail.okstate.edu To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] OOT Module Attribute Error module object has no attribute 'blockname' Nathan and Patrick, Thanks for the tips! I started with running: nm -C -u libgnuradio-modulename.so and the results of that can be found here: https://gist.github.com/loganwashbourne under the nm -C -u libgnuradio-modulename.so file. (I think github thinks I'm a robot so I can't link to the direct page yet). I'll be honest, I'm not really sure what I'm looking at in this return, I do see some error statements but I'm not sure if they are just stating how it would handle an error or if it is an actual error. I really don't think I have any callbacks in my XML code, I just reference certain input variables in the XML code. Next, the ACK_swig.i file can be found here : https://gist.github.com/loganwashbourne under the same file name. I checked it against the gr-tutorial swig file and the only difference was that the ACK_swig.i file included a magic2 function call for each of my OOT blocks(check and Text_Sanitize), while the gr-tutorial didn't. Last thing, I realized that I am creating the forecast function in the Text_Sanitize_impl.h file but not referencing it it the .cc file (I commented it out). I tried commenting out the void deceleration of the forecast function in the .h file but then I get a new error when I try to run the grc file(which is just a constant int source connected to my Text_Sanitize block, which is connected the the message debug print port). The new error is : Traceback (most recent call last): File /home/comm1/Logan/Thesis/top_block.py, line 92, in module tb = top_block() File /home/comm1/Logan/Thesis/top_block.py, line 65, in __init__ self.ACK_Text_Sanitize_0 = ACK.Text_Sanitize() File /usr/local/lib/python2.7/dist-packages/ACK/ACK_swig.py, line 399, in make return _ACK_swig.Text_Sanitize_make(*args, **kwargs) TypeError: Required argument 'message' (pos 1) not found I do apologize for the long questions, if any of you feel like I need to spend more time looking into this myself before asking the mailing list, please don't hesitate to mention it. Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) On Wed, Aug 19, 2015 at 5:06 PM, Patrick Sathyanathan wp...@hotmail.com wrote: Hi Logan, I have faced the same error twice recently in my OOT module and finally tracked it down to two causes. The basic reason for the 'object has no attribute' error is that Python's import of your module failed. In the two cases that I saw it was due to undefined symbols in the shared library for my module. My module was called 'tutorial' so the corresponding library is libgnuradio-tutorial.so and you can find it in the .../build/lib directory. To find out the undefined symbols do the following: nm -C -u libgnuradio-modulename.so and search for method names in your class. So if your class is 'MyClass' you could do: nm -C -u libgnuradio-modulename.so | grep MyClass The two cases that I ran into were: 1. A non-virtual method in my implementation class was undefined because I had forgotten to prefix the method definition with the class name. So the .cc file had void foo(...) instead of void MyClass_impl::foo(...) and foo was compiled as a ordinary function. Then the command above will report MyClass_impl::foo as undefined. 2. The second case I ran into was with defining callbacks in the XML file. If you do then you will need to add matching virtual function declarations in the header file. This is needed for SWIG to work correctly. For my case the callback foo needed a virtual function declaration virtual sometype foo(...) = 0; in the actual class declaration (not the ..._impl version) in the header file. Do you have callbacks ? If this is the issue then you should do a make clean before running make again to force SWIG to run. Hope this helps. --Patrick Date:
Re: [Discuss-gnuradio] GPS Signals recorded IQ samples file
Hi, are you sure you did not see GPS? The problem is that GPS is often below the thermal noise floor and only detectable by the virtue of processing gain. I'd try and take a whole lot of samples (like: 2s worth of samples), and calculate the autocorrelation[1]. You should see peaks at multiples of 1 ms, because that's the spreading code's period. You can also square the signal, then decimate it a bit and FFT it and you'll see peaks at whatever doppler the sat currently has. (so you'll see different peaks for different sats). Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPS Signals recorded IQ samples file
Wang: Sounds good! Thanks! Did you try it? Jean: many many thanks for sharing all the scripts! Your paper has caught my attention. I will print it and read it. Marcus: I was not expecting to see the signal because I already knew it was under noise floor. My conclusion of signal absence was after my GPS receiver was not able to decode it when I replayed it with an USRP. However, due to my little knowledge of GPS, it did not occur to me any other way of searching, so I thank you for your suggestion. I nearly killed my pc with a naive approach. :P I need a wiser one. Sylvain: interesting. I will try that too. Thanks! 2015-08-21 9:07 GMT-03:00 Sylvain Munaut 246...@gmail.com: Hi, are you sure you did not see GPS? The problem is that GPS is often below the thermal noise floor and only detectable by the virtue of processing gain. I'd try and take a whole lot of samples (like: 2s worth of samples), and calculate the autocorrelation[1]. You should see peaks at multiples of 1 ms, because that's the spreading code's period. You can also square the signal, then decimate it a bit and FFT it and you'll see peaks at whatever doppler the sat currently has. (so you'll see different peaks for different sats). Cheers, Sylvain ___ 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] GPS Signals recorded IQ samples file
On Fri, 21 Aug 2015, Francisco Albani wrote: Wang: Sounds good! Thanks! Did you try it? Yeah. It works like a charm, in both HackRF and BladeRF. Jean: many many thanks for sharing all the scripts! Your paper has caught my attention. I will print it and read it. Marcus: I was not expecting to see the signal because I already knew it was under noise floor. My conclusion of signal absence was after my GPS receiver was not able to decode it when I replayed it with an USRP. However, due to my little knowledge of GPS, it did not occur to me any other way of searching, so I thank you for your suggestion. I nearly killed my pc with a naive approach. :P I need a wiser one. Sylvain: interesting. I will try that too. Thanks! 2015-08-21 9:07 GMT-03:00 Sylvain Munaut 246...@gmail.com: Hi, are you sure you did not see GPS? The problem is that GPS is often below the thermal noise floor and only detectable by the virtue of processing gain. I'd try and take a whole lot of samples (like: 2s worth of samples), and calculate the autocorrelation[1]. You should see peaks at multiples of 1 ms, because that's the spreading code's period. You can also square the signal, then decimate it a bit and FFT it and you'll see peaks at whatever doppler the sat currently has. (so you'll see different peaks for different sats). Cheers, Sylvain ___ 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] GPS Signals recorded IQ samples file
Hi Francisco, are you sure you did not see GPS? The problem is that GPS is often below the thermal noise floor and only detectable by the virtue of processing gain. I'd try and take a whole lot of samples (like: 2s worth of samples), and calculate the autocorrelation[1]. You should see peaks at multiples of 1 ms, because that's the spreading code's period. Best regards, Marcus [1] Warning, a 8-million-points autocorrelation might take some CPU power. You might want to apply a bit of FFT magic. On 20.08.2015 04:04, Francisco Albani wrote: Hi! After googling a lot and searching in this lists archive, I couldn't find any recording of IQ samples from GPS signals. I'm trying to record one myself, with no luck so far because (I suspect) of a malfunctioning active antenna. Would anybody with the right equipment be so kind to record some minutes of 4 MHz around 1.57542 GHz and share the recorded iq samples file? Many thanks in advance! Francisco. ___ 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] DRM receiver
Hi Marcus, The device is morphy richards drm and dab 27204 radio, and I just found out that amazon has already stopped selling this device. Photo: http://att.newsmth.net/nForum/att/Radio/46380/2256/large -- Wang Kang Blog: http://scateu.me Fingerprint: 011F 0492 97D6 5D75 8AC4 6458 D43F 3CE2 3353 B7BD On Fri, 21 Aug 2015, Marcus Müller wrote: Hi 王康, Do you have a link to an amazon product page? I wasn't able to find a receiver searching for digital radio mondiale on amazon.de or amazon.com. Best regards, Marcus On 20.08.2015 14:38, 王康 wrote: I tried DRM TX using gr-drm created by KIT about two years ago. And it did transmit the right DRM signal and demodulated by Dream software correctly. Then I made a gnuradio flow to feed IQ samples into a fifo using wav file sink, then Dream opened this fifo and demodulate. This method is pretty hacking, I think you can modify the source code of Dream directly, add libuhd support to it, then it can run standalone without gnuradio. Maybe you can buy a commercial DRM receiver from amazon, which will make debug process much more easy. Havard hav...@austad.tv mailto:hav...@austad.tv于2015 年8月20日 周 四20:04写道： Dear List! Does anyone have any experience with using GNURADIO as DRM receiver? Or using Dream as a library to gnuradio? Any help will be nice (= Best regards Havard Austad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] DRM receiver
Hi 王康, Do you have a link to an amazon product page? I wasn't able to find a receiver searching for digital radio mondiale on amazon.de or amazon.com. Best regards, Marcus On 20.08.2015 14:38, 王康 wrote: I tried DRM TX using gr-drm created by KIT about two years ago. And it did transmit the right DRM signal and demodulated by Dream software correctly. Then I made a gnuradio flow to feed IQ samples into a fifo using wav file sink, then Dream opened this fifo and demodulate. This method is pretty hacking, I think you can modify the source code of Dream directly, add libuhd support to it, then it can run standalone without gnuradio. Maybe you can buy a commercial DRM receiver from amazon, which will make debug process much more easy. Havard hav...@austad.tv mailto:hav...@austad.tv于2015 年8月20日 周 四20:04写道： Dear List! Does anyone have any experience with using GNURADIO as DRM receiver? Or using Dream as a library to gnuradio? Any help will be nice (= Best regards Havard Austad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] GnuRadio: Clock Recovery MM: imu out of bounds
Hi Tom,
Thanks for your help. I've adapted the sample rate of the result coming out of
the low-pass filter now. However, if I decimate much further, my signal becomes
a bit too weak I think.
New chart:
http://imgur.com/mbt288s,etHbYLT#0
New result:
http://imgur.com/mbt288s,etHbYLT#1
Is this a better approach?
The initial error still persists though.
Regards
From: mibo...@hotmail.com
To: t...@trondeau.com
Date: Thu, 20 Aug 2015 09:09:42 +0200
CC: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GnuRadio: Clock Recovery MM: imu out of bounds
Hi Tom,
Thanks for your answer. That's indeed something that I need to think about
more. However, as I understand it, the samples per symbol rate is equal to
(samp_rate / data_rate). My sample rate is 500k, and my data rate (i think) is
only around 100 or 200. See this figure of my (cleaned) signal:
http://imgur.com/8pNqCop
You see that it takes approximately 10 ms to transmit one symbol. This means
100 symbols per second. As I have 500k samples per second, this means 5k
samples per symbol, right?
However, I have tried setting the samples per symbol to 4, just to try, and the
'out of bounds' error still persists.
Regards,
Michael
From: t...@trondeau.com
Date: Wed, 19 Aug 2015 09:41:19 -0400
Subject: Re: [Discuss-gnuradio] GnuRadio: Clock Recovery MM: imu out of bounds
To: mibo...@hotmail.com
CC: discuss-gnuradio@gnu.org
On Wed, Aug 19, 2015 at 2:51 AM, Michael B mibo...@hotmail.com wrote:
I have created a flowgraph, based on an example of Michael Ossmann, which takes
in a signal, and should output bits.I need to use the clock recovery MM block,
which I do not fully understand yet. However, after reading some blogposts, I
am quite sure that I can leave most of the settings default, except for the
Omega one. Here's my flowgraph:
http://imgur.com/pHRXnZu
When running this flowgraph, it gives me the following error:
thread[thread-per-block[5]:block clock_recovery_mm_ff (9)]:
mmse_fir_interpolator_ff: imu out of bounds.
While searching, I stumbled upon this piece of code in the source of GnuRadio:
int imu = (int)rint(mu * NSTEPS);
if((imu 0) || (imu NSTEPS)) {
throw std::runtime_error(mmse_fir_interpolator_ff: imu out of bounds.\n);
}
So, I suspect it is not due to my Omega setting (which might be wrong, I have
to play with that setting), but that it is due to my Mu setting, which is just
the default (0.5). However, I understand that Mu needs to be between 0 and 1,
so I do not really understand what the problem is. Anyone who does?Environment
details:GNU Radio Companion 3.7.7.1Running a GNU Radio live DVD in a virtual
machine (VirtualBox 4.2.12) on Windows 7.Using Volk machine: ssse3_64
Michael,
I don't have an answer, but I can say where you're doing something wrong.
You're samples/symbol (samp_per_sym) is definitely /not/ 2.5k. That's a
massively oversampled signal and can't be right. You need to think what's the
sampling rate of the system? What's the symbol rate of my signal? That will
tell you the samples/symbol you need. It should small, like 2 or 4.
Tom
___
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
