Re: [Discuss-gnuradio] SWIG 3.0.3 Issue

[Martin Braun]

Yay, SWIG troubles. Until we've figured out what's up, we should
probably put in a version check < 3.0.3 into our build setup.

>From your example, I actually prefer the 3.0.3 code output and am
curious why this would throw an error.

M

On 12/31/2014 04:19 AM, Michael Dickens wrote:
> SWIG 3.0.3 was released today (30 Dec 2014) < http://www.swig.org/ >,
> and I maintain this port in MacPorts. So, I naturally was curious to see
> if it works with GNU Radio. Sadly, GNU Radio fails because some of the
> SWIG-generated Python scripts have errors in them. For example, in SWIG
> 3.0.2 the vector_source_b::make is defined in blocks_swig1.py as:
> {{{
> def make(*args, **kwargs):
> """
> make(std::vector< unsigned char,std::allocator< unsigned char >
> > const & data, bool repeat=False, 
> int vlen=1, tags_vector_t tags=std::vector< gr::tag_t >())
> -> vector_source_b_sptr
> }}}
> while in 3.0.3 this code is:
> {{{
> def make(data, repeat=False, vlen=1, tags):
> """
> make(std::vector< unsigned char,std::allocator< unsigned char >
> > const & data, bool repeat=False, int vlen=1, tags_vector_t
> tags) -> vector_source_b_sptr
> }}}
> 
> The above are both generated using the current GIT HEAD (c67281b6), just
> changing which version of SWIG is used.
> 
> For now, I won't upgrade SWIG to 3.0.3 since this is a pretty critical
> issue. I'll also report it to the SWIG devs to see what they think -- it
> might be that there were changes to how SWIG %-things are used; it also
> might be that there's an actual error in the SWIG Python generator code.
> - MLD
> 
> ___
> 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] optional port in grc block

[Martin Braun]

Achilleas,

ports can use the  tag like params do (note this tag is the last
tag for any sink or source). Just put some Cheetah code in there to
check for $debug and set hide to all, part or none.

M

On 01/02/2015 07:24 PM, Achilleas Anastasopoulos wrote:
> Hi all,
> 
> I would like to have grc block with a bool option "Debug".
> Once this is set to True, then I would like to have an additional output
> port.
> 
> How do I do that?
> 
> I already added this part in the xml file:
> 
> 
> Debug
> debug
> False
> bool
>  
> 
> but now I don't know how to use this variable to make the additional
> port appear
> in the block.
> 
> 
> thanks
> Achilleas
> 
> 
> -
> 
> 
> ___
> 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] Getting time each time power squelch is on

[sreeraj r]

On Sat, Jan 3, 2015 at 8:39 PM, Luis Colunga  wrote:

> Hi Dan,
>
> Thanks for the response, but it seems like burst tagger would not work
> in this case because I am working with audio. What I want is when
> power squelch is triggered demod a NFM signal and then save it to a
> wav file with the time power squelch was triggered.
>

You can try keeping power squelch's gate to false (so that you will get
zero samples) and then use it as a trigger for "burst_tagger" after doing
some math manipulations. This along with a "tagged_file_sink" should work.

Please look into "gnuradio/examples/tags" for examples.

Sreeraj


>
> Thanks
>
> 2015-01-02 16:12 GMT-07:00 Dan CaJacob :
> > Hi Luis,
> >
> > I am pretty certain there is a block in mainline GR to do this with
> tagging.
> > Burst tagger maybe?  The tags define the burst boundaries and a
> timestamp is
> > recorded as well.
> >
> > On Jan 2, 2015 5:46 PM, "Luis Colunga"  wrote:
> >>
> >> Hello,
> >>
> >> I have a Python handcoded block in which I want every time that power
> >> squelch is triggered, grab the actual time and then use that filename
> >> to write a wav file with a decoded stream.
> >>
> >> What would be a good approach? I tried using variables but I see they
> >> don't update at runtime and I am not sure if you are able to change
> >> the wav sink name on runtime and just expect it to work or if it
> >> neccesary to do something else there.
> >>
> >> Thanks.
> >>
> >> ___
> >> 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
>



-- 
Regards
Sreeraj Rajendran
http://radioninja.in/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] HeirBlock2 Lock/Unlock breaks WavSink

