Re: [Discuss-gnuradio] Dynamically changing input index of Selector block.

[dushyant.marathe]

Hi Activecat,

Thanks for the reply.

As suggested by you, I used "Stream Mux"  and it worked for me.

Now I want to de-multiplex the output of "Stream Mux" so as to get back both
the inputs separately.

If you have any suggestions, please let me know.
 
Thanks and Regards,
Dushyant



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Dynamically-changing-input-index-of-Selector-block-tp48550p48614.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] assertion error beyond 4096 output items

[Activecat]

On Thu, May 29, 2014 at 2:41 PM, Karan Talasila  wrote:

> So at the input of the C++ we are giving vector_source_c() and then input
> output signatures are sizeof(gr_complex). The work function is taking
> noutput_items and returning noutput_items. We understand now that because
> we have used set_output_multiple(fft_length) in the constructor, the
> noutput_items is fixed at the fft_length and then work function is being
> called.
>

The noutput_items could be fft_length or multiple of fft_length.
Says fft_length is 8192, then noutput_items could be either 8192, 16384 or
24576 etc, determined by the scheduler.
If you only get noutput_items equals to 8192, that could be due to the
number of input elements available is less than 16384.



>  However one small doubt,when we print value of noutput_items in C++
> program inside the work function ,the print statement is executed twice for
> any fft_length we use. Is this correct?  It should only print once the
> value of noutput_items if i am right.
>

If the print statement is executed twice, that means the work() function is
invoked twice.
It could be something wrong with your code, let's show your code here.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] assertion error beyond 4096 output items

[Karan Talasila]

@Activecat Here is the c++ block code

http://pastebin.com/0y1b9guh





On Thu, May 29, 2014 at 12:31 PM, Activecat  wrote:

>
> On Thu, May 29, 2014 at 2:41 PM, Karan Talasila 
> wrote:
>
>> So at the input of the C++ we are giving vector_source_c() and then input
>> output signatures are sizeof(gr_complex). The work function is taking
>> noutput_items and returning noutput_items. We understand now that because
>> we have used set_output_multiple(fft_length) in the constructor, the
>> noutput_items is fixed at the fft_length and then work function is being
>> called.
>>
>
> The noutput_items could be fft_length or multiple of fft_length.
> Says fft_length is 8192, then noutput_items could be either 8192, 16384 or
> 24576 etc, determined by the scheduler.
> If you only get noutput_items equals to 8192, that could be due to the
> number of input elements available is less than 16384.
>
>
>
>>  However one small doubt,when we print value of noutput_items in C++
>> program inside the work function ,the print statement is executed twice for
>> any fft_length we use. Is this correct?  It should only print once the
>> value of noutput_items if i am right.
>>
>
> If the print statement is executed twice, that means the work() function
> is invoked twice.
> It could be something wrong with your code, let's show your code here.
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] assertion error beyond 4096 output items

[Activecat]

On Thu, May 29, 2014 at 3:12 PM, Karan Talasila  wrote:

> @Activecat Here is the c++ block code
>

Let's change the print statement to below, recompile, run and paste the
console output here.

  std::cout << "al_enc::work:  noutput_items=" << noutput_items <<
std::endl;

Also, what did you configure on the vector_source_c ?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Dynamically changing input index of Selector block.

[Activecat]

On Thu, May 29, 2014 at 2:59 PM, dushyant.marathe  wrote:

> Hi Activecat,
>
> Thanks for the reply.
>
> As suggested by you, I used "Stream Mux"  and it worked for me.
>
> Now I want to de-multiplex the output of "Stream Mux" so as to get back
> both
> the inputs separately.
>


Use both "Head" and "Skip Head" blocks in parallel.

For example, the Head block let you get the first 1000 elements.
The "Skip Head" block let you get elements 1001 onwards.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Out of Tree Encryption block

[Perper]

Hi all,

The system configuration proposed by Dushyant with encryption after
channel coding can work in case of stream ciphers. This is how it is
done in GSM. But encryption GSM is a very bad example of application of
cryptography. Channel coding will add some known relations between
information bits and it will be source weaknesses in the overall
cryptosystem.

Best Regards,
Piotr Krysik

