Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts
I installed the binary files gnuradio_3.7.9.2_win64.msi on a Win-8 machine succefullyon the default directory. After running gnuradio-companion file from the Gnuradio 3.7 start menu folder I see a command window opening with message "setting gnuradio environment", then a couple of warnings of the sort: ** (python.exe:5392): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags' ** (python.exe:5392): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags' ** (python.exe:5392): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags' and then the "standard" gnuradio window appears with the import-error warning Cannot import gnuradio. Is the python path environment variable set correctly? All OS: PYTHONPATH Is the library path environment variable set correctly? Linux: LD_LIBRARY_PATH Windows: PATH MacOSX: DYLD_LIBRARY_PATH (DLL load failed with error code -1073741795) --- any thoughts as to what is going wrong? thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC window is expanding to the right as the graph runs...
I observed this weird phenomenon with wx GUI static text: as the program runs the text is sliding to the right, evenually going outside the window... I attach a very simple grc file (run it and increase the window to see the effect) any thoughts? thanks Achilleas test_expanding_window.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-cdma
Ekko, you have asked EXACTLY the same questions on a thread on Nov 2015. I believe I have helped you resolve this. Please follow the same ideas. If you still have problems try to send us ALL the information that was asked of you back then. Achilleas == Message: 13 Date: Fri, 1 Apr 2016 18:08:17 +0800 From: Ekko To: "discuss-gnuradio@gnu.org" Subject: [Discuss-gnuradio] gr-cdma Message-ID: Content-Type: text/plain; charset="utf-8" hello all ,i am using the gr-cdma from https://github.com/anastas/gr-cdma and i followed the README, when i use the gnuradio-companion &, and open the cdma_tx_hier.grc i got some errors with the import Param - Import(import): Bad import syntax: "import cdma.cdma_parameters as cp". how to solve this ,thank you ! --Ekko ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] null source
The work function of null source is
---
int
null_source_impl::work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
void *optr;
for(size_t n = 0; n <* input_items.size()*; n++) { <===
optr = (void*)output_items[n];
memset(optr, 0, noutput_items *
output_signature()->sizeof_stream_item(n));
}
return noutput_items;
}
--
shouldn't the for loop be :
for(size_t n = 0; n < *output_items.size()*; n++) {
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Receiving errors with Viterbi decoder block/Decoding AIM spacecraft
Michael, I haven't seen your flowgraph, but as I wrote in my previous email you are using the fsm constructor probably in the wrong way: You are confusing the (n,k,K) parameters of a CC. k = number of input bits per period n = number of output bits per period K = constraint length of the code (related to the memory it requires) If you want to build a (2,1,*) CC then you need to call the fsm constructor with these two numbers AND a vector of 2x1=2 integers representing the two generator polynomials. (If you think about it the constraint length parameter need not be input to the constructor because it can be derived from the generator polynomials) *fsm::fsm(int k, int n, const std::vector &G)* so in the above example it should be something like *fsm(1,2, * *[79,109])* On the other hand, i don't know if this is what you want to do. If you tell us the exact parameters of the code you want to build I would be able to help more. (the rate of the code 1/2 that you gave in your previous email is not sufficient, because R=1/2=2/4 so a (4,2,*) CC will also have the same rate but it would require you to provide 4 x 2 =8 generator polynomials to construct it). Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Receiving errors with Viterbi decoder block
The problem is not the length 2048 but the way you use the fsm constructor trellis.fsm(2,7,[79,109]) You are trying to create an FSM for a (7,2) CC. This means you need to provide a vector of 2x7 integers, each representing the generator polynomial between the i-th input (i=0,1) to the j-th output (j=0,1,...,6) However you only provide 2 of them. Are you sure this is what you want to do? this is a snippet from fsm.cc //## //# Automatically generate the FSM from the generator matrix //# of a (n,k) binary convolutional code //## fsm::fsm(int k, int n, const std::vector &G) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pybombs and apache thrift help request
I had problems installing thrift myself. After consulting with the thrift forum i realized that thrift requires "trial" which is included in pythong package "twisted" (python-twisted). Unfortunately, thrift was failing silently... After installing this package on fedora-22 (or 23?) the installation of thrift went fine. Somenone can update the pybombs recipie to install python-twisted as a prereq for thrift. best Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-cdma
Another suggestion is to install your gr-cdma exactly where your gnuradio is installed. Achilleas On Mon, Nov 16, 2015 at 9:07 AM, Achilleas Anastasopoulos wrote: > Looking at the output of the cmake I think I know what is going on: > > > Your gnuradio installation is not in the standard directory /usr/local/... > > So probably your PYTHONPATH variable is not set for python to look there. > > You should add the directory > > /usr/local/lib/python2.7/site-packages/ > > > in your PYTHONPATH > > Achilleas > > > > > > On Mon, Nov 16, 2015 at 8:32 AM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > >> Ekko, >> >> Do not worry about grc for now. You first have to fix the python import >> error. >> >> It is very unusual that you have downloaded the gr-cdma in the directory >>"/home/gr-cdma" . >> In the /home directory usually there are user directories and you do not >> have permissions, etc... >> How do you run all these (as root?) you should not... >> >> Please do me a favor and try the following: >> >> As a REGULAR user (ie, not root) go to your home directory (say >> /home/ekko for example) and download gr-cdma there. >> Then change the cdma_parameters.py file to indicate the new >> prefix=/home/ekko/gr-cdma >> >> Finally can you verify that python looks at these directories: >> /usr/local/lib/python2.7/site-packages/ >> If not, you should set your PYTHONPATH. >> >> Also, I wanted to ask you: do you have a working GNURADIO installation? >> Where is it? >> Are your remaining gnuradio blocks also residing in >> /usr/local/lib/python2.7/site-packages/ directory? >> >> >> Achilleas >> >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Nov 16, 2015 at 7:14 AM, chai E >> wrote: >> >>> hello achilleas >>> >>> thank you >>> the next is mine operation and result >>> >>> step1:i modify the cdma_parameters.py >>> vim cdma_parameters.py >>> >>> the result is picture1 >>> i am sure the prefix is right >>> >>> step2: >>> mkdir build_cdma >>> cd build_cdma >>> cmake ../ >>> >>> the result is >>> >>> -- The CXX compiler identification is GNU 4.9.1 >>> -- The C compiler identification is GNU 4.9.1 >>> -- Check for working CXX compiler: /usr/bin/c++ >>> -- Check for working CXX compiler: /usr/bin/c++ -- works >>> -- Detecting CXX compiler ABI info >>> -- Detecting CXX compiler ABI info - done >>> -- Check for working C compiler: /usr/bin/cc >>> -- Check for working C compiler: /usr/bin/cc -- works >>> -- Detecting C compiler ABI info >>> -- Detecting C compiler ABI info - done >>> -- Build type not specified: defaulting to release. >>> -- Boost version: 1.56.0 >>> -- Found the following Boost libraries: >>> -- filesystem >>> -- system >>> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") >>> -- checking for module 'gnuradio-runtime' >>> -- found gnuradio-runtime, version 3.7.7 >>> -- Found GNURADIO_RUNTIME: /usr/lib/libgnuradio-runtime.so >>> Checking for GNU Radio Module: RUNTIME >>> * INCLUDES=/usr/include >>> * >>> LIBS=/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-pmt.so >>> -- Found GNURADIO_RUNTIME: >>> /usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-pmt.so >>> GNURADIO_RUNTIME_FOUND = TRUE >>> Checking for GNU Radio Module: BLOCKS >>> -- checking for module 'gnuradio-blocks' >>> -- found gnuradio-blocks, version 3.7.7 >>> * INCLUDES=/usr/include >>> * >>> LIBS=/usr/lib/libgnuradio-blocks.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-pmt.so >>> -- Found GNURADIO_BLOCKS: >>> /usr/lib/libgnuradio-blocks.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-pmt.so >>> GNURADIO_BLOCKS_FOUND = TRUE >>> Checking for GNU Radio Module: DIGITAL >>> -- checking for module 'gnuradio-digital' >>> -- found gnuradio-digital, version 3.7.7 >>> * INCLUDES=/usr/include >>> * >>> LIBS=/usr/lib/libgnuradio-digital.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-pmt.so >>> -- Found GNURADIO_DIGITAL: >>> /usr/lib/libgnuradio-digital.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnurad
Re: [Discuss-gnuradio] gr-cdma
akeFiles/gnuradio-cdma.dir/chopper_impl.cc.o > [ 26%] Building CXX object > lib/CMakeFiles/gnuradio-cdma.dir/vector_insert2_impl.cc.o > [ 33%] Building CXX object > lib/CMakeFiles/gnuradio-cdma.dir/flag_gen_impl.cc.o > Linking CXX shared library libgnuradio-cdma.so > [ 33%] Built target gnuradio-cdma > Scanning dependencies of target test-cdma > [ 40%] Building CXX object lib/CMakeFiles/test-cdma.dir/test_cdma.cc.o > [ 46%] Building CXX object lib/CMakeFiles/test-cdma.dir/qa_cdma.cc.o > Linking CXX executable test-cdma > [ 46%] Built target test-cdma > Scanning dependencies of target cdma_swig_swig_doc > [ 46%] Built target cdma_swig_swig_doc > Scanning dependencies of target _cdma_swig_swig_tag > [ 53%] Building CXX object > swig/CMakeFiles/_cdma_swig_swig_tag.dir/_cdma_swig_swig_tag.cpp.o > Linking CXX executable _cdma_swig_swig_tag > [ 53%] Built target _cdma_swig_swig_tag > [ 60%] Generating cdma_swig.tag > Scanning dependencies of target cdma_swig_swig_2d0df > [ 66%] Building CXX object > swig/CMakeFiles/cdma_swig_swig_2d0df.dir/cdma_swig_swig_2d0df.cpp.o > Linking CXX executable cdma_swig_swig_2d0df > Swig source > [ 66%] Built target cdma_swig_swig_2d0df > Scanning dependencies of target _cdma_swig > [ 73%] Building CXX object > swig/CMakeFiles/_cdma_swig.dir/cdma_swigPYTHON_wrap.cxx.o > Linking CXX shared module _cdma_swig.so > [ 73%] Built target _cdma_swig > Scanning dependencies of target pygen_swig_36e12 > [ 80%] Generating cdma_swig.pyc > [ 86%] Generating cdma_swig.pyo > [ 86%] Built target pygen_swig_36e12 > Scanning dependencies of target pygen_python_f9c4e > [ 93%] Generating __init__.pyc, cdma_parameters.pyc, > freq_timing_estimator.pyc, kronecker_filter.pyc > [100%] Generating __init__.pyo, cdma_parameters.pyo, > freq_timing_estimator.pyo, kronecker_filter.pyo > [100%] Built target pygen_python_f9c4e > Scanning dependencies of target pygen_apps_9a6dd > [100%] Built target pygen_apps_9a6dd > > this is the result , > > step 4:make install > > -- Install configuration: "Release" > -- Up-to-date: /usr/local/include/cdma/api.h > -- Up-to-date: /usr/local/include/cdma/chopper.h > -- Up-to-date: /usr/local/include/cdma/vector_insert2.h > -- Up-to-date: /usr/local/include/cdma/packet_header2.h > -- Up-to-date: /usr/local/include/cdma/packet_headerparser_b2.h > -- Up-to-date: /usr/local/include/cdma/flag_gen.h > -- Installing: /usr/local/lib/libgnuradio-cdma.so > -- Installing: /usr/local/lib/python2.7/site-packages/cdma/_cdma_swig.so > -- Removed runtime path from > "/usr/local/lib/python2.7/site-packages/cdma/_cdma_swig.so" > -- Installing: /usr/local/lib/python2.7/site-packages/cdma/cdma_swig.py > -- Installing: /usr/local/lib/python2.7/site-packages/cdma/cdma_swig.pyc > -- Installing: /usr/local/lib/python2.7/site-packages/cdma/cdma_swig.pyo > -- Up-to-date: /usr/local/include/cdma/cdma/swig/cdma_swig.i > -- Installing: /usr/local/include/cdma/cdma/swig/cdma_swig_doc.i > -- Up-to-date: /usr/local/lib/python2.7/site-packages/cdma/__init__.py > -- Up-to-date: > /usr/local/lib/python2.7/site-packages/cdma/cdma_parameters.py > -- Up-to-date: > /usr/local/lib/python2.7/site-packages/cdma/freq_timing_estimator.py > -- Up-to-date: > /usr/local/lib/python2.7/site-packages/cdma/kronecker_filter.py > -- Installing: /usr/local/lib/python2.7/site-packages/cdma/__init__.pyc > -- Installing: > /usr/local/lib/python2.7/site-packages/cdma/cdma_parameters.pyc > -- Installing: > /usr/local/lib/python2.7/site-packages/cdma/freq_timing_estimator.pyc > -- Installing: > /usr/local/lib/python2.7/site-packages/cdma/kronecker_filter.pyc > -- Installing: /usr/local/lib/python2.7/site-packages/cdma/__init__.pyo > -- Installing: > /usr/local/lib/python2.7/site-packages/cdma/cdma_parameters.pyo > -- Installing: > /usr/local/lib/python2.7/site-packages/cdma/freq_timing_estimator.pyo > -- Installing: > /usr/local/lib/python2.7/site-packages/cdma/kronecker_filter.pyo > -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/cdma_chopper.xml > -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/cdma_vector_insert2.xml > -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/cdma_message_probe.xml > -- Up-to-date: > /usr/local/share/gnuradio/grc/blocks/cdma_packet_headerparser_b2.xml > -- Up-to-date: > /usr/local/share/gnuradio/grc/blocks/cdma_packet_headerparser_b2_default.xml > -- Up-to-date: /usr/local/share/gnuradio/grc/blocks/cdma_flag_gen.xml > -- Up-to-date: > /usr/local/share/gnuradio/grc/blocks/cdma_kronecker_filter.xml > -- Up-to-date: > /usr/local/share/gnuradio/grc/blocks/cdma_freq_timing_estimator.xml > > > step5:ldconfig > > ldconfig: /usr/lib/libstdc++.so.6.0.20-gdb.py is not an ELF file - it has > th
[Discuss-gnuradio] gr-cdma
Ekko, can you tell me exactly what is the directory where gr-cdma is downloaded (trunk directory) Also can you say what exactly you put in the "prefix=" command in cdma_parameters.py file as per the instruction in the README file: --- 2) Edit the file gr-cdma/python/cdma_parameters.py and set the prefix variable with your gr-cdma trunk directory. Note: this is your git directory prefix not the installation prefix! prefix="YOUR_PREFIX_HERE/gr-cdma" # put the prefix of your gr-cdma trunk -- Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-cdma
Looking at the output of the cmake I think I know what is going on: Your gnuradio installation is not in the standard directory /usr/local/... So probably your PYTHONPATH variable is not set for python to look there. You should add the directory /usr/local/lib/python2.7/site-packages/ in your PYTHONPATH Achilleas On Mon, Nov 16, 2015 at 8:32 AM, Achilleas Anastasopoulos wrote: > Ekko, > > Do not worry about grc for now. You first have to fix the python import > error. > > It is very unusual that you have downloaded the gr-cdma in the directory >"/home/gr-cdma" . > In the /home directory usually there are user directories and you do not > have permissions, etc... > How do you run all these (as root?) you should not... > > Please do me a favor and try the following: > > As a REGULAR user (ie, not root) go to your home directory (say /home/ekko > for example) and download gr-cdma there. > Then change the cdma_parameters.py file to indicate the new > prefix=/home/ekko/gr-cdma > > Finally can you verify that python looks at these directories: > /usr/local/lib/python2.7/site-packages/ > If not, you should set your PYTHONPATH. > > Also, I wanted to ask you: do you have a working GNURADIO installation? > Where is it? > Are your remaining gnuradio blocks also residing in > /usr/local/lib/python2.7/site-packages/ directory? > > > Achilleas > > > > > > > > > > > > > On Mon, Nov 16, 2015 at 7:14 AM, chai E wrote: > >> hello achilleas >> >> thank you >> the next is mine operation and result >> >> step1:i modify the cdma_parameters.py >> vim cdma_parameters.py >> >> the result is picture1 >> i am sure the prefix is right >> >> step2: >> mkdir build_cdma >> cd build_cdma >> cmake ../ >> >> the result is >> >> -- The CXX compiler identification is GNU 4.9.1 >> -- The C compiler identification is GNU 4.9.1 >> -- Check for working CXX compiler: /usr/bin/c++ >> -- Check for working CXX compiler: /usr/bin/c++ -- works >> -- Detecting CXX compiler ABI info >> -- Detecting CXX compiler ABI info - done >> -- Check for working C compiler: /usr/bin/cc >> -- Check for working C compiler: /usr/bin/cc -- works >> -- Detecting C compiler ABI info >> -- Detecting C compiler ABI info - done >> -- Build type not specified: defaulting to release. >> -- Boost version: 1.56.0 >> -- Found the following Boost libraries: >> -- filesystem >> -- system >> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") >> -- checking for module 'gnuradio-runtime' >> -- found gnuradio-runtime, version 3.7.7 >> -- Found GNURADIO_RUNTIME: /usr/lib/libgnuradio-runtime.so >> Checking for GNU Radio Module: RUNTIME >> * INCLUDES=/usr/include >> * >> LIBS=/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-pmt.so >> -- Found GNURADIO_RUNTIME: >> /usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-pmt.so >> GNURADIO_RUNTIME_FOUND = TRUE >> Checking for GNU Radio Module: BLOCKS >> -- checking for module 'gnuradio-blocks' >> -- found gnuradio-blocks, version 3.7.7 >> * INCLUDES=/usr/include >> * >> LIBS=/usr/lib/libgnuradio-blocks.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-pmt.so >> -- Found GNURADIO_BLOCKS: >> /usr/lib/libgnuradio-blocks.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-pmt.so >> GNURADIO_BLOCKS_FOUND = TRUE >> Checking for GNU Radio Module: DIGITAL >> -- checking for module 'gnuradio-digital' >> -- found gnuradio-digital, version 3.7.7 >> * INCLUDES=/usr/include >> * >> LIBS=/usr/lib/libgnuradio-digital.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-pmt.so >> -- Found GNURADIO_DIGITAL: >> /usr/lib/libgnuradio-digital.so;/usr/lib/libgnuradio-runtime.so;/usr/lib/libgnuradio-pmt.so >> GNURADIO_DIGITAL_FOUND = TRUE >> -- checking for module 'cppunit' >> -- found cppunit, version 1.13.1 >> -- Found CPPUNIT: /usr/lib/libcppunit.so;dl >> -- >> -- Checking for module SWIG >> -- Found SWIG version 3.0.2. >> -- Found SWIG: /usr/bin/swig >> -- Found PythonLibs: /usr/lib/libpython2.7.so (found suitable version >> "2.7.3", minimum required is "2") >> -- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.3", >> minimum required is "2") >> -- Looking for sys/types.h >> -- Looking for sys/types.h - found >> -- Looking for stdint.h &g
Re: [Discuss-gnuradio] gr-cdma
Ekko, I can help you with these error messages. They are not supposed to appear. Can you describe in detail the results from the steps you followed to build/install gr-cdma. They are described in the README file of gr-cdma. There are 3 precisely defined steps. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] app crashes with ctrlport enabled. Works fine with ctrlport disabled.
So I have some more info on this: My application had a hierarchical block, inside which I had a block (called "chopper") that was setting the set_output_multiple. This block was the source of the warning: gr::log :WARN: flat_flowgraph - Block (chopper0) max output buffer set to 6656 instead of requested 8192 I don't know why this warning was given (I suspect the size of the output buffer is forced to be a multiple of the set_output_multiple and less than 8192?), but when I reprogrammed the "chopper" block and removed the set_output_multiple from it, neither do I get the warning nor does the application crash (when i run it with controlport on). So i have solved the problem but i have not understood why it crashed in the first place. This may indicate some hidden bug in the code... So the questions are the following: 1) why is it that the flat_flowgraph gives this warning when trying to flatten a hierarchical block which contains a block with a set_output_multiple ? 2) why is it that with this choice of output buffer the application crashes when controlport is activated? best, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] app crashes with ctrlport enabled. Works fine with ctrlport disabled.
I have installed ctrlport and playing around with it. What a great piece of work! thanks guys! I am running an application (cdma_txrx from my gr-cdma module) and I notice that with ctrport enabled it crashes, while without it works perfectly. With ctrport I get the following message that hints at what may be going wrong: gr::log :INFO: controlport - Apache Thrift: -h jefe.eecs.umich.edu -p 59556 gr::log :WARN: flat_flowgraph - Block (chopper0) max output buffer set to 6656 instead of requested 8192 Traceback (most recent call last): File "/home/anastas/gr-cdma/apps/cdma_txrx.py", line 587, in main() File "/home/anastas/gr-cdma/apps/cdma_txrx.py", line 582, in main tb.Start(True) File "/usr/local/lib64/python2.7/site-packages/grc_gnuradio/wxgui/top_block_gui.py", line 74, in Start self.start() File "/usr/local/lib64/python2.7/site-packages/gnuradio/gr/top_block.py", line 109, in start top_block_start_unlocked(self._impl, max_noutput_items) File "/usr/local/lib64/python2.7/site-packages/gnuradio/gr/runtime_swig.py", line 5611, in top_block_start_unlocked return _runtime_swig.top_block_start_unlocked(r, max_noutput_items) RuntimeError: block lookup failed! block not found! Exception in thread Thread-1 (most likely raised during interpreter shutdown):Exception in thread Thread-2 (most likely raised during interpreter shutdown): when i run it without contrlport i still get the warning gr::log :WARN: flat_flowgraph - Block (chopper0) max output buffer set to 6656 instead of requested 8192 but the application runs fine. Can someone suggest what the problem may be, and how to get around it? thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installation with pybombs: still missing python thrift libraries
With some help from the thrift maillist I figured out what the problem was: thrift requires "trial" and this is not part of the pybomb recipies, so thrift fails silently. So after installing "trail" the installation of thrift 0.9.3 manually from the latest source was a breeze. After configuring gnuradio it gives: -- Configuring gr-ctrlport support... -- Dependency Boost_FOUND = 1 -- Dependency SWIG_FOUND = TRUE -- Dependency SWIG_VERSION_CHECK = TRUE -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Enabling gr-ctrlport support. -- Override with -DENABLE_GR_CTRLPORT=ON/OFF -- Looking for C++ include sys/resource.h -- Looking for C++ include sys/resource.h - found -- Loading build date Fri, 16 Oct 2015 00:57:44 into constants... -- Loading version v3.7.8-172-g77083c5d into constants... -- checking for module 'thrift' -- found thrift, version 0.9.3 -- -- Python checking for Thrift -- Python checking for Thrift - found -- Found THRIFT: /usr/local/lib/libthrift.so -- Found and enabling Thrift backend to ControlPort -- Running thrift to build C++ bindings so thrift is recognized. So I guess, trial should be added to the recipie for thrift and a new trial recipie should be created. thanks everyone, Achilleas On Thu, Oct 15, 2015 at 8:04 PM, Francisco Albani < francisco.alb...@gmail.com> wrote: > I'm building gnuradio right now on Arch Linux to get thrift working. Arch > official repositories only have a 'thrift' package [1], which was not > sufficient. > > I had also to install from the Arch User Repository, 'python2-thrift' [2]. > > Now I get the correct cmake output. > > I have never used Fedora, but maybe you can "translate" my solution. > > [1] https://www.archlinux.org/packages/community/x86_64/thrift/ > [2] https://aur.archlinux.org/packages/python2-thrift/ > > 2015-10-15 18:15 GMT-03:00 Chris Kuethe : > >> Clearly I'm not running on a redhat-like system so I don't have any more >> specific advice to offer. What I can suggest is spend some time figuring >> out why the python library isn't able to build. Have a look at the config >> log, grep for errors and google for them, figure out if you're missing some >> some developer libraries/headers, maybe check stackoverflow to see how >> other people have solved it... >> >> On Thu, Oct 15, 2015 at 2:04 PM, Achilleas Anastasopoulos < >> anas...@umich.edu> wrote: >> >>> here is the output of configure for thrift: >>> >>> Building C++ Library . : yes >>> Building C (GLib) Library : yes >>> Building Java Library : no >>> Building C# Library .. : no >>> Building Python Library .. : no >>> Building Ruby Library : no >>> Building Haxe Library : no >>> Building Haskell Library . : no >>> Building Perl Library : no >>> Building PHP Library . : no >>> Building Erlang Library .. : no >>> Building Go Library .. : no >>> Building D Library ... : no >>> Building NodeJS Library .. : no >>> Building Lua Library . : no >>> >>> C++ Library: >>>Build TZlibTransport .. : yes >>>Build TNonblockingServer .. : yes >>>Build TQTcpServer (Qt4) .... : yes >>>Build TQTcpServer (Qt5) : no >>> >>> >>> >>> On Thu, Oct 15, 2015 at 4:36 PM, Chris Kuethe >>> wrote: >>> >>>> I saw something like this at grcon and it was due to an incorrectly set >>>> PYTHONPATH. Thrift installs into .../site-packages, gnuradio installs into >>>> .../dist-packages - make sure both of those are in there. >>>> >>>> On Thu, Oct 15, 2015 at 1:14 PM, Achilleas Anastasopoulos < >>>> anas...@umich.edu> wrote: >>>> >>>>> I attempted a complete installation of gnuradio with pybombs (on >>>>> fedora22). >>>>> It went smoothly, but the result is that although "thrift" executable >>>>> was generated, as well as g_lib and g++ and some other libraries, >>>>> no python related libraries were generated. >>>>> As a result, I get the following (no "*thrift" in the installed >>>>> components) >>>>> >>>>> gnuradio-config-info --enabled-components >>>>> python-support;testing-support;volk;sphinx;gnuradio-runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;* >>>>> alsa;* >>>>> oss;
Re: [Discuss-gnuradio] Installation with pybombs: still missing python thrift libraries
here is the output of configure for thrift: Building C++ Library . : yes Building C (GLib) Library : yes Building Java Library : no Building C# Library .. : no Building Python Library .. : no Building Ruby Library : no Building Haxe Library : no Building Haskell Library . : no Building Perl Library : no Building PHP Library . : no Building Erlang Library .. : no Building Go Library .. : no Building D Library ... : no Building NodeJS Library .. : no Building Lua Library . : no C++ Library: Build TZlibTransport .. : yes Build TNonblockingServer .. : yes Build TQTcpServer (Qt4) : yes Build TQTcpServer (Qt5) : no On Thu, Oct 15, 2015 at 4:36 PM, Chris Kuethe wrote: > I saw something like this at grcon and it was due to an incorrectly set > PYTHONPATH. Thrift installs into .../site-packages, gnuradio installs into > .../dist-packages - make sure both of those are in there. > > On Thu, Oct 15, 2015 at 1:14 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > >> I attempted a complete installation of gnuradio with pybombs (on >> fedora22). >> It went smoothly, but the result is that although "thrift" executable >> was generated, as well as g_lib and g++ and some other libraries, >> no python related libraries were generated. >> As a result, I get the following (no "*thrift" in the installed >> components) >> >> gnuradio-config-info --enabled-components >> python-support;testing-support;volk;sphinx;gnuradio-runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;* >> alsa;* >> oss;gr-comedi;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq >> >> = >> >> I also attempted a separate installation of gnuradio (not with pybombs) >> after manually installing thrift with the same configure options as in >> pybombs ie, >> >> ./configure --prefix=/usr/local \ >> --with-c_glib --with-cpp --with-libevent --with-python \ >> --without-csharp --without-d --without-erlang --without-go \ >> --without-haskell --without-java --without-lua --without-nodejs \ >> --without-perl --without-php --without-ruby --without-zlib \ >> --disable-tests --disable-tutorial $config_opt \ >> CC=$cc CXX=$cxx PY_PREFIX=$prefix CXXFLAGS="-DNDEBUG" >> >> after installation I get >> >> [anastas@jefe ~]$ pkg-config --libs thrift thrift-nb thrift_c_glib >> thrift-z thrift-qt >> -L/usr/local/lib -lthriftnb -lthrift_c_glib -lgobject-2.0 -lglib-2.0 >> -lthriftz -lthriftqt -lthrift >> >> and while cmaking gnuradio I get : >> >> -- >> -- Configuring gr-ctrlport support... >> -- Dependency Boost_FOUND = 1 >> -- Dependency SWIG_FOUND = TRUE >> -- Dependency SWIG_VERSION_CHECK = TRUE >> -- Dependency ENABLE_GNURADIO_RUNTIME = ON >> -- Enabling gr-ctrlport support. >> -- Override with -DENABLE_GR_CTRLPORT=ON/OFF >> -- Loading build date Thu, 15 Oct 2015 20:03:55 into constants... >> -- Loading version v3.7.8-172-g77083c5d into constants... >> -- >> -- Python checking for Thrift >> -- Python checking for Thrift - not found >> -- Could NOT find THRIFT (missing: PYTHON_THRIFT_FOUND THRIFT_FOUND) >> -- TRY_SHM_VMCIRCBUF set to ON. >> -- >> >> Any help is appreciated. >> >> I also attach here the config.log that i get from configuring thrift >> manually >> >> thanks >> Achilleas >> >> >> >> >> >> >> ___ >> 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] Installation with pybombs: still missing python thrift libraries
I wish that were the case. However, on fedora, gnuradio installs on site-packages. In any case, there are NO dist-packages on my system. also from the output of configure (for thrift), it seems that python libraries are NOT even configured for building: thanks Achilleas On Thu, Oct 15, 2015 at 4:36 PM, Chris Kuethe wrote: > I saw something like this at grcon and it was due to an incorrectly set > PYTHONPATH. Thrift installs into .../site-packages, gnuradio installs into > .../dist-packages - make sure both of those are in there. > > On Thu, Oct 15, 2015 at 1:14 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > >> I attempted a complete installation of gnuradio with pybombs (on >> fedora22). >> It went smoothly, but the result is that although "thrift" executable >> was generated, as well as g_lib and g++ and some other libraries, >> no python related libraries were generated. >> As a result, I get the following (no "*thrift" in the installed >> components) >> >> gnuradio-config-info --enabled-components >> python-support;testing-support;volk;sphinx;gnuradio-runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;* >> alsa;* >> oss;gr-comedi;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq >> >> = >> >> I also attempted a separate installation of gnuradio (not with pybombs) >> after manually installing thrift with the same configure options as in >> pybombs ie, >> >> ./configure --prefix=/usr/local \ >> --with-c_glib --with-cpp --with-libevent --with-python \ >> --without-csharp --without-d --without-erlang --without-go \ >> --without-haskell --without-java --without-lua --without-nodejs \ >> --without-perl --without-php --without-ruby --without-zlib \ >> --disable-tests --disable-tutorial $config_opt \ >> CC=$cc CXX=$cxx PY_PREFIX=$prefix CXXFLAGS="-DNDEBUG" >> >> after installation I get >> >> [anastas@jefe ~]$ pkg-config --libs thrift thrift-nb thrift_c_glib >> thrift-z thrift-qt >> -L/usr/local/lib -lthriftnb -lthrift_c_glib -lgobject-2.0 -lglib-2.0 >> -lthriftz -lthriftqt -lthrift >> >> and while cmaking gnuradio I get : >> >> -- >> -- Configuring gr-ctrlport support... >> -- Dependency Boost_FOUND = 1 >> -- Dependency SWIG_FOUND = TRUE >> -- Dependency SWIG_VERSION_CHECK = TRUE >> -- Dependency ENABLE_GNURADIO_RUNTIME = ON >> -- Enabling gr-ctrlport support. >> -- Override with -DENABLE_GR_CTRLPORT=ON/OFF >> -- Loading build date Thu, 15 Oct 2015 20:03:55 into constants... >> -- Loading version v3.7.8-172-g77083c5d into constants... >> -- >> -- Python checking for Thrift >> -- Python checking for Thrift - not found >> -- Could NOT find THRIFT (missing: PYTHON_THRIFT_FOUND THRIFT_FOUND) >> -- TRY_SHM_VMCIRCBUF set to ON. >> -- >> >> Any help is appreciated. >> >> I also attach here the config.log that i get from configuring thrift >> manually >> >> thanks >> Achilleas >> >> >> >> >> >> >> ___ >> 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
[Discuss-gnuradio] pybombs and make, swig
May I ask why pybombs recipies for "make" does not allow for rpm (but only deb or src) and for "swig" it insists only on the 2.0 version? thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problems with gr-perf-monitorx
Tom, thanks; you were right. I am missing thrift... Unfortunately, gnuardio requires 0.9.2 and the latest in fedora 22 is 0.9.1, so i guess i have to wait for this... thanks again, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problems with gr-perf-monitorx
when i run gr-perf-monitorx I get the following: [anastas@jefe gnuradio]$ gr-perf-monitorx Traceback (most recent call last): File "/usr/local/bin/gr-perf-monitorx", line 43, in from gnuradio.ctrlport.GrDataPlotter import * File "/usr/local/lib64/python2.7/site-packages/gnuradio/ctrlport/GrDataPlotter.py", line 26, in from gnuradio.ctrlport.GNURadio import ControlPort ImportError: No module named GNURadio [1]+ Donegnuradio-companion Looking at the package contents of gnuradio.cntrport I see the following PACKAGE CONTENTS GNURadioControlPortClient GrDataPlotter RPCConnection monitor So where is the GNURadio module that it complains about? and why is it not installed? thanks Achilleas PS: I have the latest gnuradio source on a Fedora 22 and all gnuradio packages installed (-- Building for version: v3.7.8-172-g77083c5d / 3.7.9git) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CDMA
Alfred, not all of what you are saying here can be true at the same time! In your previous email you said that gr-cdma is downloaded in "\home\gr-cdma" Now you are saying that this directory is actually "/home/alfred/gr-cdma" which is correct anyway? if the latter, then you have to set your prefix in the cdma_parameters file equal to "/home/alfred/gr-cdma/" Do that and then retry to import it in python. Also, as has been mentioned numerous times on this list, I strongly advise you to NOT do all these as root but as a regular user. Achilleas On Tue, Sep 29, 2015 at 9:36 AM, alfred noble wrote: > Thank you Achilleas > about permission , yes I am doing it as root > I opened the terminal in gr-cdma directory and ran 'ls -l' command as you > said , and I see all files and folder in this directory such as app , cmake > and also python and other , then in the same terminal I ran the command > 'pwd' and I received the following , > /home/alfred/gr-cdma > > Thanks > Alfred > > > On Tue, Sep 29, 2015 at 4:21 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > >> can you go inside the gr-cdma directory and do "ls -l". >> you should see several directories like apps, python etc. >> Now do "pwd" in the linux prompt and let us know the result. >> >> On Tue, Sep 29, 2015 at 8:43 AM, alfred noble >> wrote: >> >>> Thanks >>> My operating system is Ubuntu 15.04 64 bit >>> >>> Alfred >>> >>> On Tue, Sep 29, 2015 at 3:49 PM, Achilleas Anastasopoulos < >>> achilleas.anastasopou...@gmail.com> wrote: >>> >>>> What operating system are you working on? >>>> >>>> Achilleas >>>> >>>> On Sep 29, 2015, at 2:22 AM, alfred noble >>>> wrote: >>>> >>>> Thanks >>>> when I did git clone https://github.com/anastas/gr-cdma.git >>>> the file (gr-cdma) was downloaded in the following directory >>>> home\gr-cdma >>>> as it was expected >>>> >>>> Best regards >>>> Alfred >>>> >>>> >>> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CDMA
and may i ask how is it possible that you download a file in the /home/ directory for which you do not have permissions? are you doing it as root? On Tue, Sep 29, 2015 at 8:43 AM, alfred noble wrote: > Thanks > My operating system is Ubuntu 15.04 64 bit > > Alfred > > On Tue, Sep 29, 2015 at 3:49 PM, Achilleas Anastasopoulos < > achilleas.anastasopou...@gmail.com> wrote: > >> What operating system are you working on? >> >> Achilleas >> >> On Sep 29, 2015, at 2:22 AM, alfred noble >> wrote: >> >> Thanks >> when I did git clone https://github.com/anastas/gr-cdma.git >> the file (gr-cdma) was downloaded in the following directory >> home\gr-cdma >> as it was expected >> >> Best regards >> Alfred >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CDMA
can you go inside the gr-cdma directory and do "ls -l". you should see several directories like apps, python etc. Now do "pwd" in the linux prompt and let us know the result. On Tue, Sep 29, 2015 at 8:43 AM, alfred noble wrote: > Thanks > My operating system is Ubuntu 15.04 64 bit > > Alfred > > On Tue, Sep 29, 2015 at 3:49 PM, Achilleas Anastasopoulos < > achilleas.anastasopou...@gmail.com> wrote: > >> What operating system are you working on? >> >> Achilleas >> >> On Sep 29, 2015, at 2:22 AM, alfred noble >> wrote: >> >> Thanks >> when I did git clone https://github.com/anastas/gr-cdma.git >> the file (gr-cdma) was downloaded in the following directory >> home\gr-cdma >> as it was expected >> >> Best regards >> Alfred >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CDMA
OK, now tell us which directory is your gr-cdma downloaded to? Ie, when you did > git clone https://github.com/anastas/gr-cdma.git where was this downloaded to? Achilleas On Mon, Sep 28, 2015 at 3:47 PM, alfred noble wrote: > Thank you for your immediate respond > the variable "prefix" in my cdma_parameters.py has the following value . > > prefix="/home/gr-cdma" # put the prefix of your gr-cdma trunk > I opened that file and searched for the word "prefix" using Ctrl + f > shortcut then I attached that file below . > > will be waiting for your reply > Thanks in advanced > Alfred > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CDMA
Clearly, you have an issue with importing the cdma module into python. Can you tell me what is the value of the variable "prefix" in your cdma_parameters.py file? (you can find it in gr-cdma/python/ directory) Achilleas On Mon, Sep 28, 2015 at 2:47 PM, alfred noble wrote: > Thanks > I opened the terminal in gr-cdma folder and ran the following command > "python" > after that I ran this : > "from cdma import cdma_parameters as cp" > as you told me , > I received this , > > CDMA PARAMETERS : for adaptive modulation > bits_per_header= 36 > symbols_per_header= 36 > > > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.7/dist-packages/cdma/__init__.py", line 34, > in > import cdma_parameters > File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_parameters.py", > line 122, in > bits_per_coded_symbol=[int(math.log(trellis.fsm(fsm[i]).O(),2)) for i > in range(len(payload_mod))] > File > "/usr/local/lib/python2.7/dist-packages/gnuradio/trellis/trellis_swig.py", > line 471, in __init__ > this = _trellis_swig.new_fsm(*args) > RuntimeError: fsm::fsm(const char *name): file open error > > I really appreciate your help if could help me here once again > thank you in advance > > Alfred > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CDMA
open a python interpreter > python and write >>> from cdma import cdma_parameters as cp WHAT DO YOU GET? if you get an error, ie, something like: Traceback (most recent call last): File "", line 1, in ImportError: No module named cdma Then you have not set correctly the PYTHONPATH in your system, so python does not know where to search to load the cdma module. Achilleas On Mon, Sep 28, 2015 at 10:00 AM, alfred noble wrote: > Thank you one more Achilleas you are of great help to me. > > but the problem is that when I open the "file *amp_var_est_hier.grc" > manually I don't have any errors then I compile and reload the blocks > successfully , but when I close this file and open the file > "cdma_tx_hier.grc**" I can NOT compile it since there are so many errors > in this file. * > *I send you the picture of GNURadio companion when the second file , is > open in its environment * > *as an example in the 'import' block I have the following error. * > *"**Param - Import(import):* > * Bad import syntax: "import cdma.cdma_parameters as cp".**"* > *and along with some other errors that are visible in the attached > picture. * > > *last but NOT least , I never meant to disrespect anyone, specially you > *Achilleas. > I just wanted to clarify my problem completely and vividly . > > sincerely > Alfred > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CDMA
You open the corresponding file in gnuradio and then you press the button that looks like a pyramid and a sphere with an arrow between them (this compiles the file). Then you should press the button that looks like a circular arrow (this reloads the blocks). You should read at least the gnuradio companion tutorial before asking these trivial questions in the list. It shows respect for other peoples' time. Achilleas On Sun, Sep 27, 2015 at 3:39 PM, alfred noble wrote: > Thank you Achilleas I really appreciate your responsibility > The problem is that I don't know how to Load hier blocks in GNURadio > environment and I don't really understand what I should do to compile the > blocks one at the time and reload them one by one. > > Thanks > Alfred > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CDMA
PLEASE PROCEED WITH THE REMAINING OF THE README FILE INSTRUCTIONS! ... In the gnuradio-companion environment -- Load the hier blocks (compile one at a time and reload each time) "amp_var_est_hier.grc", "cdma_tx_hier.grc", "chopper_correlator.grc", "cdma_rx_hier.grc", "cdma_tx_hier1.grc", "cdma_rx_hier1.grc" and compile them -- Reload all blocks in grc .. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CDMA
This is perfectly normal. Please continue with step 3 as detailed in the README file. Let us know if you have any further problems. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cdma_txrx
Let's try to investigate the error messages you are receiving. When you run cdma_txrx.grc and you lower the SNR (the first slider) then the receiver cannot anymore track/acquire the packet and a message appears on the screen: *** MESSAGE DEBUG PRINT ((packet_num . 711) (packet_len . 54)) *** MESSAGE DEBUG PRINT ((packet_num . 712) (packet_len . 54)) INFO: Detected an invalid packet at item 25668 *** MESSAGE DEBUG PRINT #f *** MESSAGE DEBUG PRINT ((packet_num . 714) (packet_len . 54)) *** MESSAGE DEBUG PRINT ((packet_num . 715) (packet_len . 54)) When the SNR is up again the receiver goes back to acquisition/tracking and recovers the remaining messages. This is how the system is supposed to work. BTW, the messages titled "*** MESSAGE DEBUG PRINT " are coming from the message debug block, while the messages "INFO: Detected an invalid packet at item 25668" are coming from the packet_headerparser_b block. So far so good. Now, if you want to run the cdma system with an actual usrp you should use the two SEPERATE files: cdma_tx.grc and cdma_rx.grc For this you can disable the fifo sink/source and enable the already present usrp blocks. Suppose you do all these. Then you run the tx and the rx applications. Now you are saying the what you see is a message like this: Sgr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at item 0 *** MESSAGE DEBUG PRINT #f Clearly the first line is coming from the block packet_headerparser_b0 and the other 3 from the message_debug block. (why is does the first log message have a different fromat than above? ie, why does it start with "Sgr::log :"--I don't know ... ) Neither seems to be a surprise (according to the previous discussion). So the question is why the application stops (DOES IT STOP?) For this you have to help us a little bit. Can you figure out which process/thread stops? It is interesting that the error happens at the very first sample 0. Can you run JUST the cdma_rx.py and report the messages you are seeing. Also using a debugger can you identify the thread that hangs. thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CDMA
Alfread, I am willing to help you get started with this. Let's take the README file and go over the "For the impatient:" section. Which of the steps have you completed? Achilleas For the impatient: 1) Download gr-cdma from github > git clone https://github.com/anastas/gr-cdma.git 2) Edit the file gr-cdma/python/cdma_parameters.py (line 97) and set the prefix variable with your gr-cdma trunk directory. prefix="YOUR_PREFIX_HERE/gr-cdma" # put the prefix of your gr-cdma trunk 2) Build the package > mkdir build_cdma > cd build_cdma > cmake -DENABLE_DOXYGEN=ON ../gr-cdma > make > sudo make install > sudo ldconfig 3) compile hierarchical blocks and play with built in app > cd gr-cdma/apps > gnuradio-companion & In the gnuradio-companion environment -- Load the hier blocks (compile one at a time and reload each time) "amp_var_est_hier.grc", "cdma_tx_hier.grc", "chopper_correlator.grc", "cdma_rx_hier.grc", "cdma_tx_hier1.grc", "cdma_rx_hier1.grc" and compile them -- Reload all blocks in grc -- Load the application "cdma_txrx.grc" or "cdma_txrx1.grc" and have fun Experiment with manual acq/tra, auto acq/tra, changing freq and timing offset, SNR, modulation/coding type, etc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis
Sean,
I guess there was a missing normalization of the pulse.
Please add the line
p=p/sum(p)*Q/2.0;
just after the definition of the p pulse
p = numpy.ones(L*Q)
In addition, make sure you increase the Q (samples per symbol)
considerably, ie make it 16 or more. The reason is that h=25/3 results in a
BIG bandwidth for this constellation so it has to be appropriately samples
in order to be represented accurately.
let me know how it goes
Achilleas
On Thu, Sep 10, 2015 at 6:09 PM, Nowlan, Sean
wrote:
> Thanks, Achilleas, Jan, Jeff for your responses. I think I understand the
> format now, and I managed to build the gr-trellis documentation, which does
> spell out answers for a lot of what I asked.
>
>
>
> I’ve abandoned making my own FSM since I can just use the CPM utilities in
> gr-trellis. However, I’m getting unexpected BER and PER when running
> gr-trellis/examples/python/test_cpm.py with my CPFSK parameters, h = 25/3
> and L=1.
>
>
>
> Diff of test_cpm.py with my simple modifications:
>
> https://gist.github.com/nowls/5b2bc2aada87dc197e3f
>
>
>
> $ python test_cpm.py
>
> Using Volk machine: avx_64_mmx_orc
>
> 100 16868 100 0.16868 1.0
>
> 200 33852 200 0.16926 1.0
>
> 300 50786 300 0.16928667 1.0
>
> 400 67667 400 0.1691675 1.0
>
> […]
>
>
>
> As you can see, PER is 100% and BER is pretty bad for 10 dB SNR. The
> construction of the phase response, q, looks correct to me. Any idea what
> might be going wrong?
>
>
>
> Thanks,
>
> Sean
>
>
>
> *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On
> Behalf Of *Achilleas Anastasopoulos
> *Sent:* Thursday, September 10, 2015 1:28 PM
> *To:* Discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi
> algorithm using gr-trellis
>
>
>
> Sean,
>
> I just wanted to add to the previous answer:
>
> Indeed gr-trellis (and the fsm class specifically) has a built in
> constructor for generating the FSM corresponding to ANY CPM scheme.
>
> It only requires three parameters as explained in the comments
>
> in the file fsm.cc
>
> The constructed FSM is NOT based on Proakis decomposition, but on the more
> elegant decomposition by:
> "A decomposition approach to CPM", IEEE Trans. Info Theory, March 1988
> See also my own notes at
> http://www.eecs.umich.edu/~anastas/docs/cpm.pdf
>
> for all the details.
>
> In this case for h=K/P, it does not matter whether K is even or odd, the
> number of states is always = M^{L-1} * P (where M is the cardinality of the
> input alphabet),
>
> so in your case you'll have a trellis with 3 states as the previous email
> suggested.
>
> You may also find useful the python utility
>
> make_cpm_signals(K,P,M,L,q,frac)
>
> that can be found in gr-trellis/python
>
> that generates the signal space for you.
>
> (please see the above references for more info).
>
> Finally, you can take a look at the example "test_cpm.py"
>
> in the gr-trellis/examples/python
>
> and make appropriate changes for your CPFSK signal.
>
>
>
>
> Now you can always drop all the above and design your FSM and signals from
> scratch. You can create the FSM from a file (this is explained in the
> gr-trellis documentaion--which is generated from
> gr-trellis/doc/gr-trellis.xml).
>
> The ouput symbol mapping is defined EXACTLY as you suggested in your email:
>
> every line corresponds to the current state and every column to an input.
>
> The entry is a number from 0 to I-1 (where I is the input cardinality).
>
> How this index is translated to an actual signal IS NOT PART OF THE FSM
> DEFINITION but part of the modulation definition as explained very
> extensively in the gr-trellis documentation.
>
>
>
> let me know if you have any further questions,
>
> Achilleas
>
>
>
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis
One quick correction on my previous email: every line corresponds to the current state and every column to an input. The entry is a number from 0 to O-1 (where O is the output alphabet cardinality). How this index is translated to an actual signal IS NOT PART OF THE FSM DEFINITION but part of the modulation definition as explained very extensively in the gr-trellis documentation. best Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis
Sean,
I just wanted to add to the previous answer:
Indeed gr-trellis (and the fsm class specifically) has a built in
constructor for generating the FSM corresponding to ANY CPM scheme.
It only requires three parameters as explained in the comments
in the file fsm.cc
The constructed FSM is NOT based on Proakis decomposition, but on the more
elegant decomposition by:
"A decomposition approach to CPM", IEEE Trans. Info Theory, March 1988
See also my own notes at
http://www.eecs.umich.edu/~anastas/docs/cpm.pdf
for all the details.
In this case for h=K/P, it does not matter whether K is even or odd, the
number of states is always = M^{L-1} * P (where M is the cardinality of the
input alphabet),
so in your case you'll have a trellis with 3 states as the previous email
suggested.
You may also find useful the python utility
make_cpm_signals(K,P,M,L,q,frac)
that can be found in gr-trellis/python
that generates the signal space for you.
(please see the above references for more info).
Finally, you can take a look at the example "test_cpm.py"
in the gr-trellis/examples/python
and make appropriate changes for your CPFSK signal.
Now you can always drop all the above and design your FSM and signals from
scratch. You can create the FSM from a file (this is explained in the
gr-trellis documentaion--which is generated from
gr-trellis/doc/gr-trellis.xml).
The ouput symbol mapping is defined EXACTLY as you suggested in your email:
every line corresponds to the current state and every column to an input.
The entry is a number from 0 to I-1 (where I is the input cardinality).
How this index is translated to an actual signal IS NOT PART OF THE FSM
DEFINITION but part of the modulation definition as explained very
extensively in the gr-trellis documentation.
let me know if you have any further questions,
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM and Chunks_to_Symbol
Every memoryless modulation scheme can be described as M vectors in an N-dimensional space. So the chunck-to-symbols requires as dimensionality parameter the N and then it needs this array of numbers s11, s12, ... s1N, s21, s22, s2N, ... SM1, sM2, ... sMN So a 2-dim orthogonal scheme is N=2 table = 1 ,0, 0, 1 Achilleas On Mon, Jul 6, 2015 at 1:39 AM, Salija P wrote: > Hello, >How can I specify symbol table and dimension for QAM in > chunks_to_symbol block? which modulation is indicating in fsm_utils.py by > orth2 orth4? > Can anybody help me. I am new to this GnuRadio. > ThankYou > > > > > > > > > With Regards, > Salija.P > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PCCC Decoder Combo- OFDM
Pccc decoder combo requires the modulation as a parameter because it needs to evaluate soft decisions from the noisy complex QPSK signal that it receives. In that sense, it is NOT doing demodulation, as it is not supposed to... I don't know what the OFDM demodulator does, but if there is a way to get the frequency/phase corrected QPSK signal out of it then you can feed it to the pccc decoder (with appropriate "scaling" parameter) and perform decoding. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Verifying Turbo encoder output (was: Re: (no subject)
Salija,
the notation
interleaver(666)
is one way to generate a random interleaver with a given seed (666 in this
case).
The pccc block requires two FSM (finite state machine) specifications (one
for each of the constituent codes)
and an interleaver specification.
You can give the interleaver specification either through a file or by
letting gnuradio generate a random one.
The interleaver class (pretty straighforward) has been implemented in the
files:
gr-trellis/include/trellis/gnuaradio/interleaver.h
gr-trellis/lib/interleaver.cc
I am copying the class definition below:
--
/*!
* \brief INTERLEAVER class
* \ingroup trellis_coding_blk
*/
class TRELLIS_API interleaver
{
private:
int d_K;
std::vector d_INTER;
std::vector d_DEINTER;
public:
interleaver();
interleaver(const interleaver & INTERLEAVER);
interleaver(int K, const std::vector & INTER);
interleaver(const char *name);
interleaver(int K, int seed);
int K () const { return d_K; }
const std::vector & INTER() const { return d_INTER; }
const std::vector & DEINTER() const { return d_DEINTER; }
void write_interleaver_txt(std::string filename);
};
as you can see there are 5 possible constructors:
interleaver();
interleaver(const interleaver & INTERLEAVER);
interleaver(int K, const std::vector & INTER);
interleaver(const char *name);
interleaver(int K, int seed);
the first 2 are trivial and copy constructor,
the third construct an interleaver from a vector with specified
permutations and
the fourth one from a file with specified permutations.
The last one constructs it from a random permutation with a given seed
(please see .cc code for details).
Let us know if you have any more questions.
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Verifying Turbo encoder output (was: Re: (no subject))
Salija, since you are working with gr-trellis it is a good idea to run the examples given in the "examples" directory. You can always manually test the examples if you are willing to do the calculations yourself. All you need is the specification of the trellis that makes the 2 constituent encoders and the interleaver. However this is a very tedious task (unless the code is very short (say 10 bits)). Is there a reason why you need to do this manually? Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] (no subject)
Salija, can you specify which blocks are you working with? Are they in gr-trellis or in gr-fec? If the former I can help you (since I wrote most of it). best, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] control port on 3.7.8 ?
OK, so cmake cannot find thrift, which is reasonable because i didn't build it... So, I followed the instructions on building thrift and configure returns thrift 0.9.2 Building C++ Library . : no Building C (GLib) Library : yes Building Java Library : yes Building C# Library .. : no Building Python Library .. : yes Building Ruby Library : no Building Haskell Library . : no Building Perl Library : no Building PHP Library . : yes Building Erlang Library .. : no Building Go Library .. : no Building D Library ... : no Building NodeJS Library .. : no Building Lua Library . : no Java Library: Using javac ... : javac Using java : java Using ant . : /usr/bin/ant Python Library: Using Python .. : /usr/bin/python PHP Library: Using php-config .. : If something is missing that you think should be present, please skim the output of configure to find the missing component. Details are present in config.log. == Is the C++ library necessary? The config.log file says that it needs boost 1.54.0 or greater, for some files. Can this be the reason the C++ library is not built? thanks Achilleas On Wed, May 6, 2015 at 1:39 PM, Tom Rondeau wrote: > On Wed, May 6, 2015 at 1:27 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > >> After pulling the latest version of gnuradio, and remaking/installing/etc >> I am trying to run the application "pfb_sync_test.grc" in the examples >> directory of control port. >> It is giving me the following error: >> >> >> Executing: >> "/home/anastas/gnuradio_trunk/gr-blocks/examples/ctrlport/pfb_sync_test_qt.py" >> >> Using Volk machine: sse4_1_64_orc >> ControlPort Monitor running. >> Traceback (most recent call last): >> File >> "/home/anastas/gnuradio_trunk/gr-blocks/examples/ctrlport/pfb_sync_test_qt.py", >> line 233, in >> (tb.blocks_ctrlport_monitor_0).start() >> File >> "/usr/local/lib64/python2.7/site-packages/gnuradio/ctrlport/monitor.py", >> line 48, in start >> print "monitor::endpoints() = %s" % (gr.rpcmanager_get().endpoints()) >> AttributeError: 'NoneType' object has no attribute 'endpoints' >> ctrlport.monitor received shutdown signal >> == >> >> this is on a Fedora 19-64. >> >> Any help is greatly appreciated. >> >> thanks >> Achilleas >> >> > Looks like the server isn't being started. When you run cmake, you should > see that under enabled components, you have: > > * gr-ctrlport > ** thrift > > That tells you ControlPort is enabled and the Thrift backend will be built > for it. You can also tell by looking at gnuradio/config.h to see if > GR_RPCSERVER_ENABLED and GR_RPCSERVER_THRIFT are defined there. > > My guess is that cmake isn't picking up Thrift. It requires version 0.9.2 > to run. You can get some info on building this yourself here: > > http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort > > I also just pushed a new apache-thrift recipe to PyBOMBS today. > > Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] control port on 3.7.8 ?
After pulling the latest version of gnuradio, and remaking/installing/etc I am trying to run the application "pfb_sync_test.grc" in the examples directory of control port. It is giving me the following error: Executing: "/home/anastas/gnuradio_trunk/gr-blocks/examples/ctrlport/pfb_sync_test_qt.py" Using Volk machine: sse4_1_64_orc ControlPort Monitor running. Traceback (most recent call last): File "/home/anastas/gnuradio_trunk/gr-blocks/examples/ctrlport/pfb_sync_test_qt.py", line 233, in (tb.blocks_ctrlport_monitor_0).start() File "/usr/local/lib64/python2.7/site-packages/gnuradio/ctrlport/monitor.py", line 48, in start print "monitor::endpoints() = %s" % (gr.rpcmanager_get().endpoints()) AttributeError: 'NoneType' object has no attribute 'endpoints' ctrlport.monitor received shutdown signal == this is on a Fedora 19-64. Any help is greatly appreciated. thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] streams are not aligned properly in wx time sink
Hi all, I have an example where I see the output of three blocks in a wx time sink: http://web.eecs.umich.edu/~anastas/docs/wx.png I didn't get the expected result and I run in also with qt time sink: http://web.eecs.umich.edu/~anastas/docs/qt.png The two pictures are different! The wx time sink does not seem to align the three signals properly... (I double checked this by also outputing to a file and confirming that the qt picture is the correct one) Any suggestions? thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pccc encoder
You are using the pccc decoder in an incorrect way. Please see attached corrected grc file: there are two ways to use the pccc decoder (i) either as a combo or (ii) in conjuction with trellis metrics. I have provided in your file both ways. Regarding you second question about whether you can define your own FSM: Of course you can! This is the whole idea of the FSM class! Please read the extensive documentation on how to do that in: /usr/local/share/doc/gnuradio-3.7.7git/html/gr-trellis.html (or wherever you have your documentation installed), and let us know if there is something you do not understand. Achilleas FSM284_Vector_Cod_decod_turbo_error_rate.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Some misconceptions about the "peak_detector2" block
Hi all, recently there has been some discussion regarding the peak_detector2 block, both in the github/gnuradio (pull request 404) as well as in the issue tracker (issue 783). It is now well accepted that this block is buggy: there are cases the work function returns -1, which is a bug (see issue 783 on how to recreate this bug). I believe however that there is a DEEPER misconception about how this block works/should work that has resulted in some frustration on what an appropriate fix should be. In particular there is an insistence that an appropriate bug fix should pass the qa_test of this block and it should be [in the spirit] of the existing algorithm. In the following I will explain why *passing the qa_test is a consequence of the buggy behaviour* of this block and NOT its feature. In addition I will suggest what a proper behaviour of this block should be, so that others who may want to write their own version of a peak detector find it useful. So the peak_detector block is very reasonable in its conception and its name is very informative and appropriate. It works as follows: Reads the input and keeps track of a running average (through a single-pole iir filter) When the current input crosses a threshold (= average * a user-defined factor) upwards the block enters a search state, where it looks for the maximum value of the input over a window of user-defined length. This is clearly the intended behaviour of the block according to the documentation (I don't know who the original author is...). -- It should be obvious that this block is intended for a scenario where the inputs are coming continuously and the block is determining the peaks. A prototypical application is finding the peak after a MF with a training sequence in order to determine the start of a packet (BTW, there is some effort on creating a correlate and sync block, which is very relevant to this discussion). It should also be obvious that both the pole of the IIR filter, the threshold, AND the window should be properly selected per application (eg, for a training sequence of length N, it is appropriate to set the window ~N) otherwise the block will simply not work according to its specs. --- So here are some questions and my suggested answers: Q1: How should this block behave when it has already crossed the threshold upwards and is still inside the user-defined search window but there is not enough input data to process? A1: Clearly the work function should return (consuming all inputs/outputs up to the most current peak--but not more) and hopefully the next time it is called, the scheduler would provide more samples so that the search over the remaining window is exhausted and the peak is reported. --- Q2: And then, what if the scheduler does not give this block more input data? Maybe because (as in the qa_test) this block is connected to a source that outputs a finite (=21 !) number of samples? A2: Since the intended use of this block is a continuous stream of data, the above situation is an inappropriate use of this block, and thus it cannot be considered a test case. This means that an appropriate test case should make sure that enough tail data is in the finite input so that the search window is exhausted. --- Q3: What if the user insists in using the block in a way that is not intended, ie, by providing it with a finite (and small compared to the search window) number of inputs. Should there be a way that the block bails out? A3: The current implementation has this behaviour but it is a BUG not a feature: ERRONEOUSLY it decrements the window even if it does not return any data, so eventually the window becomes smaller than the available input and the block exits! This results in the block passing an ill-conceived qa_test (where the window is set to 1000 for a peak occurring within 10 samples of the threshold crossing). However the intended use of the block was never this (according to the documentation). >From the above it should be clear that any fix of this block should NOT be in the spirit of the original one, nor not passing the existing qa_test is a measure of its difference from the original block (at least from the stated intended behaviour of the original block). I attach here a clean modification of this block that has the intended behaviour. It DOES NOT pass (correctly) the inappropriate qa_test, but it does pass more appropriately designed test(s) (also attached). I am requesting some feedback for this approach so that I can finalize it and submit it for merging into the gnuradio trunk. best Achilleas /* -*- c++ -*- */ /* * Copyright 2007,2010,2013 Free Software Foundation, Inc. * * This file is part of GNU Radio * * GNU Radio is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 3, or (at your option) * any lat
Re: [Discuss-gnuradio] pccc encoder
Since your constellation is complex, then its dimensionality (in the chunks_to_symbos block, as well as in the PCCC decoder block) should be set to 1 (you are now have it at 2). The convention is that the chunks_to_symbols array is arranged as a11, a12, ... a1d, a21 a22,...,a2d,... aM1, aM2, ...aMd so that it is to be understood as the 2 D array a11, a12, ... a1d, a21 a22,...,a2d, ... aM1, aM2, ...aMd with dimensionality d. Then, at each instance, it outputs the "row" that is indexed by the input symbol. Achilleas PS: I also suggest you make a variable "constellation" and put in there your constellation and then input it in both the chunks_to_symbols AND the PCCC decoder block so that you are sure you are consistent. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pccc encoder
There are several issues with your code:
1) a PCCC encoder (as any digital communication encoder) cannot accept a
"sine wave" as its input!
it only accepts discrete information.
In this case it should be numbers {0,1,2,...,X-1} where X is the input
alphabet size of your fsm's.
2) The output cardinality of the PCCC is the product of the output
cardinalities of the two FSMs that you are using,
so in your case is 2^3 x 2^3 = 64, which is not consistent with the size of
the modulation you are using
3) The interleaver length is user-defined and there is no such thing as an
appropriate length (the longer the better performance... )
I suggest you look and try to understand the EXAMPLE (aptly named pccc.grc)
in the gr-trellis/examples/grc
and let us know if you have any questions on this particular example.
Then you can move on to change it according to your needs.
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Spread Spectrum Toolkit in gnuradio
I don't know much about this toolkit, but you can find our gr-cdma toolkit on github. It is a full blown (and fully parameterised by the user) cdma system with acquisition/tracking/adaptive modulation/coding, etc. https://github.com/anastas/gr-cdma best Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Issue with Results from GR-CDMA
Frank, see some comments inline. Achilleas > Hello sorry for the last message thought i attached my screenshot results at first. I am having some problems as to whether the information from the cdma transmission and reception are accurate. I have posted my screenshots for clarification hopefully. http://imageshack.com/a/img633/757/Yx8B7r.png The first screenshot is from executing the "cdma_txrx.grc" which seems to test well I believe because moving the sliders around and threshold I am able to notice when it performs tracking and acquisition of the signal automatically. A: I do not recall a "noise voltage" block in the cdma_txrx application. The SNR is controlled by the slider aptly called "EsN0dB". http://imageshack.com/a/img631/8451/CDqdTM.png The second screenshot is me loading two USRP's. This is the execution of the "cdma_tx.grc file with the UHD:USRP Sink and its WX GUI FFT Plot. My issue here is the FFT plot doesn't look right to. By the way the channel model for this is AWGN. A: You are saying "FFT plot doesn't look right". What is it that you expect to see and you don't ? Can you please elaborate on what does not look right about this? BTW, you don't need the cdma_tx to get this FFT plot: the cdma_txrx should give you exactly the same at the output of the tx. http://imageshack.com/a/img538/7792/1xXqN4.png After running the "cdma_tx.grc" file, I proceed to go to my other laptop and run the "cdma_rx.grc" file which is connected to that USRP(UHD USRP SOURCE. The image above is what I get. In the beginning it seems to be acquiring the packets then a few seconds later a lot of invalid packets get detected. Overall all are these images close to what I should be seeing. A: you have not told us anything about your system, so we cannot help you. For instance, what is your hardware setup (daughtercards, carrier frequency, sample rate, etc), what is the expected frequency error, what are the RX parameters that you have set? are they compatible with you working environment? is your laptop handling well the acquisition load (have you checked the load on your CPU cores?) Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-cdma
I don't know what fft you are talking about... If you have any SPECIFIC questions please write to this list with your SPECIFIC results (and maybe screenshots) and explain why you think what you see is wrong. The culture in this community is that we try things on our own and we ask for help (we generally don't ask people to do our job...) As far as I am concerned this discussion thread has gone quite long... We are looking forward to your contributions to the gnuradio community. best, Achilleas On Wed, Jan 28, 2015 at 9:02 PM, Frank Pinto wrote: > Sounds good. Can you please run your "txrx" simulation or separate "tx" > "rx" simulation and screenshot me the output because I feel like what I am > seeing is wrong. I want to be sure the output of the fft is correct. On the > receiver side I am getting the message debug that tells me the packet > number and packet length as well as if it's detecting a failed packet. > > > On Tuesday, January 27, 2015 12:11 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > Frank, > > you can perform simulations and plot BER vs SNR using either of the two > apps provided (ie, either the txrx or the separate tx and rx apps that > communicate through FIFO). The file vs FIFO is irrelevant here: the FIFOs > are just used for "emulating" > the communication between the two different tx and rx applications. > > In both cases you can either dump the rx results to a file and compare > with the "known" tx transmission, or you can add BER GRC blocks... > > All the above are not gr-cdma related, so i am sure you can find plenty > of examples of how this is done in this list and in the gnuradio examples. > > Achilleas > > > > > > > > > On Mon, Jan 26, 2015 at 10:01 PM, Frank Pinto > wrote: > > Sounds good! I figured this already just wanted to be sure. And will I be > able to plot the BER vs. Eb/NO by using the writing and reading to fifo or > simply reading and writing to a file and importing the data to matlab for > the BER vs Eb/NO plot? > > > On Friday, January 23, 2015 5:59 PM, Frank Pinto > wrote: > > > > > Sounds good! I figured this already just wanted to be sure. And will I be > able to plot the BER vs. Eb/NO by using the writing and reading to fifo or > simply reading and writing to a file and importing the data to matlab for > the BER vs Eb/NO plot? > > > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > At Jan 23, 2015, 5:53:58 PM, Achilleas Anastasopoulos wrote: > The beautiful thing about open source is that all the detail are there for > you to see! > > Looking at the cdma_parameters.py file, > you can see: > > pulse_training = numpy.array((1,1,1,1,-1,1,1,-1))+0j > pulse_data =numpy.array((-1,1,-1,1,-1,-1,-1,-1))+0j > > so we are using 8 chips per symbol with two orthogonal codes for training > and data. > > You can change them and put anything you like (they better be orthogonal > AND each should have good > autocorrelation properties-- or at least the training code should) > > best, > Achilleas > > > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-cdma
Frank, you can perform simulations and plot BER vs SNR using either of the two apps provided (ie, either the txrx or the separate tx and rx apps that communicate through FIFO). The file vs FIFO is irrelevant here: the FIFOs are just used for "emulating" the communication between the two different tx and rx applications. In both cases you can either dump the rx results to a file and compare with the "known" tx transmission, or you can add BER GRC blocks... All the above are not gr-cdma related, so i am sure you can find plenty of examples of how this is done in this list and in the gnuradio examples. Achilleas On Mon, Jan 26, 2015 at 10:01 PM, Frank Pinto wrote: > Sounds good! I figured this already just wanted to be sure. And will I be > able to plot the BER vs. Eb/NO by using the writing and reading to fifo or > simply reading and writing to a file and importing the data to matlab for > the BER vs Eb/NO plot? > > > On Friday, January 23, 2015 5:59 PM, Frank Pinto > wrote: > > > > > Sounds good! I figured this already just wanted to be sure. And will I be > able to plot the BER vs. Eb/NO by using the writing and reading to fifo or > simply reading and writing to a file and importing the data to matlab for > the BER vs Eb/NO plot? > > > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > At Jan 23, 2015, 5:53:58 PM, Achilleas Anastasopoulos wrote: > The beautiful thing about open source is that all the detail are there for > you to see! > > Looking at the cdma_parameters.py file, > you can see: > > pulse_training = numpy.array((1,1,1,1,-1,1,1,-1))+0j > pulse_data =numpy.array((-1,1,-1,1,-1,-1,-1,-1))+0j > > so we are using 8 chips per symbol with two orthogonal codes for training > and data. > > You can change them and put anything you like (they better be orthogonal > AND each should have good > autocorrelation properties-- or at least the training code should) > > best, > Achilleas > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-cdma
The beautiful thing about open source is that all the detail are there for you to see! Looking at the cdma_parameters.py file, you can see: pulse_training = numpy.array((1,1,1,1,-1,1,1,-1))+0j pulse_data =numpy.array((-1,1,-1,1,-1,-1,-1,-1))+0j so we are using 8 chips per symbol with two orthogonal codes for training and data. You can change them and put anything you like (they better be orthogonal AND each should have good autocorrelation properties-- or at least the training code should) best, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-cdma
It should be obvious that this can be done. A transmitted signal over the air can be received from multiple receivers... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] anyone familiar with this BOOST error
I think I have a hunch as to what this is. Some googling showed that this happens when you are trying to spawn more threads than your machine can handle. >From your previous post/discussions I understand this happens when you run the cdma_rx file. The part of this program that generates a lot of threads is the aqcuisition filterbank which we have made highly parallelized. If this is the case then it should also happen running cdma_txrx (please try it). Recall that gr-cdma is fully parameterized by the user. So to fix this (this is not a bug, it is the feature of the system) try to change the variable n_filt=51 to some smaller value (try 11). I hope you understand what the tradeoffs are (reduced capability of receiver to handle frequency errors). best, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-cdma
Indeed, the cdma_txrx is a simulation of the entire tx/rx. We used it to test our system and everyone can use it if they don't want to (or cannot) transmit through real hardware. The separate files cdma_tx and cdma_rx can be used with real USRPs. Finally, I don't recall where I discuss about the concept of a FIFO? Achilleas On Mon, Jan 19, 2015 at 12:30 AM, Frank Pinto wrote: > I will try the GDB tomorrow and let you know the output response. > One more question. Is the "cdma_txrx.grc" just for packet transmission > with no hardware attached, while the cdma_tx.grc and cdma_rx.grc are used > for real live cdma transmission with hardware (ex: USRP's)? > And I don't really understand the concept of fifo. I jus know it stands > for first in first out. > > > On Friday, January 16, 2015 3:01 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > You shouldn't worry about these files for now. > In any case they refer to "adaptive modulation" > which you cannot do unless some recent updates are merged into gnuradio > master. > > For now, you should be able to experiment with the txrx, tx, rx. > > best > Achilleas > > On Fri, Jan 16, 2015 at 2:14 PM, Frank Pinto > wrote: > > All the blocks were able to load, compile and show on the GRC blocks list > except from the "cdma_tx_hier1" and "cdma_rx_hier1" block (they are > producing errors and are few of their blocks are marked red because of > this). Then the "cdma_txrx1" block is producing a error because it needs > the "cdma_tx_hier1" and "cdma_rx_hier1" block in order to compile. > > > On Friday, January 16, 2015 1:34 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > yes, please disregard all previous changes. > > They have been incorporated in the updated files. > > So, please pull a clean copy from github. > > Achilleas > > On Fri, Jan 16, 2015 at 1:32 PM, Frank Pinto > wrote: > > Hello Achilleas, thank you I will do that! When I perform this edit in the > python file should I disregard the changes we did yesterday in th > cdma_parameters.py file line 124 which was changing the > "digital_constellation_8psk_natural" with "digital.constellation_8psk" and > keep the orginal code? > > > On Friday, January 16, 2015 1:23 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > Frank, > > please pull the latest version of gr-cdma. > > You have to make a small edit in the cdma_parameters.py file > (see updated README file) before you install it. > > Once you do that, open a python session and do > > >>> from cdma import cdma_parameters > > This should now give no errors. > Let us know of your progress. > > Achilleas > > > On Thu, Jan 15, 2015 at 6:24 PM, Frank Pinto > wrote: > > I have applied the change, now the error reads: AttributeError: 'module' > object has no attribute 'constellation_16qam' > > > On Thursday, January 15, 2015 3:37 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > OK, great. > > This is due to the fact a recent pull request has not yet been merged into > gnuradio. > SO the constellation module does not have yet the > "constellation_8psk_natural" > constellation. > > There is a simple fix to that: > > please go to your gr-cdma/python directory > and edit the file > cdma_parameters.py > In particular in line 124 change "digital.constellation_8psk_natural" with > "digital.constellation_8psk". > > Now you have to make, sudo make install, sudo ldconfig one more time. > > Once you do that, please open a python session and redo > > >>> from cdma import cdma_parameters as cp > > and let us know what you get. > (if you don't get any errors you are ready to go!) > > > Achilleas > > > > > On Thu, Jan 15, 2015 at 1:25 PM, Frank Pinto > wrote: > > The result is: > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.7/dist-packages/cdma/__init__.py", line 34, > in > import cdma_parameters > File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_parameters.py", > line 124, in > payload_mod = > [digital.constellation_qpsk(),digital.constellation_8psk_natural(),digital.constellation_16qam()] > AttributeError: 'module' object has no attribute > 'constellation_8psk_natural' > > > > On Thursday, January 15, 2015 1:14 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote:
Re: [Discuss-gnuradio] gr-cdma
You shouldn't worry about these files for now. In any case they refer to "adaptive modulation" which you cannot do unless some recent updates are merged into gnuradio master. For now, you should be able to experiment with the txrx, tx, rx. best Achilleas On Fri, Jan 16, 2015 at 2:14 PM, Frank Pinto wrote: > All the blocks were able to load, compile and show on the GRC blocks list > except from the "cdma_tx_hier1" and "cdma_rx_hier1" block (they are > producing errors and are few of their blocks are marked red because of > this). Then the "cdma_txrx1" block is producing a error because it needs > the "cdma_tx_hier1" and "cdma_rx_hier1" block in order to compile. > > > On Friday, January 16, 2015 1:34 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > yes, please disregard all previous changes. > > They have been incorporated in the updated files. > > So, please pull a clean copy from github. > > Achilleas > > On Fri, Jan 16, 2015 at 1:32 PM, Frank Pinto > wrote: > > Hello Achilleas, thank you I will do that! When I perform this edit in the > python file should I disregard the changes we did yesterday in th > cdma_parameters.py file line 124 which was changing the > "digital_constellation_8psk_natural" with "digital.constellation_8psk" and > keep the orginal code? > > > On Friday, January 16, 2015 1:23 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > Frank, > > please pull the latest version of gr-cdma. > > You have to make a small edit in the cdma_parameters.py file > (see updated README file) before you install it. > > Once you do that, open a python session and do > > >>> from cdma import cdma_parameters > > This should now give no errors. > Let us know of your progress. > > Achilleas > > > On Thu, Jan 15, 2015 at 6:24 PM, Frank Pinto > wrote: > > I have applied the change, now the error reads: AttributeError: 'module' > object has no attribute 'constellation_16qam' > > > On Thursday, January 15, 2015 3:37 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > OK, great. > > This is due to the fact a recent pull request has not yet been merged into > gnuradio. > SO the constellation module does not have yet the > "constellation_8psk_natural" > constellation. > > There is a simple fix to that: > > please go to your gr-cdma/python directory > and edit the file > cdma_parameters.py > In particular in line 124 change "digital.constellation_8psk_natural" with > "digital.constellation_8psk". > > Now you have to make, sudo make install, sudo ldconfig one more time. > > Once you do that, please open a python session and redo > > >>> from cdma import cdma_parameters as cp > > and let us know what you get. > (if you don't get any errors you are ready to go!) > > > Achilleas > > > > > On Thu, Jan 15, 2015 at 1:25 PM, Frank Pinto > wrote: > > The result is: > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.7/dist-packages/cdma/__init__.py", line 34, > in > import cdma_parameters > File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_parameters.py", > line 124, in > payload_mod = > [digital.constellation_qpsk(),digital.constellation_8psk_natural(),digital.constellation_16qam()] > AttributeError: 'module' object has no attribute > 'constellation_8psk_natural' > > > > On Thursday, January 15, 2015 1:14 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > Frank, > > Please do the following and report to us what you get. > > Open a python session and write > > >>> from cdma import cdma_parameters as cp > > What is the result of this? > > Achilleas > > > > On Thu, Jan 15, 2015 at 12:12 PM, Frank Pinto > wrote: > > Hello Sir, I just tried that and the first the hier block > "amp_var_est_hier.grc gets compiled with no issues. > However the others are producing errors in certain blocks and can > therefore not compile. The error states "name 'cp' is not defined. > And the import box is showing this error "Bad import syntax:import > cdma.cdma_parameters as cp". This is where I am stuck at because it seems > all the other blocks that are producing errors has this 'cp' in it somehow. > > > > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > At Jan 15, 20
Re: [Discuss-gnuradio] gr-cdma
yes, please disregard all previous changes. They have been incorporated in the updated files. So, please pull a clean copy from github. Achilleas On Fri, Jan 16, 2015 at 1:32 PM, Frank Pinto wrote: > Hello Achilleas, thank you I will do that! When I perform this edit in the > python file should I disregard the changes we did yesterday in th > cdma_parameters.py file line 124 which was changing the > "digital_constellation_8psk_natural" with "digital.constellation_8psk" and > keep the orginal code? > > > On Friday, January 16, 2015 1:23 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > Frank, > > please pull the latest version of gr-cdma. > > You have to make a small edit in the cdma_parameters.py file > (see updated README file) before you install it. > > Once you do that, open a python session and do > > >>> from cdma import cdma_parameters > > This should now give no errors. > Let us know of your progress. > > Achilleas > > > On Thu, Jan 15, 2015 at 6:24 PM, Frank Pinto > wrote: > > I have applied the change, now the error reads: AttributeError: 'module' > object has no attribute 'constellation_16qam' > > > On Thursday, January 15, 2015 3:37 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > OK, great. > > This is due to the fact a recent pull request has not yet been merged into > gnuradio. > SO the constellation module does not have yet the > "constellation_8psk_natural" > constellation. > > There is a simple fix to that: > > please go to your gr-cdma/python directory > and edit the file > cdma_parameters.py > In particular in line 124 change "digital.constellation_8psk_natural" with > "digital.constellation_8psk". > > Now you have to make, sudo make install, sudo ldconfig one more time. > > Once you do that, please open a python session and redo > > >>> from cdma import cdma_parameters as cp > > and let us know what you get. > (if you don't get any errors you are ready to go!) > > > Achilleas > > > > > On Thu, Jan 15, 2015 at 1:25 PM, Frank Pinto > wrote: > > The result is: > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.7/dist-packages/cdma/__init__.py", line 34, > in > import cdma_parameters > File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_parameters.py", > line 124, in > payload_mod = > [digital.constellation_qpsk(),digital.constellation_8psk_natural(),digital.constellation_16qam()] > AttributeError: 'module' object has no attribute > 'constellation_8psk_natural' > > > > On Thursday, January 15, 2015 1:14 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > Frank, > > Please do the following and report to us what you get. > > Open a python session and write > > >>> from cdma import cdma_parameters as cp > > What is the result of this? > > Achilleas > > > > On Thu, Jan 15, 2015 at 12:12 PM, Frank Pinto > wrote: > > Hello Sir, I just tried that and the first the hier block > "amp_var_est_hier.grc gets compiled with no issues. > However the others are producing errors in certain blocks and can > therefore not compile. The error states "name 'cp' is not defined. > And the import box is showing this error "Bad import syntax:import > cdma.cdma_parameters as cp". This is where I am stuck at because it seems > all the other blocks that are producing errors has this 'cp' in it somehow. > > > > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > At Jan 15, 2015, 11:57:05 AM, Achilleas Anastasopoulos<'anas...@umich.edu'> > wrote: > Frank, > > you have to follow the procedure in README by compiling ONE file at a > time, > and RELOADING the blocks as you go on, ie, > > Load the hier block "amp_var_est_hier.grc", > Compile it (this little button on GRC that looks like a pyramid, a sphere > and an arrow) > Reload it (this little circle button on GRC) > > Load "cdma_tx_hier.grc", > compile it as before > reload > > > Load "chopper_correlator.grc", > compile > reload > > > etc... > "cdma_rx_hier.grc", "cdma_tx_hier1.grc", "cdma_rx_hier1.grc" and compile > them > > Achilleas > > > On Thu, Jan 15, 2015 at 11:35 AM, Frank Pinto > wrote: > > Hello Sir, I have read the readme.md file already. My first issue is
Re: [Discuss-gnuradio] gr-cdma
Frank, please pull the latest version of gr-cdma. You have to make a small edit in the cdma_parameters.py file (see updated README file) before you install it. Once you do that, open a python session and do >>> from cdma import cdma_parameters This should now give no errors. Let us know of your progress. Achilleas On Thu, Jan 15, 2015 at 6:24 PM, Frank Pinto wrote: > I have applied the change, now the error reads: AttributeError: 'module' > object has no attribute 'constellation_16qam' > > > On Thursday, January 15, 2015 3:37 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > OK, great. > > This is due to the fact a recent pull request has not yet been merged into > gnuradio. > SO the constellation module does not have yet the > "constellation_8psk_natural" > constellation. > > There is a simple fix to that: > > please go to your gr-cdma/python directory > and edit the file > cdma_parameters.py > In particular in line 124 change "digital.constellation_8psk_natural" with > "digital.constellation_8psk". > > Now you have to make, sudo make install, sudo ldconfig one more time. > > Once you do that, please open a python session and redo > > >>> from cdma import cdma_parameters as cp > > and let us know what you get. > (if you don't get any errors you are ready to go!) > > > Achilleas > > > > > On Thu, Jan 15, 2015 at 1:25 PM, Frank Pinto > wrote: > > The result is: > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.7/dist-packages/cdma/__init__.py", line 34, > in > import cdma_parameters > File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_parameters.py", > line 124, in > payload_mod = > [digital.constellation_qpsk(),digital.constellation_8psk_natural(),digital.constellation_16qam()] > AttributeError: 'module' object has no attribute > 'constellation_8psk_natural' > > > > On Thursday, January 15, 2015 1:14 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > Frank, > > Please do the following and report to us what you get. > > Open a python session and write > > >>> from cdma import cdma_parameters as cp > > What is the result of this? > > Achilleas > > > > On Thu, Jan 15, 2015 at 12:12 PM, Frank Pinto > wrote: > > Hello Sir, I just tried that and the first the hier block > "amp_var_est_hier.grc gets compiled with no issues. > However the others are producing errors in certain blocks and can > therefore not compile. The error states "name 'cp' is not defined. > And the import box is showing this error "Bad import syntax:import > cdma.cdma_parameters as cp". This is where I am stuck at because it seems > all the other blocks that are producing errors has this 'cp' in it somehow. > > > > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > At Jan 15, 2015, 11:57:05 AM, Achilleas Anastasopoulos<'anas...@umich.edu'> > wrote: > Frank, > > you have to follow the procedure in README by compiling ONE file at a > time, > and RELOADING the blocks as you go on, ie, > > Load the hier block "amp_var_est_hier.grc", > Compile it (this little button on GRC that looks like a pyramid, a sphere > and an arrow) > Reload it (this little circle button on GRC) > > Load "cdma_tx_hier.grc", > compile it as before > reload > > > Load "chopper_correlator.grc", > compile > reload > > > etc... > "cdma_rx_hier.grc", "cdma_tx_hier1.grc", "cdma_rx_hier1.grc" and compile > them > > Achilleas > > > On Thu, Jan 15, 2015 at 11:35 AM, Frank Pinto > wrote: > > Hello Sir, I have read the readme.md file already. My first issue is > where it states to "load all the hier blocks and compile them". When I > loaded them via the GRC by clicking on "open an existing flowgraph" and > selecting the files, I see that they all are missing some variables, > information, and even blocks, and are shown as red. > I have taken a picture to show you this. I am using version 3.7.5.1 of > GNuRadio by the way > > > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > At Jan 15, 2015, 11:29:05 AM, Frank Pinto<'frankpint...@yahoo.com'> wrote: > Sir, I have read the readme.md file. My first issue is where it states > load all the heir blocks and compile them > > > On Thu
Re: [Discuss-gnuradio] gr-cdma
OK, great. This is due to the fact a recent pull request has not yet been merged into gnuradio. SO the constellation module does not have yet the "constellation_8psk_natural" constellation. There is a simple fix to that: please go to your gr-cdma/python directory and edit the file cdma_parameters.py In particular in line 124 change "digital.constellation_8psk_natural" with "digital.constellation_8psk". Now you have to make, sudo make install, sudo ldconfig one more time. Once you do that, please open a python session and redo >>> from cdma import cdma_parameters as cp and let us know what you get. (if you don't get any errors you are ready to go!) Achilleas On Thu, Jan 15, 2015 at 1:25 PM, Frank Pinto wrote: > The result is: > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.7/dist-packages/cdma/__init__.py", line 34, > in > import cdma_parameters > File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_parameters.py", > line 124, in > payload_mod = > [digital.constellation_qpsk(),digital.constellation_8psk_natural(),digital.constellation_16qam()] > AttributeError: 'module' object has no attribute > 'constellation_8psk_natural' > > > > On Thursday, January 15, 2015 1:14 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > Frank, > > Please do the following and report to us what you get. > > Open a python session and write > > >>> from cdma import cdma_parameters as cp > > What is the result of this? > > Achilleas > > > > On Thu, Jan 15, 2015 at 12:12 PM, Frank Pinto > wrote: > > Hello Sir, I just tried that and the first the hier block > "amp_var_est_hier.grc gets compiled with no issues. > However the others are producing errors in certain blocks and can > therefore not compile. The error states "name 'cp' is not defined. > And the import box is showing this error "Bad import syntax:import > cdma.cdma_parameters as cp". This is where I am stuck at because it seems > all the other blocks that are producing errors has this 'cp' in it somehow. > > > > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > At Jan 15, 2015, 11:57:05 AM, Achilleas Anastasopoulos<'anas...@umich.edu'> > wrote: > Frank, > > you have to follow the procedure in README by compiling ONE file at a > time, > and RELOADING the blocks as you go on, ie, > > Load the hier block "amp_var_est_hier.grc", > Compile it (this little button on GRC that looks like a pyramid, a sphere > and an arrow) > Reload it (this little circle button on GRC) > > Load "cdma_tx_hier.grc", > compile it as before > reload > > > Load "chopper_correlator.grc", > compile > reload > > > etc... > "cdma_rx_hier.grc", "cdma_tx_hier1.grc", "cdma_rx_hier1.grc" and compile > them > > Achilleas > > > On Thu, Jan 15, 2015 at 11:35 AM, Frank Pinto > wrote: > > Hello Sir, I have read the readme.md file already. My first issue is > where it states to "load all the hier blocks and compile them". When I > loaded them via the GRC by clicking on "open an existing flowgraph" and > selecting the files, I see that they all are missing some variables, > information, and even blocks, and are shown as red. > I have taken a picture to show you this. I am using version 3.7.5.1 of > GNuRadio by the way > > > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > At Jan 15, 2015, 11:29:05 AM, Frank Pinto<'frankpint...@yahoo.com'> wrote: > Sir, I have read the readme.md file. My first issue is where it states > load all the heir blocks and compile them > > > On Thursday, January 15, 2015 11:13 AM, Achilleas Anastasopoulos wrote: > > > There is no such instruction to be executed! > > Please read the README.md file and let us know which one of the detailed > instructions mentioned there you don't know how to execute. > > Achilles > > On Thu, Jan 15, 2015 at 10:52 AM, Frank Pinto > wrote: > > Ok. First instruction that I do not know how to execute is the import > variable block that says "import coma.cdma_parameters as cp". What exactly > am I supposed to be replacing in this section. > > > On Wednesday, January 14, 2015 7:08 PM, Frank Pinto < > frankpint...@yahoo.com> wrote: > > > Ok. First instruction that I do not know how to execute is "import > coma.cdma_parameters as
Re: [Discuss-gnuradio] gr-cdma
Frank, Please do the following and report to us what you get. Open a python session and write >>> from cdma import cdma_parameters as cp What is the result of this? Achilleas On Thu, Jan 15, 2015 at 12:12 PM, Frank Pinto wrote: > Hello Sir, I just tried that and the first the hier block > "amp_var_est_hier.grc gets compiled with no issues. > However the others are producing errors in certain blocks and can > therefore not compile. The error states "name 'cp' is not defined. > And the import box is showing this error "Bad import syntax:import > cdma.cdma_parameters as cp". This is where I am stuck at because it seems > all the other blocks that are producing errors has this 'cp' in it somehow. > > > > > > Sent from Yahoo Mail for iPhone <https://overview.mail.yahoo.com?.src=iOS> > > At Jan 15, 2015, 11:57:05 AM, Achilleas Anastasopoulos<'anas...@umich.edu'> > wrote: > Frank, > > you have to follow the procedure in README by compiling ONE file at a > time, > and RELOADING the blocks as you go on, ie, > > Load the hier block "amp_var_est_hier.grc", > Compile it (this little button on GRC that looks like a pyramid, a sphere > and an arrow) > Reload it (this little circle button on GRC) > > Load "cdma_tx_hier.grc", > compile it as before > reload > > > Load "chopper_correlator.grc", > compile > reload > > > etc... > "cdma_rx_hier.grc", "cdma_tx_hier1.grc", "cdma_rx_hier1.grc" and compile > them > > Achilleas > > > On Thu, Jan 15, 2015 at 11:35 AM, Frank Pinto > wrote: > >> Hello Sir, I have read the readme.md file already. My first issue is >> where it states to "load all the hier blocks and compile them". When I >> loaded them via the GRC by clicking on "open an existing flowgraph" and >> selecting the files, I see that they all are missing some variables, >> information, and even blocks, and are shown as red. >> I have taken a picture to show you this. I am using version 3.7.5.1 of >> GNuRadio by the way >> >> >> >> >> Sent from Yahoo Mail for iPhone >> <https://overview.mail.yahoo.com?.src=iOS> >> >> At Jan 15, 2015, 11:29:05 AM, Frank Pinto<'frankpint...@yahoo.com'> >> wrote: >> Sir, I have read the readme.md file. My first issue is where it states >> load all the heir blocks and compile them >> >> >> On Thursday, January 15, 2015 11:13 AM, Achilleas Anastasopoulos >> wrote: >> >> >> There is no such instruction to be executed! >> >> Please read the README.md file and let us know which one of the detailed >> instructions mentioned there you don't know how to execute. >> >> Achilles >> >> On Thu, Jan 15, 2015 at 10:52 AM, Frank Pinto >> wrote: >> >> Ok. First instruction that I do not know how to execute is the import >> variable block that says "import coma.cdma_parameters as cp". What exactly >> am I supposed to be replacing in this section. >> >> >> On Wednesday, January 14, 2015 7:08 PM, Frank Pinto < >> frankpint...@yahoo.com> wrote: >> >> >> Ok. First instruction that I do not know how to execute is "import >> coma.cdma_parameters as cp". What exactly am I supposed to be replacing in >> this section >> >> >> On Wednesday, January 14, 2015 6:54 PM, Achilleas Anastasopoulos < >> anas...@umich.edu> wrote: >> >> >> Please follow the detailed instructions on the README.md file and >> let us know which of these does not work for you >> (or which of these instructions you don't know how to execute). >> >> best >> 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] gr-cdma
Frank, you have to follow the procedure in README by compiling ONE file at a time, and RELOADING the blocks as you go on, ie, Load the hier block "amp_var_est_hier.grc", Compile it (this little button on GRC that looks like a pyramid, a sphere and an arrow) Reload it (this little circle button on GRC) Load "cdma_tx_hier.grc", compile it as before reload Load "chopper_correlator.grc", compile reload etc... "cdma_rx_hier.grc", "cdma_tx_hier1.grc", "cdma_rx_hier1.grc" and compile them Achilleas On Thu, Jan 15, 2015 at 11:35 AM, Frank Pinto wrote: > Hello Sir, I have read the readme.md file already. My first issue is > where it states to "load all the hier blocks and compile them". When I > loaded them via the GRC by clicking on "open an existing flowgraph" and > selecting the files, I see that they all are missing some variables, > information, and even blocks, and are shown as red. > I have taken a picture to show you this. I am using version 3.7.5.1 of > GNuRadio by the way > > > > > Sent from Yahoo Mail for iPhone <https://overview.mail.yahoo.com?.src=iOS> > > At Jan 15, 2015, 11:29:05 AM, Frank Pinto<'frankpint...@yahoo.com'> wrote: > Sir, I have read the readme.md file. My first issue is where it states > load all the heir blocks and compile them > > > On Thursday, January 15, 2015 11:13 AM, Achilleas Anastasopoulos wrote: > > > There is no such instruction to be executed! > > Please read the README.md file and let us know which one of the detailed > instructions mentioned there you don't know how to execute. > > Achilles > > On Thu, Jan 15, 2015 at 10:52 AM, Frank Pinto > wrote: > > Ok. First instruction that I do not know how to execute is the import > variable block that says "import coma.cdma_parameters as cp". What exactly > am I supposed to be replacing in this section. > > > On Wednesday, January 14, 2015 7:08 PM, Frank Pinto < > frankpint...@yahoo.com> wrote: > > > Ok. First instruction that I do not know how to execute is "import > coma.cdma_parameters as cp". What exactly am I supposed to be replacing in > this section > > > On Wednesday, January 14, 2015 6:54 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > Please follow the detailed instructions on the README.md file and > let us know which of these does not work for you > (or which of these instructions you don't know how to execute). > > best > 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] gr-cdma
There is no such instruction to be executed! Please read the README.md file and let us know which one of the detailed instructions mentioned there you don't know how to execute. Achilles On Thu, Jan 15, 2015 at 10:52 AM, Frank Pinto wrote: > Ok. First instruction that I do not know how to execute is the import > variable block that says "import coma.cdma_parameters as cp". What exactly > am I supposed to be replacing in this section. > > > On Wednesday, January 14, 2015 7:08 PM, Frank Pinto < > frankpint...@yahoo.com> wrote: > > > Ok. First instruction that I do not know how to execute is > "import coma.cdma_parameters as cp". What exactly am I supposed to be > replacing in this section > > > On Wednesday, January 14, 2015 6:54 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > > > Please follow the detailed instructions on the README.md file and > let us know which of these does not work for you > (or which of these instructions you don't know how to execute). > > best > 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] gr-cdma
Please follow the detailed instructions on the README.md file and let us know which of these does not work for you (or which of these instructions you don't know how to execute). best Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distorted QPSK Constellation
I believe that even with the MF you'll have ISI because you have 4 samples/symbol in this example. Only if you down sample at 1 sample/symbol (at the right epoch) will you get rid of the ISI and get a clean QPSK. best Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PDU_to_tagged_stream consumes 100% CPU even though it is throttled!
Hi all, I have the following problem that is been bugging me for quite some time now, and I would like to solicit your help. I made a hier block in GRC (called "test_pdu_to_tag") with: pad_source--->pdu_to_tagged_stream-->pad_sink (I also made the pad_source "optional" and the pad_sink "required") After compiling this block, I test it using the following GRC test test_pdu_to_tag-->throttle (at 100Hz!)-->null_sink (observe that the "test_pdu_to_tag" does not have an input) == When I run this I get that the CPU load goes to 100%. can anyone help me figure out why this is happening? This is all with the latest master on a Fedora 19. Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Peak_Detector2 stalls simulation
Stephan, We have worked with this block and realized it has a bug (not just an inefficient functionality). This is easy to see if you consider what happens when the first time work is called, the threshold is passed, a peak is found in item "i" and so "d_peak_ind" is set to "i", but there are less that d_lookahead_items to be processed. Then suppose the second time the work is called, no other peak is found and d_lookahead_remaining goes to 0. Then the output buffer will be accessed at: "optr[d_peak_ind] = 1" which may not even be a valid access since the value of d_peak_ind was set to "i" in the previous work call! Anyway, I attach a fix to this (we were supposed to post it sooner on the list but got delayed by some other issues). Please note that in this current form the functionality is a bit different than the one suggested in the manual, ie, the peak finder ONLY looks ahead d_lookahead items from the point the threshold is crossed, but it does not reset this window every time a new peak is found within the window. It should be pretty easy to do this as well... Please let us know if you have any comments. best Achilleas peak_detector2_fb_impl.cc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] optional port in grc block
Hi all, I would like to have grc block with a bool option "Debug". Once this is set to True, then I would like to have an additional output port. How do I do that? I already added this part in the xml file: Debug debug False bool but now I don't know how to use this variable to make the additional port appear in the block. thanks Achilleas - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] BFSK
There isn't muchin this.
Here is a brief explanation.
Consider a signal
f(t)
which represents an instantaneous frequency of a sinusoid
and which carries some information.
Then you can generate the signal
phi(t) = 2 * pi* K * int_0^t f(tau) dtau
which is the instantaneous phase (since it is an integral of f(t))
with some frequency gain K.
Now you can form the complex exponential baseband signal
s(t) = exp( j phi(t) )
and transmit it. This is the basis of FM modulation.
Now imagine doing the above in discrete time.
You would have something like
f_k = f(k Ts)
phi_k = phi(k Ts) ~= 2 * pi* K * sum_i=0^k f(i Ts) Ts
= phi_{k-1} + 2 * pi * K * Ts * f_k(1)
and finally
s_k = exp(j phi_k) (2)
The FM modulator block in GNURADIO does exactly that,
ie
equations (1) and (2) with
sensitivity = 2 * pi * K * Ts
The quadrature demodulator block in GNURADIO extracts
phi_k from s_k (or from any complex signal for that matter) and multiplies
with some irrelevant gain M so you get
M * phi_k
I hope this help,
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-ctrlport-monitor (x) not installed?
I may have an issue with my ctrlport installation. I cannot find the file gr-ctrlport-monitor and gr-ctrlport-monitorx. I am on a fedora 19 64bit machine and this is the output of cmake on 3.7.6. thanks Achilleas === foo Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Request for feature in GRC
I recently had a problem with GRC where two threads were accessing a set_variable callback creating some unwanted behaviour (actually crashing the xmlrpc server). I fixed it by editing the python file created by GRC and locking the set_ callback. I thought that this can be a separate and interesting feature of the "variable" block in GRC, ie, a selector that selects if the user wants it to be "protected". Then a piece of code like below will be generated: self.lock = threading.Lock() def set_variable(self, value): self.lock.acquire() self.value = value other set_ cllabacks self.lock.release() best, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] xmlrpc and threading
Marcus, thanks for the suggestions. I fixed the problem by protecting the set_ callback of the variable with a lock. Incidentally this can be a nice little feature of GRC (i will put a request for feature on a separate post) Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] xmlrpc and threading
I have an application that uses two probes/function_probe blocks
and an xmlrpc client.
Most of the times I see that the two threads are crushing, I guess making
concurrent requests to the SimpleXMLRPCServer.
I googled it and I found that the SimpleXMLRPCServer cannot by default
handle these cases, but if it is derived by the "*MixIn" classes you can
handle concurrent requests.
Is there something obvious and simple that needs to be changed in the
xmlrpc_server.xml block?
thanks
Achilleas
===
Exception in thread Thread-4:
Traceback (most recent call last):
File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner
self.run()
File "/usr/lib64/python2.7/threading.py", line 764, in run
self.__target(*self.__args, **self.__kwargs)
File "./cdma_rx1.py", line 213, in _Esest_probe
self.set_Esest(val)
File "./cdma_rx1.py", line 280, in set_Esest
self.set_EsN0dB_est(10*numpy.log10( cp.epsilon + abs(self.Esest)/
(abs(self.N0est)+cp.epsilon) ) )
File "./cdma_rx1.py", line 296, in set_EsN0dB_est
self.set_DataEsN0dB_est(self.EsN0dB_est + 10*numpy.log10(
1.0-self.training_percent/100.0 ) )
File "./cdma_rx1.py", line 329, in set_DataEsN0dB_est
self.set_appr_tcm_type(2 if (self.DataEsN0dB_est<=15.0) else (1 if
(self.DataEsN0dB_est<=20.0) else 0))
File "./cdma_rx1.py", line 455, in set_appr_tcm_type
self.xmlrpc_client_0.set_tcm_type_selector(self.appr_tcm_type)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
return self.__send(self.__name, args)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
verbose=self.__verbose
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1289, in single_request
self.send_request(h, handler, request_body)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1391, in send_request
connection.putrequest("POST", handler, skip_accept_encoding=True)
File "/usr/lib64/python2.7/httplib.py", line 871, in putrequest
raise CannotSendRequest()
CannotSendRequest
Exception in thread Thread-3:
Traceback (most recent call last):
File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner
self.run()
File "/usr/lib64/python2.7/threading.py", line 764, in run
self.__target(*self.__args, **self.__kwargs)
File "./cdma_rx1.py", line 201, in _N0est_probe
self.set_N0est(val)
File "./cdma_rx1.py", line 273, in set_N0est
self.set_EsN0dB_est(10*numpy.log10( cp.epsilon + abs(self.Esest)/
(abs(self.N0est)+cp.epsilon) ) )
File "./cdma_rx1.py", line 296, in set_EsN0dB_est
self.set_DataEsN0dB_est(self.EsN0dB_est + 10*numpy.log10(
1.0-self.training_percent/100.0 ) )
File "./cdma_rx1.py", line 329, in set_DataEsN0dB_est
self.set_appr_tcm_type(2 if (self.DataEsN0dB_est<=15.0) else (1 if
(self.DataEsN0dB_est<=20.0) else 0))
File "./cdma_rx1.py", line 455, in set_appr_tcm_type
self.xmlrpc_client_0.set_tcm_type_selector(self.appr_tcm_type)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1224, in __call__
return self.__send(self.__name, args)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1578, in __request
verbose=self.__verbose
File "/usr/lib64/python2.7/xmlrpclib.py", line 1264, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib64/python2.7/xmlrpclib.py", line 1294, in single_request
response = h.getresponse(buffering=True)
File "/usr/lib64/python2.7/httplib.py", line 1033, in getresponse
raise ResponseNotReady()
ResponseNotReady
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Regarding lock protection when setting private variables in gnuradio blocks
Is "forecast()"" need to be protected in such a case as well? just searching on the web i realized that no operation can be assumed atomic, so I guess every single set_ method (even if it assigns a float/int/short/char) needs to be protected...is this an overkill? Achilleas On Wed, Oct 15, 2014 at 11:59 AM, Tom Rondeau wrote: > On Wed, Oct 15, 2014 at 11:49 AM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > >> My question arose from a comment that Jonathan made on one of the pull >> requests >> in gnuradio (#293). >> >> If we have a set function in a gr block that sets some private variable >> that is >> used in the work function, do we need to protect it to make the whole >> operation thread safe? >> >> Is this a standard practice in gnuradio blocks? >> eg, why is this not used in "add_const_vXX_impl.h.t" ? >> >> >> thanks >> Achilleas >> > > If it's not atomic, then yes, you really should protect it. All blocks > have a mutex called d_setlock you can easily use for this: > > gr::thread::scoped_lock lock(d_setlock); > > Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Regarding lock protection when setting private variables in gnuradio blocks
My question arose from a comment that Jonathan made on one of the pull requests in gnuradio (#293). If we have a set function in a gr block that sets some private variable that is used in the work function, do we need to protect it to make the whole operation thread safe? Is this a standard practice in gnuradio blocks? eg, why is this not used in "add_const_vXX_impl.h.t" ? thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] variable @FSM_FILE_INSTALL_DIR@ does not evaluate in grc
>From the latest master, when I run one of the examples in gr-trellis/examples/grc, the value of the parameter "prefix" which is set to @FSM_FILE_INSTALL_DIR@ does not evaluate... Can someone confirm? Is there something I should do to set it? thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] several updates on gr-trellis examples waiting to be merged
Hi all, I have made several updates to the gr-trellis examples (adding options etc). They are here: https://github.com/anastas/gnuradio.git under branch "trelllisupdates" I hope they'll get merged to the master branch soon. Please let me know if there are any issues to be resolved. best, Achilelas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] change value of variable in GRC when a message is received
Dan, when I said "messages" I meant "gnuradio messages" (http://gnuradio.org/doc/doxygen/page_msg_passing.html) So my problem is not with any "remote messaging" issue. Apologies for not making this more clear. best Achilleas On Thu, May 8, 2014 at 1:29 PM, Dan CaJacob wrote: > I'm not sure it's what you want, but the RPC Server block lets you change > the value of any GR variable in a running FG remotely. There also seems to > be some work ongoing t bring zeromq endpoints into GR. > > Very Respectfully, > > Dan CaJacob > > > On Thu, May 8, 2014 at 1:07 PM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > >> Is there a simple way for a GRC block to asynchronously >> change the value of a GRC variable when >> the block receives a specific message? >> >> 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
[Discuss-gnuradio] change value of variable in GRC when a message is received
Is there a simple way for a GRC block to asynchronously change the value of a GRC variable when the block receives a specific message? thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on callback functions implementation of blocks in gr-trellis
Zhe, there are way too many changes in this diff file for anyone to track and debug. I suggest you start with a clean gr-trellis and change JUST one block (say the viterbi_combined) and see if this change propagates in python and grc as you expect. You can also post this change to the list for further feedback (together with the SIMPLEST possible grc example that indicates the problem.) best, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Latest Hackfest (discussion on trellis and RA codes)
Miklos and Tom, one option may be to merge the work that Miklos described with gr-trellis (or the other way around :-)) Recall there was a discussion in the recent past of volk-ing the basic trellis algorithms such as VA and SISO. I believe the work that Miklos describes would be a wonderful way to start. Also, Miklos, some of the functionality you are describing (interleaving, generation of codes, FSM structure, etc) is in gr-trellis. In the spirit of not duplicating efforts, would you consider a joint effort to refactor as much as possible into one module/API? best Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-cdma is ready
-- Forwarded message -- From: Zhe Feng Date: Sun, Mar 9, 2014 at 2:42 PM Subject: Re: [Discuss-gnuradio] gr-cdma is ready To: Karan Talasila Cc: Achilleas Anastasopoulos Hi Karan, If you installed this gr-cdma module with DENABLE_DOXYGEN=ON, you can find the html documentation in usr/local/share/doc/gr-cdma/html/index.html This html gives a general description of the module and contains the documentation of all the c++ blocks used (flag_gen, chopper, vector_insert2), and all hier blocks. For the python blocks (kronecker_filter, freq_timing_estimator), you open your python and do: *import cdma,* *help(cdma) #for a general look of cdma* *help(cdma.kronecker_filter)#for checking the documentation of the block kronecker_filter. * Please feel free to reply if you have any additional questions or suggestions. Best, Zhe On Sat, Mar 8, 2014 at 6:50 AM, Karan Talasila wrote: > Hi Achillaes, > can you tell me where the documentation of all the > blocks used in cdma_tx and cdma_rx are? I tried the cdma_trrx.grc and i got > a menu list with options to change freq and timing offset and eb/N0. But i > wasn't able to transmit and recieve packets or know how changing parameters > in the menu is changing the output. I would like to look into the > documentation of inidvidual blocks to understand better. > > > On Fri, Mar 7, 2014 at 3:44 AM, Achilleas Anastasopoulos < > anas...@umich.edu> wrote: > >> Dear all, >> >> the OOT module gr-cdma that we have been working on with Zhe Feng is now >> ready (also fully documented). You can find it here: >> >> https://github.com/anastas/gr-cdma.git >> >> An important acknowledgement: >> >> this project grew out of the DARPA SPECTRUM CHALLENGE: >> our team eventually dropped out of the race because of other time >> commitments but I and Zhe decided to finish up the design and make it >> publicly available since DARPA was generous enough to send us USRPs for >> testing etc. >> >> I am looking forward to feedback from the community and to ideas for >> expanding/improving the design. >> >> === >> For the impatient: >> >> 1) Download gr-cdma from github >> > git clone https://github.com/anastas/gr-cdma.git >> >> 2) Build the package >> > mkdir build_cdma >> > cd build_cdma >> > cmake -DENABLE_DOXYGEN=ON ../gr-cdma >> > make >> > sudo make install >> > sudo ldconfig >> >> 3) compile hierarchical blocks and play with built in app >> > cd gr-cdma/apps >> > gnuradio-companion & >> In the gnuradio-companion environment >> -- Load the hier block "amp_var_est_hier.grc", "cdma_tx_hier.grc", >> "chopper_correlator1.grc", "cdma_rx_hier.grc" and compile them >> making sure to reload blocks after each compilation >> -- Load the application "cdma_txrx.grc" and have fun >>Experiment with manual acq/tra, auto acq/tra, changing freq and timing >> offset, SNR, etc >> -- If you have 2 USRPs load the cdma_tx.grc and cdma_rx.grc and enjoy >> real-time >> CDMA transmission. You can also use the cdma_tx.grc and cdma_rx.grc by >> writting >> and reading to a fifo (first do > makefifo /tmp/cdma.fifo) >> = >> >> best, >> Achilleas >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > -- > Regards > Karan Talasila > -- Zhe Feng Electrical Engineering: System University of Michigan Ann Arbor Tel: 734-834-3188 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-cdma is ready
Dear all, the OOT module gr-cdma that we have been working on with Zhe Feng is now ready (also fully documented). You can find it here: https://github.com/anastas/gr-cdma.git An important acknowledgement: this project grew out of the DARPA SPECTRUM CHALLENGE: our team eventually dropped out of the race because of other time commitments but I and Zhe decided to finish up the design and make it publicly available since DARPA was generous enough to send us USRPs for testing etc. I am looking forward to feedback from the community and to ideas for expanding/improving the design. === For the impatient: 1) Download gr-cdma from github > git clone https://github.com/anastas/gr-cdma.git 2) Build the package > mkdir build_cdma > cd build_cdma > cmake -DENABLE_DOXYGEN=ON ../gr-cdma > make > sudo make install > sudo ldconfig 3) compile hierarchical blocks and play with built in app > cd gr-cdma/apps > gnuradio-companion & In the gnuradio-companion environment -- Load the hier block "amp_var_est_hier.grc", "cdma_tx_hier.grc", "chopper_correlator1.grc", "cdma_rx_hier.grc" and compile them making sure to reload blocks after each compilation -- Load the application "cdma_txrx.grc" and have fun Experiment with manual acq/tra, auto acq/tra, changing freq and timing offset, SNR, etc -- If you have 2 USRPs load the cdma_tx.grc and cdma_rx.grc and enjoy real-time CDMA transmission. You can also use the cdma_tx.grc and cdma_rx.grc by writting and reading to a fifo (first do > makefifo /tmp/cdma.fifo) = best, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSoC2014 Turbo Equalizer
Mike, there are roughly 3 ways you can parallelize these algorithms: 1) packet-level: run a lot of codewords at the same time 2) subblock level: divide each codeword into pieces (overlapping) and run SISOs on each one of them in parallel 3) trellis level: do ACS operations in parallel take a look at the following link and references to get some ideas (not claiming it is a seminal paper though :-)) http://web.eecs.umich.edu/~anastas/docs/turbogpu.pdf best, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSoC2014 Turbo Equalizer
Yes, I agree with Tom. A good starting point is the three or four core algorithms in gr-trellis/lib/core_algorithms.cc viterbi_algorithm, siso_algorithm, sccc_decoder pccc_decoder (and their "_combined" versions) Jan, let me know if you decide to work on these; I can provide some ideas if you are interested. best, Achilleas On Tue, Feb 25, 2014 at 10:47 AM, Tom Rondeau wrote: > On Tue, Feb 25, 2014 at 10:39 AM, Achilleas Anastasopoulos > wrote: > > Just FYI, the gr-trellis has implementations of all these components you > > suggested. > > > > One interesting project is to take the core algorithms of gr-trellis > > (Viterbi and SISO) and make them threaded for multi-core > > (eg, by parallelizing forward/backward recursions, or by parallelizing > using > > overlapping subblocks, etc) > > > > best > > Achilleas > > Also using VOLK inside gr-trellis blocks should provide significant > speedup there. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GSoC2014 Turbo Equalizer
Just FYI, the gr-trellis has implementations of all these components you suggested. One interesting project is to take the core algorithms of gr-trellis (Viterbi and SISO) and make them threaded for multi-core (eg, by parallelizing forward/backward recursions, or by parallelizing using overlapping subblocks, etc) best Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] simple control of wxgui application
I have a simple python gui application (compiled from grc)
that I want to control by adding some sleep statement in the main
and changing some variables as it runs and then stop it.
The code produced by grc looks like:
...
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
(options, args) = parser.parse_args()
tb = my_test()
tb.Start(True)
tb.Wait()
I would like to add some sleep statement and change some variables after
starting the application and then stop it after some time.
How is this done?
(I have an idea how to do that in non-gui, but not for gui apps).
thanks
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Documentation for out-of-tree module
Tom, thanks,for the reply. Just want to confirm that in the current way gr_modtool generates a new OOT module, no matter what content we put on the "docs" directory, this will not result in an invocation of doxygen, and thus it will not generate ANY kind of manual (not necessarily from header files, but even , say, a intro page for the module). Can you confirm that. thanks again Achilleas On Wed, Feb 5, 2014 at 4:58 AM, Tom Rondeau wrote: > On Tue, Feb 4, 2014 at 7:51 PM, Achilleas Anastasopoulos > wrote: > > > > To add to the question: > > > > > > And what about the documentation on the C++ header files? > > Achilleas, > > We definitely want to support this. Possibly we just don't have the > hooks that take the doc xml output and insert them into the GRC files. > Will have to check into the issue. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question on discrepancy between local vs web gnuradio documentation
$ doxygen --version 1.8.3.1 this is really strange... any suggestions what to try next? thanks Achilleas On Tue, Feb 4, 2014 at 6:40 PM, Tom Rondeau wrote: > On Tue, Feb 4, 2014 at 11:35 PM, Achilleas Anastasopoulos > wrote: > > When I point my browser to > > > > http://gnuradio.org/doc/doxygen/index.html > > > > I see the gnuradio documentation including > > Main Page > > Related Topics > > Modules > > Namespaces > > Classes > > Files > > > > Now when I build my local gnuradio with enabled docs and point my > browser > > to > > > > file:///usr/local/share/doc/gnuradio-3.7.2git/html/index.html > > > > I only see a subset of this, in particular: > > Namespaces > > Classes > > Files > > > > where are the rest of the pages? > > Am i doing something wrong? > > > > thanks > > Achilles > > > I think that's related to the Doxygen version used to build the docs > with. You should still have all of the pages, just organized > differently. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question on discrepancy between local vs web gnuradio documentation
When I point my browser to http://gnuradio.org/doc/doxygen/index.html I see the gnuradio documentation including Main Page Related Topics Modules Namespaces Classes Files Now when I build my local gnuradio with enabled docs and point my browser to file:///usr/local/share/doc/gnuradio-3.7.2git/html/index.html I only see a subset of this, in particular: Namespaces Classes Files where are the rest of the pages? Am i doing something wrong? thanks Achilles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: Documentation for out-of-tree module
To add to the question: And what about the documentation on the C++ header files? Ie, in gr-xxx/include/xxx there are C++ header files which can be documented. How is this documentation generated and installed using cmake, etc. in an OOT module? Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error in hier block with 4 outputs and an async message!
SUCCESS!! after renaming the output message pad as zzz_something, the right order is restored! I will make sure to file a bug ticket on this, but for now I am set. thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error in hier block with 4 outputs and an async message!
Marcus, the error is still there even if you don't have direct connections between in/out pads. See attached Achilleas test_msg_hier.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error in hier block with 4 outputs and an async message!
Please see attached simple hier block with 4 complex outputs and 1 async message output. Everything compiles but the application does not run giving python error: Using Volk machine: sse4_1_64_orc Traceback (most recent call last): File "./test_msg.py", line 67, in tb = test_msg() File "./test_msg.py", line 31, in __init__ self.test_msg_hier_0 = test_msg_hier() File "/home/anastas/.grc_gnuradio/test_msg_hier.py", line 34, in __init__ self.connect((self, 0), (self, 0)) File "/usr/local/lib64/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 75, in connect self._connect(points[i-1], points[i]) File "/usr/local/lib64/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 81, in _connect dst_block.to_basic_block(), dst_port) File "/usr/local/lib64/python2.7/site-packages/gnuradio/gr/runtime_swig.py", line 2848, in primitive_connect return _runtime_swig.hier_block2_sptr_primitive_connect(self, *args) ValueError: connect: src and destination blocks cannot be the same Notice that the python file of the hier block indexes outputs as 0,1,2,4 instead of 0,1,2,3 ? Achilleas --- linux; GNU C++ version 4.8.2 20131017 (Red Hat 4.8.2-1); Boost_105300; UHD_003.005.004-143-gde4ce9ea <<< Welcome to GNU Radio Companion 3.7.2git-142-g66196335 >>> test_msg_hier.grc Description: Binary data test_msg.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] hier blocks with message output pads
Sebastian,
it turns out that the colour mismatch was not the issue here (your pointed
questions
made me realize that).
There must be a problem with hier blocks with 4 or more ports (one of which
is an async message)!!!
I attach here a trivial example.
I will also repost this question under a separate title on the mailing
list...
Achilleas
On Thu, Jan 30, 2014 at 6:35 AM, Koslowski, Sebastian (CEL) <
sebastian.koslow...@kit.edu> wrote:
>
> On 01/29/2014 06:20 PM, Achilleas Anastasopoulos wrote:
> > 1) the colour of the pad connection is not exactly the same as the
> > message connection (maybe this implies something...)
>
> Like the color difference between "Message Queue" and "Async Message"
> ports (see Help-->Types)?
>
> > When I compile the block, the python code does not have any
> > signature that refers to the message output.
>
> Can you provide an example (your files, a screen-shot, a generic
> example,...)?
>
> Sebastian
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Sebastian Koslowski
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe, Germany
>
> Phone: +49 721 608-46275
> Fax: +49 721 608-46071
> Email: sebastian.koslow...@kit.edu
> Web: http://www.cel.kit.edu/
>
> KIT - University of the State of Baden-Wuerttemberg and National
> Research Center of the Helmholtz Association
>
>
test_msg_hier.grc
Description: Binary data
#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: test_msg
# Author: Achilleas
# Generated: Thu Jan 30 16:01:40 2014
##
execfile("/home/anastas/.grc_gnuradio/test_msg_hier.py")
from gnuradio import analog
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
class test_msg(gr.top_block):
def __init__(self):
gr.top_block.__init__(self, "test_msg")
##
# Variables
##
self.samp_rate = samp_rate = 32000
##
# Blocks
##
self.test_msg_hier_0 = test_msg_hier()
self.blocks_throttle_0 = blocks.throttle(gr.sizeof_gr_complex*1, samp_rate)
self.blocks_null_sink_0_3_1_0 = blocks.null_sink(gr.sizeof_float*1)
self.blocks_null_sink_0_3_1 = blocks.null_sink(gr.sizeof_gr_complex*1)
self.blocks_null_sink_0_3 = blocks.null_sink(gr.sizeof_gr_complex*1)
self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_gr_complex*1)
self.blocks_message_debug_0 = blocks.message_debug()
self.analog_const_source_x_0 = analog.sig_source_c(0, analog.GR_CONST_WAVE, 0, 0, 0)
##
# Connections
##
self.connect((self.analog_const_source_x_0, 0), (self.blocks_throttle_0, 0))
self.connect((self.blocks_throttle_0, 0), (self.test_msg_hier_0, 0))
self.connect((self.test_msg_hier_0, 0), (self.blocks_null_sink_0, 0))
self.connect((self.test_msg_hier_0, 1), (self.blocks_null_sink_0_3, 0))
self.connect((self.test_msg_hier_0, 2), (self.blocks_null_sink_0_3_1, 0))
self.connect((self.test_msg_hier_0, 3), (self.blocks_null_sink_0_3_1_0, 0))
##
# Asynch Message Connections
##
self.msg_connect(self.test_msg_hier_0, "out_msg", self.blocks_message_debug_0, "print")
# QT sink close method reimplementation
def get_samp_rate(self):
return self.samp_rate
def set_samp_rate(self, samp_rate):
self.samp_rate = samp_rate
self.blocks_throttle_0.set_sample_rate(self.samp_rate)
if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
(options, args) = parser.parse_args()
tb = test_msg()
tb.start()
raw_input('Press Enter to quit: ')
tb.stop()
tb.wait()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] hier blocks with message output pads
Hi there, I am having the following problem: I create a simple hier block in grc and one of the outputs is a message. I added an output pad with message port, but I see two issues: 1) the colour of the pad connection is not exactly the same as the message connection (maybe this implies something...) When I compile the block, the python code does not have any signature that refers to the message output. Am i doing something obviously wrong? Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Looking for DSSS demodulator
Bob, As I mentioned in my email, the only application that currently runs is the timing_test.grc For it to run you need to load the block chopper_correlator.grc and compile it in grc so that it gets to your custom grc directory. Please let me know if you have any issues with this. This application contains all the essentials for the cdma system, but it is not THE cdma system... The whole project is built on gnuradio 3.7.2 The remaining apps/blocks for cdma are work-in-progress. best, Achilleas On Fri, Nov 22, 2013 at 10:19 AM, bob wole wrote: > Great share Achilleas. But I am having problem running it. Quite a few > blocks are missing. Please share on what version of GnuRadio was it built > against? Did you use custom blocks too? > > -- > Bob > > >> >> Outstanding! Thanks for putting in the time to make this happen! >> >> What version of gnuRadio was it built against? >> >> @(^.^)@ Ed >> >> >> >> On 11/20/13 4:05 PM, Achilleas Anastasopoulos wrote: >> > I have been working on a DSSS system for some time now. >> > You can find our work-in-progress here: >> > >> > https://github.com/anastas/gr-cdma.git >> > >> > A few comments: >> > >> > this project grew out of the DARPA spectrum challenge: >> > our team eventually dropped out of the race because of other time >> > commitments but >> > I decided to finish up the design and make it publicly available >> > since DARPA was generous enough to send us USRPs for testing etc. >> >> >> >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Looking for DSSS demodulator
I have been working on a DSSS system for some time now. You can find our work-in-progress here: https://github.com/anastas/gr-cdma.git A few comments: this project grew out of the DARPA spectrum challenge: our team eventually dropped out of the race because of other time commitments but I decided to finish up the design and make it publicly available since DARPA was generous enough to send us USRPs for testing etc. Now about the gr-cdma project: The idea is to build a fully parametrized DS system. Users can set spreading , modulation, framing parameters etc. The structure is as follows: There is a frame structure and in each frame we superimpose 2 orthogonal channels: 1) training/synchronization and 2) data. At the receiver, there is a time/frequency searching engine (consisting of a user defined number of correlators at different freqiuencies) that looks at the sync channel and can move nicely between Acquisition mode and Tracking mode This part is really cool, since at Ack we spend a lot of computational resources (N chip based matched filters over the entire frame, each of length chips_per_frame), while at tracking very few (1 despreading MF of length chips_per_symbol). Once ack/tracking is done the rest of the Rx is trivial: The frames are handed to the rest of the Rx which correlates with the data pn-sequence, despreads, phase-tracks and demodulates data. That said the project is not yet ready for prime time, but I took the opportunity to announce it due to this request on the list. The basic idea of the automatic Acquisition/Tracking is ready and tested and can be found in the application apps/timing_test.grc as well as the individual apps (in case you want to try to to different machines) apps/timing_test_tx.grc and apps/timing_test_rx.grc The cool thing about those is that they are build exclusively on grc using "probe" and "function probe" blocks to detect SNR level and switch between acquisition and tracking (there is an option to do it manually or auto). I anticipate that in a few weeks the system can be fully functional...but cannot promise that..I work on it on my spare time... best, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug in freq_xlating_fir_filter_XXX
I stand corrected.
Everything works fine with the new patch now!
thanks for the help,
Achilleas
On Thu, Oct 10, 2013 at 11:22 AM, Tom Rondeau wrote:
> On Wed, Oct 9, 2013 at 11:01 PM, Achilleas Anastasopoulos
> wrote:
> > I attach the patch for this correction
> > (for some reason I cannot git push...)
> >
> > Achilleas
>
> Sorry for the delay getting back to you. I walked through the math
> myself but couldn't find where you were wrong, but I knew this patch
> changed the sign of frequency translation. Just try it with a sine
> wave a 1 kHz and set the Center Frequency to 1 kHz. The signal out is
> not at 2 kHz.
>
> Turns out we were both missing something. This just spins the filter
> from baseband to bandpass around fwT0, but there's still the rotator
> (d_r) that is responsible for spinning the output down.
>
> Basically, we're changing x(t) -> (mult by -fwT0) -> LPF -> y(t)
> Into: x(t) -> BPF -> (mult by fwT0) -> y(t)
>
> (The block is also taking into account downsampling that's not
> accounted for above such that we downsample in the filter before down
> shifting in frequency.)
>
> So this, I think, is the correct patch:
>
> diff --git a/gr-filter/lib/freq_xlating_fir_filter_XXX_impl.cc.t
> b/gr-filter/lib/freq_xlating_fir_filter_XXX_impl.cc.t
> index 72a2c05..f3c8ffd 100644
> --- a/gr-filter/lib/freq_xlating_fir_filter_XXX_impl.cc.t
> +++ b/gr-filter/lib/freq_xlating_fir_filter_XXX_impl.cc.t
> @@ -77,14 +77,15 @@ namespace gr {
> {
>std::vector ctaps(d_proto_taps.size());
>
> - float fwT0 = -2 * M_PI * d_center_freq / d_sampling_freq;
> + //float fwT0 = -2 * M_PI * d_center_freq / d_sampling_freq;
> + float fwT0 = 2 * M_PI * d_center_freq / d_sampling_freq;
>for(unsigned int i = 0; i < d_proto_taps.size(); i++) {
> ctaps[i] = d_proto_taps[i] * exp(gr_complex(0, i * fwT0));
>}
>
> - std::reverse(ctaps.begin(), ctaps.end());
> + //std::reverse(ctaps.begin(), ctaps.end());
>d_composite_fir->set_taps(ctaps);
> - d_r.set_phase_incr(exp(gr_complex(0, fwT0 * decimation(;
> + d_r.set_phase_incr(exp(gr_complex(0, -fwT0 * decimation(;
> }
>
> void
>
>
> Tom
>
>
>
> > On Wed, Oct 9, 2013 at 12:59 PM, Achilleas Anastasopoulos
> > wrote:
> >>
> >> Maybe I am wrong, but here is the idea:
> >>
> >> the original taps are "taps".
> >> then inside the freq_xlating filter new "combined" taps are generated
> >> as follows
> >>
> >> comb_t = taps_t *exp(-j A t)
> >>
> >> then the COMBINED filter is reversed.
> >> The effect of that is that essentially we have the filter
> >>
> >> reversed_t = taps_{-t} *exp( + j A t)
> >>
> >> If we drop the reversing part from the process (commenting out one line
> of
> >> code) we will end up
> >> with the filter nonreversed with
> >>
> >> nonrevered_t = comb_t = taps_t *exp(-j A t)
> >>
> >> Comparing the reveresed and non-reversed we see that even when taps are
> >> symmetric, the frequency sign gas changed so we need to change it back!
> >>
> >> let me know if i am missing something,
> >> Achilleas
> >>
> >>
> >>
> >> On Wed, Oct 9, 2013 at 11:02 AM, Tom Rondeau wrote:
> >>>
> >>> On Wed, Oct 9, 2013 at 10:45 AM, Achilleas Anastasopoulos
> >>> wrote:
> >>> > I will submit the patch.
> >>> >
> >>> > regarding the sign change in frequency, I didn't mean to change the
> >>> > convention:
> >>> > the sign change IS REQUIRED in order to KEEP the convention because
> now
> >>> > the taps are not reversed...
> >>> >
> >>> > Achilleas
> >>>
> >>> Sorry, Achilleas, I'm not seeing it. In the common case of a symmetric
> >>> FIR filter, the reverse function doesn't change any behavior, but the
> >>> minus sine definitely does.
> >>>
> >>> I don't see how reversing the order of the filter taps and changing
> >>> the sign have anything to do with each other.
> >>>
> >>> Tom
> >>>
> >>>
> >>> > On Wed, Oct 9, 2013 at 9:20 AM, Tom Rondeau
> wrote:
> >>> >>
> >>> >> On Tue, Oct 8, 2013 at 9:39 PM, Achilleas Anastasopoulos
> >>> >> wrote:
> >>> >> >
> >>> >>
Re: [Discuss-gnuradio] Bug in freq_xlating_fir_filter_XXX
I attach the patch for this correction
(for some reason I cannot git push...)
Achilleas
On Wed, Oct 9, 2013 at 12:59 PM, Achilleas Anastasopoulos wrote:
> Maybe I am wrong, but here is the idea:
>
> the original taps are "taps".
> then inside the freq_xlating filter new "combined" taps are generated
> as follows
>
> comb_t = taps_t *exp(-j A t)
>
> then the COMBINED filter is reversed.
> The effect of that is that essentially we have the filter
>
> reversed_t = taps_{-t} *exp( + j A t)
>
> If we drop the reversing part from the process (commenting out one line of
> code) we will end up
> with the filter nonreversed with
>
> nonrevered_t = comb_t = taps_t *exp(-j A t)
>
> Comparing the reveresed and non-reversed we see that even when taps are
> symmetric, the frequency sign gas changed so we need to change it back!
>
> let me know if i am missing something,
> Achilleas
>
>
>
> On Wed, Oct 9, 2013 at 11:02 AM, Tom Rondeau wrote:
>
>> On Wed, Oct 9, 2013 at 10:45 AM, Achilleas Anastasopoulos
>> wrote:
>> > I will submit the patch.
>> >
>> > regarding the sign change in frequency, I didn't mean to change the
>> > convention:
>> > the sign change IS REQUIRED in order to KEEP the convention because now
>> > the taps are not reversed...
>> >
>> > Achilleas
>>
>> Sorry, Achilleas, I'm not seeing it. In the common case of a symmetric
>> FIR filter, the reverse function doesn't change any behavior, but the
>> minus sine definitely does.
>>
>> I don't see how reversing the order of the filter taps and changing
>> the sign have anything to do with each other.
>>
>> Tom
>>
>>
>> > On Wed, Oct 9, 2013 at 9:20 AM, Tom Rondeau wrote:
>> >>
>> >> On Tue, Oct 8, 2013 at 9:39 PM, Achilleas Anastasopoulos
>> >> wrote:
>> >> >
>> >> > I was playing around with
>> >> >
>> >> > fir_filter_XXX
>> >> >
>> >> > and
>> >> >
>> >> > freq_xlating_fir_filter_XXX
>> >> >
>> >> > and noticed that the two do not give the same output
>> >> > for the same input (and center_freq=0 in the xlating filter).
>> >> >
>> >> > Looking at the implementation of the latter
>> >> > it is obvious why: the taps are reversed in the line:
>> >> >
>> >> > std::reverse(ctaps.begin(), ctaps.end());
>> >> >
>> >> > For consistency the taps should not be reversed (as in all other
>> >> > filters)
>> >> > We also need to set
>> >>
>> >> Yes, please submit a patch for this. The taps are reversed inside the
>> >> fir filters, so this is redundant and confusing. Most people probably
>> >> use symmetric filter taps, which is why it has not been found.
>> >>
>> >> > float fwT0 = 2 * M_PI * d_center_freq / d_sampling_freq;
>> >> >
>> >> > (instead of the minus sign in the code).
>> >> >
>> >> > unless there is an objection, I will go ahead and push a correction,
>> >> > Achilleas
>> >>
>> >> Don't change the sign of the frequency. I know this is controversial,
>> >> but from my experience with users, more people find the current way
>> >> easier to understand. We're telling the filter what the center
>> >> frequency is, which means that we will take a signal at Fc and
>> >> downshift it to DC. To me, if we're on carrier Fc and we specify -Fc
>> >> as the "Center Frequency", that's more confusing.
>> >>
>> >> Tom
>> >
>> >
>>
>
>
0001-fixed-freq_xlating_filter-block-so-that-it-does-not-.patch
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug in freq_xlating_fir_filter_XXX
Maybe I am wrong, but here is the idea:
the original taps are "taps".
then inside the freq_xlating filter new "combined" taps are generated
as follows
comb_t = taps_t *exp(-j A t)
then the COMBINED filter is reversed.
The effect of that is that essentially we have the filter
reversed_t = taps_{-t} *exp( + j A t)
If we drop the reversing part from the process (commenting out one line of
code) we will end up
with the filter nonreversed with
nonrevered_t = comb_t = taps_t *exp(-j A t)
Comparing the reveresed and non-reversed we see that even when taps are
symmetric, the frequency sign gas changed so we need to change it back!
let me know if i am missing something,
Achilleas
On Wed, Oct 9, 2013 at 11:02 AM, Tom Rondeau wrote:
> On Wed, Oct 9, 2013 at 10:45 AM, Achilleas Anastasopoulos
> wrote:
> > I will submit the patch.
> >
> > regarding the sign change in frequency, I didn't mean to change the
> > convention:
> > the sign change IS REQUIRED in order to KEEP the convention because now
> > the taps are not reversed...
> >
> > Achilleas
>
> Sorry, Achilleas, I'm not seeing it. In the common case of a symmetric
> FIR filter, the reverse function doesn't change any behavior, but the
> minus sine definitely does.
>
> I don't see how reversing the order of the filter taps and changing
> the sign have anything to do with each other.
>
> Tom
>
>
> > On Wed, Oct 9, 2013 at 9:20 AM, Tom Rondeau wrote:
> >>
> >> On Tue, Oct 8, 2013 at 9:39 PM, Achilleas Anastasopoulos
> >> wrote:
> >> >
> >> > I was playing around with
> >> >
> >> > fir_filter_XXX
> >> >
> >> > and
> >> >
> >> > freq_xlating_fir_filter_XXX
> >> >
> >> > and noticed that the two do not give the same output
> >> > for the same input (and center_freq=0 in the xlating filter).
> >> >
> >> > Looking at the implementation of the latter
> >> > it is obvious why: the taps are reversed in the line:
> >> >
> >> > std::reverse(ctaps.begin(), ctaps.end());
> >> >
> >> > For consistency the taps should not be reversed (as in all other
> >> > filters)
> >> > We also need to set
> >>
> >> Yes, please submit a patch for this. The taps are reversed inside the
> >> fir filters, so this is redundant and confusing. Most people probably
> >> use symmetric filter taps, which is why it has not been found.
> >>
> >> > float fwT0 = 2 * M_PI * d_center_freq / d_sampling_freq;
> >> >
> >> > (instead of the minus sign in the code).
> >> >
> >> > unless there is an objection, I will go ahead and push a correction,
> >> > Achilleas
> >>
> >> Don't change the sign of the frequency. I know this is controversial,
> >> but from my experience with users, more people find the current way
> >> easier to understand. We're telling the filter what the center
> >> frequency is, which means that we will take a signal at Fc and
> >> downshift it to DC. To me, if we're on carrier Fc and we specify -Fc
> >> as the "Center Frequency", that's more confusing.
> >>
> >> Tom
> >
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug in freq_xlating_fir_filter_XXX
I will submit the patch. regarding the sign change in frequency, I didn't mean to change the convention: the sign change IS REQUIRED in order to KEEP the convention because now the taps are not reversed... Achilleas On Wed, Oct 9, 2013 at 9:20 AM, Tom Rondeau wrote: > On Tue, Oct 8, 2013 at 9:39 PM, Achilleas Anastasopoulos > wrote: > > > > I was playing around with > > > > fir_filter_XXX > > > > and > > > > freq_xlating_fir_filter_XXX > > > > and noticed that the two do not give the same output > > for the same input (and center_freq=0 in the xlating filter). > > > > Looking at the implementation of the latter > > it is obvious why: the taps are reversed in the line: > > > > std::reverse(ctaps.begin(), ctaps.end()); > > > > For consistency the taps should not be reversed (as in all other filters) > > We also need to set > > Yes, please submit a patch for this. The taps are reversed inside the > fir filters, so this is redundant and confusing. Most people probably > use symmetric filter taps, which is why it has not been found. > > > float fwT0 = 2 * M_PI * d_center_freq / d_sampling_freq; > > > > (instead of the minus sign in the code). > > > > unless there is an objection, I will go ahead and push a correction, > > Achilleas > > Don't change the sign of the frequency. I know this is controversial, > but from my experience with users, more people find the current way > easier to understand. We're telling the filter what the center > frequency is, which means that we will take a signal at Fc and > downshift it to DC. To me, if we're on carrier Fc and we specify -Fc > as the "Center Frequency", that's more confusing. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