[Luke Berndt]

Short story - doing a Lock/Unlock on a HeirBlock2 to reconfigure its internal 
flow graph stops a WavFile_Sink that is in it until a new wav file is opened. 
It doesn’t affect any File_Sinks that are in the graph. If there are multiple 
instances of the HeirBlock2 running, it will stop the WavFile_Sink running in 
all the instances. This didn’t happen in 3.6, but started in 3.7. I have an 
extremely simplified sample program that demonstrates the problem: 
https://github.com/robotastic/multi-wav 


Long Story - I am recording multiple audio channels from my SDR to capture my 
local fire departments radio system. I have to add and remove multiple 
recorders at different freq offsets to catch the different transmissions as the 
start and stop. To do that I have a bunch of HeirBlock2 based graphs that I 
attach to the source. When they are not being used I lock the block and connect 
the block source to a null sink. When they are needed, I connect all the 
internal blocks together and tune the xlating offset.

The sample program I wrote shows this. It starts up 6 recording blocks. After 
10 seconds it will randomly lock/unlock one of the recording blocks. You will 
see that all of the WavFile_Sinks in each instance of the block stops 
recording. However the file_sinks that are attached inside the Block keep on 
recording fine. You will see the raw file size continue to grow and the wav 
file size stop.

The sample program is in C++. You should be able to download, do ‘cmake .’ and 
then ‘make’ and then ‘./multi-wav’  Then look in the ‘recordings’ directory.

It seems like there is a problem with GnuRadio and HeirBlock Locking in 3.7…. 
or wavfile_sink. Also possible I did something really dumb. Any thoughts?


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

Re: [Discuss-gnuradio] optional port in grc block

[Tom Rondeau]

On Sun, Jan 4, 2015 at 5:17 AM, Martin Braun  wrote:

> Achilleas,
>
> ports can use the  tag like params do (note this tag is the last
> tag for any sink or source). Just put some Cheetah code in there to
> check for $debug and set hide to all, part or none.
>
> M


There are lots of examples for how to use the hide tag in parameters and
ports, though mostly for message ports. Check out the
constellation_receiver XML file for how it uses a boolean parameter to
determine if it should show the message port or not.

Tom



> On 01/02/2015 07:24 PM, Achilleas Anastasopoulos wrote:
> > Hi all,
> >
> > I would like to have grc block with a bool option "Debug".
> > Once this is set to True, then I would like to have an additional output
> > port.
> >
> > How do I do that?
> >
> > I already added this part in the xml file:
> >
> > 
> > Debug
> > debug
> > False
> > bool
> >  
> >
> > but now I don't know how to use this variable to make the additional
> > port appear
> > in the block.
> >
> >
> > thanks
> > Achilleas
> >
> >
> > -
> >
> >
> > ___
> > 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] SWIG 3.0.3 Issue

[Tom Rondeau]

On Sun, Jan 4, 2015 at 5:09 AM, Martin Braun  wrote:

> Yay, SWIG troubles. Until we've figured out what's up, we should
> probably put in a version check < 3.0.3 into our build setup.
>
> From your example, I actually prefer the 3.0.3 code output and am
> curious why this would throw an error.
>
> M


Yes, this is supposedly a new feature of SWIGs. From their changelog:

2014-10-28: vadz
[Python] Patch #201 The generated .py file no longer uses *args for all
Python parameters.
Instead, the parameters are named using the C++ parameter names.

2014-10-21: wsfulton
Fix issue #242 - Use of the "kwargs" feature no longer automatically turns
on the
"compactdefaultargs" feature if the target language does not support kwargs.
Only Java and Python support kwargs, so this affects all the other
languages.

*** POTENTIAL INCOMPATIBILITY ***


So either we need to change the syntax of something to point swig to set a
proper default argument for std::vector arguments or they need to fix a bug.

Tom



