Re: [Discuss-gnuradio] How to call another blocks in custom out-of-tree module

[y...@solid.co.kr]

-Original Message-
From: discuss-gnuradio-bounces+ykoh=solid.co...@gnu.org 
[mailto:discuss-gnuradio-bounces+ykoh=solid.co...@gnu.org] On Behalf Of Martin 
Braun (CEL)
Sent: Tuesday, November 05, 2013 10:11 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How to call another blocks in custom 
out-of-tree module

On Tue, Nov 05, 2013 at 12:56:24PM +, y...@solid.co.kr wrote:
> I want to call another gnu-blocks (or another hier-block) in work function.
> (Line 14~16)
> 
> 1) How to connect input item to another block’s input
> 
> 2) How to connect local array to another block’s output

In GNU Radio's 'block' terminology, you will *never* call another block from 
within one block's work function. You always connect the output of one block 
the input of the next.

What exactly are you trying to do? Are you simply trying to outsource some 
signal processing code out of your block?
We do this quite a lot, but then the object we call from the work function is 
not a GNU Radio block, but rather a generic object. Of course, you can include 
any Python module or object into your own Python blocks.

Or are you trying to call another, existing GNU Radio block? In this case, you 
might want to think about splitting your block up such that you can connect 
your block and existing blocks through the regular mechanism (i.e. 
top_block.connect()).

> Please help me.
> 
> Actually I need to make my own sub block.
> 
> But I need gnuradio blocks during processing my own block.

Perhaps a hier block will solve your problem?

MB

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and National Laboratory of 
the Helmholtz Association
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] The GSoC project on LDPC codes.

[Miklos Maroti]

Hi Manu,

Thanks for the report, it was more informative than the presentation.
Yes, I have seen the BER figure, but that is not very will presented
(e.g. you should use logarithmic scale for BER) and should have better
resolution on the Eb/N0 axes. You write that it does not use VOLK or
SSE2. How fast is it? Do you have any performance number? Do you plan
to work on it in the near future?

Miklos

On Wed, Nov 6, 2013 at 5:38 AM, Manu T S  wrote:
> Hello Mikios
>
> Here is the link to the presentation and report I made for my
> thesis(intermediate evaluation) at IIT Bombay. Last part describes the
> results I have obtained.
> It has a BER plot as well.
>
> https://github.com/manuts/first_stage/blob/master/ppt.pdf
> https://github.com/manuts/first_stage/blob/master/report.pdf
>
> The implementation is generic, in the sense that if you input a code (in
> alist file format), we can construct the encoder and decoder.
> The decoder merely implements sum product algorithm. I have tested it
> against many regular codes, where there was the significant gap between the
> rate and the capacity. I'm yet to test it against an irregular code of large
> block length, mainly because the encoder and decoder becomes really slow.
> (Many optimizations are still in order.)
>
> I wish I could tell you I had a better BER plot, but what's there in the
> report is all I have currently.
> Thanks for checking out.
>
>
> On Tue, Nov 5, 2013 at 11:08 PM, Miklos Maroti 
> wrote:
>>
>> Dear Manu,
>>
>> Do you have any performance numbers on your LDPC decoder? I could not
>> find any info, even in your presentation. Do you have also a BER
>> figure, or even better would be some technical report. I would love to
>> get some sense on the performance of your implementation.
>>
>> Best,
>> Miklos
>>
>> On Tue, Nov 5, 2013 at 6:15 PM, Manu T S  wrote:
>> > Dear Max,
>> >
>> > You are correct. It is a bug. Now I'm wondering why I didn't get any
>> > segmentation faults.
>> >
>> > Probably I didn't get any segmentation faults because, after i = M - 1,
>> > EOF
>> > has reached.
>> >
>> > Thanks for the correction.
>> >
>> >
>> > On Tue, Nov 5, 2013 at 9:14 PM, ikjtel  wrote:
>> >>
>> >> Greetings
>> >>
>> >> I was very interested in this project for possible application to the
>> >> op25
>> >> project, since P25 uses several FEC codes
>> >> including RS and other block codes.  I've brought up the gr-ldpc
>> >> library
>> >> and have a few questions.  Due to the hateful YAhoo mail composer, I'm
>> >> hesitant to post lengthy emails to the general list with no opportunity
>> >> for
>> >> preview prior to hitting SEND, so I'll try breaking up the list of
>> >> questions
>> >> into several posts, one per question...
>> >>
>> >> First question: I was getting lots of errors, seg faults, aborts, and
>> >> other misbehavior from the code, which were traced to an apparent bug
>> >> in
>> >> alist.cc, all of which cleared up when I applied the following patch:
>> >>
>> >> --- ../../repo/gr-ldpc/lib/alist.cc 2013-10-18 10:25:47.508781061
>> >> -0400
>> >> +++ ./alist.cc  2013-11-05 11:21:03.879972116 -0500
>> >> @@ -123,7 +123,7 @@
>> >>  }
>> >>
>> >>  // Parse indices with non zero entries in ith row
>> >> -for (int row = 0; row < N; row++) {
>> >> +for (int row = 0; row < M; row++) {
>> >>  std::getline(file, line);
>> >>  ss << line;
>> >>  for (int entry = 0; entry < num_mlist[row]; entry++) {
>> >>
>> >> Can you confirm, is this really a bug?
>> >>
>> >> Thanks and Best
>> >>
>> >> Max
>> >
>> >
>> >
>> >
>> > --
>> > Manu T S
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>
>
>
>
> --
> Manu T S

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Michael Dickens]

One final update: You're not supposed to change configure.cxx_stdlib, even 
though you are allowed to do so.  It is set to libc++ by default in 10.9, and 
libstdc++ in 10.8 and earlier.  Even trying to override it per the below does 
not work, because some ports are now designed internally to assume libc++ on 
10.9 (those dealing with compiling code: ld64, cctools; for example).

So, the bottom line is truly that GNU Radio (in full) will not work with 10.9 
until either (1) SWIG is updated to be C++11 compliant; or (2) GNU Radio moves 
away from using SWIG to some other means for interfacing to Python.  Today I 
will see if the C++ parts of GNU Radio work on 10.9, without the SWIG Python 
interface.

Sorry for the bummer news, you OSX 10.9 users!  Go ahead and downgrade to 10.8 
for now, and GNU Radio should install and work out of the box via MacPorts. - 
MLD

On Nov 5, 2013, at 3:05 PM, Michael Dickens  wrote:
> {{{
> sudo port -f uninstall installed
> sudo port clean all
> sudo port install gnuradio +gcc48 +atlas configure.cxx_stdlib=libstdc++
> }}}


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] The GSoC project on LDPC codes.

[Manu T S]

Hi Miklos,

The implementation is quite slow. I don't have any quantitative performance
measures, yet.
Nevertheless I have some empirical measures. For example, on testing the
implementation (all C++ and no GNU Radio) with a (8000, 4000) code(rate
0.5, regular), in with AWGN of 0.8 added to it (capacity 0.678),
it took about 15-20 minutes[*] on an i7 machine to transmit and decode 100
blocks. With smaller noise, this will be done a bit faster, for the number
of decoding iterations required is less.

The major time consuming factor in the implementation is the encoder
construction. You may find the encoding method I implemented in the report.
It has a complexity of O((NM)^2). Once we have the encoder matrix encoding
is done in O(K^2) time. Decoding doesn't take that much time, but the
current space requirement is huge. I'm using a M x N matrix(double
elements) to hold the messages being passed between check nodes and
variable nodes. For the (8000, 4000) code that turns out to be some 244 MB.
Since H is sparse, most of the entries in the M x N message matrix is 0 and
not used.

