Re: [Discuss-gnuradio] Problem with SWIG on Windows

[Geof Nieboer]

It looks like there are some AVX instructions being added to the libraries
even on the vanilla builds.  This will cause a DLL not be unable to load,
which ends up with the error message you received.  This is either because:

1- I've missed something during the build process and something is being
built that way by mistake
2- Because many of these libraries were originally built for Linux, which
is more likely to assume that the code is being run on the same machine
it's compiled on, it's possible an internal build routine is using the
compiling CPU's capabilities and something is sneaking by.
3- There is a bug in MSVC.

Unfortunately, this is difficult to troubleshoot at the moment because I
don't have a development machine without AVX handy, at least for the next
month or so.
While #3 seems unlikely, I've been examining some very fast vectorized
cos() code that MSVC is emitting, and I'm seeing AVX instructions when I've
disabled SIMD, so there's more to look at there.

Bottom line... it may take a bit to figure that out for your machine.


On Mon, Apr 25, 2016 at 7:48 AM, Geof Nieboer  wrote:

> Also,
>
> 1- Do you have the MSVC 14.0 runtimes installed?  The current installer
> does NOT install them automatically for Win 8.
> 2- See an earlier email on the mailing list about troubleshooting this
> with Dependency Walker to see if any libraries are not being found.
> 3- I assume you weren't able to get anything to run... will volk_profile
> run successfully?
> 4- You did download the "generic" release version and you are running
> 64-bit windows, correct?
>
>
> On Mon, Apr 25, 2016 at 7:23 AM, Geof Nieboer 
> wrote:
>
>> What CPU do you have?  We are having some problems with older CPUs.
>>
>> Geof
>>
>> On Mon, Apr 25, 2016 at 12:56 AM, Camera Parts 
>> wrote:
>>
>>> Hi,
>>>
>>>   I am new to GnuRadio.
>>>
>>>   I installed on Windows 8 using gnuradio_3.7.9.2_win64.msi.  I am
>>> looking for a simple example in order to test the installation. When I try
>>> to run mono_tone.py located in \share\gnuradio\examples\audio, I got an
>>> error saying "ImportError: DLL load failed: %1 is not a valid Win32
>>> application."
>>>
>>>   Could someone help?
>>>
>>> Thanks
>>>
>>>
>>> C:\GNURadio-3.7\share\gnuradio\examples\audio>python mono_tone.py
>>> Traceback (most recent call last):
>>>   File "mono_tone.py", line 23, in 
>>> from gnuradio import gr
>>>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\__init__.py", line
>>> 41, in
>>> 
>>> from runtime_swig import *
>>>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
>>> line 28,
>>>  in 
>>> _runtime_swig = swig_import_helper()
>>>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
>>> line 24,
>>>  in swig_import_helper
>>> _mod = imp.load_module('_runtime_swig', fp, pathname, description)
>>> ImportError: DLL load failed: %1 is not a valid Win32 application.
>>>
>>> ___
>>> 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] Problem with SWIG on Windows

[Anon Lister]

Also, does gnuradio companion run from the start menu?
On Apr 24, 2016 5:57 PM, "Camera Parts"  wrote:

> Hi,
>
>   I am new to GnuRadio.
>
>   I installed on Windows 8 using gnuradio_3.7.9.2_win64.msi.  I am looking
> for a simple example in order to test the installation. When I try to run
> mono_tone.py located in \share\gnuradio\examples\audio, I got an error
> saying "ImportError: DLL load failed: %1 is not a valid Win32 application."
>
>   Could someone help?
>
> Thanks
>
>
> C:\GNURadio-3.7\share\gnuradio\examples\audio>python mono_tone.py
> Traceback (most recent call last):
>   File "mono_tone.py", line 23, in 
> from gnuradio import gr
>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\__init__.py", line
> 41, in
> 
> from runtime_swig import *
>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
> line 28,
>  in 
> _runtime_swig = swig_import_helper()
>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
> line 24,
>  in swig_import_helper
> _mod = imp.load_module('_runtime_swig', fp, pathname, description)
> ImportError: DLL load failed: %1 is not a valid Win32 application.
>
> ___
> 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] Problem with SWIG on Windows

[Geof Nieboer]

Also,

1- Do you have the MSVC 14.0 runtimes installed?  The current installer
does NOT install them automatically for Win 8.
2- See an earlier email on the mailing list about troubleshooting this with
Dependency Walker to see if any libraries are not being found.
3- I assume you weren't able to get anything to run... will volk_profile
run successfully?
4- You did download the "generic" release version and you are running
64-bit windows, correct?