> On 12/31/2014 04:19 AM, Michael Dickens wrote:
> > SWIG 3.0.3 was released today (30 Dec 2014) < http://www.swig.org/ >,
> > and I maintain this port in MacPorts. So, I naturally was curious to see
> > if it works with GNU Radio. Sadly, GNU Radio fails because some of the
> > SWIG-generated Python scripts have errors in them. For example, in SWIG
> > 3.0.2 the vector_source_b::make is defined in blocks_swig1.py as:
> > {{{
> > def make(*args, **kwargs):
> > """
> > make(std::vector< unsigned char,std::allocator< unsigned char >
> > > const & data, bool repeat=False,
> > int vlen=1, tags_vector_t tags=std::vector< gr::tag_t >())
> > -> vector_source_b_sptr
> > }}}
> > while in 3.0.3 this code is:
> > {{{
> > def make(data, repeat=False, vlen=1, tags):
> > """
> > make(std::vector< unsigned char,std::allocator< unsigned char >
> > > const & data, bool repeat=False, int vlen=1, tags_vector_t
> > tags) -> vector_source_b_sptr
> > }}}
> >
> > The above are both generated using the current GIT HEAD (c67281b6), just
> > changing which version of SWIG is used.
> >
> > For now, I won't upgrade SWIG to 3.0.3 since this is a pretty critical
> > issue. I'll also report it to the SWIG devs to see what they think -- it
> > might be that there were changes to how SWIG %-things are used; it also
> > might be that there's an actual error in the SWIG Python generator code.
> > - MLD
> >
> > ___
> > 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] SWIG 3.0.3 Issue

[Michael Dickens]

I sent the primary SWIG maintainer (William S Fulton) an email, and got
a prompt reply forwarding my email to the SWIG developer's list. He
primarily just verified and checked in the changes (that Tom found and
quoted, below); he hopes that some of the SWIG developers can help him
figure out what's going on -- is it a bug in their code, or the way GNU
Radio is handling things. I don't subscript to this list; maybe Tom or
Martin does? I do see SWIG checkins, so if anything comes up there
hopefully I'll catch it.

On Sun, Jan 4, 2015, at 05:09 AM, Martin Braun wrote:
> Yay, SWIG troubles. Until we've figured out what's up, we should
> probably put in a version check < 3.0.3 into our build setup.

Agreed.

> From your example, I actually prefer the 3.0.3 code output and am
> curious why this would throw an error.

Yes, I do to. 

On Sun, Jan 4, 2015, at 01:59 PM, Tom Rondeau wrote:
> Yes, this is supposedly a new feature of SWIGs. From their changelog:
{{{
2014-10-28: vadz
[Python] Patch #201 The generated .py file no longer uses *args for all
Python parameters.
Instead, the parameters are named using the C++ parameter names.

2014-10-21: wsfulton
Fix issue #242 - Use of the "kwargs" feature no longer automatically
turns on the
"compactdefaultargs" feature if the target language does not support
kwargs.
Only Java and Python support kwargs, so this affects all the other
languages.

*** POTENTIAL INCOMPATIBILITY ***
}}}
> So either we need to change the syntax of something to point swig to set a 
> proper default argument for std::vector arguments or they need to fix a bug.

Also agreed. I think the hard part will be to keep compatibility for
both the "new" and "old" ways at the same time, if this is not a bug. -
MLD

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

Re: [Discuss-gnuradio] Getting time each time power squelch is on

[Luis Colunga]

Hello sreeraj,

I am checking those examples, thanks. Can you elaborate with what you
mean with math manipulations?? Even if I am using tagged_file_sink can
I interpret what is generated as if they were audio wav files?

Thank you.

2015-01-04 4:43 GMT-07:00 sreeraj r :
> On Sat, Jan 3, 2015 at 8:39 PM, Luis Colunga  wrote:
>>
>> Hi Dan,
>>
>> Thanks for the response, but it seems like burst tagger would not work
>> in this case because I am working with audio. What I want is when
>> power squelch is triggered demod a NFM signal and then save it to a
>> wav file with the time power squelch was triggered.
>
>
> You can try keeping power squelch's gate to false (so that you will get zero
> samples) and then use it as a trigger for "burst_tagger" after doing some
> math manipulations. This along with a "tagged_file_sink" should work.
>
> Please look into "gnuradio/examples/tags" for examples.
>
> Sreeraj
>
>>
>>
>> Thanks
>>
>> 2015-01-02 16:12 GMT-07:00 Dan CaJacob :
>> > Hi Luis,
>> >
>> > I am pretty certain there is a block in mainline GR to do this with
>> > tagging.
>> > Burst tagger maybe?  The tags define the burst boundaries and a
>> > timestamp is
>> > recorded as well.
>> >
>> > On Jan 2, 2015 5:46 PM, "Luis Colunga"  wrote:
>> >>
>> >> Hello,
>> >>
>> >> I have a Python handcoded block in which I want every time that power
>> >> squelch is triggered, grab the actual time and then use that filename
>> >> to write a wav file with a decoded stream.
>> >>
>> >> What would be a good approach? I tried using variables but I see they
>> >> don't update at runtime and I am not sure if you are able to change
>> >> the wav sink name on runtime and just expect it to work or if it
>> >> neccesary to do something else there.
>> >>
>> >> Thanks.
>> >>
>> >> ___
>> >> 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
>
>
>
>
> --
> Regards
> Sreeraj Rajendran
> http://radioninja.in/

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