So these are the things in my agenda for the near future.
1. Improving the space requirement in the decoder.
2. Find better methods(eg. Sparse LU) to implement encoder.

I will start work with VOLK after the above mentioned improvements.


[*] As I said before encoder construction took huge time. So to test the
codes, I generated the encoder matrix and saved it in a separate alist
file. This file is not generally sparse. The file size would depend on the
structure of the code. For example, for the (8000, 4000) code the size of
the alist file for the encoder matrix was about 64MB. The only gain here is
that we need not generate the encoder matrix every time we need to use this
code. We can load it from the alist file. Had I not done this, the
experiment would have taken longer.


On Wed, Nov 6, 2013 at 5:47 PM, Miklos Maroti wrote:

> Hi Manu,
>
> Thanks for the report, it was more informative than the presentation.
> Yes, I have seen the BER figure, but that is not very will presented
> (e.g. you should use logarithmic scale for BER) and should have better
> resolution on the Eb/N0 axes. You write that it does not use VOLK or
> SSE2. How fast is it? Do you have any performance number? Do you plan
> to work on it in the near future?
>
> Miklos
>
> On Wed, Nov 6, 2013 at 5:38 AM, Manu T S  wrote:
> > Hello Mikios
> >
> > Here is the link to the presentation and report I made for my
> > thesis(intermediate evaluation) at IIT Bombay. Last part describes the
> > results I have obtained.
> > It has a BER plot as well.
> >
> > https://github.com/manuts/first_stage/blob/master/ppt.pdf
> > https://github.com/manuts/first_stage/blob/master/report.pdf
> >
> > The implementation is generic, in the sense that if you input a code (in
> > alist file format), we can construct the encoder and decoder.
> > The decoder merely implements sum product algorithm. I have tested it
> > against many regular codes, where there was the significant gap between
> the
> > rate and the capacity. I'm yet to test it against an irregular code of
> large
> > block length, mainly because the encoder and decoder becomes really slow.
> > (Many optimizations are still in order.)
> >
> > I wish I could tell you I had a better BER plot, but what's there in the
> > report is all I have currently.
> > Thanks for checking out.
> >
> >
> > On Tue, Nov 5, 2013 at 11:08 PM, Miklos Maroti  >
> > wrote:
> >>
> >> Dear Manu,
> >>
> >> Do you have any performance numbers on your LDPC decoder? I could not
> >> find any info, even in your presentation. Do you have also a BER
> >> figure, or even better would be some technical report. I would love to
> >> get some sense on the performance of your implementation.
> >>
> >> Best,
> >> Miklos
> >>
> >> On Tue, Nov 5, 2013 at 6:15 PM, Manu T S  wrote:
> >> > Dear Max,
> >> >
> >> > You are correct. It is a bug. Now I'm wondering why I didn't get any
> >> > segmentation faults.
> >> >
> >> > Probably I didn't get any segmentation faults because, after i = M -
> 1,
> >> > EOF
> >> > has reached.
> >> >
> >> > Thanks for the correction.
> >> >
> >> >
> >> > On Tue, Nov 5, 2013 at 9:14 PM, ikjtel  wrote:
> >> >>
> >> >> Greetings
> >> >>
> >> >> I was very interested in this project for possible application to the
> >> >> op25
> >> >> project, since P25 uses several FEC codes
> >> >> including RS and other block codes.  I've brought up the gr-ldpc
> >> >> library
> >> >> and have a few questions.  Due to the hateful YAhoo mail composer,
> I'm
> >> >> hesitant to post lengthy emails to the general list with no
> opportunity
> >> >> for
> >> >> preview prior to hitting SEND, so I'll try breaking up the list of
> >> >> questions
> >> >> into several posts, one per question...
> >> >>
> >> >> First question: I was getting lots of errors, seg faults, aborts, and
> >> >> other misbehavior from the code, which were traced to an apparent bug
> >> >> in
>