W dniu 28.05.2014 22:45, Marcus Müller pisze:
> Hi Dushyant,
>
> A side note:
> I'm going to go assume that with "encoder" and "decoder" you mean
> Channel Coding.
> You *must* do channel coding after encryption, otherwise you won't get
> decryptable bits
> as soon as you don't have infinite SNR. This is not optional, because
> with proper
> encryption a single flipped bit will damage your signal in several places.
> This thread reminds me of
> http://lists.gnu.org/archive/html/discuss-gnuradio/2014-04/msg00277.html
> so there might a solution to your problem there; Ralph has posted some
> interesting insights
> back then.
>
> Usually, you'll want to have something that applies something like a
> block cipher on packetized data.
> Although I'm not aware of any existing Modules that do this, using
> stream tagged blocks, and the
> gr-digital header demux infrastructure, you should be able to packetize
> your data and encrypt the payload
> en bloc, for example using AES.
>
> Greetings,
> Marcus
>
>
> On 28.05.2014 15:25, dushyant.marathe wrote:
>> I want to simulate a voice transmission system in GNURadio Companion (GRC).
>>
>> My system configuration is as follows:
>>
>> TRANSMITTER : Wav file source --> encoder --> encryption --> modulator -->
>> RF  
>>
>> RECEIVER : speaker/Wav file sink <-- decoder <-- decryption <-- demodulator
>> <-- RF
>>
>> I have simulated the above configuration in Ubuntu 12.04  machine but
>> without
>> encryption/decryption blocks.
>>
>> If you can point me to an existing OoTM of digital encryption, it would be
>> nice.
>>
>> Thanks and Regards,  
>> Dushyant
>>
>>
>>
>> --
>> View this message in context: 
>> http://gnuradio.4.n7.nabble.com/Out-of-Tree-Encryption-block-tp48595.html
>> Sent from the GnuRadio mailing list archive at Nabble.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] assertion error beyond 4096 output items

[Karan Talasila]

We changed the print statement to what you said and console output is

sagar@Horus:~/gr-alamouti/
build$ ctest -V -R al_enc
UpdateCTestConfiguration  from
:/home/sagar/gr-alamouti/build/DartConfiguration.tcl
UpdateCTestConfiguration  from
:/home/sagar/gr-alamouti/build/DartConfiguration.tcl
Test project /home/sagar/gr-alamouti/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 2
Start 2: qa_al_enc

2: Test command: /bin/sh
"/home/sagar/gr-alamouti/build/python/qa_al_enc_test.sh"
2: Test timeout computed to be: 9.99988e+06
2: al_enc::work:noutput_items1024
2: al_enc::work:noutput_items1024
2: .
2: --
2: Ran 1 test in 0.014s
2:
2: OK
1/1 Test #2: qa_al_enc    Passed0.21 sec

The following tests passed:
qa_al_enc

100% tests passed, 0 tests failed out of 1

Total Test time (real) =   0.21 sec



