[Discuss-gnuradio] gnu radio installation error
Hi all, I have a problem after cloning the gnuradio .when i execute cmake command i'm getting the below error.i installed all the packages and dependencies CMake Error at volk/CMakeLists.txt:79 Please can anybody help me ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Still missing gnuradio-runtime in OOT modules...
Hi Achilleas, sorry if I write something someone else already suggested; I can't seem to find your previous post, as you seem to have a lot :) However, the problem is usually pkg-config not finding gnuradio runtime. So please run pkg-config --libs gnuradio-runtime This should return something like -Lpath to the libraries -lgnuradio-runtime -lgnuradio-pmt If it does not return successfully, please find your gnuradio-runtime.pc and append its path to the PKG_CONFIG_PATH variable. In theory, this should not be necessary if you installed GNU Radio to the default prefix or used the multiple installations method from the FAQ (http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#The-problem-of-multiple-installs). Hope that helped, Greetings, Marcus On 09/24/2013 01:37 AM, Achilleas Anastasopoulos wrote: I have the latest master installed and tested on a 64bit Fedora 18 . When I generate an OOT module with gr_modtool i still cannot build/compile, since I get the error -- checking for module 'gnuradio-runtime' -- package 'gnuradio-runtime' not found -- Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_LIBRARIES) when I cmake it. I followed the instructions for copying the FindGnuradioRuntime.cmake file as suggested in a previous post but it still does not work for me... Any suggestions? thanks 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] gnu radio installation error
Hi Sadhya, usually, there is a line that follows that error, describing what went wrong. That would be interesting here. Greetings, Marcus On 09/24/2013 08:59 AM, Sandhya G wrote: Hi all, I have a problem after cloning the gnuradio .when i execute cmake command i'm getting the below error.i installed all the packages and dependencies CMake Error at volk/CMakeLists.txt:79 Please can anybody help me ___ 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] gnu radio installation error
Sandhya, please always reply to the list. Maybe remove the formatting, makes things easier on my eyes at least ;) You're still ommitting relevant information. Why did you follow the specific how to make CMake work different systems build guide instead of the official installation / build guide? Using pybombs should take care of all your installation needs. Describe your system... OS, distribution (if applyable), version. Put the build log somewhere (github gist, pastebin, attachement, whatever). How exactly did you install boost? The page you are referring to doesn't say anything about how, but only that you should install boost. Usually, you should be able to get boost via your system's package management (unless you are using windows...). Greetings, Marcus On 09/24/2013 11:13 AM, Sandhya G wrote: hi Marcus Its given volk needs boost to build,But i installed boost package 1.54 as per the link http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork Thanks sandhya On Tue, Sep 24, 2013 at 2:03 PM, Marcus Müller mar...@hostalia.de mailto:mar...@hostalia.de wrote: Hi Sadhya, usually, there is a line that follows that error, describing what went wrong. That would be interesting here. Greetings, Marcus On 09/24/2013 08:59 AM, Sandhya G wrote: Hi all, I have a problem after cloning the gnuradio .when i execute cmake command i'm getting the below error.i installed all the packages and dependencies CMake Error at volk/CMakeLists.txt:79 Please can anybody help me ___ 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 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] Addding enums to custom processing blocks
Hi,
What's the process by which enums are added to the Python namespace via
SWIG in gnuradio? I mean in gr_firdes, the following are added to the
gr.firdes namespace in Python:
enum win_type {
WIN_HAMMING = 0,// max attenuation 53 dB
WIN_HANN = 1,// max attenuation 44 dB
WIN_BLACKMAN = 2,// max attenuation 74 dB
WIN_RECTANGULAR = 3,
WIN_KAISER = 4, // max attenuation variable with beta, google it
WIN_BLACKMAN_hARRIS = 5,
};
But I can't seem to get it to work with my code?
Cheers,
John
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Creating GUI widgets OOT using C++
Hi, I'm currently attempting to create an OOT WX widget. And I'm facing some issue with SWIG (I think). The make method looks like this : wx::sptr wx::make(wxWindow* parent) And the GRC .xml gives as the first argument the 'top_level' (like in other wx elements), which is of the type : grc_gnuradio.wxgui.panel.Panel; proxy of Swig Object of type 'wxPanel *' at 0x3ab9440 and wxPanel is indeed a subclass of wxWindow, however I get : Traceback (most recent call last): File ./top_block.py, line 55, in module tb = top_block() File ./top_block.py, line 32, in __init__ self.guitest_wx_0 = guitest.wx(self.GetWin()) File /opt/gnuradio-3.7/lib64/python2.7/site-packages/guitest/guitest_swig.py, line 111, in make return _guitest_swig.wx_make(*args, **kwargs) TypeError: in method 'wx_make', argument 1 of type 'wxWindow *' So my guess is that SWIG somehow needs to know where/what/how about the wx vs wxPython relation ship ... but I have no idea how. Everything I tried so far resulted in a bunch of errors. For examples, trying to %import the window.i from /usr/include/wx-2.8/wx/i_files/ results in a bunch of errors like : /usr/share/swig/2.0.9/std/std_vector.i:87: Error: Can't copy typemap (directorout) std::vector size_t,std::allocator size_t = std::vector size_t,std::allocator size_t DIRECTOROUT So has anyone ever done something like this ? Even if I manage to create it, the next issue I face is the threading model. I'm playing with OpenGL and OpenCL and essentially everything needs to run from one single thread (which ever was used to create the GL context), and I'm not really sure how to ensure that as a wx widget. Cheers, Sylvain Munaut PS: I'll also need to do the same for Qt as well a bit later so if you have any example of that, feel free to share. Although given it's already C++ in the base widgets, I hope it'll be easier. The threading issue will be the same though, so if you have info on that, please share. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AGC and Dynamic Range of ADC
On 09/23/2013 11:07 PM, bob wole wrote: Can somebody please guide me on this ? Bob On Fri, Sep 20, 2013 at 4:44 PM, bob wole address@hidden wrote: I have USRPN210 with WBX and RFX2400. Is there any AGC chip on N210 motherboard or WBX, RFX2400 before ADC to utilize the dynamic range of ADC ? if yes, which one? If not, then won't the varying input signal (for example signal from moving object) to ADC affect the performance of ADC ? Bob The ADC on an N210 has over 80dB of dynamic range. If that isn't enough, then your application can adjust the RF gain to taste. Only a subset of applications actually benefit from the usual hardware AGC schemes, and such schemes are invariably application-specific, so there's no *automatic* gain control. But your application can dynamically make gain adjustments as it goes. Hi Marcus thanks for response, If there is no automatic gain control then how does it is ensured that ADC doesn't saturate ? I mean what if there is a signal whose amplitude is greater that ADC's highest input level ? Won't it saturate the ADC ? Also what if the signal is too weak to span much of the ADC input voltage, then again we are not using all bits effectively. Guide please. Thanks, Bob -- 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] AGC and Dynamic Range of ADC
On 09/24/2013 10:30 AM, bob wole wrote: On 09/23/2013 11:07 PM, bob wole wrote: Can somebody please guide me on this ? Bob On Fri, Sep 20, 2013 at 4:44 PM, bob wole address@hidden mailto:address@hidden wrote: I have USRPN210 with WBX and RFX2400. Is there any AGC chip on N210 motherboard or WBX, RFX2400 before ADC to utilize the dynamic range of ADC ? if yes, which one? If not, then won't the varying input signal (for example signal from moving object) to ADC affect the performance of ADC ? Bob The ADC on an N210 has over 80dB of dynamic range. If that isn't enough, then your application can adjust the RF gain to taste. Only a subset of applications actually benefit from the usual hardware AGC schemes, and such schemes are invariably application-specific, so there's no *automatic* gain control. But your application can dynamically make gain adjustments as it goes. Hi Marcus thanks for response, If there is no automatic gain control then how does it is ensured that ADC doesn't saturate ? I mean what if there is a signal whose amplitude is greater that ADC's highest input level ? Won't it saturate the ADC ? Also what if the signal is too weak to span much of the ADC input voltage, then again we are not using all bits effectively. Guide please. Thanks, Bob -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org http://www.sbrac.org/ There is nothing to ensure that ADC values are neither too little nor too big. That's up to your application. There's an RF gain control on the WBX, for example, that gives 31.5dB of gain control.If you have very weak signals, then you have to use an external LNA. If your dynamic range requirements exceed the 80dB dynamic range of the ADC, then your application has to account for this, and adjust RF gain accordingly. -- 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] Still missing gnuradio-runtime in OOT modules...
Thanks this solved the problem. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error building gnuradio in arch.
The qa_qtgui module is failing. When I run it manually in gdb and bt after the segfault I get. #0 0x7fffedcd360a in QString::fromLocal8Bit(char const*, int) () from /lib64/libQtCore.so.4 #1 0x7fffedd8fc61 in QCoreApplication::arguments() () from /lib64/libQtCore.so.4 #2 0x7fffee335c3a in ?? () from /lib64/libQtGui.so.4 #3 0x7fffee3367d5 in ?? () from /lib64/libQtGui.so.4 #4 0x7fffec819c38 in _SmcProcessMessage () from /lib64/libSM.so.6 #5 0x7fffec60aa26 in IceProcessMessages () from /lib64/libICE.so.6 #6 0x7fffedda1b48 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /lib64/libQtCore.so.4 #7 0x7fffeddec57e in QSocketNotifier::activated(int) () from /lib64/libQtCore.so.4 #8 0x7fffeddaa92b in QSocketNotifier::event(QEvent*) () from /lib64/libQtCore.so.4 #9 0x7fffee2bd12c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQtGui.so.4 #10 0x7fffee2c36f0 in QApplication::notify(QObject*, QEvent*) () from /lib64/libQtGui.so.4 #11 0x7fffedd8debd in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /lib64/libQtCore.so.4 #12 0x7fffeddbb780 in ?? () from /lib64/libQtCore.so.4 #13 0x7fffed18ad96 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #14 0x7fffed18b0e8 in ?? () from /lib64/libglib-2.0.so.0 #15 0x7fffed18b18c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #16 0x7fffeddbab25 in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib64/libQtCore.so.4 #17 0x7fffee35a266 in ?? () from /lib64/libQtGui.so.4 #18 0x7fffedd913ef in QCoreApplication::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /lib64/libQtCore.so.4 #19 0x7fffef5e97fe in SpectrumGUIClass::openSpectrumWindow(QWidget*, bool, bool, bool, bool) () from /home/scap/code/radio/gnuradio-git/src/gnuradio/build/gr-qtgui/lib/libgnuradio-qtgui-3.7.2git.so.0.0.0 #20 0x7fffef5ee75d in gr::qtgui::sink_c_impl::initialize() () from /home/scap/code/radio/gnuradio-git/src/gnuradio/build/gr-qtgui/lib/libgnuradio-qtgui-3.7.2git.so.0.0.0 #21 0x7fffef5eefc4 in gr::qtgui::sink_c_impl::sink_c_impl(int, int, double, double, std::string const, bool, bool, bool, bool, QWidget*) () from /home/scap/code/radio/gnuradio-git/src/gnuradio/build/gr-qtgui/lib/libgnuradio-qtgui-3.7.2git.so.0.0.0 #22 0x7fffef5ef147 in gr::qtgui::sink_c::make(int, int, double, double, std::string const, bool, bool, bool, bool, QWidget*) () from /home/scap/code/radio/gnuradio-git/src/gnuradio/build/gr-qtgui/lib/libgnuradio-qtgui-3.7.2git.so.0.0.0 #23 0x7fffef8f0aa9 in _wrap_sink_c_make () from /home/scap/code/radio/gnuradio-git/src/gnuradio/build/gr-qtgui/python/qtgui/../../swig/_qtgui_swig.so #24 0x77af8ad4 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #25 0x77afa290 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 #26 0x77af9489 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #27 0x77af9552 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #28 0x77afa290 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 Any ideas? Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AGC and Dynamic Range of ADC
Well that is 80 dB of dynamic range inside the Nyquist zone (at best and let's call it N). I can add a bit of increase in dynamic range by downsampling (filter and decimation) and growing the accumulator size by a bit for each decimation by 4. This will increase dynamic range. I don't believe this is happening to a large extent in the N210 unless it is included in you 80 dB number which I believe is you just doing 14 bits of ADC is 80 dB. Bob On Mon, Sep 23, 2013 at 11:54 PM, Marcus D. Leech mle...@ripnet.com wrote: ** On 09/23/2013 11:07 PM, bob wole wrote: Can somebody please guide me on this ? Bob On Fri, Sep 20, 2013 at 4:44 PM, bob wole bnw...@gmail.com wrote: I have USRPN210 with WBX and RFX2400. Is there any AGC chip on N210 motherboard or WBX, RFX2400 before ADC to utilize the dynamic range of ADC ? if yes, which one? If not, then won't the varying input signal (for example signal from moving object) to ADC affect the performance of ADC ? Bob The ADC on an N210 has over 80dB of dynamic range. If that isn't enough, then your application can adjust the RF gain to taste. Only a subset of applications actually benefit from the usual hardware AGC schemes, and such schemes are invariably application-specific, so there's no *automatic* gain control. But your application can dynamically make gain adjustments as it goes. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Owner and Technical Director, Allied Communication, LLC 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
Re: [Discuss-gnuradio] Endianness in OFDM Implementation
Hello All, I have a question about the implementation of the mapping from an incoming bit-stream to generate an output of frequency-domain OFDM symbols (ofdm_mapper_bcv_impl.cc). Let's say that the incoming bit-stream is '0x00', '0x36', '0x00', '0x36', '0xff', '0x3f', '0x37', '0x27' '0x37'. Converting this from a hex to binary representation, this stream is: 0011 0110 0011 0110 0011 0011 0111 0010 0111 0011 0111. Assuming that we use QAM64, this stream should be broken up into chunks of 6 bits each, to give us: 00 11 011000 00 001101 10 00 11 001101 110010 011100 110111. Once the mapping is done, this should correspond to (at least, in my head) the frequency-domain representation of the 6-bit chunks (shown in Hex below): 0 3 28 0 0d 2f 3c 3f 0d 32 1c 37. But the output from the stock implementation (ofdm_mapper_bcv_impl.cc) is: 1 18 3 0 36 3c 3f f 37 1c 32 d. I know my question has to do with endianness: Is the reference implementation correct? If so, how does one interpret the endianness of the incoming bit-stream? Thanks! Best, Aditya Upon further examination, this does seem like classic little-endianness. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] dual coherent channel rtl_sdr
On 09/23/2013 10:59 AM, Juha Vierinen wrote: I was playing around with the rtl_sdr dongles and came up with a trivial hack to build a receiver with multiple coherent channels. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master rtl dongle to the slave units (I've attached some pictures). You still have to do sample alignment in software, but this is relatively easy. There are a lot of cool applications, such as a dual frequency beacon satellite receiver, interferometry, or passive radar that you can now do with $16. juha So, what were your test conditions? I'm feeding a +3.3dBm signal from a high-precision communications test set at 28.8Mhz to two of those dongles. Then I'm feeding in a 45Mhz sine wave into the two devices RF input through a splitter and variable attenuator. The result is horrible relative-phase-noise between the two channels. They dance all over the place on the scope display. In comparision, a B100 with TVRX2, under the same conditions, works flawlessly, with no appreciable relative phase jitter between the two channels. -- 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] Creating GUI widgets OOT using C++
So after continuing to bang my head against a wall for WX, I decided to try my luck at Qt. That mostly works better. However I tried having my class inherit both from gr_sync block and from QWidget and that doesn't seem to work too well. It seems that my destructor gets called : Breakpoint 2, 0x7fffe07e17c0 in gr::guitest::qt_impl::~qt_impl() () from /opt/gnuradio-3.7/lib64/libgnuradio-guitest.so (gdb) bt #0 0x7fffe07e17c0 in gr::guitest::qt_impl::~qt_impl() () from /opt/gnuradio-3.7/lib64/libgnuradio-guitest.so #1 0x7fffec017332 in ?? () from /usr/lib64/python2.7/site-packages/PyQt4/QtDesigner.so #2 0x751866fb in ?? () from /usr/lib64/python2.7/site-packages/sip.so #3 0x7518a077 in ?? () from /usr/lib64/python2.7/site-packages/sip.so #4 0x7518af73 in ?? () from /usr/lib64/python2.7/site-packages/sip.so #5 0x77afa1ce in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #6 0x77afb955 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0 #7 0x77a8724c in ?? () from /usr/lib64/libpython2.7.so.1.0 #8 0x77a61413 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #9 0x77a7020f in ?? () from /usr/lib64/libpython2.7.so.1.0 #10 0x77a61413 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #11 0x77ab7d86 in ?? () from /usr/lib64/libpython2.7.so.1.0 #12 0x77ab79e8 in ?? () from /usr/lib64/libpython2.7.so.1.0 #13 0x77a61413 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0 #14 0x77af8c4a in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0 #15 0x77afb955 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0 #16 0x77afba82 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0 #17 0x77b15d1c in ?? () from /usr/lib64/libpython2.7.so.1.0 #18 0x77b16b80 in PyRun_FileExFlags () from /usr/lib64/libpython2.7.so.1.0 #19 0x77b1760d in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0 #20 0x77b290ab in Py_Main () from /usr/lib64/libpython2.7.so.1.0 #21 0x7747460d in __libc_start_main () from /lib64/libc.so.6 #22 0x0040091d in _start () But I don't know why !?! ... Is there really no other way than to have a distinct GUI widget class and gr_sync block class and forward everything from one to the other ? Cheers, Sylvain On Tue, Sep 24, 2013 at 3:31 PM, Sylvain Munaut 246...@gmail.com wrote: Hi, I'm currently attempting to create an OOT WX widget. And I'm facing some issue with SWIG (I think). The make method looks like this : wx::sptr wx::make(wxWindow* parent) And the GRC .xml gives as the first argument the 'top_level' (like in other wx elements), which is of the type : grc_gnuradio.wxgui.panel.Panel; proxy of Swig Object of type 'wxPanel *' at 0x3ab9440 and wxPanel is indeed a subclass of wxWindow, however I get : Traceback (most recent call last): File ./top_block.py, line 55, in module tb = top_block() File ./top_block.py, line 32, in __init__ self.guitest_wx_0 = guitest.wx(self.GetWin()) File /opt/gnuradio-3.7/lib64/python2.7/site-packages/guitest/guitest_swig.py, line 111, in make return _guitest_swig.wx_make(*args, **kwargs) TypeError: in method 'wx_make', argument 1 of type 'wxWindow *' So my guess is that SWIG somehow needs to know where/what/how about the wx vs wxPython relation ship ... but I have no idea how. Everything I tried so far resulted in a bunch of errors. For examples, trying to %import the window.i from /usr/include/wx-2.8/wx/i_files/ results in a bunch of errors like : /usr/share/swig/2.0.9/std/std_vector.i:87: Error: Can't copy typemap (directorout) std::vector size_t,std::allocator size_t = std::vector size_t,std::allocator size_t DIRECTOROUT So has anyone ever done something like this ? Even if I manage to create it, the next issue I face is the threading model. I'm playing with OpenGL and OpenCL and essentially everything needs to run from one single thread (which ever was used to create the GL context), and I'm not really sure how to ensure that as a wx widget. Cheers, Sylvain Munaut PS: I'll also need to do the same for Qt as well a bit later so if you have any example of that, feel free to share. Although given it's already C++ in the base widgets, I hope it'll be easier. The threading issue will be the same though, so if you have info on that, please share. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Constellations in OOT projects
I am having issues implementing what was discussed previously. I have
created an OOT module (constellation_theta), and placed it within the
gr::digital namespace. All of the cpp code is written and working fine.
As I am attempting to add a custom constellation, I used the existing
instances of constellations (bpsk, qpsk, etc.) as an example for my
constellation object as far as the swig .i files and the cpp files from the
gr-digital section of the gnuradio gr-digital source for my new module.
When I attempt to run this module, I get the following python runtime
error:
File
/usr/local/lib/python2.7/dist-packages/constellation_theta/constellation_theta_swig.py,
line 102, in module
constellation_theta = constellation_theta.make;
NameError: name 'constellation_theta' is not defined
This line is driven directly from the swig .i file, of which I copied the
format from the .../gnuradio/gr-digital/swig/constellation.i file.
Comparing the generated .py files from the installed swig generated code,
I also do not understand why I have so many differences from this. The
gnuradio code has the cpp class laid out inside the .py file perfectly,
with all of the exposed methods; however, my code has none of that, just
the basic constructor (which I don't even want exposed to preserve the
shared pointer structure).
I am not sure where to go from this point on getting this up and running,
any help would be greatly appreciated.
Thank you very much,
Michael Berman
On Mon, Sep 23, 2013 at 9:21 AM, Michael Berman mrberma...@gmail.comwrote:
Tom,
Thanks for the response. This is what i was thinking was the appropriate
action, I just wanted to make sure. As for the header, I didn't realize I
didn't add one until after I sent the email out; I'll try to not let that
one happen again.
Thanks,
Michael Berman
On Sat, Sep 21, 2013 at 8:09 AM, Tom Rondeau t...@trondeau.com wrote:
On Fri, Sep 20, 2013 at 7:55 PM, Michael Berman mrberma...@gmail.com
wrote:
I am attempting to add a custom constellation class to be used with the
generic_mod_demod object for digital PSK. I have the code working as a
simple addition to the gnuradio source with a re-compilation, however I
would like to set this up similar to an Out Of Tree module (although it
isn't entirely a standalone module). Would the way I go about
approaching
this be the same as the adding an Out Of Tree module tutorial on the
gnuradio website? Or would there be a preferred method than the
gr_modtool.
I would like to set this up so that the code I add sits in the
gr::digital
scope and have everything look as though it all sits in the
constellation.{cc, h, i} files. Does anybody have recommendations for
attacking this task?
Thank you very much,
Michael Berman
Hi Michael,
Please use a proper subject line in the future to help us sort and
keep track of things.
As to your question, that shouldn't be a problem. You should be able
to create a class in your OOT module and inherit from
gr::digital::constellation (or one of it's children). And just putting
it inside the gr::digital namespace. This will obviously now exist in
your own libyourlibrary.so and not in libgnuradio-digital.so. So I'm
not sure what you mean by sits inside constellation.{cc,h,i}. If you
are in an OOT project, you wouldn't be able to add this directly to
the gnuradio-digital library or Python module (ok, there's a way to do
the latter by smashing it in during install, but that's seriously ugly
business that you want no part of).
And use gr_modtool. Definitely the best, easiest, and preferred way of
setting things up. When creating your new class, use 'gr_modtool add'
and for the 'code type' use 'noblock.'
--
Tom
GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Floating point exception (core dumped)
Hello list, 1/ I have been stuck into debugging process of some code, Am getting a: 'Floating point exception (core dumped)' which pop up randomly: In other words, I have tried to find out was that related really to an arithmetic error of division by zero, and I fixed all possibilities of getting the error because of that, however now every possibility of getting division by zero is eliminated I still get the error and worse every time am running the code I get the exception raised from a different place. Reading more on that exception on GR forum, I did not understood how could connecting a packet modulator with a USRP sink, raise such exceptions, (the context is as follows: a mod_pkts_sptr connected to usrp_sink Inside the section of mod_pkts_sptr there is a thread generating packets and sending them continuously) Please, if there is any hints or explanations I will be very pleased, 2/ Apart from that is there any accurate way to ask gdb to locate exactly which instruction is erroneous or which section of the code is causing trouble. 3/ Is that a correct way to connect foo block to a currently described block: opaque_self gr_hier_block2_self(); connect(foo, 0, self(), 0); Regards, -- View this message in context: http://gnuradio.4.n7.nabble.com/Floating-point-exception-core-dumped-tp43810.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] dual coherent channel rtl_sdr
On Sep 24, 2013, at 11:41 AM, Marcus D. Leech mle...@ripnet.com wrote: On 09/23/2013 10:59 AM, Juha Vierinen wrote: I was playing around with the rtl_sdr dongles and came up with a trivial hack to build a receiver with multiple coherent channels. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master rtl dongle to the slave units (I've attached some pictures). You still have to do sample alignment in software, but this is relatively easy. There are a lot of cool applications, such as a dual frequency beacon satellite receiver, interferometry, or passive radar that you can now do with $16. juha So, what were your test conditions? I'm feeding a +3.3dBm signal from a high-precision communications test set at 28.8Mhz to two of those dongles. Then I'm feeding in a 45Mhz sine wave into the two devices RF input through a splitter and variable attenuator. The result is horrible relative-phase-noise between the two channels. They dance all over the place on the scope display. In comparision, a B100 with TVRX2, under the same conditions, works flawlessly, with no appreciable relative phase jitter between the two channels. -- Marcus Leech Marcus, (appreciate you may have done a lot more than your brief description above, but just in case….) The type of cheap 2 pin oscillator used with the Realtek chips will be connected across an internal inverting buffer amplifier in the IC with shunt capacitance and all the circuit goodness that makes such thinks work. If you are going to replace that with a buffered clock source such as a bench signal source or expensive TXCO you're normally going to only drive the crystal input pin and leave the other unconnected….now which pin that is I can;t tell you because the data sheet/schematic isn't available to my knowledge…but hey, its $8 so trial and error! Might also want to consider series termination for each cable to the boards to minimize SI issues also. Of course in Juha's case he's just using the original clock-osc and getting lucky that it's still oscillating cleanly with the two IC's driving the crystal. -Ian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] dual coherent channel rtl_sdr
On Sep 24, 2013, at 1:54 PM, Ian Buckley i...@ionconcepts.com wrote: On Sep 24, 2013, at 11:41 AM, Marcus D. Leech mle...@ripnet.com wrote: On 09/23/2013 10:59 AM, Juha Vierinen wrote: I was playing around with the rtl_sdr dongles and came up with a trivial hack to build a receiver with multiple coherent channels. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master rtl dongle to the slave units (I've attached some pictures). You still have to do sample alignment in software, but this is relatively easy. There are a lot of cool applications, such as a dual frequency beacon satellite receiver, interferometry, or passive radar that you can now do with $16. juha So, what were your test conditions? I'm feeding a +3.3dBm signal from a high-precision communications test set at 28.8Mhz to two of those dongles. Then I'm feeding in a 45Mhz sine wave into the two devices RF input through a splitter and variable attenuator. The result is horrible relative-phase-noise between the two channels. They dance all over the place on the scope display. In comparision, a B100 with TVRX2, under the same conditions, works flawlessly, with no appreciable relative phase jitter between the two channels. -- Marcus Leech Marcus, (appreciate you may have done a lot more than your brief description above, but just in case….) The type of cheap 2 pin oscillator used with the Realtek chips will be connected across an internal inverting buffer amplifier in the IC with shunt capacitance and all the circuit goodness that makes such thinks work. If you are going to replace that with a buffered clock source such as a bench signal source or expensive TXCO you're normally going to only drive the crystal input pin and leave the other unconnected….now which pin that is I can;t tell you because the data sheet/schematic isn't available to my knowledge…but hey, its $8 so trial and error! Might also want to consider series termination for each cable to the boards to minimize SI issues also. Of course in Juha's case he's just using the original clock-osc and getting lucky that it's still oscillating cleanly with the two IC's driving the crystal. -Ian Couple of random application notes on the topic: http://www.maximintegrated.com/app-notes/index.mvp/id/3582 http://www.micrel.com/_PDF/App-Notes/clk/PAN0704111%20-%20Replacing%20Crystals%20and%20Oscillators.pdf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Floating point exception (core dumped)
Hi again, I just realized how to pinpoint the erroneous section from gdb, by doing 'gdb --core=mycoredump ./NeoTx' gdb run It was the gr_diff_encoder_bb::work which cause the exception, I am not initializing the variable of the modulus (the parameter to gr_make_diff_encoder_bb). -- View this message in context: http://gnuradio.4.n7.nabble.com/Floating-point-exception-core-dumped-tp43810p43813.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] dual coherent channel rtl_sdr
On 09/24/2013 04:57 PM, Ian Buckley wrote: Marcus, (appreciate you may have done a lot more than your brief description above, but just in case….) The type of cheap 2 pin oscillator used with the Realtek chips will be connected across an internal inverting buffer amplifier in the IC with shunt capacitance and all the circuit goodness that makes such thinks work. If you are going to replace that with a buffered clock source such as a bench signal source or expensive TXCO you're normally going to only drive the crystal input pin and leave the other unconnected….now which pin that is I can;t tell you because the data sheet/schematic isn't available to my knowledge…but hey, its $8 so trial and error! Might also want to consider series termination for each cable to the boards to minimize SI issues also. Of course in Juha's case he's just using the original clock-osc and getting lucky that it's still oscillating cleanly with the two IC's driving the crystal. -Ian Couple of random application notes on the topic: http://www.maximintegrated.com/app-notes/index.mvp/id/3582 http://www.micrel.com/_PDF/App-Notes/clk/PAN0704111%20-%20Replacing%20Crystals%20and%20Oscillators.pdf Just tried a series termination on each dongle, consisting of a 1000pF cap in series with a 200Ohm resistor on each arm. It still is sane with a +3.3dBm sinusoidal input, but there's no difference in the relative phase-noise between both channels. -- 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] Constellations in OOT projects
Upon looking at the generated *_swig.py files, I am seeing more of the
differences. For some reason my OOT module is not generating the python
wrapper for the constellation_theta class, it is only creating the wrapper
for the shared pointer object. I am curious now as to what the gnuradio
swig interface files are doing elsewhere that are causing that build to
pick up the object files when only the shared pointer is called out in the
swig .i file.
Thank you very much for the help,
Michael Berman
On Tue, Sep 24, 2013 at 1:16 PM, Michael Berman mrberma...@gmail.comwrote:
I am having issues implementing what was discussed previously. I have
created an OOT module (constellation_theta), and placed it within the
gr::digital namespace. All of the cpp code is written and working fine.
As I am attempting to add a custom constellation, I used the existing
instances of constellations (bpsk, qpsk, etc.) as an example for my
constellation object as far as the swig .i files and the cpp files from the
gr-digital section of the gnuradio gr-digital source for my new module.
When I attempt to run this module, I get the following python runtime
error:
File
/usr/local/lib/python2.7/dist-packages/constellation_theta/constellation_theta_swig.py,
line 102, in module
constellation_theta = constellation_theta.make;
NameError: name 'constellation_theta' is not defined
This line is driven directly from the swig .i file, of which I copied the
format from the .../gnuradio/gr-digital/swig/constellation.i file.
Comparing the generated .py files from the installed swig generated code,
I also do not understand why I have so many differences from this. The
gnuradio code has the cpp class laid out inside the .py file perfectly,
with all of the exposed methods; however, my code has none of that, just
the basic constructor (which I don't even want exposed to preserve the
shared pointer structure).
I am not sure where to go from this point on getting this up and running,
any help would be greatly appreciated.
Thank you very much,
Michael Berman
On Mon, Sep 23, 2013 at 9:21 AM, Michael Berman mrberma...@gmail.comwrote:
Tom,
Thanks for the response. This is what i was thinking was the appropriate
action, I just wanted to make sure. As for the header, I didn't realize I
didn't add one until after I sent the email out; I'll try to not let that
one happen again.
Thanks,
Michael Berman
On Sat, Sep 21, 2013 at 8:09 AM, Tom Rondeau t...@trondeau.com wrote:
On Fri, Sep 20, 2013 at 7:55 PM, Michael Berman mrberma...@gmail.com
wrote:
I am attempting to add a custom constellation class to be used with the
generic_mod_demod object for digital PSK. I have the code working as a
simple addition to the gnuradio source with a re-compilation, however I
would like to set this up similar to an Out Of Tree module (although it
isn't entirely a standalone module). Would the way I go about
approaching
this be the same as the adding an Out Of Tree module tutorial on the
gnuradio website? Or would there be a preferred method than the
gr_modtool.
I would like to set this up so that the code I add sits in the
gr::digital
scope and have everything look as though it all sits in the
constellation.{cc, h, i} files. Does anybody have recommendations for
attacking this task?
Thank you very much,
Michael Berman
Hi Michael,
Please use a proper subject line in the future to help us sort and
keep track of things.
As to your question, that shouldn't be a problem. You should be able
to create a class in your OOT module and inherit from
gr::digital::constellation (or one of it's children). And just putting
it inside the gr::digital namespace. This will obviously now exist in
your own libyourlibrary.so and not in libgnuradio-digital.so. So I'm
not sure what you mean by sits inside constellation.{cc,h,i}. If you
are in an OOT project, you wouldn't be able to add this directly to
the gnuradio-digital library or Python module (ok, there's a way to do
the latter by smashing it in during install, but that's seriously ugly
business that you want no part of).
And use gr_modtool. Definitely the best, easiest, and preferred way of
setting things up. When creating your new class, use 'gr_modtool add'
and for the 'code type' use 'noblock.'
--
Tom
GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] dual coherent channel rtl_sdr
On 09/25/2013 12:04 AM, Jared Clements wrote: Hi Marcus, Interesting discussion. I was wondering how well synchronized clocking might work. Was hoping it would work better than it sounds. Could you quantify the level of phase noise you're seeing, like with a power spectral density plot? Just for curiosity's sake? I know of a recently updated OOT module that should have the blocks you need ;-) I was hoping to build a correlating interferometer by modifying several of these dongles to run off the same clock. I may need to rethink the plan. Jared I'll get to that tomorrow night. I just ran a simulation of what I was observing (just because the lab is downstairs, and I'm upstairs). Looks like the best it does is about -40dB/c 75kHz from the carrier. That's bluddy awful. phase_noise_sim.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