Re: [Discuss-gnuradio] The GSoC project on LDPC codes.

[Miklos Maroti]

Wow, interesting to read all about this. Thanks for all the good work. Miklos

On Wed, Nov 6, 2013 at 3:17 PM, Manu T S  wrote:
> Hi Miklos,
>
> The implementation is quite slow. I don't have any quantitative performance
> measures, yet.
> Nevertheless I have some empirical measures. For example, on testing the
> implementation (all C++ and no GNU Radio) with a (8000, 4000) code(rate 0.5,
> regular), in with AWGN of 0.8 added to it (capacity 0.678),
> it took about 15-20 minutes[*] on an i7 machine to transmit and decode 100
> blocks. With smaller noise, this will be done a bit faster, for the number
> of decoding iterations required is less.
>
> The major time consuming factor in the implementation is the encoder
> construction. You may find the encoding method I implemented in the report.
> It has a complexity of O((NM)^2). Once we have the encoder matrix encoding
> is done in O(K^2) time. Decoding doesn't take that much time, but the
> current space requirement is huge. I'm using a M x N matrix(double elements)
> to hold the messages being passed between check nodes and variable nodes.
> For the (8000, 4000) code that turns out to be some 244 MB. Since H is
> sparse, most of the entries in the M x N message matrix is 0 and not used.
>
> So these are the things in my agenda for the near future.
> 1. Improving the space requirement in the decoder.
> 2. Find better methods(eg. Sparse LU) to implement encoder.
>
> I will start work with VOLK after the above mentioned improvements.
>
>
> [*] As I said before encoder construction took huge time. So to test the
> codes, I generated the encoder matrix and saved it in a separate alist file.
> This file is not generally sparse. The file size would depend on the
> structure of the code. For example, for the (8000, 4000) code the size of
> the alist file for the encoder matrix was about 64MB. The only gain here is
> that we need not generate the encoder matrix every time we need to use this
> code. We can load it from the alist file. Had I not done this, the
> experiment would have taken longer.
>
>
> On Wed, Nov 6, 2013 at 5:47 PM, Miklos Maroti 
> wrote:
>>
>> Hi Manu,
>>
>> Thanks for the report, it was more informative than the presentation.
>> Yes, I have seen the BER figure, but that is not very will presented
>> (e.g. you should use logarithmic scale for BER) and should have better
>> resolution on the Eb/N0 axes. You write that it does not use VOLK or
>> SSE2. How fast is it? Do you have any performance number? Do you plan
>> to work on it in the near future?
>>
>> Miklos
>>
>> On Wed, Nov 6, 2013 at 5:38 AM, Manu T S  wrote:
>> > Hello Mikios
>> >
>> > Here is the link to the presentation and report I made for my
>> > thesis(intermediate evaluation) at IIT Bombay. Last part describes the
>> > results I have obtained.
>> > It has a BER plot as well.
>> >
>> > https://github.com/manuts/first_stage/blob/master/ppt.pdf
>> > https://github.com/manuts/first_stage/blob/master/report.pdf
>> >
>> > The implementation is generic, in the sense that if you input a code (in
>> > alist file format), we can construct the encoder and decoder.
>> > The decoder merely implements sum product algorithm. I have tested it
>> > against many regular codes, where there was the significant gap between
>> > the
>> > rate and the capacity. I'm yet to test it against an irregular code of
>> > large
>> > block length, mainly because the encoder and decoder becomes really
>> > slow.
>> > (Many optimizations are still in order.)
>> >
>> > I wish I could tell you I had a better BER plot, but what's there in the
>> > report is all I have currently.
>> > Thanks for checking out.
>> >
>> >
>> > On Tue, Nov 5, 2013 at 11:08 PM, Miklos Maroti
>> > 
>> > wrote:
>> >>
>> >> Dear Manu,
>> >>
>> >> Do you have any performance numbers on your LDPC decoder? I could not
>> >> find any info, even in your presentation. Do you have also a BER
>> >> figure, or even better would be some technical report. I would love to
>> >> get some sense on the performance of your implementation.
>> >>
>> >> Best,
>> >> Miklos
>> >>
>> >> On Tue, Nov 5, 2013 at 6:15 PM, Manu T S  wrote:
>> >> > Dear Max,
>> >> >
>> >> > You are correct. It is a bug. Now I'm wondering why I didn't get any
>> >> > segmentation faults.
>> >> >
>> >> > Probably I didn't get any segmentation faults because, after i = M -
>> >> > 1,
>> >> > EOF
>> >> > has reached.
>> >> >
>> >> > Thanks for the correction.
>> >> >
>> >> >
>> >> > On Tue, Nov 5, 2013 at 9:14 PM, ikjtel  wrote:
>> >> >>
>> >> >> Greetings
>> >> >>
>> >> >> I was very interested in this project for possible application to
>> >> >> the
>> >> >> op25
>> >> >> project, since P25 uses several FEC codes
>> >> >> including RS and other block codes.  I've brought up the gr-ldpc
>> >> >> library
>> >> >> and have a few questions.  Due to the hateful YAhoo mail composer,
>> >> >> I'm
>> >> >> hesitant to post lengthy emails to the general list with no
>> >> >> opportunity
>> >> >> for

