Re: [Discuss-gnuradio] gr-drm for GNU Radio 3.7 available

On Sat, Apr 5, 2014 at 11:13 AM, Felix W. <address@hidden> wrote:

Ok, thanks for testing! That's strange, I will have to check with the 3.6.5 version which used to work. At least at some point...

Von: Jordan Johnson
Gesendet: 05.04.2014 19:43
An: Felix W.
Betreff: Re: [Discuss-gnuradio] gr-drm for GNU Radio 3.7 available

Though, upon further testing, RMA does not work. RMB does. Have not tried C or D (E/DRM+ is beyond my bandwidth requirements) Dream, nor SoDiRa will sync with an RMA signal, no matter the bandwidth.

On Fri, Apr 4, 2014 at 2:52 AM, Felix W. <address@hidden> wrote:

Ok that sounds good. I installed DREAM via apt-get and using RM A and 20 kHz it does not really seem to get synchronization. Strange.

To change the RM you can set the variable block in the flow graph accordingly. 0 corresponds to RM A, 1, to B and so on. In theory, even DRM+ as RM E is available although it's completely untested. For the AAC decoder you can install FAAD if you want.

2014-04-04 1:57 GMT+02:00 Jordan Johnson <address@hidden>:

I cannot reproduce and error. Using RM B and 20Khz bandwidth it works just fine. Though, as I usually used RM A, what is the setting for that?

But yeah, I don't have an AAC decoder, but it gives text and seems to decode properly.

On Thu, Apr 3, 2014 at 2:08 PM, Jordan Johnson <address@hidden> wrote:

That was actually what I was planning to do tonight. It already is set in my IBOC graph, I just need to execute it. I'll be sure to report my findings. Dream can be kind of weird sometimes, I have some other DRM reception software I'll use too if Dream doesn't play nice.

On Wed, Apr 2, 2014 at 12:26 AM, Felix W. <address@hidden> wrote:

Ok, I have to correct myself. RM B and SO 5 (20 kHz) give you only 42.9 kbps audio (AAC mono). As DREAM supports Opus, you could actually swap out my AAC encoder with the OPUS encoder. Of course you might have to deal with the correct packing of the bytes onto the transmission frame. But DREAM might be a nice guideline for doing this.

I'm a bit embarrassed to admit that while playing around with the flow graph it looked like nothing but RM B is actually working (at least with DREAM). Can you confirm this?

I don't know what happened there, it all worked when I thorougly tested it in 2012. I ported it to GR 3.7 in the meantime, can't think of a way this affects single robustness modes, though.

About your other questions: The language can be set in generate_fac_vb_impl.cc:265, the program type in line 272 (service descriptor). The respective bit strings can be found in the standard document which you can get here: http://www.etsi.org/deliver/etsi_es/201900_201999/201980/03.01.01_60/es_201980v030101p.pdf on page 77.

If you have other questions, don't hesitate to ask!

Cheers
Felix

2014-04-01 0:39 GMT+02:00 Felix W. <address@hidden>:

The other, and probably more important, main parameter besides the Robustness Mode controlling the bit rate is the spectrum occupancy (bandwidth). I usually use RM B and SO 3 (10 kHz). If I remember correctly, that gave me about 55 kbps and a pretty good audio quality.

Region info, program type and language are actually hard coded somewhere in the code, you would have to recompile the project. All these parameters are represented by a special bit string. You might try to grep for it. As I'm not on my dev machine right now I can't say more, but tomorrow I will have a look at it and give you some more detailed information about that!

2014-04-01 0:27 GMT+02:00 Jordan Johnson <address@hidden>:

Opus (http://opus-codec.org/) is the evolved version of the CELT codec and Dream can transmit and receive it just fine. I'll have to test it and see if I can get it to work. Though, if I do use AAC which I don't mind I suppose, how do I go about increasing the bitrate? I usually use RM A giving me about 64KB/s to play with.

Also, where do I go about changing region info, program type, language, etc?   I have it working in IBOC mode which awesome! I just need to fix those trivial issues.

On Mon, Mar 31, 2014 at 3:15 PM, Felix W. <address@hidden> wrote:

Hm, let me think a bit. Basically, you can connect anything to the input of the scrambler in the MSC path. It all depends on your receiver which, of course, has to be aware of what you are doing on the transmitter side. And that's where the problems begin. You would have to write your own GNU Radio DRM receiver or take DREAM and cut it open at the corresponding interface and extract the bits before they go to the audio decoder. The first alternative is surely a lot of work, the second might be doable although you would have to go through their source code first.

Are there any reasons why you can't use the built-in AAC encoder? I recently added a M3U playlist source (on current git master) that enables you to specify a list of wav files to be played. Or you just plug in your microphone, that will work as well.

2014-03-31 23:00 GMT+02:00 Jordan Johnson <address@hidden>:

I guess it might help explain what I doing.
Basically using gr-drm, I will be modulating two DRM signals on the LSB and USB of a normal FM Stereo signal. Jack takes audio from two sources, one goes to the FM and the first digital signal, and then another goes to the second DRM signal.

I had been doing this using Dream but the CPU utilization was ridiculous. This is exciting due to the fact that I can now work gr-drm into my IBOC flowgraph and run it in realtime.

Thank you for your assistance.

On Mon, Mar 31, 2014 at 1:35 PM, Felix W. <address@hidden> wrote:

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 <address@hidden>:

....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 <address@hidden> 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.

Hmmmmm....

On Mon, Mar 31, 2014 at 12:00 PM, Felix W. <address@hidden> 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 <address@hidden>:

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. <address@hidden> 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 <address@hidden>:

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/AAAAAAAAwZs/DnOG6Ol9eFA/w1021-h512-no/Screenshot+-+03312014+-+10%253A52%253A29+AM.png

https://lh6.googleusercontent.com/-Os9OqtHLpEE/Uzmrxqbl04I/AAAAAAAAwZw/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 but....for the life of me cannot remember what the underlying catalyst was.

On Mon, Mar 31, 2014 at 2:21 AM, Felix W. <address@hidden> 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. <address@hidden>
Date: 2014-03-31 10:20 GMT+02:00
Subject: Re: [Discuss-gnuradio] gr-drm for GNU Radio 3.7 available
To: Jordan Johnson <address@hidden>

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 <address@hidden>:

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. <address@hidden> 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 <address@hidden>:

Exciting! This should help one of my projects along nicely.

Problem is, they blocks do not show up....at 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

From:	Jordan Johnson
Subject:	Re: [Discuss-gnuradio] gr-drm for GNU Radio 3.7 available
Date:	Tue, 15 Apr 2014 09:44:07 -0700