On Mon, Apr 25, 2016 at 7:23 AM, Geof Nieboer  wrote:

> What CPU do you have?  We are having some problems with older CPUs.
>
> Geof
>
> On Mon, Apr 25, 2016 at 12:56 AM, Camera Parts 
> wrote:
>
>> Hi,
>>
>>   I am new to GnuRadio.
>>
>>   I installed on Windows 8 using gnuradio_3.7.9.2_win64.msi.  I am
>> looking for a simple example in order to test the installation. When I try
>> to run mono_tone.py located in \share\gnuradio\examples\audio, I got an
>> error saying "ImportError: DLL load failed: %1 is not a valid Win32
>> application."
>>
>>   Could someone help?
>>
>> Thanks
>>
>>
>> C:\GNURadio-3.7\share\gnuradio\examples\audio>python mono_tone.py
>> Traceback (most recent call last):
>>   File "mono_tone.py", line 23, in 
>> from gnuradio import gr
>>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\__init__.py", line
>> 41, in
>> 
>> from runtime_swig import *
>>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
>> line 28,
>>  in 
>> _runtime_swig = swig_import_helper()
>>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
>> line 24,
>>  in swig_import_helper
>> _mod = imp.load_module('_runtime_swig', fp, pathname, description)
>> ImportError: DLL load failed: %1 is not a valid Win32 application.
>>
>> ___
>> 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] Problem with SWIG on Windows

[Camera Parts]

AMD Sempron Dual Core 2200 (2.0 GHz), bought around 2008.

Yes, it is quite old, but why?


On Sun, 4/24/16, Geof Nieboer  wrote:

 Subject: Re: [Discuss-gnuradio] Problem with SWIG on Windows
 To: "Camera Parts" , "Discuss-gnuradio@gnu.org" 

 Date: Sunday, April 24, 2016, 9:23 PM
 
 What CPU
 do you have?  We are having some problems with older
 CPUs.
 Geof
 On Mon, Apr 25, 2016 at
 12:56 AM, Camera Parts 
 wrote:
 Hi,
 
 
 
   I am new to GnuRadio.
 
 
 
   I installed on Windows 8 using
 gnuradio_3.7.9.2_win64.msi.  I am looking for a simple
 example in order to test the installation. When I try to run
 mono_tone.py located in
 \share\gnuradio\examples\audio, I got an
 error saying "ImportError: DLL load failed: %1 is not a
 valid Win32 application."
 
 
 
   Could someone help?
 
 
 
 Thanks
 
 
 
 
 
 C:\GNURadio-3.7\share\gnuradio\examples\audio>python
 mono_tone.py
 
 Traceback (most recent call last):
 
   File "mono_tone.py", line 23, in
 
 
     from gnuradio import gr
 
   File
 "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\__init__.py",
 line 41, in
 
 
 
     from runtime_swig import *
 
   File
 "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
 line 28,
 
  in 
 
     _runtime_swig = swig_import_helper()
 
   File
 "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
 line 24,
 
  in swig_import_helper
 
     _mod = imp.load_module('_runtime_swig', fp,
 pathname, description)
 
 ImportError: DLL load failed: %1 is not a valid Win32
 application.
 
 
 
 ___
 
 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] Problem with SWIG on Windows

[Geof Nieboer]

What CPU do you have?  We are having some problems with older CPUs.

Geof

On Mon, Apr 25, 2016 at 12:56 AM, Camera Parts 
wrote:

> Hi,
>
>   I am new to GnuRadio.
>
>   I installed on Windows 8 using gnuradio_3.7.9.2_win64.msi.  I am looking
> for a simple example in order to test the installation. When I try to run
> mono_tone.py located in \share\gnuradio\examples\audio, I got an error
> saying "ImportError: DLL load failed: %1 is not a valid Win32 application."
>
>   Could someone help?
>
> Thanks
>
>
> C:\GNURadio-3.7\share\gnuradio\examples\audio>python mono_tone.py
> Traceback (most recent call last):
>   File "mono_tone.py", line 23, in 
> from gnuradio import gr
>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\__init__.py", line
> 41, in
> 
> from runtime_swig import *
>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
> line 28,
>  in 
> _runtime_swig = swig_import_helper()
>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
> line 24,
>  in swig_import_helper
> _mod = imp.load_module('_runtime_swig', fp, pathname, description)
> ImportError: DLL load failed: %1 is not a valid Win32 application.
>
> ___
> 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] baz-utils and python path