[Discuss-gnuradio] Decoding funcube telemetry with gnuradio

[M Dammer]

FUNcube-1 will be launched in about two weeks time and I would like to
ask if anybody has aleady worked or is working on receiving / decoding
the FUNcube telemetry with gnuradio (and an RTL-SDR as receiver)?
Modulation is 1200bps BPSK. The telemetry format is well described on
the funcube page ( http://funcube.org.uk/working-documents/ ).
I am interested in grc flowgraphs for BPSK reception as well.
73 Mark



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr and bladerf...

[The Silver Fox]

I’ve used it quite lot with a variety of dongles, funcube and hackrf.  They
all work for me with variations on gain needed to produce reliable results.
I did not try the interfaces to other programs such as google maps.  I found
that dump1090 gave me better data.

73,

Alan – W6ARH

 

From: discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org
[mailto:discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Tuesday, November 05, 2013 9:52 PM
To: 'Nick Foster'
Cc: 'GNURadio Discussion List'
Subject: Re: [Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr and
bladerf...

 

Just as a note, I also did not get the gui to work with my USRP1, the error
messages are different, but at least it did not receive.

 

Ralph.

 

From: Nick Foster [mailto:bistrom...@gmail.com] 
Sent: Tuesday, 5 November, 2013 19:14
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr and
bladerf...

 

I've only tested osmocom in gr-air-modes with the HackRF. The relevant code
is in python/radio.py lines 177-189. modes_gui does reinstantiate the source
block a couple of times (to populate the options boxes) -- it's possible
that this isn't allowing gr-osmocom enough time to close/open the USB
device, or maybe gr-osmocom doesn't like reopening the device from within
the same process?

 

--n

 

On Tue, Nov 5, 2013 at 10:04 AM, Ralph A. Schmid, dk5ras 
wrote:

Yes, works just fine, also other “toolchains” like gqrx – gr-osmosdr –
bladerf do not show any strange effects, so osmosdr seems to be OK.

 

Ralph

 

 

From: Nick Foster [mailto:bistrom...@gmail.com] 
Sent: Tuesday, 5 November, 2013 18:10
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] gr-airmodes with gnuradio. gr-osmosdr and
bladerf...

 

Does osmocom_fft work?

 

--n

 

On Tue, Nov 5, 2013 at 9:00 AM, Ralph A. Schmid, dk5ras 
wrote:

Hi,

gr-airmodes, gr-osmosdr, gnuradio and bladerf all with latest versions,
built directly from the repo.

modes_rx works just fine, the messages come through.

modes_gui throws this error, when switching insinde the gui to osmosdr:

ras@ubuntu:~$ modes_gui
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-164-g0c5099ab

gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0
[bladeRF source] Using nuand LLC bladeRF #0 SN
8efd2b30699e61bec690a0b37cc5ad57 FW v1.5.3 FPGA v0.0.0
gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0

FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.

gr-osmosdr v0.1.0-40-ge1b699fd (0.1.1git) gnuradio 3.7.2git-149-g0993c1b0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf netsdr
[INFO] Instance: 0

FATAL: [bladeRF source] Failed to open bladeRF device libusb:instance=0

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.



The bladerf is flashed with latest fx3 image and latest fpga file into the
SPI flash.

All the involved packages itself work just fine.

Any ideas what there may be wrong?


--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223  
ra...@schmid.xxx
http://www.bclog.de/




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

 

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3426 / Virus Database: 3222/6812 - Release Date: 11/05/13

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BPSK receiver issue / message passing

[Vanush Vaswani]

Thanks for the reply. It seems to be an endian issue such that I can't
simply shift bits but must use a proper framer.

I have modified an existing AX.25 block such that I can now see my
frames over the air using debug prints but I am having difficulty
getting my data out from gnuradio. The AX.25 block, from gr-ec,
creates frames through several iterations of the work() fn using a
state machine and also has a message queue output (but hasn't actually
implemented the message passing). Once I have a verified frame, what
is the best way to get the data out?

I have tried this technique:

d_good_byte_cnt += frame_size-2; // don't count CRC
gr_message_sptr msg = gr_make_message(0, 0, 0, d_good_byte_cnt);
memcpy(msg->msg(), frame_buf, d_good_byte_cnt);
d_target_queue->insert_tail(msg);
msg.reset();

and then connect to a message source, and then a file sink. However,
the memcpy seems to cause my flowgraph to crash. Any tips?


On Wed, Nov 6, 2013 at 1:42 AM, Tom Rondeau  wrote:
> On Mon, Nov 4, 2013 at 10:25 AM, Vanush Vaswani  wrote:
>> Hi all,
>>
>> I am using GR 3.6.5.1 to receive BPSK modulated data from a third
>> party RF chip / microcontroller combination and am having a strange
>> experience. I am implementing a very simple protocol by constantly
>> transmitting 0x7E constantly and then ASCII data triggered by a serial
>> connection to the microcontroller, all at 9.6kbps
>>
>> With the  following configuration
>> FCDPP source sampling at 192KHz.
>> -> AGC
>>  -> Freq Xlate (bring near baseband)
>>  -> Costas loop (remove carrier)
>> -> RRC (48 taps, symbol rate = 9600)
>> -> PSK Demod (sps = 20 as 192/20 = 9.6kbps, everything else default)
>>
>> I can see my 0x7E bitstream "square wave" in a scope sink.
>> When I pack the bits and send it to a file sink, I can see my 0x7E's
>> and also ascii data that I've typed in to the microcontroller serial
>> port. However - this is rare. Most of the time, I see the bytes of
>> rotated flag - 0x3F, 0xFC, 0x3F etc. I thought this was ok, I can
>> simply rotate the whole file by x bits to remake all the flags as
>> 0x7E. But when I do this, my ascii text input is completely garbled,
>> with only a few letters showing up.
>>
>> Can anyone give me a hint as to what is going on? I don't think my
>> transmitter is the issue, as when I get my flag bytes in the output
>> file, I can see my data.
>>
>> vanush
>
> The PSK demod has the FLL, Costas loop, and RRC filter in it. That's
> what each of those bandwidth settings are for (frequency, phase, and
> timing). But also, going in at 20 sps is really high. You should put a
> channel filter in front that both removes any extra noise and
> downsamples (by a factor of 5 or 10 to get to 4 or 2 sps).
>
> Tom

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Resolution of USRP N210 and N200

[Isdren Gineer]

To add to what Ben has wrote, if decimation is involved in the processing
stages it is possible to get a higher resolution than that of the initial
samples. For example, a decimation by a factor of two can increase the bit
precision by one. So in this case, it could depend on where the interface
is being defined. Perhaps the ADC chips being used are indeed 14 bits, as
per the spec sheet, but the implementations of the different LFRX versions
may have different post-ADC processing stages. If this is the case, while
the precision of the ADC chips is 14 bits, the output of the LFRX could
have a higher resolution.

For those wanting to learn more, this is the principle behind sigma-delta
ADCs .


On Tue, Nov 5, 2013 at 4:12 PM, Ben Hilburn  wrote:

> Hi Ting -
>
> Sorry, there really wasn't a good reason for me to not answer your
> question, regardless =)
>
> So the ADCs are indeed 14 bits, but those samples go through a lot of
> processing on a number of different platforms, and get sent over a few
> different buses. At any of these stages, depending on your system
> parameters, there might be conversions and scaling factors applied to the
> data, which changes the representation. Remember that since the ADC is a
> 14-bit ADC, you are never really getting more precision than those 14-bits;
> they are just different ways of representing that data.
>
> Does that help, at all?
>
> Cheers,
> Ben
>
>
> On Tue, Nov 5, 2013 at 11:34 AM, Ben Hilburn  wrote:
>
>> Ting -
>>
>> This question really isn't GNURadio related. If you resend it over the
>> USRP-Users list, though, we will help explain things quickly!
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> Cheers,
>> Ben
>>
>>
>> On Sat, Nov 2, 2013 at 12:22 AM, Ting Wu <
>> wu.t...@comf5.comm.eng.osaka-u.ac.jp> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> Both of USRP N210 and N200 have 14 bit ADC, which means a range of
>>> +/-2e13=+/-8129.
>>>
>>> However, as I tested a N210 with LFRX, I got values from -32704 ~ 30073,
>>> close to +/-2e15=32768.
>>>
>>> Last year, I also tested a N200 with LFRX, I got values from -16357 ~
>>> 16241, close to +/-2e14=16384.
>>>
>>> The sampling rate was set to 4 MHz.
>>>
>>>
>>>
>>> So why does the ADC has a real resolution higher than 14 bit, and are
>>> N210 and N200 the same?
>>>
>>> I’m really new to the world of ADC, so some basics would be very helpful.
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> Wu
>>>
>>> ___
>>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [coproc] Domain concept for blocks and ports

[Ben Hilburn]

Sylvain -

I've been mulling over this, and I like this design a lot. I think it
provides a lot of flexibility while also preventing any particular scenario
from becoming a "corner case". I'm still thinking about it and trying to
find somewhere to poke a hole, but at a high-level I think it is really
straight-forward.

I suggest that we discuss this further in some future [CoProc] call, and
that you add the idea to the wiki =)