Vector_source_c takes in an argument numb which is a list that contains
fft_size values. I will paste the qa code here(http://pastebin.com/da21Ww4B).




On Thu, May 29, 2014 at 1:53 PM, Activecat  wrote:

>
> On Thu, May 29, 2014 at 3:12 PM, Karan Talasila 
> wrote:
>
>> @Activecat Here is the c++ block code
>>
>
> Let's change the print statement to below, recompile, run and paste the
> console output here.
>
>   std::cout << "al_enc::work:  noutput_items=" << noutput_items <<
> std::endl;
>
> Also, what did you configure on the vector_source_c ?
>



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

Re: [Discuss-gnuradio] assertion error beyond 4096 output items

[Activecat]

On Thu, May 29, 2014 at 4:54 PM, Karan Talasila  wrote:

> We changed the print statement to what you said and console output is
>
> sagar@Horus:~/gr-alamouti/
> build$ ctest -V -R al_enc
> UpdateCTestConfiguration  from
> :/home/sagar/gr-alamouti/build/DartConfiguration.tcl
> UpdateCTestConfiguration  from
> :/home/sagar/gr-alamouti/build/DartConfiguration.tcl
> Test project /home/sagar/gr-alamouti/build
> Constructing a list of tests
> Done constructing a list of tests
> Checking test dependency graph...
> Checking test dependency graph end
> test 2
> Start 2: qa_al_enc
>
> 2: Test command: /bin/sh
> "/home/sagar/gr-alamouti/build/python/qa_al_enc_test.sh"
> 2: Test timeout computed to be: 9.99988e+06
> 2: al_enc::work:noutput_items1024
> 2: al_enc::work:noutput_items1024
>


This is unittest, not the application flowgraph.

Unittest is used to verify your code.
Application flowgraph is used to run RF simulations.

In application flowgraph, if you only have 8192 inputs while the fft_length
is set to 8192, then the work() should be called only once.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Out of Tree Encryption block

[Marcus Müller]

Hi Piotr, hi Dushyant,

> GSM
of course, that's true; but it's, as you said, widely agreed upon that
this is security-wise a bad design choice; and it drastically complicate
design of such a transmission system (because you can't check
transmission correctness before decryption).
With stream ciphers, a wrong symbol in the ciphered text stays but a
wrong symbol in the plaintext; for GSM designers this was important,
because the neither had the hardware that would have made handsets
capable of decoding big blocks of data, nor was channel coding that
effective in the beginning; I agree, for things like audio applications,
where occasional post-FEC bit errors are totally ok, a stream cipher
will be the right choice. Maybe my mind was a little centered on
packeted data transmission, where you'd want your channel coding to
detect all bit errors, and the system to retransmit that package (iff
these can't be corrected). With an effective zero-bitrate per receive
packet, doing a stream cipher has no functional advantage.

So: You got me there :)

Greetings,
Marcus

On 29.05.2014 10:33, Perper wrote:
> Hi all,
> 
> The system configuration proposed by Dushyant with encryption after
> channel coding can work in case of stream ciphers. This is how it is
> done in GSM. But encryption GSM is a very bad example of application of
> cryptography. Channel coding will add some known relations between
> information bits and it will be source weaknesses in the overall
> cryptosystem.
> 
> Best Regards,
> Piotr Krysik
> 
> W dniu 28.05.2014 22:45, Marcus Müller pisze:
>> Hi Dushyant,
>>
>> A side note:
>> I'm going to go assume that with "encoder" and "decoder" you mean
>> Channel Coding.
>> You *must* do channel coding after encryption, otherwise you won't get
>> decryptable bits
>> as soon as you don't have infinite SNR. This is not optional, because
>> with proper
>> encryption a single flipped bit will damage your signal in several places.
>> This thread reminds me of
>> http://lists.gnu.org/archive/html/discuss-gnuradio/2014-04/msg00277.html
>> so there might a solution to your problem there; Ralph has posted some
>> interesting insights
>> back then.
>>
>> Usually, you'll want to have something that applies something like a
>> block cipher on packetized data.
>> Although I'm not aware of any existing Modules that do this, using
>> stream tagged blocks, and the
>> gr-digital header demux infrastructure, you should be able to packetize
>> your data and encrypt the payload
>> en bloc, for example using AES.
>>
>> Greetings,
>> Marcus
>>
>>
>> On 28.05.2014 15:25, dushyant.marathe wrote:
>>> I want to simulate a voice transmission system in GNURadio Companion (GRC).
>>>
>>> My system configuration is as follows:
>>>
>>> TRANSMITTER : Wav file source --> encoder --> encryption --> modulator -->
>>> RF  
>>>
>>> RECEIVER : speaker/Wav file sink <-- decoder <-- decryption <-- demodulator
>>> <-- RF
>>>
>>> I have simulated the above configuration in Ubuntu 12.04  machine but
>>> without
>>> encryption/decryption blocks.
>>>
>>> If you can point me to an existing OoTM of digital encryption, it would be
>>> nice.
>>>
>>> Thanks and Regards,  
>>> Dushyant
>>>
>>>
>>>
>>> --
>>> View this message in context: 
>>> http://gnuradio.4.n7.nabble.com/Out-of-Tree-Encryption-block-tp48595.html
>>> Sent from the GnuRadio mailing list archive at Nabble.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 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] assertion error beyond 4096 output items

[Activecat]

On Thu, May 29, 2014 at 4:54 PM, Karan Talasila  wrote:

> We changed the print statement to what you said and console output is
>
> sagar@Horus:~/gr-alamouti/
> build$ ctest -V -R al_enc
> UpdateCTestConfiguration  from
> :/home/sagar/gr-alamouti/build/DartConfiguration.tcl
> UpdateCTestConfiguration  from
> :/home/sagar/gr-alamouti/build/DartConfiguration.tcl
> Test project /home/sagar/gr-alamouti/build
> Constructing a list of tests
> Done constructing a list of tests
> Checking test dependency graph...
> Checking test dependency graph end
> test 2
> Start 2: qa_al_enc
>
> 2: Test command: /bin/sh
> "/home/sagar/gr-alamouti/build/python/qa_al_enc_test.sh"
> 2: Test timeout computed to be: 9.99988e+06
> 2: al_enc::work:noutput_items1024
> 2: al_enc::work:noutput_items1024
>