[Nate Temple]

Hello,

The config.pyc is a compiled python / byte code file. You'll need to delete the 
config.pyc file and edit the config.py, as the scanner.py program reads in the 
config.py for it's settings. 

- Nate


> On Apr 24, 2016, at 3:06 AM, Freedomfighter099 . 
>  wrote:
> 
> Hello
> 
> I got the cyberspectrum  scanner.py running following your instructions
> 
> But I don’t seem to have any control or options to configure my USRP been 
> looking into the code in both scanner.py and the config.pyc and within 
> scanner.py is most related to FFT and the config.pyc I can’t edit because of 
> the format
> 
> So how do I configure my USRP B200 to a specific frequency range and RX2 
> antenna, gain, step size and so on I’m guessing that I need to configure my 
> config.pyc file but I can’t read this file with gedit or notepadqq any advice 
> or instructions would be greatly appreciated
> 
> Thanks
> 
> 
> 2016-04-24 6:37 GMT+02:00 Nate Temple :
> Hello,
> 
> Within the cyberspectrum/ folder there is the file "config.model.py", you 
> need to copy it to "config.py" by running
> 
> cp config.model.py config.py
> 
> 
> You can then run the scanner.py program with:
> 
> python scanner.py
> 
> If you want to graph the data, you can add the --graph flag, such as:
> 
> python scanner.py --graph
> 
> Regards,
> Nate
> 
> > On Apr 23, 2016, at 1:06 PM, Freedomfighter099 . 
> >  wrote:
> >
> > I understand the error message  which is printed in the error
> >
> > what I don’t understand is what to copy and where to past it?
> >
> > Within cyberspectrum directory there are a bunch of py executable codes
> >
> > Scanner.py and spectrum_view and such are in the same directory as the 
> > config.model.py which is the code in question, what do I do with this code? 
> > Furthermore where do I paste it to.
> >
> > Sorry I am a newbie to all of this coding stuff, so things are not 
> > self-explanatory to me yet
> >
> > I have a USRP B200 which is a detail which might be relevant.
> >
> > And again thanks
> >
> >
> > 2016-04-23 20:42 GMT+02:00 Nate Temple :
> > Hello,
> >
> > The solution to resolving your error is printed within the error itself.
> >
> > "Make sure you have a config.py (e.g. make a copy of config.model.py)"
> >
> > You need to copy config.model.py to config.py within the cyberspectrum/ 
> > folder. scanner.py should then run.
> >
> > Here is the relevant bit of code - 
> > https://github.com/balint256/cyberspectrum/blob/master/scanner.py#L67
> >
> > Regards,
> > Nate
> >
> >
> > > On Apr 23, 2016, at 1:59 AM, Freedomfighter099 . 
> > >  wrote:
> > >
> > > I got everything to work using the export command so thanks for that,
> > >
> > > I have unfortunately already run into another issue which I could need 
> > > some guidance on
> > >
> > > I’m running into this error: Could not import configuration: No module 
> > > named config
> > >
> > > Make sure you have a config.py (e.g. make a copy of config.model.py)
> > >
> > > Traceback (most recent call last):
> > >
> > >   File "./scanner.py", line 74, in 
> > >
> > > raise e
> > >
> > > ImportError: No module named config
> > >
> > > freedomfighter@radiocom:/usr/local/gnuradio/cyberspectrum$
> > >
> > > it would seem that the python code in config.model.py is not executable 
> > > is that right and if so how can I make it executable so that I can get 
> > > the following scanner.py and spectrum_viewer.py to work
> > >
> > > Any advice or guidance would be greatly appreciated
> > >
> > > Thanks
> > >
> > >
> > > 2016-04-23 0:31 GMT+02:00 Nate Temple :
> > > Hello,
> > >
> > > You can add the path to your PYTHONPATH variable by adding this line to 
> > > the end of your ~/.bashrc file
> > >
> > > export PYTHONPATH=$PYTHONPATH:/path/to/baz-utils/lib/python
> > >
> > >
> > > You'll need to update the "/path/to/baz-utils/lib/python" to where you 
> > > have cloned baz-utils. Also note baz-utils directory structure has 
> > > changed and the readme is outdated , it should say lib/python instead of 
> > > src/python. ( The structure was changed with this commit: 
> > > https://github.com/balint256/baz-utils/commit/66d1382383e48a09b9af65a86f43f2eb813f83a3
> > >  )
> > >
> > > After you add the export line above to your ~/.bashrc file, you'll need 
> > > to log out and log back in for it to take effect. You can check it with
> > >
> > > echo $PYTHONPATH
> > >
> > >
> > >
> > >
> > > - Nate
> > >
> > >
> > > > On Apr 22, 2016, at 1:31 PM, Freedomfighter099 . 
> > > >  wrote:
> > > >
> > > > Hello
> > > >
> > > > Would someone please explain to me how to add the following to python 
> > > > path: Add src/python to PYTHONPATH
> > > >
> > > > I can’t seem to get it to work! instructions would be greatly 
> > > > appreciated
> > > >
> > > > cheers
> > > >