Cheers,
Ben


On Fri, Oct 18, 2013 at 2:10 AM, Sylvain Munaut <246...@gmail.com> wrote:

> Hi,
>
> This is an evolution of a concept that was mentioned at GRcon which I
> really liked and I thought a bit more about it.
>
> The general idea is that each block and each port within blocks would
> have a "domain" associated to it.
>
> For the blocks this would essentially represent where that block is
> running, like CPU, DSP, FPGA, GPU
> For the ports this would represent where the data are stored Main
> memory, GPU memory, page-locked memory for a coproc, shared zone with
> a DSP, ...
>
> Once you have those, you'd need ingress/egress blocks to cross over
> data domains, they could be either a memcpy on the host, or a
> read/write buffer queued in a CL command queue, or whatever is
> required. Those wouldn't even need to be really exposed to the user.
> GRC/GR-core could be smart enough to find an appropriate path to move
> the data from one data domain to the other, it just needs a list of
> such available block.
>
> The advantage of introducting this concept to blocks is that for all
> the various types of coproc you can think of, the GR core doesn't have
> to know anything special and can delegate to appropriate domain
> handlers/plugins. Even the CPU domain and Main memory domain would
> just be plugins, no special case or anything, they would be treated
> just like any other. So coproc aren't "second class citizens", they're
> treated just like the main CPU is.
>
> Anyway, just my 2 ct.
>
> Cheers,
>
> Sylvain
>
> ___
> 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] [coproc] Domain concept for blocks and ports