Are you sure this is from the code unmodified at
http://pastebin.com/da21Ww4B ?
You configured n=2048 but the work() is called with noutput_items=1024.
Earlier you said it worked well.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] assertion error beyond 4096 output items

[Karan Talasila]

Activecat,
I am sorry, I pasted the wrong qa code. I changed value
of n to n=1024 and then when i printed it, I got the output I pasted above.


On Thu, May 29, 2014 at 3:19 PM, Activecat  wrote:

>
> On Thu, May 29, 2014 at 4:54 PM, Karan Talasila 
> wrote:
>
>> We changed the print statement to what you said and console output is
>>
>> sagar@Horus:~/gr-alamouti/
>> build$ ctest -V -R al_enc
>> UpdateCTestConfiguration  from
>> :/home/sagar/gr-alamouti/build/DartConfiguration.tcl
>> UpdateCTestConfiguration  from
>> :/home/sagar/gr-alamouti/build/DartConfiguration.tcl
>> Test project /home/sagar/gr-alamouti/build
>> Constructing a list of tests
>> Done constructing a list of tests
>> Checking test dependency graph...
>> Checking test dependency graph end
>> test 2
>> Start 2: qa_al_enc
>>
>> 2: Test command: /bin/sh
>> "/home/sagar/gr-alamouti/build/python/qa_al_enc_test.sh"
>> 2: Test timeout computed to be: 9.99988e+06
>> 2: al_enc::work:noutput_items1024
>> 2: al_enc::work:noutput_items1024
>>
>
> Are you sure this is from the code unmodified at
> http://pastebin.com/da21Ww4B ?
> You configured n=2048 but the work() is called with noutput_items=1024.
> Earlier you said it worked well.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] question on 802.15.4 implementation

[Bastian Bloessl]

Hi Anirud,

On 28 May 2014, at 18:47, Sahoo, Anirudha  wrote:

> mac.cc:mac_in: pmt_is_pair
> mac.cc::mac_in: data_len = 30
> CRC at Reception: 0
> MAC: Dropping packet self routed
>  
> I poked around mac.cc code a bit. It looks like the message received has the 
> same mac id as the mac id of the receiver. It seems that the MAC layer does 
> not use the *real* MAC id, rather it generates mac id using “rand() % 100”. 
> My understanding is that the receiver is also getting the same mac-id as the 
> sender and hence dropping packet.
> Any idea how to fix the problem?

Which code are you using? I can neither find the debug output nor the “rand() % 
100” code. Also what do you mean with MAC id? Sequence number or MAC address?

Best,
Bastian


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

Re: [Discuss-gnuradio] importing blocks to GRC

[Pengyu Zhang]

Yeah. I also think some configurations on my machine are not correct. Here
are the output of several commands.

$ cmake ..
-- The CXX compiler identification is GNU 4.8.2
-- The C compiler identification is GNU 4.8.2
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   filesystem
--   system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- checking for module 'gnuradio-runtime'
--   found gnuradio-runtime, version 3.7.2.1
-- Found GNURADIO_RUNTIME: /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so
-- checking for module 'cppunit'
--   found cppunit, version 1.13.1
-- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
-- Found SWIG: /usr/bin/swig2.0 (found version "2.0.11")
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
suitable version "2.7.6", minimum required is "2")
CMake Warning (dev) at cmake/Modules/GrSwig.cmake:25 (include):
  Syntax Warning in cmake code at

/home/vijaykp/gr-howto/cmake/Modules/GrPython.cmake:196:44

  Argument not separated from preceding token by whitespace.
Call Stack (most recent call first):
  swig/CMakeLists.txt:28 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at cmake/Modules/GrSwig.cmake:25 (include):
  Syntax Warning in cmake code at

/home/vijaykp/gr-howto/cmake/Modules/GrPython.cmake:196:92

  Argument not separated from preceding token by whitespace.
Call Stack (most recent call first):
  swig/CMakeLists.txt:28 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at cmake/Modules/GrSwig.cmake:25 (include):
  Syntax Warning in cmake code at