Re: [Discuss-gnuradio] Multiple Inputs in Tagged Stream Block

[Martin Braun]

On 24 Apr 2016 14:31, "Jingyi Sun"  wrote:
>
> Hi Martin,
>
> Thanks! We implemented the changes you suggested and it worked! We are
now able to have multiple inputs and propagate the proper tags. We are now
working on our next roadblock, which we feel like must also be a simple
problem:
>
> As a test to make sure that we could propagate data + tags properly, we
wrote geese_vcvc so that it takes just one input_items (in this case
input_items[0]) and sends it directly to the output_items[0]:
>
>   const gr_complex *d = (const gr_complex *) input_items[0];
>   const gr_complex *alpha = (const gr_complex *) input_items[1];
>   const gr_complex *x = (const gr_complex *) input_items[2];
>   const gr_complex *out = (const gr_complex *) output_items[0];
>
>   int frame_len = 0;
>
>   if (d_fixed_frame_len) {
>   frame_len = d_fixed_frame_len;
>   } else {
>   frame_len = ninput_items[0];
>   }
>
>   std::vector tags
>
>   out = d;

You're assigning the output vector. You need to memcpy the data. Also
please stay on the list.

M
>
> Then in the OFDM RX chain, we inserted the geese_vcvc block between the
OFDM frame equalizer and the OFDM frame serializer; geese_vcvc has three
inputs, but we wired the output of OFDM frame equalizer to all three inputs
(see attached image). In theory, our input_item[0] passes through
geese_vcvc untouched and the OFDM Receiver behaves just as it would without
geese_vcvc. We confirmed that all tags were passing through untouched.
Unfortunately, we suspect that something is corrupting the data bytes.
>
> We tracked the problem using tag debug, and found that after the stream
crc32 block, all the tags are dropped and no data was getting through. We
know that the crc32 has a function built in to allow it to drop failed
packets, which must be happening here. However, we can't figure out what in
geese_vcvc is corrupting the data, given that we're just passing the input
to the output. Any ideas?
>
> Thanks!
> Jenny & Team
>
>
>
>
> On Sun, Apr 24, 2016 at 2:19 PM, Martin Braun  wrote:
>>
>> On 04/23/2016 12:36 PM, Jingyi Sun wrote:
>> > Hi Martin and everyone,
>> >
>> > I've pinpointed what causes this error to occur with 3 inputs, but not
>> > occur with just 1 input.
>> >
>> > gr::log :FATAL: geese_vcvc0 - Missing a required length tag on port
>> > 1 at item #0
>> > thread[thread-per-block[46]: ]: Missing
length
>> > tag.
>>
>> Tagged streams carry tags to identify burst boundaries. Your input is
>> not seeing such a tag.
>>
>> Now, you should never, ever manually handle those tags. Whatever your
>> upstream block is, it should thus be either a tagged_stream_block, or
>> have automatic tag propagation.
>>
>>
>> > The culprit seems to be the following block of code inside my
>> > geese_vcvc_impl.cc file. I have it in my code right now because I based
>> > my block on ofdm_frame_equalizer.cc.  I gather that it parses length of
>> > tags, and but seems to only do so for one input?  Unfortunately I am
>> > unsure how to exactly interpret what it is doing.
>>
>> Well, yes, the original block only has one input. This is an advanced
>> functionality of tagged stream blocks. You rarely need to override it.
>> The only reason we do that here is because we allow the equalizer to run
>> either as a tagged stream block, or a fixed size (but non-tagged-steram)
>> block.
>>
>> Just don't use the fixed-length feature, don't include this method, and
>> you'll be fine.
>>
>> Also don't paste pictures of code -- how am I supposed to comment on it
>> inline.
>>
>> Cheers,
>> M
>>
>> > Martin, I notice you've worked on the ofdm_frame_equalizer block
>> > before--could you please help me go through what this piece of code
>> > does, and how I could change it to be compatible with a block with
>> > multiple inputs.  I'm not thoroughly familiar with c++, and also am not
>> > sure about the particular purposes of variables here, or what the
>> > specific characteristics of "tags" vector are.
>> >
>> > *My goal is to do something similar to add two equalized input tagged
>> > streams together, and output the sum tagged stream, while also
>> > propagating tags through for tag debug.*
>> >
>> > *I would tremendously appreciate if you could briefly walk me through
>> > the following lines. Is this code necessary for tag propagation, or can
>> > I do without it? I don't get the error if this code is commented out.*
>> >
>> > ​
>> >
>> > On Fri, Apr 22, 2016 at 12:15 PM, Jingyi Sun > > > wrote:
>> >
>> > Hi Martin, Andrej and everyone,
>> >
>> > Revision on my last email: I found out why my out-of-tree copy of
>> > tagged_stream_mux wasn't working and fixed the problem--it was a
bug
>> > with having the wrong variable name input in the blockt after
>> > everything was built.  My copy now works like the original
>> > tagged_stream_mux 

[Discuss-gnuradio] Problem with SWIG on Windows

[Camera Parts]

Hi,

  I am new to GnuRadio. 

  I installed on Windows 8 using gnuradio_3.7.9.2_win64.msi.  I am looking for 
a simple example in order to test the installation. When I try to run 
mono_tone.py located in \share\gnuradio\examples\audio, I got an error saying 
"ImportError: DLL load failed: %1 is not a valid Win32 application."

  Could someone help? 

Thanks
  

C:\GNURadio-3.7\share\gnuradio\examples\audio>python mono_tone.py
Traceback (most recent call last):
  File "mono_tone.py", line 23, in 
from gnuradio import gr
  File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\__init__.py", line 41, in

from runtime_swig import *
  File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py", line 28,
 in 
_runtime_swig = swig_import_helper()
  File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py", line 24,
 in swig_import_helper
_mod = imp.load_module('_runtime_swig', fp, pathname, description)
ImportError: DLL load failed: %1 is not a valid Win32 application.

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

Re: [Discuss-gnuradio] Pybomb installation error

[Martin Braun]

My apologies, just double-checked and I was looking at an older version.
Try updating, it should be fixed now.

M

On 04/24/2016 11:12 AM, Martin Braun wrote:
> Shanaz,
> 
> On 04/23/2016 04:50 PM, Shahnaz Shirazi wrote:
>> [...]
>> line 150, in _run_init
>> if op.exists(op.join(path, self.prefix.prefix_conf_dir)):
>> *AttributeError: 'NoneType' object has no attribute 'prefix_conf_dir'
> 
> This line doesn't exist in PyBOMBS. Maybe you do have an old version or
> something. I know you said you've reinstalled, but that's not the
> current code.
> 
> M
> 


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

Re: [Discuss-gnuradio] stream_mux tag propagation

[Martin Braun]

The mux is easy because it can be dynamic by analysing the input tagged
streams. A demux needs logic to figure out how to demux a stream. An
example is the header_payload_demux, which has a massive amount of logic
(and still relies on outside blocks).

M

On 04/23/2016 01:05 AM, Merlin Chlosta wrote:
> On 21.04.2016 13:34, Andrej Rode wrote:
>>> Is that a bug in stream_mux? It means that the streams cannot be demuxed by
>>> looking at the tags.
>> There is no special processing for stream tags in stream_mux. It simply 
>> takes 
>> the input streams and copies them input-wise into the output buffer. Stream 
>> tags are propagated according to their initial offset at the input. And 
>> there 
>> you get behaviour you described.
>>
>> Did you have a look at tagged_stream_mux ? Maybe it will serve your needs?
> 
> The tagged_stream_mux uses the packet_len tags to determine the input 
> lengths. It outputs a new packet_len that is the sum of the input 
> packet_lens. So here you also loose information about the streams that were 
> muxed.
> 
> What sense would the standard tag propagation make in this case?
> 
> The context is that I was looking for a demux-block to separate data that 
> comes out of my custom block. I did not find any demux-block -- and then 
> investigated how the muxer works to understand why there's no demuxer. In 
> this case the only way a demuxer could work is to have the muxer scheme 
> constant and share it to muxer and demuxer.
> 
> --Merlin Chlosta
> 
> ___
> 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] Multiple Inputs in Tagged Stream Block

[Martin Braun]

On 04/23/2016 12:36 PM, Jingyi Sun wrote:
> Hi Martin and everyone,
> 
> I've pinpointed what causes this error to occur with 3 inputs, but not
> occur with just 1 input. 
> 
> gr::log :FATAL: geese_vcvc0 - Missing a required length tag on port
> 1 at item #0
> thread[thread-per-block[46]: ]: Missing length
> tag.

Tagged streams carry tags to identify burst boundaries. Your input is
not seeing such a tag.

Now, you should never, ever manually handle those tags. Whatever your
upstream block is, it should thus be either a tagged_stream_block, or
have automatic tag propagation.


> The culprit seems to be the following block of code inside my
> geese_vcvc_impl.cc file. I have it in my code right now because I based
> my block on ofdm_frame_equalizer.cc.  I gather that it parses length of
> tags, and but seems to only do so for one input?  Unfortunately I am
> unsure how to exactly interpret what it is doing.

Well, yes, the original block only has one input. This is an advanced
functionality of tagged stream blocks. You rarely need to override it.
The only reason we do that here is because we allow the equalizer to run
either as a tagged stream block, or a fixed size (but non-tagged-steram)
block.

Just don't use the fixed-length feature, don't include this method, and
you'll be fine.

Also don't paste pictures of code -- how am I supposed to comment on it
inline.

Cheers,
M

> Martin, I notice you've worked on the ofdm_frame_equalizer block
> before--could you please help me go through what this piece of code
> does, and how I could change it to be compatible with a block with
> multiple inputs.  I'm not thoroughly familiar with c++, and also am not
> sure about the particular purposes of variables here, or what the
> specific characteristics of "tags" vector are.
> 
> *My goal is to do something similar to add two equalized input tagged
> streams together, and output the sum tagged stream, while also
> propagating tags through for tag debug.*
> 
> *I would tremendously appreciate if you could briefly walk me through
> the following lines. Is this code necessary for tag propagation, or can
> I do without it? I don't get the error if this code is commented out.*
> 
> ​
> 
> On Fri, Apr 22, 2016 at 12:15 PM, Jingyi Sun  > wrote:
> 
> Hi Martin, Andrej and everyone,
> 
> Revision on my last email: I found out why my out-of-tree copy of
> tagged_stream_mux wasn't working and fixed the problem--it was a bug
> with having the wrong variable name input in the blockt after
> everything was built.  My copy now works like the original
> tagged_stream_mux does!
> 
> So I will work on slowly modifying this copy of tagged_stream_mux to
> look like what I want until something breaks, and then update you
> guys on that. Hopefully that will help!
> 
> Thanks again for all your help!!
> 
> Best,
> Jenny
> 
> On Thu, Apr 21, 2016 at 2:37 PM, Jingyi Sun  > wrote:
> 
> Hi Martin,
> 
> I did more tests, including*trying to recreate
> tagged_stream_mux* as an out-of-tree block. My block is called
> mux, but everything else (.cc, .c, .xml), are exactly the same.
> I copied and pasted everything from github, minus the name.
> 
> *It gives me the same error. *
> 
> I suspect the source code that my installed binary version of
> GNU Radio is based on is different from the one used to
> originally create tagged_stream_mux block that comes with GNU Radio.
> 
> Do you know if there is a specific person I can contact who
> would know about tagged_stream_block source code? Or do you
> think there's something else I haven't thought of.
> 
> I'm not sure what else I can try right now, and would be willing
> to try anything you (or anyone else) might have to suggest.
> 
> Thanks,
> Jenny
> 
> 
> On Thu, Apr 21, 2016 at 2:02 PM, Martin Braun
> > wrote:
> 
> On 04/20/2016 04:48 PM, Jingyi Sun wrote:
> > tagged_stream_mux works when substituted for my block, so I 
> think all of
> > my inputs are tagged streams. Also, my inputs are coming from 
> the
> > outputs of OFDM_frame_equalizer, which I think propagates 
> tagged streams?
> 
> Yes.
> 
> M
> 
> > I think it's an error somewhere in the code, but the changes I 
> mentioned
> > are the only changes I made between the block working and the 
> block not
> > working.
> >
> > My code is based on OFDM_frame_equalizer, but without the 
> actual signal
> > processing part. I will fill in my own signal processing after 
> I know I
> > can at least pass one out of three inputs 

Re: [Discuss-gnuradio] Pybomb installation error

[Martin Braun]

Shanaz,

On 04/23/2016 04:50 PM, Shahnaz Shirazi wrote:
> [...]
> line 150, in _run_init
> if op.exists(op.join(path, self.prefix.prefix_conf_dir)):
> *AttributeError: 'NoneType' object has no attribute 'prefix_conf_dir'

This line doesn't exist in PyBOMBS. Maybe you do have an old version or
something. I know you said you've reinstalled, but that's not the
current code.

M


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

Re: [Discuss-gnuradio] packet_header_default formatter packet length - why constant?

[Martin Braun]

Steven,

this is a tricky one. It took me a while to make sense of this stuff
(despite having written it) which is already a bad sign in terms of
documentation.

Here's the long story: When specifying 'header length', we never specify
the *unit*. Now, one thing is important: The header_len() method *must*
return the number of items, because that's important for the block to
function properly. So it mustn't return the number of bits, but the
number of symbols (which is what you're saying, too). The constructor
now also has a header_len parameter, and it means the same thing as
header_len().

When I was writing this, I had the default *and* OFDM header objects in
mind. The latter are a bit more tricky, and it's important to figure out
the number of OFDM *symbols*. However, these special header
formatter/parser objects are subclasses of the default class, so it's
not a simple matter to just change things.

I need to take a closer look at this. At the very least, documentation
needs fixing. But there's probably also a bug in there somewhere. And
maybe there's even a way to un-kludge this without breaking too much and
making it useful for all types of modulation.

Cheers,
M

On 04/23/2016 07:57 AM, Steven Knudsen wrote:
> Hi,
> 
> I have created a packet header that subclasses
> gr::digital::packet_header_default and so far so good.
> 
> In trying to understand the base class behaviour, I created a simple
> header packet generation GRC project that multiplexes a header with a
> payload.
> 
> The header_formatter is defined as
> digital.packet_header_default(32,legnth_tag_key) where length_tag_key is
> set to “packet_len”; this is the same as many examples, obviously.
> 
> The header packet generator works fine with this, generating a 32 byte
> header with 1 bit of header data per byte. This makes sense since I left
> the default bits_per_byte in the header_formatter, which implies a BPSK
> modulator is used for the header.
> 
> However, if I change the header_formatter to
> digital.packet_header_default(32,legnth_tag_key,num_tag_key,header_mod.bits_per_symbol())
> where num_tag_key is “packet_num” and header_mod is defined as
> digital.constellation_qpsk(), which means now 2 header bits per byte are
> encoded, the header generator still outputs 32 bytes and a packet_len =
> 32. Shouldn’t 16 bytes be output and packet_len = 16?
> 
> Accounting for the bits per symbol would make sense a) because that is
> consistent with the packet_header_default constructor bits_per_byte
> argument and b) it would be consistent with the behaviour of other
> blocks, such as Repack Bits, that are commonly used with packet blocks.
> 
> Anyone have an explanation? Perhaps I am not following GNU Radio
> philosophy in this approach?
> 
> BTW, in my packet header class I simply override the
> packet_header_default::header_len() to return the right number of bytes.
> That seems right to me :-)
> 
> Thanks!
> 
> steven
>  
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca 
> 
> www.linkedin.com/in/knudstevenknudsen
> 
> 
> 
> All the wires are cut, my friends
> Live beyond the severed ends.  Louis MacNeice
> 
> 
> 
> 
> ___
> 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] Is there a property setting box for WX scope for persistence?

[atlas steels]

I see such settings for *WX FFT * but not for simple WX scope? What am I
missing? I'd really like to default this to ON and value=xyz. I can use the
GUI to set thinks up, but I'd really like not to. This is for an eye-diagram
application.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Is-there-a-property-setting-box-for-WX-scope-for-persistence-tp59711.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] baz-utils and python path

[Freedomfighter099 .]

Hello

I got the cyberspectrum  scanner.py running following your instructions

But I don’t seem to have any control or options to configure my USRP been
looking into the code in both scanner.py and the config.pyc and within
scanner.py is most related to FFT and the config.pyc I can’t edit because
of the format

So how do I configure my USRP B200 to a specific frequency range and RX2
antenna, gain, step size and so on I’m guessing that I need to configure my
config.pyc file but I can’t read this file with gedit or notepadqq any
advice or instructions would be greatly appreciated

Thanks

2016-04-24 6:37 GMT+02:00 Nate Temple :

> Hello,
>
> Within the cyberspectrum/ folder there is the file "config.model.py", you
> need to copy it to "config.py" by running
>
> cp config.model.py config.py
>
>
> You can then run the scanner.py program with:
>
> python scanner.py
>
> If you want to graph the data, you can add the --graph flag, such as:
>
> python scanner.py --graph
>
> Regards,
> Nate
>
> > On Apr 23, 2016, at 1:06 PM, Freedomfighter099 . <
> freedomfighter.missing.l...@gmail.com> wrote:
> >
> > I understand the error message  which is printed in the error
> >
> > what I don’t understand is what to copy and where to past it?
> >
> > Within cyberspectrum directory there are a bunch of py executable codes
> >
> > Scanner.py and spectrum_view and such are in the same directory as the
> config.model.py which is the code in question, what do I do with this
> code? Furthermore where do I paste it to.
> >
> > Sorry I am a newbie to all of this coding stuff, so things are not
> self-explanatory to me yet
> >
> > I have a USRP B200 which is a detail which might be relevant.
> >
> > And again thanks
> >
> >
> > 2016-04-23 20:42 GMT+02:00 Nate Temple :
> > Hello,
> >
> > The solution to resolving your error is printed within the error itself.
> >
> > "Make sure you have a config.py (e.g. make a copy of config.model.py)"
> >
> > You need to copy config.model.py to config.py within the cyberspectrum/
> folder. scanner.py should then run.
> >
> > Here is the relevant bit of code -
> https://github.com/balint256/cyberspectrum/blob/master/scanner.py#L67
> >
> > Regards,
> > Nate
> >
> >
> > > On Apr 23, 2016, at 1:59 AM, Freedomfighter099 . <
> freedomfighter.missing.l...@gmail.com> wrote:
> > >
> > > I got everything to work using the export command so thanks for that,
> > >
> > > I have unfortunately already run into another issue which I could need
> some guidance on
> > >
> > > I’m running into this error: Could not import configuration: No module
> named config
> > >
> > > Make sure you have a config.py (e.g. make a copy of config.model.py)
> > >
> > > Traceback (most recent call last):
> > >
> > >   File "./scanner.py", line 74, in 
> > >
> > > raise e
> > >
> > > ImportError: No module named config
> > >
> > > freedomfighter@radiocom:/usr/local/gnuradio/cyberspectrum$
> > >
> > > it would seem that the python code in config.model.py is not
> executable is that right and if so how can I make it executable so that I
> can get the following scanner.py and spectrum_viewer.py to work
> > >
> > > Any advice or guidance would be greatly appreciated
> > >
> > > Thanks
> > >
> > >
> > > 2016-04-23 0:31 GMT+02:00 Nate Temple :
> > > Hello,
> > >
> > > You can add the path to your PYTHONPATH variable by adding this line
> to the end of your ~/.bashrc file
> > >
> > > export PYTHONPATH=$PYTHONPATH:/path/to/baz-utils/lib/python
> > >
> > >
> > > You'll need to update the "/path/to/baz-utils/lib/python" to where you
> have cloned baz-utils. Also note baz-utils directory structure has changed
> and the readme is outdated , it should say lib/python instead of
> src/python. ( The structure was changed with this commit:
> https://github.com/balint256/baz-utils/commit/66d1382383e48a09b9af65a86f43f2eb813f83a3
> )
> > >
> > > After you add the export line above to your ~/.bashrc file, you'll
> need to log out and log back in for it to take effect. You can check it with
> > >
> > > echo $PYTHONPATH
> > >
> > >
> > >
> > >
> > > - Nate
> > >
> > >
> > > > On Apr 22, 2016, at 1:31 PM, Freedomfighter099 . <
> freedomfighter.missing.l...@gmail.com> wrote:
> > > >
> > > > Hello
> > > >
> > > > Would someone please explain to me how to add the following to
> python path: Add src/python to PYTHONPATH
> > > >
> > > > I can’t seem to get it to work! instructions would be greatly
> appreciated
> > > >
> > > > cheers
> > > >
> > > > ___
> > > > 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
> >
> >
> > ___
> >