[Johnathan Corgan]

On 11/06/2013 09:44 AM, Ben Hilburn wrote:

> I've been mulling over this, and I like this design a lot. I think it
> provides a lot of flexibility while also preventing any particular
> scenario from becoming a "corner case". I'm still thinking about it and
> trying to find somewhere to poke a hole, but at a high-level I think it
> is really straight-forward.

I agree with this assessment.  Based on some discussion work we had at
the GNU Radio conference, we also came up with a design for asking GNU
Radio to delegate memory allocation for block output buffers to blocks
themselves, to allow them to create their own doubly-mapped userspace
memory regions out of physical pages they control.

In this design, a block indicates to GNU Radio that it needs to allocate
the memory for either its input buffer (actually, the upstream block's
output buffer) or its own output buffer, by adding a flags field to the
io_signature and having one of the possible flags be WE_OWN.

Once all the blocks are created, and the connectivity between is
established, then GNU Radio can parse the topology and buffer flags to
know which blocks get standard GNU Radio allocated host memory buffers,
and which blocks need to be asked for a prepared memory region to use
for either its output buffer or its upstream block output buffer.  This
would be implemented by an additional overridable virtual function that
would get called by the runtime with the itemsize and count, and return
with the allocated host memory region.

The changes to GNU Radio are very minimal in this respect--adding flags
to io_signature, adding a function to gr_block, and adding logic during
buffer allocation to either use GNU Radio's allocator or a block's
allocator.  This is completely general and can be used to allow blocks
communicating with whatever underlying hardware to manage things in
whatever way is needed, creating the physical-to-virtual mappings with
whatever constraints the hardware needs.  The GNU Radio work function
"contract" imposes a few requirements for doubly mapping physical pages
to virtual pages, but we weren't able to come up with any examples that
weren't solvable from with the block.

A few topological problems arise that aren't solved yet by this, such as
having adjacent accelerator blocks that both want to own the shared
memory buffer.  The suggestion here is to use the above mechanism to
create a domain crossing "sink" block and a domain crossing "source"
block as endpoints in a hierarchical block that also instantiates
whatever logic is needed to do the chained accelerators inside.

Thus, again with minimally invasive changes to the GNU Radio internals,
this mechanism supports both single accelerator blocks as well as the
domain crossing sources and sinks.

Finally, this solution is orthogonal to the desired capability of having
in-place processing blocks.  It can be implemented fairly rapidly, even
in a 3.7 API compatible way, and gives the hooks for additional work to
implement block's requesting in-place semantics vs. the existing
streaming semantics.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Build DVB-T2 system

[ayoosh O]

Hi
I have a project about digital tv , my task now is to build the system of 
DVB-T2 using gnuradio.
but I have two problems :
1. how to read the video and convert it to binary ( the code I should to use in 
c   )2. the block of  MPEG  how to build and also it's code
Please help me
Regards aya   ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [coproc] Domain concept for blocks and ports

[Johnathan Corgan]

On 11/06/2013 10:09 AM, Johnathan Corgan wrote:

> Thus, again with minimally invasive changes to the GNU Radio internals,
> this mechanism supports both single accelerator blocks as well as the
> domain crossing sources and sinks.

I forgot to add to this that this is also a mechanism that existing
source and sink blocks could use to provide a memory region to GNU Radio
that the block would then be able to use for zero-copy (or "one less
copy") semantics with its underlying hardware driver.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [coproc] Domain concept for blocks and ports

[Ben Hilburn]

Awesome write-up, Johnathan. I really enjoyed reading it.

A few topological problems arise that aren't solved yet by this, such as
> having adjacent accelerator blocks that both want to own the shared
> memory buffer.  The suggestion here is to use the above mechanism to
> create a domain crossing "sink" block and a domain crossing "source"
> block as endpoints in a hierarchical block that also instantiates
> whatever logic is needed to do the chained accelerators inside.
>

This goes back to the "ingress" and "egress" blocks that Justin's team used
in their original design.

I think having these transitions represented with such blocks makes sense,
from a graphical perspective, but under-the-hood I think we should
architect these "gresses" as zero-copies. How that relationship /
responsibility gets controlled & delegated is something we still need to
figure out, I think.


> Thus, again with minimally invasive changes to the GNU Radio internals,
> this mechanism supports both single accelerator blocks as well as the
> domain crossing sources and sinks.
>

Yeah, this is a big selling point of the design, I think.

Finally, this solution is orthogonal to the desired capability of having
> in-place processing blocks.  It can be implemented fairly rapidly, even
> in a 3.7 API compatible way, and gives the hooks for additional work to
> implement block's requesting in-place semantics vs. the existing
> streaming semantics.
>

Right, and this is the key, I think. This problem has to be solved in a
"coproc / accelerator"-independent way; otherwise the design would be
fundamentally flawed.

Cheers,
Ben


>
> --
> Johnathan Corgan, Corgan Labs
> SDR Training and Development Services
> http://corganlabs.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRC | Block to Variable

[Aditya Dhananjay]

Hello!

In GRC, is it possible to store the latest output of a block into a
variable? Let's say I have a block "A" that is outputting floats. I want to
save the latest output of block "A" into a variable "var" such that a block
"B" can read "var" asynchronously if it needs to.

Thanks!

Aditya
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [coproc] Domain concept for blocks and ports

[Johnathan Corgan]

On 11/06/2013 11:23 AM, Ben Hilburn wrote:

> This goes back to the "ingress" and "egress" blocks that Justin's team
> used in their original design.
> 
> I think having these transitions represented with such blocks makes
> sense, from a graphical perspective, but under-the-hood I think we
> should architect these "gresses" as zero-copies. How that relationship /
> responsibility gets controlled & delegated is something we still need to
> figure out, I think.

Sure, the working group is a great place to iterate on this.

> 
> Thus, again with minimally invasive changes to the GNU Radio internals,
> this mechanism supports both single accelerator blocks as well as the
> domain crossing sources and sinks.
> 
> 
> Yeah, this is a big selling point of the design, I think.

I rebased the first commit I did for this right after the conference
onto the current master branch and pushed it here:

https://github.com/jmcorgan/gnuradio/commit/aa6f59aa33a80c3c4b6b9adfc800d97282baf68c

It just adds the buffer flags member variable and provides the modified
io_signature functions to allow setting it, with defaults to make it
compatible with the current API.  The next step is to add the gr::block
virtual function signature to be overridden, and then to implement the
parsing logic in the runtime to know when to call that instead of the
built-in memory allocator.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] generic LP/BP filters

