Re: [Discuss-gnuradio] FOSDEM attendee? Re: 802.15.4 CSS PHY
Hi, that was me ;). I also talked to Bastian Bloessl and we agreed that I will create a pull request to gr-ieee802-15-4 once I finish my master's thesis and have it all cleaned up. In the meantime, you can find my fork of Bastian's repo here: https://github.com/fewu/gr-ieee802-15-4. The branch with my work is called css_phy. Currently I'm working on the synchronization for the CSS PHY. My previous work focused on evaluating PHY and MAC performance with the assumption of perfect sync. It's also not really complete yet (e.g. preamble and PHR are dropped in the receiver because their content is assumed to be known) and endianness might be wrong at some points. But I will try to fix that in the next weeks. Feel free to contact me if you have any questions! Greetings Felix 2015-02-02 7:52 GMT+01:00 Christopher Friedt : > Hi list, > > this is just a shot in the dark, but I forgot to get the name of an > attendee during the Internet of #allthethings talk. > > If you are, or know who is, the person who said he had implemented an > 802.15.4 CSS PHY in the question period, please get in touch with me > or pass on the message. > > It would be very beneficial to collect the 15.4 related work into one > repository to reuse some amount of code. The 800 & 900 MHz PHY would > be very useful to have in there and would be relatively painless to > design. The CSS PHY is obviously much more interesting :-) > > Also, in particular, any future UWB PHY designers would be helpful. > The SDR hardware for such a PHY might be a bit pricey. Even a > unit-test driven PHY design would be helpful or simulation. > > As of this point, I have not heard of any major silicon vendors are > even speaking about offering an UWB PHY, so it would be nice to be > ahead of the game. > > Cheers, > > C > > ___ > 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] Running out of memory during BER simulations
That fixed it! Thanks!! 2014-11-25 18:48 GMT+01:00 Marcus Müller : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Does increasing kernel.shmmni using sysctl to let's say 16k improve > the situation? > > On 11/25/2014 06:37 PM, Marcus Müller wrote: > > Hi Felix, > > > > > > On 11/25/2014 06:15 PM, Felix W. wrote: > >> Between every run, I call tb.stop() followed by tb.wait(). > >> Unfortunately, after a few runs (around 20), I get the following > >> error message: > > > >> gr::vmcircbuf_sysv_shm: shmget (2): No space left on device > > I have a suspicion. First of all, I know this sounds basic, but > > you're not using a 32bit GR on your 64 bit machine, are you? (that > > would explain running out of RAM faster, just because process > > memory is so very limited for 32bit processes) > > > > then: vmcircbuf is one of the things I always was kind of hesitant > > to touch (or even try to understand in depth), just because it > > deals with a lot of POSIX/OS specifics that I'm not an expert in, > > but: > > > > Maybe tb.stop()/wait doesn't actually successfully unmap the > > shared memory segments of the buffers; there's a global maximum of > > segments, and it 4096 by default (/proc/sys/kernel/shmmni). > > However, this shouldn't be the problem at hand: there's an error > > number for this condition. And it would be: ENOSPC. Great. The same > > thing as for "No space left on device"; Thank you, Posix.1... > > > > Cheers, Marcus > > > > ___ Discuss-gnuradio > > mailing list Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUdMD0AAoJEAFxB7BbsDrL88sIAKE8Ic6WLuvIXcjVl9Rtiwrk > OMGx6iL07PpWDlZBJfU5Twy0O4T+VYSQiwp5DtyMAe60zUH1uBP3eUQ/e9fyFLsN > VV89J9MB4lGlhg8m73kjj8yV2RrM9TttccU9yXHyUiVTQGQ838GRE5QS/CULv3bv > A2hZXX+IVfZLPuxmbd1fuiVDHcX5fxrlPHgLcZRWtOGJkVuvkRYip7mwtHInaVFD > xO6bI8CuujYUAJPKvUbRe3QIyKkxzLi2SPe4Vzn52KqAagwVy1fb8BK109fQ97fU > EPDMedpv5sTbRcB9mhY8SSi3bXaY01C5bLQIT8mw61Tp4D2/AUVdXSJykEc/0HQ= > =o6F6 > -END PGP SIGNATURE- > > ___ > 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] Running out of memory during BER simulations
I built GR from source on the machine and the machine is running Ubuntu 14.04 64-bit. So I guess my GR is 64-bit, too. Actually, while watching the simulation running at the moment, I noticed that memory usage is indeed increasing slowly (but at a rate that wouldn't fill up the system memory in days...). 2014-11-25 18:37 GMT+01:00 Marcus Müller : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Felix, > > > On 11/25/2014 06:15 PM, Felix W. wrote: > > Between every run, I call tb.stop() followed by tb.wait(). > > Unfortunately, after a few runs (around 20), I get the following > > error message: > > > > gr::vmcircbuf_sysv_shm: shmget (2): No space left on device > I have a suspicion. > First of all, I know this sounds basic, but you're not using a 32bit > GR on your 64 bit machine, are you? (that would explain running out of > RAM faster, just because process memory is so very limited for 32bit > processes) > > then: vmcircbuf is one of the things I always was kind of hesitant to > touch (or even try to understand in depth), just because it deals with > a lot of POSIX/OS specifics that I'm not an expert in, but: > > Maybe tb.stop()/wait doesn't actually successfully unmap the shared > memory segments of the buffers; there's a global maximum of segments, > and it 4096 by default (/proc/sys/kernel/shmmni). However, this > shouldn't be the problem at hand: there's an error number for this > condition. And it would be: ENOSPC. Great. The same thing as for "No > space left on device"; Thank you, Posix.1... > > Cheers, > Marcus > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUdL5ZAAoJEAFxB7BbsDrLaIcH/3GZa562FhMLZ7vqafSEQnBG > o3DWr54Wmq1NFbWGVuLTdT4+QFFn5UN5s7RKCdmhJ+KVeqxisV/nCSbH/WfShx8Y > DIq5o28BWsudwNsxtkq94mo57ELgj27fnHItIthqSsPGcUuIX4xszL7YTxsD++ai > Fz6wikE7rt0+01sP5OeIXKpJkXAvWB7VLX+M89tlDCWceF9Nr0nJCleLZCLXSeIq > 0n+u7RR3iXU6+RSyDLgK9KNCtNiUyb0p24L4m+jqsAQ/IfT6J/Ip0X5CFLoXg1A3 > ocBj6+kT1bq9aztRE2j92ZLVk//CKiuWANCo2lahNUatVehQJ0kANT2DDwp8rNU= > =32+6 > -END PGP SIGNATURE- > > ___ > 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] Running out of memory during BER simulations
Hi list, I'm currently performing BER measurements for an IEEE 802.15.4 system. In order to do so, I have created a flowgraph (in GRC/python) that is executed for different SNR values until a certain number of bits has been processed. Between every run, I call tb.stop() followed by tb.wait(). Unfortunately, after a few runs (around 20), I get the following error message: gr::vmcircbuf_sysv_shm: shmget (2): No space left on device gr::vmcircbuf_sysv_shm: shmget (2): No space left on device gr::vmcircbuf_sysv_shm: shmget (2): No space left on device gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB gr::vmcircbuf_sysv_shm: shmget (2): No space left on device gr::vmcircbuf_sysv_shm: shmget (2): No space left on device gr::vmcircbuf_sysv_shm: shmget (2): No space left on device gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted (core dumped) sysctl says: kernel.shmall = 2097152 kernel.shmmax = 2147483648 I don't really understand why this happens as my memory usage is very stable and < 20% of total RAM throughout the simulation. In my understanding, calling, tb.stop() and tb.wait() should delete anything the flowgraph allocated before. I also noticed that the block numbers (which are displayed because I call set_min_output_buffer() ) are monotonically increasing during the simulation even though the top block is stopped multiple times. This might be completely unrelated, however it indicates that my understanding might not be correct. Any ideas? --Felix Wunsch ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Messages getting dropped
Hi list, I have a strange problem with one of my custom blocks. It's a char stream sink with a message output. It basically takes the input stream, selects a few samples, packs them into blobs, makes a pmt::cons out of it and publishes the message. My original QA flowgraph looked like this: vector_source_b --> my_custom_block --> pdu_to_tagged_stream --> vector_sink_b The flowgraph is run with tb.start(); time.sleep(2); tb.stop() In this setup, I constantly lose the last of the 3 published packets. I made sure that the packets are actually published with a print statement right after the call to message_port_pub(). During debugging, I attached a message_debug block to my_custom_block and now all messages are received, even at the vector sink. There has been no change to the custom block! I can reproduce the packet loss by commenting out the message_debug block. Any ideas what is happening here? Felix ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: gr-drm for GNU Radio 3.7 available
The buffer warnings are expected and nothing you should have to worry about. It stems from the (admittedly unlucky) design choice to use vectors instead of single samples. I didn't see that error before, though. Are you on a machine with very limited memory? This thread [1] describes a similar behavior, maybe you can try the advised steps and report back if it helped. [1] http://www.marshut.com/ihktyk/invalid-argument-failed-to-allocate-buffer.html 2014-03-31 21:29 GMT+02:00 Jordan Johnson : > and now a problem with the buffer apparently. > > Using Volk machine: sse4_2_64_orc > gr::buffer::allocate_buffer: warning: tried to allocate >104 items of size 630. Due to alignment requirements >2048 were allocated. If this isn't OK, consider padding >your structure to a power-of-two bytes. >On this platform, our allocation granularity is 4096 bytes. > gr::buffer::allocate_buffer: warning: tried to allocate >7 items of size 8390. Due to alignment requirements >2048 were allocated. If this isn't OK, consider padding >your structure to a power-of-two bytes. >On this platform, our allocation granularity is 4096 bytes. > gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument > gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument > gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument > gr::buffer::allocate_buffer: failed to allocate buffer of size 16780 KB > gr::buffer::allocate_buffer: warning: tried to allocate > > > > > On Mon, Mar 31, 2014 at 12:06 PM, Jordan Johnson > wrote: > >> I'm willing to wager that's why you disabled them. :p >> Just to be sure, the only WAV block I have on is the WAV sink. That being >> a sink, it shouldn't be making a fuss over a file it hasn't written not >> being there. I use jack as the audio input through the regular audio source >> block; no JACK messages that would indicate an issue there, though it >> doesn't run long enough to even appear as a connection. >> >> Looking at the py files, the pys it has in its execute commands are there >> too. >> >> Hm >> >> >> On Mon, Mar 31, 2014 at 12:00 PM, Felix W. >> wrote: >> >>> I'm not sure if it's the .py file it's looking for or the sound (*.wav) >>> file you want to transmit. Did you maybe forget to specify one? Happened to >>> me all the time ;). >>> >>> >>> 2014-03-31 20:42 GMT+02:00 Jordan Johnson : >>> >>>> Patched and everything looks fine. But of course, the ride doesn't end. >>>> :) >>>> >>>> Executing: >>>> "/home/ushio/Code/gr-drm-stable/flow_graphs/drm_transmitter_64sm_16.py" >>>> [Errno 2] No such file or directory >>>> >>>> Even though in thunar and through ls it is obviously exactly where it >>>> wants it to be. They are executable and their permissions seem fine. Am I >>>> doing something wrong? Each transmitter graph now has its own py file that >>>> it doesn't want to find for some reason. >>>> >>>> >>>> On Mon, Mar 31, 2014 at 11:25 AM, Felix W. >>> > wrote: >>>> >>>>> This is actually a GNU Radio bug where XML files are not generated >>>>> correctly. At the vlen parameter of the hier blocks a $ is missing. This >>>>> patch from Sebastian Koslowski should fix it: >>>>> https://github.com/skoslowski/gnuradio/commit/227478f343f50431d238a16d93afd8a40ef9e06e >>>>> >>>>> >>>>> Just apply the patch and create the hier blocks once again. Then it >>>>> all should work. Tell me, if it does not! >>>>> >>>>> Felix >>>>> >>>>> >>>>> 2014-03-31 19:59 GMT+02:00 Jordan Johnson : >>>>> >>>>>> Nope, have not mad any modifications to any of the ones I want to. >>>>>> Here are some screenshots if this may give you an idea. >>>>>> >>>>>> >>>>>> https://lh6.googleusercontent.com/-598cz4JydqE/Uzmrxd3Y0_I/wZs/DnOG6Ol9eFA/w1021-h512-no/Screenshot+-+03312014+-+10%253A52%253A29+AM.png >>>>>> >>>>>> >>>>>> https://lh6.googleusercontent.com/-Os9OqtHLpEE/Uzmrxqbl04I/wZw/Ea85203_qyM/w931-h524-no/Screenshot+-+03312014+-+10%253A51%253A40+AM.png >>>>>> >>>>>> I recall having a similar issue with some of my FM and ATSC stuff >>>>>> butfor the life of me cannot remember what the
Re: [Discuss-gnuradio] Fwd: gr-drm for GNU Radio 3.7 available
I'm not sure if it's the .py file it's looking for or the sound (*.wav) file you want to transmit. Did you maybe forget to specify one? Happened to me all the time ;). 2014-03-31 20:42 GMT+02:00 Jordan Johnson : > Patched and everything looks fine. But of course, the ride doesn't end. :) > > Executing: > "/home/ushio/Code/gr-drm-stable/flow_graphs/drm_transmitter_64sm_16.py" > [Errno 2] No such file or directory > > Even though in thunar and through ls it is obviously exactly where it > wants it to be. They are executable and their permissions seem fine. Am I > doing something wrong? Each transmitter graph now has its own py file that > it doesn't want to find for some reason. > > > On Mon, Mar 31, 2014 at 11:25 AM, Felix W. wrote: > >> This is actually a GNU Radio bug where XML files are not generated >> correctly. At the vlen parameter of the hier blocks a $ is missing. This >> patch from Sebastian Koslowski should fix it: >> https://github.com/skoslowski/gnuradio/commit/227478f343f50431d238a16d93afd8a40ef9e06e >> >> >> Just apply the patch and create the hier blocks once again. Then it all >> should work. Tell me, if it does not! >> >> Felix >> >> >> 2014-03-31 19:59 GMT+02:00 Jordan Johnson : >> >>> Nope, have not mad any modifications to any of the ones I want to. >>> Here are some screenshots if this may give you an idea. >>> >>> >>> https://lh6.googleusercontent.com/-598cz4JydqE/Uzmrxd3Y0_I/wZs/DnOG6Ol9eFA/w1021-h512-no/Screenshot+-+03312014+-+10%253A52%253A29+AM.png >>> >>> >>> https://lh6.googleusercontent.com/-Os9OqtHLpEE/Uzmrxqbl04I/wZw/Ea85203_qyM/w931-h524-no/Screenshot+-+03312014+-+10%253A51%253A40+AM.png >>> >>> I recall having a similar issue with some of my FM and ATSC stuff >>> butfor the life of me cannot remember what the underlying catalyst was. >>> >>> >>> On Mon, Mar 31, 2014 at 2:21 AM, Felix W. >>> wrote: >>> >>>> Ok, so this looks like the hierarchical blocks are not properly >>>> parameterized. In my transmitter, I'm always processing whole vectors of >>>> specific data types, so each block uses input sizes of >>>> vector_length*sizeof(data_type). What GRC is reporting is that all MLC >>>> blocks use vector length 1, therefore the input sizes vary between 1 >>>> (sizeof(char)) and 8 (sizeof(gr_complex)). Please have a look at the MLC >>>> blocks in GRC and see if all the fields, especially the ones named "Input >>>> vector length" and "Output vector length" are filled and not marked with >>>> red. Please also check if the variable "tp" (in the upper left corner, >>>> right next to the "Options" block) is written in black. I'm assuming you >>>> didn't change anything in the flow graph so far. >>>> >>>> Felix >>>> >>>> -- Forwarded message -- >>>> From: Felix W. >>>> Date: 2014-03-31 10:20 GMT+02:00 >>>> Subject: Re: [Discuss-gnuradio] gr-drm for GNU Radio 3.7 available >>>> To: Jordan Johnson >>>> >>>> >>>> About the "no module named drm" error: Obviously the needed library is >>>> not found. Normally, a "sudo ldconfig" should solve this, but only if it >>>> can find it. So your library has to be placed somewhere in the standard >>>> paths like "usr/local/lib", where also the other GNU Radio libraries are >>>> located. Looking at the man page of "ldconfig" it seems that you can also >>>> give it a path to your shared library. Maybe that's already enough. >>>> >>>> Because you couldn't execute the hierarchical blocks the respective >>>> files were not generated and this is why they are missing when you open the >>>> transmitter flow graph. GRC is just telling you that the MLC blocks are >>>> missing and therefore it can't connect them to the adjacent blocks. >>>> >>>> To sum it up: Try to find out where the working GNU Radio files such as >>>> XML files and shared libraries are placed and install the DRM stuff there. >>>> Unfortunately, I'm not familiar with the differences between Arch and >>>> Ubuntu so I'm sorry that I can't give you more detailed instructions. >>>> >>>> Keep me posted about your progress! >>>> >>
Re: [Discuss-gnuradio] Fwd: gr-drm for GNU Radio 3.7 available
This is actually a GNU Radio bug where XML files are not generated correctly. At the vlen parameter of the hier blocks a $ is missing. This patch from Sebastian Koslowski should fix it: https://github.com/skoslowski/gnuradio/commit/227478f343f50431d238a16d93afd8a40ef9e06e Just apply the patch and create the hier blocks once again. Then it all should work. Tell me, if it does not! Felix 2014-03-31 19:59 GMT+02:00 Jordan Johnson : > Nope, have not mad any modifications to any of the ones I want to. > Here are some screenshots if this may give you an idea. > > > https://lh6.googleusercontent.com/-598cz4JydqE/Uzmrxd3Y0_I/wZs/DnOG6Ol9eFA/w1021-h512-no/Screenshot+-+03312014+-+10%253A52%253A29+AM.png > > > https://lh6.googleusercontent.com/-Os9OqtHLpEE/Uzmrxqbl04I/wZw/Ea85203_qyM/w931-h524-no/Screenshot+-+03312014+-+10%253A51%253A40+AM.png > > I recall having a similar issue with some of my FM and ATSC stuff > butfor the life of me cannot remember what the underlying catalyst was. > > > On Mon, Mar 31, 2014 at 2:21 AM, Felix W. wrote: > >> Ok, so this looks like the hierarchical blocks are not properly >> parameterized. In my transmitter, I'm always processing whole vectors of >> specific data types, so each block uses input sizes of >> vector_length*sizeof(data_type). What GRC is reporting is that all MLC >> blocks use vector length 1, therefore the input sizes vary between 1 >> (sizeof(char)) and 8 (sizeof(gr_complex)). Please have a look at the MLC >> blocks in GRC and see if all the fields, especially the ones named "Input >> vector length" and "Output vector length" are filled and not marked with >> red. Please also check if the variable "tp" (in the upper left corner, >> right next to the "Options" block) is written in black. I'm assuming you >> didn't change anything in the flow graph so far. >> >> Felix >> >> -- Forwarded message -- >> From: Felix W. >> Date: 2014-03-31 10:20 GMT+02:00 >> Subject: Re: [Discuss-gnuradio] gr-drm for GNU Radio 3.7 available >> To: Jordan Johnson >> >> >> About the "no module named drm" error: Obviously the needed library is >> not found. Normally, a "sudo ldconfig" should solve this, but only if it >> can find it. So your library has to be placed somewhere in the standard >> paths like "usr/local/lib", where also the other GNU Radio libraries are >> located. Looking at the man page of "ldconfig" it seems that you can also >> give it a path to your shared library. Maybe that's already enough. >> >> Because you couldn't execute the hierarchical blocks the respective files >> were not generated and this is why they are missing when you open the >> transmitter flow graph. GRC is just telling you that the MLC blocks are >> missing and therefore it can't connect them to the adjacent blocks. >> >> To sum it up: Try to find out where the working GNU Radio files such as >> XML files and shared libraries are placed and install the DRM stuff there. >> Unfortunately, I'm not familiar with the differences between Arch and >> Ubuntu so I'm sorry that I can't give you more detailed instructions. >> >> Keep me posted about your progress! >> >> >> 2014-03-31 9:56 GMT+02:00 Jordan Johnson : >> >> Shoulda figured. Arch likes to put things in /usr/local/share as opposed >>> to /usr/local. Has caused problems with some programs in the past. >>> However, it looks like it put things in several wrong spots. As running the >>> heir-blocks graphs gets me this: >>> >>> "No module named drm" >>> >>> No missing blocks there, DRM section appears. >>> >>> On top of it, on opening the transmitter flowgraphs, I am confronted >>> with this: >>> >>> >>> Error: Block key "drm_mlc_16qam_vbvc" not found in Platform - >>> grc(GNU Radio Companion) >>> >>> Error: Block key "drm_mlc_64qam_sm_vbvc" not found in Platform - >>> grc(GNU Radio Companion) >>> >>> Error: Block key "drm_mlc_4qam_vbvc" not found in Platform - grc(GNU >>> Radio Companion) >>> >>> Error: Connection between drm_mlc_64qam_sm_vbvc_0(0) and >>> drm_interleaver_vcvc_0(0) could not be made. >>> source block id "drm_mlc_64qam_sm_vbvc_0" not in block ids >>> >>> Error: Connection between drm_scrambler_vbvb_0(0) and >>> drm_mlc_64qam_sm_vbvc_0(0) could not be made. >>> sink
Re: [Discuss-gnuradio] Fwd: gr-drm for GNU Radio 3.7 available
Ok, so this looks like the hierarchical blocks are not properly parameterized. In my transmitter, I'm always processing whole vectors of specific data types, so each block uses input sizes of vector_length*sizeof(data_type). What GRC is reporting is that all MLC blocks use vector length 1, therefore the input sizes vary between 1 (sizeof(char)) and 8 (sizeof(gr_complex)). Please have a look at the MLC blocks in GRC and see if all the fields, especially the ones named "Input vector length" and "Output vector length" are filled and not marked with red. Please also check if the variable "tp" (in the upper left corner, right next to the "Options" block) is written in black. I'm assuming you didn't change anything in the flow graph so far. Felix -- Forwarded message -- From: Felix W. Date: 2014-03-31 10:20 GMT+02:00 Subject: Re: [Discuss-gnuradio] gr-drm for GNU Radio 3.7 available To: Jordan Johnson About the "no module named drm" error: Obviously the needed library is not found. Normally, a "sudo ldconfig" should solve this, but only if it can find it. So your library has to be placed somewhere in the standard paths like "usr/local/lib", where also the other GNU Radio libraries are located. Looking at the man page of "ldconfig" it seems that you can also give it a path to your shared library. Maybe that's already enough. Because you couldn't execute the hierarchical blocks the respective files were not generated and this is why they are missing when you open the transmitter flow graph. GRC is just telling you that the MLC blocks are missing and therefore it can't connect them to the adjacent blocks. To sum it up: Try to find out where the working GNU Radio files such as XML files and shared libraries are placed and install the DRM stuff there. Unfortunately, I'm not familiar with the differences between Arch and Ubuntu so I'm sorry that I can't give you more detailed instructions. Keep me posted about your progress! 2014-03-31 9:56 GMT+02:00 Jordan Johnson : Shoulda figured. Arch likes to put things in /usr/local/share as opposed to > /usr/local. Has caused problems with some programs in the past. However, > it looks like it put things in several wrong spots. As running the > heir-blocks graphs gets me this: > > "No module named drm" > > No missing blocks there, DRM section appears. > > On top of it, on opening the transmitter flowgraphs, I am confronted with > this: > > >>> Error: Block key "drm_mlc_16qam_vbvc" not found in Platform - grc(GNU > Radio Companion) > >>> Error: Block key "drm_mlc_64qam_sm_vbvc" not found in Platform - > grc(GNU Radio Companion) > >>> Error: Block key "drm_mlc_4qam_vbvc" not found in Platform - grc(GNU > Radio Companion) > >>> Error: Connection between drm_mlc_64qam_sm_vbvc_0(0) and > drm_interleaver_vcvc_0(0) could not be made. > source block id "drm_mlc_64qam_sm_vbvc_0" not in block ids > >>> Error: Connection between drm_scrambler_vbvb_0(0) and > drm_mlc_64qam_sm_vbvc_0(0) could not be made. > sink block id "drm_mlc_64qam_sm_vbvc_0" not in block ids > >>> Error: Connection between drm_scrambler_vbvb_0_1(0) and > drm_mlc_16qam_vbvc_0(0) could not be made. > sink block id "drm_mlc_16qam_vbvc_0" not in block ids > >>> Error: Connection between drm_mlc_16qam_vbvc_0(0) and > cell_mapping_vcvc_0(1) could not be made. > source block id "drm_mlc_16qam_vbvc_0" not in block ids > >>> Error: Connection between drm_scrambler_vbvb_0_0(0) and > drm_mlc_4qam_vbvc_0_0(0) could not be made. > sink block id "drm_mlc_4qam_vbvc_0_0" not in block ids > >>> Error: Connection between drm_mlc_4qam_vbvc_0_0(0) and > blocks_stream_to_vector_0_0(0) could not be made. > source block id "drm_mlc_4qam_vbvc_0_0" not in block ids > > ...should I re-make with different locations? > > > On Mon, Mar 31, 2014 at 12:32 AM, Felix W. wrote: > >> Hi Jordan, >> >> Nice to hear that you can use my code! I just tried to reproduce your >> problem on my machine (Ubuntu 12.10, GNU Radio v3.7.2.1-263-g78551a56) but >> all seemed to be fine. >> >> So here are some guesses that come to my mind: >> Did you make sure to reload the block list if GRC was already open by >> using the respective button on the top or did you restart GRC inbetween? >> You could also check (assuming you are on linux) if the blocks' XML files >> are placed in '/usr/local/share/gnuradio/grc/blocks' ? The 'install' output >> also shows where it copies stuff. After the install, you
[Discuss-gnuradio] Fwd: gr-drm for GNU Radio 3.7 available
Forgot to include the mailing list... -- Forwarded message -- From: Felix W. Date: 2014-03-31 10:20 GMT+02:00 Subject: Re: [Discuss-gnuradio] gr-drm for GNU Radio 3.7 available To: Jordan Johnson About the "no module named drm" error: Obviously the needed library is not found. Normally, a "sudo ldconfig" should solve this, but only if it can find it. So your library has to be placed somewhere in the standard paths like "usr/local/lib", where also the other GNU Radio libraries are located. Looking at the man page of "ldconfig" it seems that you can also give it a path to your shared library. Maybe that's already enough. Because you couldn't execute the hierarchical blocks the respective files were not generated and this is why they are missing when you open the transmitter flow graph. GRC is just telling you that the MLC blocks are missing and therefore it can't connect them to the adjacent blocks. To sum it up: Try to find out where the working GNU Radio files such as XML files and shared libraries are placed and install the DRM stuff there. Unfortunately, I'm not familiar with the differences between Arch and Ubuntu so I'm sorry that I can't give you more detailed instructions. Keep me posted about your progress! 2014-03-31 9:56 GMT+02:00 Jordan Johnson : Shoulda figured. Arch likes to put things in /usr/local/share as opposed to > /usr/local. Has caused problems with some programs in the past. However, > it looks like it put things in several wrong spots. As running the > heir-blocks graphs gets me this: > > "No module named drm" > > No missing blocks there, DRM section appears. > > On top of it, on opening the transmitter flowgraphs, I am confronted with > this: > > >>> Error: Block key "drm_mlc_16qam_vbvc" not found in Platform - grc(GNU > Radio Companion) > >>> Error: Block key "drm_mlc_64qam_sm_vbvc" not found in Platform - > grc(GNU Radio Companion) > >>> Error: Block key "drm_mlc_4qam_vbvc" not found in Platform - grc(GNU > Radio Companion) > >>> Error: Connection between drm_mlc_64qam_sm_vbvc_0(0) and > drm_interleaver_vcvc_0(0) could not be made. > source block id "drm_mlc_64qam_sm_vbvc_0" not in block ids > >>> Error: Connection between drm_scrambler_vbvb_0(0) and > drm_mlc_64qam_sm_vbvc_0(0) could not be made. > sink block id "drm_mlc_64qam_sm_vbvc_0" not in block ids > >>> Error: Connection between drm_scrambler_vbvb_0_1(0) and > drm_mlc_16qam_vbvc_0(0) could not be made. > sink block id "drm_mlc_16qam_vbvc_0" not in block ids > >>> Error: Connection between drm_mlc_16qam_vbvc_0(0) and > cell_mapping_vcvc_0(1) could not be made. > source block id "drm_mlc_16qam_vbvc_0" not in block ids > >>> Error: Connection between drm_scrambler_vbvb_0_0(0) and > drm_mlc_4qam_vbvc_0_0(0) could not be made. > sink block id "drm_mlc_4qam_vbvc_0_0" not in block ids > >>> Error: Connection between drm_mlc_4qam_vbvc_0_0(0) and > blocks_stream_to_vector_0_0(0) could not be made. > source block id "drm_mlc_4qam_vbvc_0_0" not in block ids > > ...should I re-make with different locations? > > > On Mon, Mar 31, 2014 at 12:32 AM, Felix W. wrote: > >> Hi Jordan, >> >> Nice to hear that you can use my code! I just tried to reproduce your >> problem on my machine (Ubuntu 12.10, GNU Radio v3.7.2.1-263-g78551a56) but >> all seemed to be fine. >> >> So here are some guesses that come to my mind: >> Did you make sure to reload the block list if GRC was already open by >> using the respective button on the top or did you restart GRC inbetween? >> You could also check (assuming you are on linux) if the blocks' XML files >> are placed in '/usr/local/share/gnuradio/grc/blocks' ? The 'install' output >> also shows where it copies stuff. After the install, you should also do a >> 'sudo ldconfig' although this should not keep the blocks from showing in >> GRC. >> >> Let me know if there are any further problems! >> >> Felix >> >> >> 2014-03-31 6:25 GMT+02:00 Jordan Johnson : >> >>> Exciting! This should help one of my projects along nicely. >>> >>> Problem is, they blocks do not show upat all. I am using as >>> up-to-date version of GNURadio that is available to pacman. The make goes >>> fine, make-test passes with flying colors, and install appears fine too; no >>> blocks though. I attempted to place the blocks in the custom block folder; >>> still no dice. >>> >>> If it helps, packages and their versions: >>> gnuradio-3.7.2.1-2 >>> >>> ___ >>> 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-drm for GNU Radio 3.7 available
Hi Jordan, Nice to hear that you can use my code! I just tried to reproduce your problem on my machine (Ubuntu 12.10, GNU Radio v3.7.2.1-263-g78551a56) but all seemed to be fine. So here are some guesses that come to my mind: Did you make sure to reload the block list if GRC was already open by using the respective button on the top or did you restart GRC inbetween? You could also check (assuming you are on linux) if the blocks' XML files are placed in '/usr/local/share/gnuradio/grc/blocks' ? The 'install' output also shows where it copies stuff. After the install, you should also do a 'sudo ldconfig' although this should not keep the blocks from showing in GRC. Let me know if there are any further problems! Felix 2014-03-31 6:25 GMT+02:00 Jordan Johnson : > Exciting! This should help one of my projects along nicely. > > Problem is, they blocks do not show upat all. I am using as up-to-date > version of GNURadio that is available to pacman. The make goes fine, > make-test passes with flying colors, and install appears fine too; no > blocks though. I attempted to place the blocks in the custom block folder; > still no dice. > > If it helps, packages and their versions: > gnuradio-3.7.2.1-2 > > ___ > 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] Sine wave of only 3 cycles
Hi, you can use a Head block to make the sample stream stop after a given number of samples. Just calculate how many samples there will be in three cycles and set the Head block's parameter accordingly. Greetings Felix 2014-01-30 Activecat : > Dear Sir, > > A block of Signal Source (Sine) generates sine wave continuously. > How to make it just generates 3 wave-cycle and then stop generating > immediately. > At the end of the flow-graph there is a File Sink. This captures data for > offline processing. > > Regards, > active...@gmail.com > > > ___ > 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] gr-drm for GNU Radio 3.7 available
Hi all, I just want to make a quick announcement: gr-drm is now available for GNU Radio 3.7! Go and check it out under https://github.com/kit-cel/gr-drm! I also added a commit tag if you want to get the last version working with GR 3.6. All others just get the latest version from the 'stable' branch. For those of you who did not hear of this project before: gr-drm is a fully standard conformant software implementation of a DRM (Digital Radio Mondiale) transmitter. DRM is a digital short-wave broadcasting standard aimed at replacing existing analog technologies in the long run. With this project and a suitable HF front end (e.g. the USRP) you can set up your own DRM broadcast. Out of the box, you can either transmit an audio file of your choice or even your own voice using the microphone input. However, please keep your local spectrum regulations in mind before going on air ;). Decoding of the created signal is possible with any commercially available DRM receiver, but also with the open source tool DREAM which can be downloaded at SourceForge. Greetings Felix Wunsch ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC Hier block with vector IO not working as expected
It works for me and does not break anything as far as I can see. Didn't test it with other blocks, though. Thanks a lot! Greetings, Felix 2014/1/9 Wunsch, Felix > > > Von: Koslowski, Sebastian (CEL) > Gesendet: Donnerstag, 9. Januar 2014 10:00 > An: Tom Rondeau; Johannes Demel > Cc: Johnathan Corgan; Martin Braun; Wunsch, Felix > Betreff: Re: [Discuss-gnuradio] GRC Hier block with vector IO not working > as expected > > Yes, its indeed Sebastian issue =) > > Johannes, I remember you had this exact issue a few months back. I wrote > a patch for that. You never told me it was incomplete ;-) > > This should fix the generated xml file: > > > https://github.com/skoslowski/gnuradio/commit/227478f343f50431d238a16d93afd8a40ef9e06e > > I haven't tested it for unwanted side-effects. Felix, please check if it > works you and doesn't break anything (!) > > John, this patch is off maint. It will let you know when its ready to be > merged. > > 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 > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC Hier block with vector IO not working as expected
Hi, thanks for confirming that and pointing me to the right spot in the code. For now, I'll just fix it in the xml as I include them in the repo anyway. Is this a known bug or should I file a bug report for this? Regards, Felix 2014/1/8 Johannes Demel > Hi Felix, > > I can reproduce it. Problem is that the generated 'xml' file is not > generated correctly. The parameter 'vlen' should be written as '$vlen' in > the xml files source/sink section but it is written as 'vlen'. Thus 'vlen' > is treated as the value. Happens with 'v3.7.2-11-g3b27cc47'. I don't know > how to fix it though. > > Happy hacking > Johannes > > > On Wed, Jan 8, 2014 at 12:59 PM, Felix W. wrote: > >> Hi list, >> >> I'm currently in the process of porting my gr-drm project to the 3.7 API >> and now I'm a little bit stuck and hope that someone here can help me. >> >> I want to create a hier block (in GRC) that accepts vectors as input and >> output. Their size is controlled by parameters like vlen_in and vlen_out. >> Unfortunately, the IO size of the generated hier block always stays 1, no >> matter what I use as parameter. I attached a minimal (pure GNU Radio) >> example flow graph and hier block that reproduces my problem. Maybe I >> overlooked something obvious, but I don't get why this is not working. >> >> If someone had the time to try this and could report if it works (it does >> not for me), I would be very grateful. >> >> I'm on Ubuntu 12.10 and have GNU Radio v3.7.2.1-116-ge751e54a installed. >> >> Regards, >> Felix Wunsch >> >> >> ___ >> 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] GRC Hier block with vector IO not working as expected
Hi list, I'm currently in the process of porting my gr-drm project to the 3.7 API and now I'm a little bit stuck and hope that someone here can help me. I want to create a hier block (in GRC) that accepts vectors as input and output. Their size is controlled by parameters like vlen_in and vlen_out. Unfortunately, the IO size of the generated hier block always stays 1, no matter what I use as parameter. I attached a minimal (pure GNU Radio) example flow graph and hier block that reproduces my problem. Maybe I overlooked something obvious, but I don't get why this is not working. If someone had the time to try this and could report if it works (it does not for me), I would be very grateful. I'm on Ubuntu 12.10 and have GNU Radio v3.7.2.1-116-ge751e54a installed. Regards, Felix Wunsch example_hier_block.grc Description: application/gnuradio-grc example_fg.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