Re: [Discuss-gnuradio] Getting time each time power squelch is on

[Luis Colunga]

Hi, sreeraj,

I figured out what you meant by the math manipulations. Thanks

I based on the example of the uhd energy detector.py for modifying the
output of the power squelch to use it as a trigger on burst tagger.

I see that if I put on audacity 32bit float it's  going to interpret
the file created by the tagged file sink right.

Thanks all of you :)



2015-01-04 16:03 GMT-07:00 Luis Colunga :
> Hello sreeraj,
>
> I am checking those examples, thanks. Can you elaborate with what you
> mean with math manipulations?? Even if I am using tagged_file_sink can
> I interpret what is generated as if they were audio wav files?
>
> Thank you.
>
> 2015-01-04 4:43 GMT-07:00 sreeraj r :
>> On Sat, Jan 3, 2015 at 8:39 PM, Luis Colunga  wrote:
>>>
>>> Hi Dan,
>>>
>>> Thanks for the response, but it seems like burst tagger would not work
>>> in this case because I am working with audio. What I want is when
>>> power squelch is triggered demod a NFM signal and then save it to a
>>> wav file with the time power squelch was triggered.
>>
>>
>> You can try keeping power squelch's gate to false (so that you will get zero
>> samples) and then use it as a trigger for "burst_tagger" after doing some
>> math manipulations. This along with a "tagged_file_sink" should work.
>>
>> Please look into "gnuradio/examples/tags" for examples.
>>
>> Sreeraj
>>
>>>
>>>
>>> Thanks
>>>
>>> 2015-01-02 16:12 GMT-07:00 Dan CaJacob :
>>> > Hi Luis,
>>> >
>>> > I am pretty certain there is a block in mainline GR to do this with
>>> > tagging.
>>> > Burst tagger maybe?  The tags define the burst boundaries and a
>>> > timestamp is
>>> > recorded as well.
>>> >
>>> > On Jan 2, 2015 5:46 PM, "Luis Colunga"  wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> I have a Python handcoded block in which I want every time that power
>>> >> squelch is triggered, grab the actual time and then use that filename
>>> >> to write a wav file with a decoded stream.
>>> >>
>>> >> What would be a good approach? I tried using variables but I see they
>>> >> don't update at runtime and I am not sure if you are able to change
>>> >> the wav sink name on runtime and just expect it to work or if it
>>> >> neccesary to do something else there.
>>> >>
>>> >> Thanks.
>>> >>
>>> >> ___
>>> >> 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
>>
>>
>>
>>
>> --
>> Regards
>> Sreeraj Rajendran
>> http://radioninja.in/

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

[Discuss-gnuradio] Rewrite rx_time tag in tagged_file_sink

[Luis Colunga]

Hello list,

What would be a good approach to rewrite the rx_time tag in
tagged_file_sink with my own information?? I am triggering a burst
tagger wit a power squelch. What I want to get is timestamp
information and channel info.

Thanks

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

Re: [Discuss-gnuradio] Rewrite rx_time tag in tagged_file_sink

[Martin Braun]

On 01/05/2015 05:39 AM, Luis Colunga wrote:
> Hello list,
> 
> What would be a good approach to rewrite the rx_time tag in
> tagged_file_sink with my own information?? I am triggering a burst
> tagger wit a power squelch. What I want to get is timestamp
> information and channel info.

Probably by adding in a  custom block that does exactly that.
This'll be a few lines of code in Python, if that's enough performance-wise.

M


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