[Tom Rondeau]

On Fri, Nov 1, 2013 at 9:44 PM, Marcus D. Leech  wrote:
> For the "generic" LP/BP filter blocks, would it make sense for them to
> automatically select either a conventional FIR or FFT-fast-convolution
> filter,
>   depending on the number of taps and other parameters?

Sorry, which classes are you talking about? Are you referring to what
we've referred to internally as the FIR/FFT filter "kernels"? These
live in gr-filter/lib/fir_filter.cc and gr-filter/lib/fft_filter.cc.

Or are you talking about the blocks themselves? Like filter.fir_filter_ccf?

Also, I'll just refer to our fast-convolution filters as the FFT
filters (since the block name is filter.fft_filter_XXX).

> The user still has access to the low-level implementations, but the choice
> between conventional FIR and fast convolution based on FFT is something that
>   *could* be done whenever the filter parameters change, yes?

Possibly... One of the problems is that the crossover between which is
the more efficient can change based on the processor. On Intel/AMD,
it's probably roughly the same. I've done a number of tests of this on
my own machines. The crossover seems to be between 10 and 30 items. So
on my AVX-enabled processor, the crossover is around 10 taps, but the
difference is so tiny between the FFT and FIR filters that whenever I
can, I use an FFT filter.

One big issue that I haven't properly tested well is the difference
between the fft_filter_ccc and fir_filter_ccf. If you have real taps
(like an LPF), we use fir_filter_ccf because we can get away with the
float-complex multiple. We don't want to have to promote the taps to
complex to run the computations. But we only have the fft_filter_ccc
(since we take the FFT of the filter taps, we make them complex,
anyways). I'm not sure how those two compare against each other.

... few seconds later.

I just compared them on an Intel i7 870 at 2.93 GHz.
fir_filter_ccc vs fft_filter_ccc: ~10 taps
fir_filter_ccf vs fft_filter_ccc: ~24 taps.

Bottom line, though. It's still probably possible and could make
sense. We could make generalized rules that is more or less right for
any platform, unless it's one where the FFT was implemented by a
monkey. Even if we say 50 taps, the amount of difference won't be that
extreme. And if it's still too much, you should always have the option
to select which one you want.

But I warn you; just because I agree that this could be and maybe
should be done, I'm probably not going to do it for lack of motivation
on my part. But if it gets done and submitted, well, that's another
story...

> Furthermore when running a standard dot-product FIR filter, do we take
> advantage of the identities shown in this paper:
>
> http://www.ws.binghamton.edu/fowler/fowler%20personal%20page/EE521_files/IV-05%20Polyphase%20FIlters_2007.pdf
>
> Which allows you to avoid computations in a FIR that will never be used in
> the output?   Looking at the code, it *looks* like we do, but I'm
>   not certain.

Yes, we definitely do. We have the pfb_decimator block, which is
basically the same thing as the fir_filter as long as the channel you
select is 0. The pfb_decimator filter allows us to select which
channel we actually want to extract. If the channel is 0, probably
better just to use the fir_filter since there's a bit less logic here
(though my test show they are /roughly/ equivalent in speed).

Tom


> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [coproc] Domain concept for blocks and ports

[Sylvain Munaut]

Hi

> In this design, a block indicates to GNU Radio that it needs to allocate
> the memory for either its input buffer (actually, the upstream block's
> output buffer) or its own output buffer, by adding a flags field to the
> io_signature and having one of the possible flags be WE_OWN.

Well, what I was thinking about is a bit different.

The block didn't really did that itself. It was delegated to a "domain" object.

The advantages are :
 - No special casing or flags. The "normal" host buffers as they are
now can be handled in the same way.
 - Since the block doesn't do that itself, that means that several
blocks can use the same "domain" object and then, if two blocks are
back to back, that object would know how to handle that.
   If the block does it all itself, two blocks using a GPU for
examples couldn't really realize that they're both in the GPU and that
there is no need to copy data back to the host at all between them. By
delegating those to standardized domain plugins, it would allow to
handle those case more gracefully IMHO.

Of course this is a bit further from the current architecture but I
think the external visible API wouldn't have to change that much when
implementing this scheme either.


Cheers,

  Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [coproc] Domain concept for blocks and ports

[Johnathan Corgan]

On 11/06/2013 12:58 PM, Sylvain Munaut wrote:

> Well, what I was thinking about is a bit different.
> 
> The block didn't really did that itself. It was delegated to a "domain" 
> object.
> 
> The advantages are :
>  - No special casing or flags. The "normal" host buffers as they are
> now can be handled in the same way.
>  - Since the block doesn't do that itself, that means that several
> blocks can use the same "domain" object and then, if two blocks are
> back to back, that object would know how to handle that.
>If the block does it all itself, two blocks using a GPU for
> examples couldn't really realize that they're both in the GPU and that
> there is no need to copy data back to the host at all between them. By
> delegating those to standardized domain plugins, it would allow to
> handle those case more gracefully IMHO.
> 
> Of course this is a bit further from the current architecture but I
> think the external visible API wouldn't have to change that much when
> implementing this scheme either.

Unfortunately, this moves the knowledge of how a domain works into GNU
Radio, and away from the code/coders that know about it.  It would mean
that any time a different co-processor or hardware offload design comes
up, GNU Radio itself would have to change, and designers would have to
have knowledge of GNU Radio internals in order to develop their code.

I suggest that a way to implement domain-specific knowledge across
multiple blocks, allowing the kind of optimization you describe above,
would be to make a parent class for each domain that the blocks of that
type all derive from.  In the parent class, static instance
variables/methods would be able to maintain the overall state needed to
coordinate the activities of the instances of the derived classes that
are sharing that domain.  The code developer then only needs to have the
domain-specific knowledge of how to create memory buffers usable by GNU
Radio and work with the co-processor.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [coproc] Domain concept for blocks and ports

[Sylvain Munaut]

Hi,

> Unfortunately, this moves the knowledge of how a domain works into GNU
> Radio, and away from the code/coders that know about it.  It would mean
> that any time a different co-processor or hardware offload design comes
> up, GNU Radio itself would have to change, and designers would have to
> have knowledge of GNU Radio internals in order to develop their code.

Not necessarily. I would see those "domain objects" be handled like
blocks, pluggable. And GR would have some for very standardized stuff
(typically the current default behavior / host memory) and you could
have some in external tree / projects.

If someone has an interface that's completly custom, they could ship
their domain plugin right along their custom block that uses it.

> I suggest that a way to implement domain-specific knowledge across
> multiple blocks, allowing the kind of optimization you describe above,
> would be to make a parent class for each domain that the blocks of that
> type all derive from.

Well, it's not that far off from what I was thinking. But doing it via
inheritance on the block level rather than by delegation to a 'domain
object' has one downside in my mind : It's global to the block. While
OTOH delegation could be part of the io signature and per-port. I can
see some blocks having input / output ports in different domains with
different requirements.

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC | Block to Variable

[Aditya Dhananjay]

Update:

I had tried to use "Function Probe" to accomplish this task, but couldn't
get it to work. After the latest pull from the git repo, it works!

Best,
Aditya



On Wed, Nov 6, 2013 at 2:54 PM, Aditya Dhananjay  wrote:

> Hello!
>
> In GRC, is it possible to store the latest output of a block into a
> variable? Let's say I have a block "A" that is outputting floats. I want to
> save the latest output of block "A" into a variable "var" such that a block
> "B" can read "var" asynchronously if it needs to.
>
> Thanks!
>
> Aditya
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1

[Aditya Dhananjay]

>
>
>
> With this fix, now I see a new error:
>
> INFO: Detected an invalid packet at item 0
> INFO: Parser returned #f
> thread[thread-per-block[18]: ]: Buffer
> too small for min_noutput_items
>
> I'll look into this, but just in case this is familiar to anyone...
>

I face the same problem.

I created an OFDM TX/RX flowgraph (mostly copying stuff out from the GNU
Radio reference GRC implementation), where the TX goes out to a USRP UHD
sink, and the RX reads from a USRP UHD source.

As long as the receive SNR is high enough, the problem does not show up.
However, as I gradually reduce the RX gain, at some point, the entire thing
crashes with the "Buffer too small for min_noutput_items" error.

Any help would be greatly appreciated.

Aditya
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration

[Michael Dickens]

As of mid-day today, gr-fosphor is available via MacPorts for OSX < 10.9 users. 
 It looks quite nice!  Thanks Sylvain! - MLD

On Oct 26, 2013, at 4:23 PM, Sylvain Munaut <246...@gmail.com> wrote:
> The home page of the project can be found at
> https://sdr.osmocom.org/trac/wiki/fosphor


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Build DVB-T2 system

[Leonardo Vargas Bernal]

Aya,

GNU Radio will help you with the PHY layer, you can find more information
about DVB-T2 at

http://www.etsi.org/deliver/etsi_en/302700_302799/302755/01.03.01_60/en_302755v010301p.pdf

http://www.dvb.org/standards

DVB-T2 is an open standard, you will find all the information on those
links.

--
Leonardo Vargas Bernal
Ingeniero Telemático


On Wed, Nov 6, 2013 at 2:14 PM, ayoosh O  wrote:

> Hi
>
> I have a project about digital tv , my task now is to build the system of
> DVB-T2 using gnuradio.
>
> but I have two problems :
>
> 1. how to read the video and convert it to binary ( the code I should to
> use in c   )
> 2. the block of  MPEG  how to build and also it's code
>
> Please help me
>
> Regards
>
> aya
>
> ___
> 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