[Discuss-gnuradio] spectrum record
Hi list, I want to record a 5MHz wide bandwidth with usrp1 (equipped with dbsrx1 and modified clock @ 52MHz), can anyone guide me how to do this, I am using usrp_rx_cfile (using gnuradio-3.4.2 for special purpose) with gain =52 decimation= 26 Please do let me know if I need to make any changes in any file to accomplish my task. Thanks in advance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with large number of inputs.
Having your complete general_work function wouldn't have hurt my
understanding much...
I really can't make out what you're trying to do without doubt.
Anyway, from the code below I think in *must at least* have the same
number of entries that your for loop has iterations; did you just try using
d_group * N_FS(d_normal) instead of d_N_phich_group * N_FS_phich(d_normal_cp)
when allocating your array?
It seems to me that having two ways to determine how many inputs there is a
likely cause for mistake. Use the size() of the input_items to determine how
many inputs you really have, and assert(input_items.size() ==
number_of_inputs_like_I_calculate_it); to make sure things line up.
Also, the whole process seems unnecessary, since you do nothing more than
copying the pointers from input_items to in; the typecast is nothing but
syntactic magic and can be done by having in = ((const gr_complex*)*)
input_items;; also, I encourage you to use the C++-style explicit cast
operators (in this case, reinterpret_cast) for their clarity, but that's more
a question of personal liking :)
Greetings,
Marcus
On 26.07.2014 21:55, Mostafa Alizadeh wrote:
Hi Marcus,
You're right. I didn't clarify the problem.
Actually in C++, I wrote:
block_impl::block_impl(bool normal, int group)
: gr::block(phich_grouping,
gr::io_signature::make(1, group * N_FS(normal), sizeof
(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
// N_FS function returns 8 or 4 depends on its input.
// in the work function :
// d_normal and d_group are defined in the .h file
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
for (int i=0; id_group * N_FS(d_normal); i++)
{
in[i] = (const gr_complex *) input_items[i];
}
when I set the group value to 3, the number of input ports would be 24.
In this case, I want to access to one element of in like this:
cout in in[0][0] endl;
I got the aforementioned error!
But when I set group = 1 which means 8 input ports, all things are fine.
any idea please,
Best
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] spectrum record
Hi gsmandvoip, Your decimation seems about right (oh, I don't miss libusrp). I don't think you need to change the example, but please be aware that libusrp has become so obsolete that I don't even have the source code around anymore. I'm not totally sure you need to use libusrp to have openBTS (which is what I guess you mean by special purpose): http://wush.net/trac/rangepublic/wiki/BuildInstallRun I haven't tried, but I'm fairly certain that UHD still supports the B100/USRP1 (and that GNU Radio thus did not drop support for that on 3.5.0), and thus I don't really know why the combination OpenBTS and USRP1 calls for GR3.4.2; is there someone who could enlighten me? I'm fairly certain I've been sending text messages over openBTS that was operating a B210, so UHDopenBTS *should* work... Greetings, Marcus On 27.07.2014 12:08, gsmandvoip wrote: Hi list, I want to record a 5MHz wide bandwidth with usrp1 (equipped with dbsrx1 and modified clock @ 52MHz), can anyone guide me how to do this, I am using usrp_rx_cfile (using gnuradio-3.4.2 for special purpose) with gain =52 decimation= 26 Please do let me know if I need to make any changes in any file to accomplish my task. Thanks in advance ___ 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] Persistence Checkbox of WX GUI Scope Plot
Dear Sir, It is found that in newer version of gnuradio, the WX GUI Scope Sink doesn't have a Persistence checkbox. In this case how to get back the feature ..? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New WX GUI Scope Sink
On Sun, Jul 27, 2014 at 10:36 AM, Activecat active...@gmail.com wrote: Dear Sir, The new WX GUI Scope Sink behaves slightly differently from the previous one. How come it only plots the center part (as circled), how to make it plot the full graph without changing the time/div of x-axis? Activecat, We haven't changed anything in the wxgui for quite some time. My guess from this and your last post is that it's either a version issue of wxWidgets/wxPython on your machine or that you are not using the OpenGL versions of the pltoters. Check to make sure that python-opengl is installed. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Narrowband Tunnel.py Error
On Fri, Jul 25, 2014 at 4:28 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: On Fri, Jul 25, 2014 at 1:13 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jul 24, 2014 at 7:42 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: Thanks for the response. A colleague of mine recommended going into the uhd_interface file and change the self.u.set_center_freq() and not use the lo_offset as a parameter. Then again it couldn't hurt to just add the command line argument. Thank you for the gr-mac link, it is within my interests to use it. Jonathan Best to focus on using gr-mac. Getting started with it might be a bit difficult, but it's far superior to tunnel.py and where we want to go, anyways. GNU Radio will hopefully be adopting this in the future, too, and removing tunnel.py. Tom On Thu, Jul 24, 2014 at 7:09 PM, Mike Jameson mike.jame...@ettus.com wrote: Try adding '--lo-offset=10e6' as a commandline argument. Thanks for the bug report, I'll push a fix asap. FYI, the tunnel.py script has been superseded by gr-mac: https://github.com/balint256/gr-mac Mike -- Mike Jameson M0MIK BSc MIET Ettus Research Technical Support Email: supp...@ettus.com Web: http://ettus.com On Thu, Jul 24, 2014 at 10:15 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: I am currently running GNU Radio 3.7.4 and I am getting an error running the stock narrowband tunnel.py script. This is what I am getting: [root@cobra narrowband]# ./tunnel.py -f 146.0M -a addr=10.2.8.104 linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-4); Boost_104100; UHD_003.007.001-64-g92b0b7ab Using Volk machine: sse4_2_64 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 -- Detecting internal GPSDO Found an internal GPSDO -- found -- Setting references to the internal GPSDO -- Initializing time to the internal GPSDO No gain specified. Setting gain to 19.00 (from [0.00, 38.00]) Traceback (most recent call last): File ./tunnel.py, line 296, in module main() File ./tunnel.py, line 259, in main options) File ./tunnel.py, line 103, in __init__ options.verbose) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 199, in __init__ freq, lo_offset, gain, spec, antenna, clock_source) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 70, in __init__ self._freq = self.set_freq(freq, lo_offset) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 120, in set_freq r = self.u.set_center_freq(uhd.tune_request(freq, lo_offset)) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/__init__.py, line 52, in __init__ super(tune_request_t, self).__init__(*args) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 792, in __init__ this = _uhd_swig.new_tune_request_t(*args) NotImplementedError: Wrong number of arguments for overloaded function 'new_tune_request_t'. Possible C/C++ prototypes are: uhd::tune_request_t(double) uhd::tune_request_t(double,double) I am not too sure what to do, I have looked up the error but I couldn't find a solution. Anyone know what to do? Also, the benchmark scripts work, it is just the tunnel script that doesn't. Thanks Jonathan I did try the --lo-offset=10e6 argument and it didn't work. I may just have to tweak the self.u.set_center_freq to not have the uhd.tune_request because it doesn't work just as self.u.set_center_freq(uhd.tune_request(freq)). I know the latest version of GNU Radio has a burst tagger block, so is the gr-mac project already incorporated? No. As I said, we will hopefully be adopting it in the future, but it is still a separate project. And the burst tagger block has been in GNU Radio for quite some time. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute
I followed the tutorial to generate a module and all was well. My square module worked. I then created a new module invert_bb. This also worked. So far so good. Now a few days later on I get AttributeError: 'module' object has no attribute 'invert_bb' and I have no clue as to why. The previous QA tests that passed before now fail. I have not been able to find much documentation and Google does not seem to help, lots of people with this error, no solutions. Any idea why something would work one day and not the next? I have spent 6 or so hours trying to solve this one by myself. I have made, remade, cleaned, installed, uninstalled, reinstalled and even gone back to re-installing gnuradio via pybombs but the error persists. I assume something somewhere has become corrupted but the way blocks are implmented is extremely complex and beyond my ability to understand. Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute
Hi Mike, my first guess if making from scratch didn't help: maybe your module's name is conflicting with an existing module, or there are remnants of a former installation lying around for some reasons. You could try uninstalling your module via make uninstall, and then running a python trying to import yourmodule; if that doesn't fail, we know there's a conflict. Another popular source for errors are spaces and special characters in paths; but since you didn't move your module, this is not very likely the cause. Btw: what's your GNU Radio version (gnuradio-config-info -v)? Greetings, Marcus On 27.07.2014 18:17, Mike wrote: I followed the tutorial to generate a module and all was well. My square module worked. I then created a new module invert_bb. This also worked. So far so good. Now a few days later on I get AttributeError: 'module' object has no attribute 'invert_bb' and I have no clue as to why. The previous QA tests that passed before now fail. I have not been able to find much documentation and Google does not seem to help, lots of people with this error, no solutions. Any idea why something would work one day and not the next? I have spent 6 or so hours trying to solve this one by myself. I have made, remade, cleaned, installed, uninstalled, reinstalled and even gone back to re-installing gnuradio via pybombs but the error persists. I assume something somewhere has become corrupted but the way blocks are implmented is extremely complex and beyond my ability to understand. Mike ___ 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] [USRP-users] USRP-users Digest, Vol 47, Issue 27
Hi Mike, is it possible that you are responding to my response on gnuradio by replying to the usrp-users digest? I'm a little confused... The stopped working might be explained by the fact that as soon as you update a library (ie. as soon as you update GNU Radio), you need to rebuild all software against the new version. But that doesn't explain the no invert_bb in modulename error. Are you positive that you deleted the build/ directory of your module, and run a cmake .. on it, make and make install? Greetings, Marcus On 27.07.2014 18:53, Mike Willis via USRP-users wrote: Hi Its now 3.7.5git-88-gfd0db71f as I did a complete re-install. Before that is was 3.7.4. I suppose its possible its a clash, but on all modules in the tree? I would remove them one by one and see which is a problem but i don't want to lose all my work on each one. I have made several modules now and they have suddenly stopped working. I was editing one of my modules so I could have messed things up in some database perhaps. after sudo make uninstall running a flowgraph now gives me: Traceback (most recent call last): File /home/mike/Demod_Multirate_file.py, line 22, in module import ukube ImportError: No module named ukube Suspect maybe but I think that's what I would expect. Mike ___ USRP-users mailing list usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with large number of inputs.
Thank you for your notes Marcus,
As you said this is unnecessary process to point to the input_items in a
for loop!!
However, this is not the problem because I checked that I have the same
number of iteration in the for loop as the number of input ports.
The problem is somewhere else. *Again I must mention that if I use, only 8
input ports, the code runs perfectly,* however, with 24 inputs, it does
something wrong! (perhaps pointing to somewhere in the memory which is not
allocated to the input as it seemed to allocated to the input!). In another
words, when I want to access the first input of the first input port, I can
write:
gr_complex **in = (gr_complex) input_items;
// for example
cout in[0][0] endl;
The program terminated with unexpected error!
Please help me, where is the problem?? :(
On Sun, Jul 27, 2014 at 4:21 AM, Marcus Müller marcus.muel...@ettus.com
wrote:
Having your complete general_work function wouldn't have hurt my
understanding much...
I really can't make out what you're trying to do without doubt.
Anyway, from the code below I think in *must at least* have the same
number of entries that your for loop has iterations; did you just try using
d_group * N_FS(d_normal) instead of d_N_phich_group *
N_FS_phich(d_normal_cp) when allocating your array?
It seems to me that having two ways to determine how many inputs there is
a likely cause for mistake. Use the size() of the input_items to determine
how many inputs you really have, and assert(input_items.size() ==
number_of_inputs_like_I_calculate_it); to make sure things line up.
Also, the whole process seems unnecessary, since you do nothing more than
copying the pointers from input_items to in; the typecast is nothing but
syntactic magic and can be done by having in = ((const gr_complex*)*)
input_items;; also, I encourage you to use the C++-style explicit cast
operators (in this case, reinterpret_cast) for their clarity, but that's
more a question of personal liking :)
Greetings,
Marcus
On 26.07.2014 21:55, Mostafa Alizadeh wrote:
Hi Marcus,
You're right. I didn't clarify the problem.
Actually in C++, I wrote:
block_impl::block_impl(bool normal, int group)
: gr::block(phich_grouping,
gr::io_signature::make(1, group * N_FS(normal), sizeof
(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
// N_FS function returns 8 or 4 depends on its input.
// in the work function :
// d_normal and d_group are defined in the .h file
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
for (int i=0; id_group * N_FS(d_normal); i++)
{
in[i] = (const gr_complex *) input_items[i];
}
when I set the group value to 3, the number of input ports would be 24.
In this case, I want to access to one element of in like this:
cout in in[0][0] endl;
I got the aforementioned error!
But when I set group = 1 which means 8 input ports, all things are
fine.
any idea please,
Best
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with large number of inputs.
As I said, you should use the gdb debugging approach to find the mistake.
gr_complex **in = (gr_complex) input_items; shouldn't compile, because
the types are incompatible.
I can't help you any further with the information you're offering.
Please share at least your complete general_work method, and the methods
that you use to calculate the input numbers. I stand by my opininion
that beauty lies in simplicity. If you want to make sure you don't do
more for iterations than you have inputs, iterate over the number of
inputs (input_items.size()) and not something you calculate yourself.
That's the simple approach of eliminating error sources.
Also, you're using a gr::block. If you play around with the forecast
method, you might trigger situations where you are asked to produce a
number of output items on different output streams, and have zero input
items on some input streams; I don't see you check for that in the code
excerpt you were sharing.
Again, it isn't very useful to share only a portion of your block,
especially when you are very sure yourself that this portion is correct,
if you want help identifying what goes wrong.
With best regards,
Marcus Müller
On 27.07.2014 19:21, Mostafa Alizadeh wrote:
Thank you for your notes Marcus,
As you said this is unnecessary process to point to the input_items in a
for loop!!
However, this is not the problem because I checked that I have the same
number of iteration in the for loop as the number of input ports.
The problem is somewhere else. *Again I must mention that if I use, only 8
input ports, the code runs perfectly,* however, with 24 inputs, it does
something wrong! (perhaps pointing to somewhere in the memory which is not
allocated to the input as it seemed to allocated to the input!). In another
words, when I want to access the first input of the first input port, I can
write:
gr_complex **in = (gr_complex) input_items;
// for example
cout in[0][0] endl;
The program terminated with unexpected error!
Please help me, where is the problem?? :(
On Sun, Jul 27, 2014 at 4:21 AM, Marcus Müller marcus.muel...@ettus.com
wrote:
Having your complete general_work function wouldn't have hurt my
understanding much...
I really can't make out what you're trying to do without doubt.
Anyway, from the code below I think in *must at least* have the same
number of entries that your for loop has iterations; did you just try using
d_group * N_FS(d_normal) instead of d_N_phich_group *
N_FS_phich(d_normal_cp) when allocating your array?
It seems to me that having two ways to determine how many inputs there is
a likely cause for mistake. Use the size() of the input_items to determine
how many inputs you really have, and assert(input_items.size() ==
number_of_inputs_like_I_calculate_it); to make sure things line up.
Also, the whole process seems unnecessary, since you do nothing more than
copying the pointers from input_items to in; the typecast is nothing but
syntactic magic and can be done by having in = ((const gr_complex*)*)
input_items;; also, I encourage you to use the C++-style explicit cast
operators (in this case, reinterpret_cast) for their clarity, but that's
more a question of personal liking :)
Greetings,
Marcus
On 26.07.2014 21:55, Mostafa Alizadeh wrote:
Hi Marcus,
You're right. I didn't clarify the problem.
Actually in C++, I wrote:
block_impl::block_impl(bool normal, int group)
: gr::block(phich_grouping,
gr::io_signature::make(1, group * N_FS(normal), sizeof
(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
// N_FS function returns 8 or 4 depends on its input.
// in the work function :
// d_normal and d_group are defined in the .h file
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
for (int i=0; id_group * N_FS(d_normal); i++)
{
in[i] = (const gr_complex *) input_items[i];
}
when I set the group value to 3, the number of input ports would be 24.
In this case, I want to access to one element of in like this:
cout in in[0][0] endl;
I got the aforementioned error!
But when I set group = 1 which means 8 input ports, all things are
fine.
any idea please,
Best
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-fec LDPC comments / questions.
Hi Sylvain, Thanks for looking at this code. I really appreciate the feedback. Comments/questions inline below. ~ tracie perez On Jul 25, 2014, at 1:25 PM, Sylvain Munaut wrote: Hi, I've been looking at the LDPC code and I have a few comments / questions : 1) Memory management seems to be lacking. I see only 3 calls to gsl_matrix_free but much more matrices being allocated and create by operations. Am I missing something here or is the code leaking tons of memory at each encode/decode ? For the ldpc_par_chk_matrix class: There are 6 other submatrices, but they're submatrix views of the larger parity check matrix H. Since they're only views of the matrix already stored in memory, freeing the memory for H should be all that's necessary, if I'm understanding the GSL functions correctly. Then there are only 2 other matrices for which to free memory, so 3 calls total. To be clear - the idea is that a parity check matrix object is created, and then remains in memory through each encode/decode. For the encoder/decoder, you're totally right. I didn't free any of the temporary matrices. I just updated those classes with gsl_matrix_free calls. 2) Encoder efficiency : AFAIU, the method implemented in ldpc_R_U_encoder_impl is meant to be efficient for real-time encoding. But the efficiency is derived mainly because it makes a lot of the operation work on sparse matrix and those can be efficiently multiplied. This is not exploited here at all. The gsl matrix multiplication is just the plain old classic algorithm for dense matrix and so the R_U method is probably slower than just using a multiplication by the generator matrix. Yea, you are totally correct here too. The way to exploit it is to use back substitution in the steps to calculate the codeword, rather than regular matrix multiplication calls. I need to write a routine to do this, since the GSL linear algebra functions don't support GF(2), as far as I can tell. This should be straightforward; I'm working on it now. 3) Format of the H matrix and support for degenerate/ideal case : I've been trying to trace the BER curve for the codes used in the GMR-1 satcom standard. I have the H matrix in numpy and saved it to alist using the method in the python code in the gr-fec repo. The H matrix is of the form : [ P' | I ] already, so it's already in lower triangular form (actually even more than this, since it's the identity matrix on the right side). So I'd assume I could use this matrix with the code in the repo and use gap=0, but this doesn't work. Digging a bit more in the code, I see that the code decomposes it as follows : / T | A | B \/ | ---+---+--- | \ E | C | D / But in the paper I'm looking at ( http://www.ldpc-codes.com/papers/encoding.pdf ) the T E matrices are on the right side, which would match much better of course and honestly makes more sense to me since the reulting codeword often has the systematic bits first and then the parity bits. I didn't reference that paper. My GSoC mentor last summer, Jens, pointed me to their textbook Modern Coding Theory. In the book's method, the matrix is of the form you see in my code (TAB/ECD). Yes, to respond to your follow-up email - this is why I assumed the parity part would come first when I wrote the decoder. My LDPC knowledge is still pretty limited to just these few algorithms. I agree that we should be consistent with whatever the community is used to, or somehow make it configurable. If y'all think it's best to change it to ABT/CDE form, I can change it, but I won't be able to get back to this for a couple of weeks. I don't really understand why it's like that in the code. Also, should the code already work with the degenerate case where g=0 (which I think should be pretty common if you provide a check matrix that's already in the nice [ P' | I ] form. So now I'm sure you can see why a matrix in the form [P | I ] would not work with this TAB/ECD decomposition. If this class had a more unique name, it would probably be more clear that this parity check matrix class is specifically for use with the R_U encoder. So, I've renamed it from ldpc_par_chk_mtrx to ldpc_R_U_mtrx. I think it makes sense to have a separate FECAPI encoder variable for using a generator matrix in the standard form [ I | P ] (or given a parity check matrix in the form [P' | I ]. That has been on my to-do list to write. For a given parity check matrix that is full rank, or can be brought to full rank, it can be ran through the algorithm to bring it into TAB/ECD, or ABT/CDE form. I could add that functionality to the python script intended to be executed as preprocessing step. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-fec LDPC comments / questions.
Hi, For the encoder/decoder, you're totally right. I didn't free any of the temporary matrices. I just updated those classes with gsl_matrix_free calls. Ok good. Whenever we move to a more efficient implementation that doesn't use GSL for GF2 operation, it would probably make sense to have those pre-allocated to avoid alloc/free cycles. If this class had a more unique name, it would probably be more clear that this parity check matrix class is specifically for use with the R_U encoder. So, I've renamed it from ldpc_par_chk_mtrx to ldpc_R_U_mtrx. I think it makes sense to have a separate FECAPI encoder variable for using a generator matrix in the standard form [ I | P ] (or given a parity check matrix in the form [P' | I ]. That has been on my to-do list to write. Yes, OK, it probably make sense to have another matrix class for the R_U encoder and then have another encoder and matrix class for the [ I | P ] case. For that latter case, it can just copy the systematic bit, then use a sparse multiply by P to get the parity bits. However for the decoder that really shouldn't matter and the same code should handle both. You should just be able to give it the matrix and it should only use it to compute the syndrome and that's it. The only change to the decoder is that it should be able to handle both case where the systematic bits are at the front or at the back. So I guess both those matrix classes should inherit a common base that can just return the H() matrix itself for the decoder. The matrix H() doesn't fully define the code tough. You need to separately specify which ones are the systematic bits. For a given parity check matrix that is full rank, or can be brought to full rank, it can be ran through the algorithm to bring it into TAB/ECD, or ABT/CDE form. I could add that functionality to the python script intended to be executed as preprocessing step. Yes, you can but that takes _forever_ to precompute and shouldn't really be necessary. In the DVB and GMR code, P is sparse so I don't really see the point of using the R_U method in that case at all and the decoder should be able to cope with it no problem. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with large number of inputs.
Yes you're right about casting between in and input_items, however, I
think this problem is somehow related to the large number input ports! I
don't why!
Here is the whole block:
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include gnuradio/io_signature.h
#include phich_grouping_impl.h
int N_FS_phich(bool normal_cp){
if(normal_cp)
return 8;
else
return 4;
}
namespace gr {
namespace my {
phich_grouping::sptr
phich_grouping::make(bool normal_cp, int N_phich_group)
{
return gnuradio::get_initial_sptr
(new phich_grouping_impl(normal_cp, N_phich_group));
}
/*
* The private constructor
*/
phich_grouping_impl::phich_grouping_impl(bool normal_cp, int
N_phich_group)
: gr::block(phich_grouping,
gr::io_signature::make(N_phich_group *
N_FS_phich(normal_cp), N_phich_group * N_FS_phich(normal_cp) ,
sizeof(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
d_normal_cp(normal_cp),
d_N_phich_group(N_phich_group)
{
set_tag_propagation_policy(TPP_DONT);
}
/*
* Our virtual destructor.
*/
phich_grouping_impl::~phich_grouping_impl()
{
}
void
phich_grouping_impl::forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
for (int i=0; id_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
ninput_items_required[i] = 12;
}
}
int
phich_grouping_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
gr_complex *out = (gr_complex *) output_items[0];
//in = (const gr_complex *) input_items;
cout n input input_items.size() endl;
int phich_in_len[d_N_phich_group];
int x = 0;
for (int i=0; id_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
in[i] = (const gr_complex *) input_items[i];
// reading tags
vectortag_t tag_len;
get_tags_in_window(tag_len,
0,
0,
ninput_items[0],
pmt::string_to_symbol(length));
if(tag_len.size()0)
{
phich_in_len[i] = pmt::to_long(tag_len[0].value);
x++;
}
}
gr_complex y_p[d_N_phich_group][12];
gr_complex y__p_tilt[d_N_phich_group/2][12];
//cout \tin[0][0] in[0][0] endl;
if (x == d_N_phich_group * N_FS_phich(d_normal_cp)) // x ==
d_N_phich_group) is for checking all the input tags are read
{
// grouping ...
for (int i=0; id_N_phich_group ;i++)
{
for (int k=0; kphich_in_len[i]; k++)
{
y_p[i][k] = 0;
for (int j=0; jN_FS_phich(d_normal_cp); j++)
{
y_p[i][k] = y_p[i][k] + in[i*8+j][k];
}
}
}
...
...
// adding tag
add_item_tag(0,
nitems_written(0),
pmt::string_to_symbol(length),
pmt::from_long(12));
cout PHICH grouping endl;
consume_each(12);
}
else
{ // if tags didn't read
produce(0, 0);
consume_each(0);
}
return WORK_CALLED_PRODUCE;
}
} /* namespace my */
} /* namespace gr */
Input to this block is a random source and its output is a file sink. I
would be glad to see the comments on the code to improve it also finding
the problem.
Best,
Mostafa Alizadeh
On Sun, Jul 27, 2014 at 10:10 PM, Marcus Müller marcus.muel...@ettus.com
wrote:
As I said, you should use the gdb debugging approach to find the mistake.
gr_complex **in = (gr_complex) input_items; shouldn't compile, because
the types are incompatible.
I can't help you any further with the information you're offering.
Please share at least your complete general_work method, and the methods
that you use to calculate the input numbers. I stand by my opininion
that beauty lies in simplicity. If you want to make sure you don't do
more for iterations than you have inputs, iterate over the number of
inputs (input_items.size()) and not something you calculate yourself.
That's the simple approach of eliminating error sources.
Also, you're using a gr::block. If you play around with the forecast
method, you might trigger situations where you are asked to produce a
number of output items on different output streams, and have zero input
items on some input streams; I don't see you check for
Re: [Discuss-gnuradio] Problem with large number of inputs.
I forgot to say, I'm using Qtcreator to debug my GNURadio codes I do not
need any others!
The prgram is terminated at line in which I read from the input for the
first time i.e. :
y_p[i][k] = 0;
for (int j=0; jN_FS_phich(d_normal_cp); j++)
{
y_p[i][k] = y_p[i][k] + in[i*8+j][k];
}
Best,
On Mon, Jul 28, 2014 at 4:05 AM, Mostafa Alizadeh m.alizade...@gmail.com
wrote:
Yes you're right about casting between in and input_items, however, I
think this problem is somehow related to the large number input ports! I
don't why!
Here is the whole block:
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include gnuradio/io_signature.h
#include phich_grouping_impl.h
int N_FS_phich(bool normal_cp){
if(normal_cp)
return 8;
else
return 4;
}
namespace gr {
namespace my {
phich_grouping::sptr
phich_grouping::make(bool normal_cp, int N_phich_group)
{
return gnuradio::get_initial_sptr
(new phich_grouping_impl(normal_cp, N_phich_group));
}
/*
* The private constructor
*/
phich_grouping_impl::phich_grouping_impl(bool normal_cp, int
N_phich_group)
: gr::block(phich_grouping,
gr::io_signature::make(N_phich_group *
N_FS_phich(normal_cp), N_phich_group * N_FS_phich(normal_cp) ,
sizeof(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
d_normal_cp(normal_cp),
d_N_phich_group(N_phich_group)
{
set_tag_propagation_policy(TPP_DONT);
}
/*
* Our virtual destructor.
*/
phich_grouping_impl::~phich_grouping_impl()
{
}
void
phich_grouping_impl::forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
for (int i=0; id_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
ninput_items_required[i] = 12;
}
}
int
phich_grouping_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
gr_complex *out = (gr_complex *) output_items[0];
//in = (const gr_complex *) input_items;
cout n input input_items.size() endl;
int phich_in_len[d_N_phich_group];
int x = 0;
for (int i=0; id_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
in[i] = (const gr_complex *) input_items[i];
// reading tags
vectortag_t tag_len;
get_tags_in_window(tag_len,
0,
0,
ninput_items[0],
pmt::string_to_symbol(length));
if(tag_len.size()0)
{
phich_in_len[i] = pmt::to_long(tag_len[0].value);
x++;
}
}
gr_complex y_p[d_N_phich_group][12];
gr_complex y__p_tilt[d_N_phich_group/2][12];
//cout \tin[0][0] in[0][0] endl;
if (x == d_N_phich_group * N_FS_phich(d_normal_cp)) // x ==
d_N_phich_group) is for checking all the input tags are read
{
// grouping ...
for (int i=0; id_N_phich_group ;i++)
{
for (int k=0; kphich_in_len[i]; k++)
{
y_p[i][k] = 0;
for (int j=0; jN_FS_phich(d_normal_cp); j++)
{
y_p[i][k] = y_p[i][k] + in[i*8+j][k];
}
}
}
...
...
// adding tag
add_item_tag(0,
nitems_written(0),
pmt::string_to_symbol(length),
pmt::from_long(12));
cout PHICH grouping endl;
consume_each(12);
}
else
{ // if tags didn't read
produce(0, 0);
consume_each(0);
}
return WORK_CALLED_PRODUCE;
}
} /* namespace my */
} /* namespace gr */
Input to this block is a random source and its output is a file sink. I
would be glad to see the comments on the code to improve it also finding
the problem.
Best,
Mostafa Alizadeh
On Sun, Jul 27, 2014 at 10:10 PM, Marcus Müller marcus.muel...@ettus.com
wrote:
As I said, you should use the gdb debugging approach to find the mistake.
gr_complex **in = (gr_complex) input_items; shouldn't compile, because
the types are incompatible.
I can't help you any further with the information you're offering.
Please share at least your complete general_work method, and the methods
that you use to calculate
[Discuss-gnuradio] spectrum record
Hi Marcus, list, Thanks for swift response. You are right about openBTS, but at the same time I am using really old system (12.04) havent formatted for years due to its required installation, which can turn into real time consuming tasks thats why dragging it as long as I can avoid above situation. Now Decimation, yes its seems right to me as well, but when I am trying to decode I am getting SCH errors (I am using channelizer.py given in GR example directory for this purpose) with following configuration channels= 10 sample rate= clock rate/decimation pfb decimation= 4 OSR= channels/pfb decimation= 2.5 but when I am recording single frequency with 156 decimation, it works just fine. partially I believe this question belongs to airprobe mailing list, but think there is very little or null development on it, thus thought to coin it here, a much active list. I want to make sure I am not doing anything wrong in spectrum recording and channelizing afterwards once it comes to airprobe, will give a head on Also if libusrp is the only bottelneck for me, I will change my system configuration and install GR-3.6 (which I think supports openBTS and UHD as well) at moment I am moving like headless chicken between GR and airprobe, not sure who is and what is going wrong, please spread some light here. Thankyou ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with large number of inputs.
Mostafa,
I do not think you have truly run the complete codes using Qtcreator,
because that doesn't have a gnuradio runtime (the scheduler).
At the other hand, your problem sounds more like a c++ coding error rather
than gnuradio-specific.
The helpful approach is
1). Put up the OOT into github.
This should be the simplest but complete OOT.
2). Provide a big picture of what you try to accomplish.
From experience many amateur programmers write codes wrong from the
ground up, and yet expect others to troubleshoot.
When this happens, the only way to help is to start with the big
picture of what you wish to accomplish.
From previous experience you refused to reveal the big picture but
emphasize others to look at your existing buggy codes.
Please be reminded that this is an open forum and nobody get paid for
helping you.
On Mon, Jul 28, 2014 at 7:39 AM, Mostafa Alizadeh m.alizade...@gmail.com
wrote:
I forgot to say, I'm using Qtcreator to debug my GNURadio codes I do not
need any others!
The prgram is terminated at line in which I read from the input for the
first time i.e. :
y_p[i][k] = 0;
for (int j=0; jN_FS_phich(d_normal_cp); j++)
{
y_p[i][k] = y_p[i][k] + in[i*8+j][k];
}
Best,
On Mon, Jul 28, 2014 at 4:05 AM, Mostafa Alizadeh m.alizade...@gmail.com
wrote:
Yes you're right about casting between in and input_items, however, I
think this problem is somehow related to the large number input ports! I
don't why!
Here is the whole block:
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include gnuradio/io_signature.h
#include phich_grouping_impl.h
int N_FS_phich(bool normal_cp){
if(normal_cp)
return 8;
else
return 4;
}
namespace gr {
namespace my {
phich_grouping::sptr
phich_grouping::make(bool normal_cp, int N_phich_group)
{
return gnuradio::get_initial_sptr
(new phich_grouping_impl(normal_cp, N_phich_group));
}
/*
* The private constructor
*/
phich_grouping_impl::phich_grouping_impl(bool normal_cp, int
N_phich_group)
: gr::block(phich_grouping,
gr::io_signature::make(N_phich_group *
N_FS_phich(normal_cp), N_phich_group * N_FS_phich(normal_cp) ,
sizeof(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
d_normal_cp(normal_cp),
d_N_phich_group(N_phich_group)
{
set_tag_propagation_policy(TPP_DONT);
}
/*
* Our virtual destructor.
*/
phich_grouping_impl::~phich_grouping_impl()
{
}
void
phich_grouping_impl::forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
for (int i=0; id_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
ninput_items_required[i] = 12;
}
}
int
phich_grouping_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
gr_complex *out = (gr_complex *) output_items[0];
//in = (const gr_complex *) input_items;
cout n input input_items.size() endl;
int phich_in_len[d_N_phich_group];
int x = 0;
for (int i=0; id_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
in[i] = (const gr_complex *) input_items[i];
// reading tags
vectortag_t tag_len;
get_tags_in_window(tag_len,
0,
0,
ninput_items[0],
pmt::string_to_symbol(length));
if(tag_len.size()0)
{
phich_in_len[i] = pmt::to_long(tag_len[0].value);
x++;
}
}
gr_complex y_p[d_N_phich_group][12];
gr_complex y__p_tilt[d_N_phich_group/2][12];
//cout \tin[0][0] in[0][0] endl;
if (x == d_N_phich_group * N_FS_phich(d_normal_cp)) // x ==
d_N_phich_group) is for checking all the input tags are read
{
// grouping ...
for (int i=0; id_N_phich_group ;i++)
{
for (int k=0; kphich_in_len[i]; k++)
{
y_p[i][k] = 0;
for (int j=0; jN_FS_phich(d_normal_cp); j++)
{
y_p[i][k] = y_p[i][k] + in[i*8+j][k];
}
}
}
...
...
// adding tag
add_item_tag(0,
nitems_written(0),
pmt::string_to_symbol(length),