/home/vijaykp/gr-howto/cmake/Modules/GrPython.cmake:196:100

  Argument not separated from preceding token by whitespace.
Call Stack (most recent call first):
  swig/CMakeLists.txt:28 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.6",
minimum required is "2")
CMake Warning (dev) at swig/CMakeLists.txt:29 (include):
  Syntax Warning in cmake code at

/home/vijaykp/gr-howto/cmake/Modules/GrPython.cmake:196:44

  Argument not separated from preceding token by whitespace.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at swig/CMakeLists.txt:29 (include):
  Syntax Warning in cmake code at

/home/vijaykp/gr-howto/cmake/Modules/GrPython.cmake:196:92

  Argument not separated from preceding token by whitespace.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at swig/CMakeLists.txt:29 (include):
  Syntax Warning in cmake code at

/home/vijaykp/gr-howto/cmake/Modules/GrPython.cmake:196:100

  Argument not separated from preceding token by whitespace.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found Doxygen: /usr/bin/doxygen (found version "1.8.6")
CMake Warning (dev) at cmake/Modules/GrSwig.cmake:182 (include):
  Syntax Warning in cmake code at

/home/vijaykp/gr-howto/cmake/Modules/GrPython.cmake:196:44

  Argument not separated from preceding token by whitespace.
Call Stack (most recent call first):
  swig/CMakeLists.txt:47 (GR_SWIG_INSTALL)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at cmake/Modules/GrSwig.cmake:182 (include):
  Syntax Warning in cmake code at

/home/vijaykp/gr-howto/cmake/Modules/GrPython.cmake:196:92

  Argument not separated from preceding token by whitespace.
Call Stack (most recent call first):
  swig/CMakeLists.txt:47 (GR_SWIG_INSTALL)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at cmake/Modules/GrSwig.cmake:182 (include):
  Syntax Warning in cmake code at

/home/vijaykp/gr-howto/cmake/Modules/GrPython.cmake:196:100

  Argument not separated from preceding token by whitespace.
Call Stack (most recent call first):
  swig/CMakeLists.txt:47 (GR_SWIG_INSTALL)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at python/CMakeLists.txt:23 (include):
  Syntax Warning in cmake code at

/home/vijaykp/gr-howto/cmake/Modules/GrPython.cmake:196:44

  Argument not separated from preceding token by whitespace.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at python/CMakeLists.txt:23 (include):
  Syntax Warning in cmake code at

/home/vijaykp/gr-howto/cmake/Modules/GrPython.cmake:196:92

  Argument not separated from preceding token by 

Re: [Discuss-gnuradio] importing blocks to GRC

[Alfredo Muniz]

On Thu, May 29, 2014 at 5:13 AM, Pengyu Zhang  wrote:

> I also think some configurations on my machine are not correct


Let's simplify the problem even more. It should be the case that when you
place a xml file in /usr/local/share/gnuradio/blocks/ it will show up in
GNU Radio Companion regardless of if you actually made the block. Do a sudo
cp on howto_square2_ff.xml. Then open up GNU Radio and see if you can find
the HOWTO category and the square block.

If that doesn't work, GNU Radio is likely searching somewhere else for new
blocks similar to this problem
http://gnuradio.4.n7.nabble.com/Cannot-see-my-custom-blocks-in-GRC-td45780.htmlsince
your versions match. I recommend updating.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Using an OFDM Modulation for Transmit_Path.py and Receive_Path.py

[Jonathan Fox]

I am building a hierarchical block for an OFDM tranceiver (two classes in
the same py file) and I was wondering if I could save time by using the old
transmit_path and receive_path scripts. Would they work with the OFDM
modulator and demod from the default build?

Thanks

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

Re: [Discuss-gnuradio] importing blocks to GRC

[Pengyu Zhang]

I think the default GNU Radio search path is /usr/share/gnuradio/grc/blocks
because all existing blocks are stored within this directory. I added the
new path into GRC_BLOCKS_PATH variable.

export GRC_BLOCKS_PATH=/usr/local/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH

Now I can see the howto block in GRC. For a quick test, I connected a
constant source 0.5 to the howto module. The output of howto module is
0.25, which is the square of input. Therefore, the gr-howto block functions
as expected. However, when I run the GRC, I saw one error message and am
not sure what it indicates.

libGL error: failed to load driver: swrast


On Thu, May 29, 2014 at 12:28 PM, Alfredo Muniz 
wrote:

>
> On Thu, May 29, 2014 at 5:13 AM, Pengyu Zhang  wrote:
>
>> I also think some configurations on my machine are not correct
>
>
> Let's simplify the problem even more. It should be the case that when you
> place a xml file in /usr/local/share/gnuradio/blocks/ it will show up in
> GNU Radio Companion regardless of if you actually made the block. Do a sudo
> cp on howto_square2_ff.xml. Then open up GNU Radio and see if you can find
> the HOWTO category and the square block.
>
> If that doesn't work, GNU Radio is likely searching somewhere else for new
> blocks similar to this problem
> http://gnuradio.4.n7.nabble.com/Cannot-see-my-custom-blocks-in-GRC-td45780.html
> since your versions match. I recommend updating.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] header_payload_demux

[xianda]

Hi:
  Thank you in advance.
  I have two simple question:
 1.In the grc,i see a block: header_payload_demux  
  It has 3 input:in,trigger,header_data.But i see the 
header_payload_demux_impl.cc:iosignature::make2(1,2,..,..).But it has 3 
input,why?
 Thank you.
 2.fft:I see the shift:yes.
  I want to save the symbol to file sink and analyse by matlab.But now i 
don't know it's shift earlier or fft earlier?
 Thank you.
Best regards,
xianda___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] header_payload_demux

[Martin Braun]

On 05/29/2014 08:07 PM, xianda wrote:
> Hi:
>   Thank you in advance.
>   I have two simple question:
>  1.In the grc,i see a block: header_payload_demux  
>   It has 3 input:in,trigger,header_data.But i see
> the header_payload_demux_impl.cc:iosignature::make2(1,2,..,..).But it
> has 3 input,why?

Why 3 inputs or how come only 2 are in the io signature?
header_data is a message port, I guess that's what you're after.

>  Thank you.
>  2.fft:I see the shift:yes.
>   I want to save the symbol to file sink and analyse by matlab.But
> now i don't know it's shift earlier or fft earlier?

Can you rephrase that question?

M

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

Re: [Discuss-gnuradio] header_payload_demux

[xianda]

Hi Thanks for your kindly reply. 1.The second question is:I 
see the fft block,it has one option:shift,and you set yes. And in the 
transmit part,we should do the ifft.And in the receive part,we should do the 
fft. They all set the shift:yes. And now I want to save the 
data to file and analyse the data by matlab. In the transmit maybe 
ifft(fftshift(symbol)),but in the receive what command? 2.I see maybe 
you don't use the pilot in the receive part.Am I right? 3.I see maybe 
the cyclic prefix is dropped in the header_payload_demux block.Am I right? 
Thank you.Can you explain it?Thank you.Best regards
At 2014-05-30 05:05:54, "Martin Braun"  wrote:
>On 05/29/2014 08:07 PM, xianda wrote:
>> Hi:
>>   Thank you in advance.
>>   I have two simple question:
>>  1.In the grc,i see a block: header_payload_demux  
>>   It has 3 input:in,trigger,header_data.But i see
>> the header_payload_demux_impl.cc:iosignature::make2(1,2,..,..).But it
>> has 3 input,why?
>
>Why 3 inputs or how come only 2 are in the io signature?
>header_data is a message port, I guess that's what you're after.
>
>>  Thank you.
>>  2.fft:I see the shift:yes.
>>   I want to save the symbol to file sink and analyse by matlab.But
>> now i don't know it's shift earlier or fft earlier?
>
>Can you rephrase that question?
>
>M
>
>___
>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] assertion error beyond 4096 output items

[Activecat]

On Thu, May 29, 2014 at 4:54 PM, Karan Talasila  wrote:

> Vector_source_c takes in an argument numb which is a list that contains
> fft_size values. I will paste the qa code here(http://pastebin.com/da21Ww4B).
> 
>


Something a little bit out of topic:
Part of your code at http://pastebin.com/da21Ww4B

numb=list()
for i in range (n):
numb.append(complex(lst1[i],lst2[i]))


Above code is not "vectorized".
The vectorized version may look like:

numb = numpy.complex64( lst1 )  +  1j * numpy.complex64( lst2 )


Vectorization is probably less critical in unittest, but should not be
overlooked for blocked coded in python.
For info about vectorization,
http://www.mathworks.com/help/matlab/matlab_prog/vectorization.html
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio