Re: [Discuss-gnuradio] log4cpp library not found

[Marcus D. Leech]

On 03/31/2017 09:13 PM, li...@lazygranch.com wrote:

opensuse 42.2

This is the only "missing" thing I can find in the cmake ..:



-- Configuring volk support...
--   Enabling volk support.
--   Override with -DENABLE_VOLK=ON/OFF
--   Override with -DENABLE_INTERNAL_VOLK=ON/OFF
-- ENABLE_GR_LOG set to ON.
-- HAVE_LOG4CPP set to False.
-- LOG4CPP_LIBRARIES set to .

Though the library is there. Perhaps it has a different name in other
distributions? I can make symbolic links if need be.

/usr/lib64 # ls
liblog4cpp* liblog4cpp.so  liblog4cpp.so.5  liblog4cpp.so.5.0.6



It may be the case that you don't have the matching #include files, 
which is what code being compiled needs in addition to the libraries.




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

Re: [Discuss-gnuradio] ASK Modulation

[Martin Braun]

You mean, mapping 1s and 0s to 1s and 0s? :)

You can very simply implement an ASK modem with pulse shaping filters
and some other blocks. I'm not sure about clock synchronization, though.

-- M

On 03/31/2017 01:17 PM, Qurat-Ul-Ann Akbar wrote:
> Hello,
> 
> Is ASK modulation implemented in gnuradio? I know that BPSK, QPSK and
> QAM are.
> 
> 
> 
> 
> ___
> 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] log4cpp library not found

[li...@lazygranch.com]

opensuse 42.2 

This is the only "missing" thing I can find in the cmake ..:



-- Configuring volk support...
--   Enabling volk support.
--   Override with -DENABLE_VOLK=ON/OFF
--   Override with -DENABLE_INTERNAL_VOLK=ON/OFF
-- ENABLE_GR_LOG set to ON.
-- HAVE_LOG4CPP set to False.
-- LOG4CPP_LIBRARIES set to .

Though the library is there. Perhaps it has a different name in other
distributions? I can make symbolic links if need be.

/usr/lib64 # ls
liblog4cpp* liblog4cpp.so  liblog4cpp.so.5  liblog4cpp.so.5.0.6  




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

Re: [Discuss-gnuradio] installing a python package without elevated privileges

[U L]

Being all things to everyone is tough.  I recently contributed some code to
support the openSUSE package manager, zypper, in pybombs.  So universal
support is kind of an evolving feature.  Perhaps it would be a start to
simply limit the initial virtualenv support to python2.  I would suggest
that if one were in a virtualenv, you let that handle the pip version
(which should be referenced just by the pip command).  I would also submit
that python packages should not be added to the system via a package
manager if you're in a virtualenv.  This would alleviate some of the
package naming discrepancies between the versions.  I don't think
gr-recipes supports python3 packages right now for any packager.  Good
points nonetheless.

Jared.

On Fri, Mar 31, 2017 at 10:30 AM, Martin Braun 
wrote:

> Please note that there's an open issue on how PyBOMBS and venvs are
> effectively broken (https://github.com/gnuradio/pybombs/issues/363).
> There are also related issues regarding the fact that we don't know if
> we're running Python 2 or 3. So yeah, I know about this, and would love
> to see it fixed, but I'm not doing it myself anytime soon.
>
> For example, what if your system's default is Python 2, but your
> virtualenv is running Python 3. In that case, you would need to make
> sure that you don't accidentally check your system's package manager for
> python2-mako. pybombs itself may be running a different Python than is
> going to be executed in the prefix.
> The same holds for if we need pip, pip2, or pip3.
>
> I'm open for suggestions and pull requests, but keep in mind that I
> can't merge stuff if
>
> - It's based on personal preferences, e.g. the pip vs. apt discussion.
> Note that there's also different cases here, you might prefer apt over
> pip for system-wide installs, and pip over apt for your virtualenv install.
> - It hardcodes stuff where it shouldn't (e.g., having IF PKGR == PIP
> style code in the package_manager.py)
> - It makes assumptions about people's systems.
>
> Also, I should acknowledge that both Jared and Marcus have contributed
> to PyBOMBS, so this is not just an empty discussion here :)
>
> Cheers,
> Martin
>
> On 03/27/2017 08:14 PM, U L wrote:
> > This is a problem I have faced as well.  I have a number of projects at
> > various levels of modification of GR and various 3rd party python
> > packages being supported.  I find having virtualenvs to be very useful
> > in keeping python package versions, GR mods, and my own modules in
> > agreement.  I've been tinkering a bunch with getting venvs and pybombs
> > to work together and I think I've made some headway.  For example, the
> > elevated privileges for pip is (nominally) hardcoded in
> > packagers/pip.py.  I made a modification to condition elevation on the
> > presence of a virtualenv, which is detected in the config_manager.  This
> > is one way to perhaps get pybombs and virtualenvs to play nice.  I'll
> > hopefully be offering a pull request soon that incorporates a number of
> > changes.
> >
> > On Wed, Mar 22, 2017 at 12:30 PM, Naceur  > > wrote:
> >
> > You are right if they had access to it at first place. Anyhow I
> > fixed it.
> >
> >
> >
> > --
> > View this message in context:
> > http://gnuradio.4.n7.nabble.com/installing-a-python-
> package-without-elevated-privileges-tp63183p63258.html
> >  package-without-elevated-privileges-tp63183p63258.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

[Discuss-gnuradio] ASK Modulation

[Qurat-Ul-Ann Akbar]

Hello,

Is ASK modulation implemented in gnuradio? I know that BPSK, QPSK and QAM
are.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM/GR-IEEE802-11

[Thomas Wilkinson]

Understood. Thanks!

On Fri, Mar 31, 2017 at 2:32 PM, Marcus Müller 
wrote:

> Depends on where you are. But usually, no.
>
> On 31.03.2017 19:54, Thomas Wilkinson wrote:
>
> Legally, I can perform tests within ISM bands. Correct?
>
> On Fri, Mar 31, 2017 at 1:14 PM, Martin Braun  wrote:
>
>> You can change the frequency technically. Legally, we can't give you
>> advice here other than to follow the rules.
>>
>> Cheers,
>> Martin
>>
>> On 03/30/2017 09:52 AM, Thomas Wilkinson wrote:
>> >
>> > Please forgive me as I am new to SDRs and DSP.
>> >
>> > I am interested in development of a radio link using two B210s and
>> > GR-IEEE802-11.   However, I would like for this link to operate at any
>> > frequency. I am interested in a robust waveform with minimum of 11MBPS
>> > throughput, which is why I am interested in OFDM/802.11. My very limited
>> > hope/understanding is that I can potentially change the frequency of
>> > operation in the PHY layer.
>> >
>> > Thanks in advance for your help.
>> >
>> >
>> > Tom
>> >
>> >
>> > ___
>> > 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,
>
> Tom Wilkinson
> SMART Scholar 
> MS Student, Electrical Engineering
> NC State University
> c: 919.951.4449 <%28919%29%20951-4449>
> e: tbwil...@ncsu.edu
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Regards,

Tom Wilkinson
SMART Scholar 
MS Student, Electrical Engineering
NC State University
c: 919.951.4449
e: tbwil...@ncsu.edu
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM/GR-IEEE802-11

[Marcus Müller]

Depends on where you are. But usually, no.


On 31.03.2017 19:54, Thomas Wilkinson wrote:
> Legally, I can perform tests within ISM bands. Correct?
>
> On Fri, Mar 31, 2017 at 1:14 PM, Martin Braun  > wrote:
>
> You can change the frequency technically. Legally, we can't give you
> advice here other than to follow the rules.
>
> Cheers,
> Martin
>
> On 03/30/2017 09:52 AM, Thomas Wilkinson wrote:
> >
> > Please forgive me as I am new to SDRs and DSP.
> >
> > I am interested in development of a radio link using two B210s and
> > GR-IEEE802-11.   However, I would like for this link to operate
> at any
> > frequency. I am interested in a robust waveform with minimum of
> 11MBPS
> > throughput, which is why I am interested in OFDM/802.11. My very
> limited
> > hope/understanding is that I can potentially change the frequency of
> > operation in the PHY layer.
> >
> > Thanks in advance for your help.
> >
> >
> > Tom
> >
> >
> > ___
> > 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,
>
> Tom Wilkinson
> SMART Scholar 
> MS Student, Electrical Engineering
> NC State University
> c: 919.951.4449 
> e: tbwil...@ncsu.edu 
>
>
> ___
> 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] OFDM/GR-IEEE802-11

[Thomas Wilkinson]

Legally, I can perform tests within ISM bands. Correct?

On Fri, Mar 31, 2017 at 1:14 PM, Martin Braun  wrote:

> You can change the frequency technically. Legally, we can't give you
> advice here other than to follow the rules.
>
> Cheers,
> Martin
>
> On 03/30/2017 09:52 AM, Thomas Wilkinson wrote:
> >
> > Please forgive me as I am new to SDRs and DSP.
> >
> > I am interested in development of a radio link using two B210s and
> > GR-IEEE802-11.   However, I would like for this link to operate at any
> > frequency. I am interested in a robust waveform with minimum of 11MBPS
> > throughput, which is why I am interested in OFDM/802.11. My very limited
> > hope/understanding is that I can potentially change the frequency of
> > operation in the PHY layer.
> >
> > Thanks in advance for your help.
> >
> >
> > Tom
> >
> >
> > ___
> > 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,

Tom Wilkinson
SMART Scholar 
MS Student, Electrical Engineering
NC State University
c: 919.951.4449 <(919)%20951-4449>
e: tbwil...@ncsu.edu
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

[Martin Braun]

On 03/24/2017 12:21 PM, Ben Hilburn wrote:
> While this does prove the feasibility of independent front-end and
> back-ends, it is still "all-in" on Bokeh in the sense that the server
> and integration with GR is built with Bokeh. Again, I'm not saying
> that's the wrong decision, but I want to be sure that where the
> delineations lie are clearly called out in the proposal & docs.

I'd like to emphasize this. There's absolutely nothing wrong with a
Bokeh GUI OOT, and trying to solve all problems of the universe within a
GSoC is a sure recipe for failure. Just make sure the boundaries and
(in)flexibilities are clearly laid out.

Too broad proposal == bad proposal.

-- M


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

Re: [Discuss-gnuradio] installing a python package without elevated privileges

[Martin Braun]

Please note that there's an open issue on how PyBOMBS and venvs are
effectively broken (https://github.com/gnuradio/pybombs/issues/363).
There are also related issues regarding the fact that we don't know if
we're running Python 2 or 3. So yeah, I know about this, and would love
to see it fixed, but I'm not doing it myself anytime soon.

For example, what if your system's default is Python 2, but your
virtualenv is running Python 3. In that case, you would need to make
sure that you don't accidentally check your system's package manager for
python2-mako. pybombs itself may be running a different Python than is
going to be executed in the prefix.
The same holds for if we need pip, pip2, or pip3.

I'm open for suggestions and pull requests, but keep in mind that I
can't merge stuff if

- It's based on personal preferences, e.g. the pip vs. apt discussion.
Note that there's also different cases here, you might prefer apt over
pip for system-wide installs, and pip over apt for your virtualenv install.
- It hardcodes stuff where it shouldn't (e.g., having IF PKGR == PIP
style code in the package_manager.py)
- It makes assumptions about people's systems.

Also, I should acknowledge that both Jared and Marcus have contributed
to PyBOMBS, so this is not just an empty discussion here :)

Cheers,
Martin

On 03/27/2017 08:14 PM, U L wrote:
> This is a problem I have faced as well.  I have a number of projects at
> various levels of modification of GR and various 3rd party python
> packages being supported.  I find having virtualenvs to be very useful
> in keeping python package versions, GR mods, and my own modules in
> agreement.  I've been tinkering a bunch with getting venvs and pybombs
> to work together and I think I've made some headway.  For example, the
> elevated privileges for pip is (nominally) hardcoded in
> packagers/pip.py.  I made a modification to condition elevation on the
> presence of a virtualenv, which is detected in the config_manager.  This
> is one way to perhaps get pybombs and virtualenvs to play nice.  I'll
> hopefully be offering a pull request soon that incorporates a number of
> changes.
> 
> On Wed, Mar 22, 2017 at 12:30 PM, Naceur  > wrote:
> 
> You are right if they had access to it at first place. Anyhow I
> fixed it.
> 
> 
> 
> --
> View this message in context:
> 
> http://gnuradio.4.n7.nabble.com/installing-a-python-package-without-elevated-privileges-tp63183p63258.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] [GSoC] Submission deadline is nearly up!

[Martin Braun]

Everyone,

the student submission deadline for projects is nearly up. Please make
sure to wrap up your conversations on this list, and post a PDF to the
GSoC website. Of course, there's still time to discuss proposals until
March 3rd, when the submission ends, and I believe you can also update
PDFs until then, so I would recommend submitting a preliminary proposal
now and then see if you can refine it until the deadline.

If you have feedback for students, please don't hold back!

Cheers,
Martin

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

Re: [Discuss-gnuradio] FG probe generation of thread.start() race conditions (python tutorials)

[Martin Braun]

James,

thanks for pointing that out! Can you submit a pull request against the
gr-tutorial repository?

Thanks,
Martin

On 03/29/2017 10:22 AM, James Shimer wrote:
> Sorry if this is a duplicate/newbie question (didn't find anything
> searching).  When going thru the python examples.  I came across a race
> condition where the thread would start to run prior to object's
> constructor completing.  The fix is to manually move the code generated
> for starting the probe thread to the very end of the constructor.
> 
> 
> If this "bug" is open already thanks for your time, if not here are some
> more details:
> 
> 
> Tutorial 3, section 3.1.5, you're asked to modify the probe thread to
> reference members of the class to set_ampl and set_freq, those functions
> in-turn access members of the object, which may not have been
> initialized yet because the thread runs while the constructor is still
> running.
> 
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python
> 
> The symptom:
> 
> Exception in thread Thread-1:
> 
> Traceback (most recent call last):
> 
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py",
> line 801, in __bootstrap_inner
> 
> self.run()
> 
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py",
> line 754, in run
> 
> self.__target(*self.__args, **self.__kwargs)
> 
>   File "power.py", line 95, in _variable_function_probe_0_probe
> 
> self.set_ampl(0.3)
> 
>   File "power.py", line 174, in set_ampl
> 
> self.analog_sig_source_x_0.set_amplitude(self.ampl)
> 
>   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py",
> line 92, in __getattr__
> 
> return getattr(self._impl, name)
> 
> AttributeError: 'top_block_sptr' object has no attribute
> 'analog_sig_source_x_0'
> 
> 
> The resolution:
> 
> diff -rupN if_else.py if_else2.py 
> 
> --- if_else.py2017-03-29 13:20:32.0 -0400
> 
> +++ if_else2.py2017-03-29 13:19:37.0 -0400
> 
> @@ -101,7 +101,6 @@ class if_else(gr.top_block, Qt.QWidget):
> 
>  time.sleep(1.0 / (10))
> 
>  _variable_function_probe_0_thread =
> threading.Thread(target=_variable_function_probe_0_probe)
> 
>  _variable_function_probe_0_thread.daemon = True
> 
> -_variable_function_probe_0_thread.start()
> 
>  
> 
>  self.qtgui_time_sink_x_0 = qtgui.time_sink_f(
> 
>  1024, #size
> 
> @@ -160,6 +159,7 @@ class if_else(gr.top_block, Qt.QWidget):
> 
>  self.connect((self.analog_sig_source_x_0, 0),
> (self.blocks_throttle_0, 0))
> 
>  self.connect((self.analog_sig_source_x_1, 0),
> (self.qtgui_time_sink_x_0, 0))
> 
>  self.connect((self.blocks_throttle_0, 0), (self.probe, 0))
> 
> +_variable_function_probe_0_thread.start()
> 
>  
> 
>  def closeEvent(self, event):
> 
>  self.settings = Qt.QSettings("GNU Radio", "if_else")
> 
> 
> 
> 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

Re: [Discuss-gnuradio] OFDM/GR-IEEE802-11

[Martin Braun]

You can change the frequency technically. Legally, we can't give you
advice here other than to follow the rules.

Cheers,
Martin

On 03/30/2017 09:52 AM, Thomas Wilkinson wrote:
> 
> Please forgive me as I am new to SDRs and DSP. 
> 
> I am interested in development of a radio link using two B210s and
> GR-IEEE802-11.   However, I would like for this link to operate at any
> frequency. I am interested in a robust waveform with minimum of 11MBPS
> throughput, which is why I am interested in OFDM/802.11. My very limited
> hope/understanding is that I can potentially change the frequency of
> operation in the PHY layer.
> 
> Thanks in advance for your help. 
> 
> 
> Tom
> 
> 
> ___
> 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] Undocumented custom blocks in GNU Radio

[Martin Braun]

Both these problems probably stem from the same root cause. Try and load
the underlying library file in Python (something like "cd build/swig;
python -c 'import _channelsounder_swig.py'") and it'll most likely
crash. That should clue you into what's going wrong.

-- M

On 03/30/2017 10:36 PM, Ammar Mahmood wrote:
> Dear all,
> 
> 
> I am trying to run the gr-channelsounder flow graph
> (https://github.com/gbaier/gr_channelsounder
> ). The custom blocks in the
> flowgraph build successfully but are shown as *undocumented in GNU
> Radio*. Also, the following error occurs if these blocks are used in a
> simulation:
> 
> Traceback (most recent call last):
>   File "/home/ammar/top_block.py", line 87, in 
> main()
>   File "/home/ammar/top_block.py", line 81, in main
> tb = top_block_cls()
>   File "/home/ammar/top_block.py", line 61, in __init__
> self.channelsounder_avg_m_over_n_cc_0 =
> channelsounder.avg_m_over_n_cc(2000, 255)
> AttributeError: 'module' object has no attribute 'avg_m_over_n_cc'
> 
> Can anybody help me out regarding how to remove this error?
> 
> Regards,
> Ammar
> 
> p.s. I also tried the solution provided to remove attribute errors
> provided on below mentioned link to no avail as there were no faulty
> methods or I was not able to find them by running the " nm -C -u
> libgnuradio-.so | grep MyClass " command replacing
> modulename and Myclass with the respective names of my module and class.
> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-08/msg00374.html
> 
> 
> 
> ___
> 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] [GSoC] GNU Radio Companion Extensions: Output C++ Code

[Martin Braun]

On 03/31/2017 07:32 AM, Koslowski, Sebastian (CEL) wrote:
> Dear Håkon,
> 
> I am very excited to see interest in this topic! A few additional comments:
> 
> - Any new templating should be done using Mako. The new YAML format
> Martin mentioned roughly looks like this:

The more I think about it, the more it probably makes sense to go
straight to Mako. Skip the Cheetah. Don't bother about 3.7.

-- M

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

Re: [Discuss-gnuradio] How to know that the last sample has arrived

[Marcus Müller]

Hi Ruben,

technically, I like the idea of having the scheduler do things like
tagging final packets. That could be a low-overhead operation (happens
only once in an application's livetime), and you could hack it into the
scheduler relatively easy, but, to be honest, the last thing our
scheduler needs now is more special cases and hand-hacked-in features...
But that's my 2ct.

> An example is if I want to make an input signal which consists of 100
> zeros, followed by 1000 random bits, then followed by the content of a
> file?
> With a concatenation block, it could be done with 4 blocks:
> vector_source, random_source, file_source, contatenate_inputs_ff.
Well, you could implement that with a general block that consumes
different amount of samples from different inputs if you know how many
will be coming from each.

Personally, I like the idea of the file source, **even** in repeat mode,
adding a "EOF" tag (at the end of file) so very much that I'd definitely
help you extend the file source to do that and get it merged into GNU
Radio :)

Best regards,

Marcus


On 31.03.2017 16:38, Ruben Undheim wrote:
> Thank you both for answering.
>
>> I would totally agree with Marcus. Especially you first approach can't
>> work reliably.
> It appeared quite stable for file_source, but I got some problems
> today with one of my custom blocks which suddenly caused the following
> block to be called with ninput_items[0] == 1, without it being the
> last sample...
>
>> What about using tagged streams or just a tag on the last sample? Is
>> that an option?
> The reason for posting the question was mainly to make sure I am not
> missing something obvious. Putting a tag on the last sample sounds
> like the best solution so far. Thanks. The only complication is that
> then I will have to CLONE the implementations for vector_source,
> file_source, random_source...  Would it be an idea to modify these
> blocks so that they always add an "END" tag on the last sample in the
> main code base?
>
> I am just wondering, how would one go about to make blocks for
> "concatenating" input streams, or "repeating" the finite-length input
> stream, or "zero-padding" finite-length input streams if we do not
> have such an "END" tag? I am a bit surprised if nobody has never
> wanted to do this before.
>
> An example is if I want to make an input signal which consists of 100
> zeros, followed by 1000 random bits, then followed by the content of a
> file?
> With a concatenation block, it could be done with 4 blocks:
> vector_source, random_source, file_source, contatenate_inputs_ff.
>
>
> Cheers,
> Ruben
>
> ___
> 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] Dealing with GRC variables and GRC callbacks (was: GNU Radio Companion Extensions: Output C++ Code)

[Marcus Müller]

Hi Sebastian,

(Håkon, this is half-related to your proposal; there's questions arising
from this, but I think I'd like to raise them later, if at all, after
Sebastian has enlightened me :) )

you're touching a very delicate subject here: I personally think that
GRC variables should have been for instantiation-time variability only,
but through the fact that they are actually Python variables, we've
enabled (which is a great thing) people to use them as dynamic things at
run time. (think: changing the gain using a GUI slider that calls the
generated variable setter, rather than e.g. sending a PMT message).

As far as I can tell, that cannot really work out in C++, unless we
really come up with automatic wrapping of block methods with something
like a message passing interface. We already have that message passing,
we don't have the C++ method-to-message-handler wrapping (which somehow
reminds me of a feature PR that I made quite a while ago...).

But if we demand that we can use variables at runtime, we would first
have to implement that inside the GR runtime – basically, the
servicification that Johnathan is dreaming of.+

So, we could only do this at instantiation, or, to be honest, at code
creation time – in which case a simple "eval()" might be the best option
(as little as I like that).

But that's really a rather personal, maybe not very well-backed view on
this. I'd love to hear your opinion on that; I'm biased, I'd rather lose
the ability to use raw Python in block parameters and convert the GRC
variable concept to "automatically generated subscribers and
publishers", but I know that would be a complete paradigm change, and
that's what I don't like about my idea.

Cheers,
Marcus


On 31.03.2017 16:32, Koslowski, Sebastian (CEL) wrote:
> Dear Håkon,
>
> I am very excited to see interest in this topic! A few additional
> comments:
>
> - Any new templating should be done using Mako. The new YAML format
> Martin mentioned roughly looks like this:
> """
> id: blocks_add_const_vxx
> label: Add Const
>
> parameters:
> -   id: type
> label: IO Type
> dtype: enum
> options: [complex, float, int, short]
> option_attributes:
> const_type: [complex_vector, real_vector, int_vector, int_vector]
> fcn: [cc, ff, ii, ss]
> hide: part
> -   id: const
> label: Constant
> dtype: ${ type.const_type }
> default: '0'
> -   id: vlen
> label: Vec Length
> dtype: int
> default: '1'
> hide: ${ 'part' if vlen == 1 else 'none' }
>
> inputs:
> -   dtype: ${ type }
> vlen: ${ vlen }
>
> outputs:
> -   dtype: ${ type }
> vlen: ${ vlen }
>
> templates:
> imports: from gnuradio import blocks
> make: blocks.add_const_v${type.fcn}(${const})
> callbacks:
> - set_k(${const})
> """
>
> C++ specific templates could be added under "cpp_templates" or sth.
> The main part of your work would be to implement a Generator subclass.
> You maybe want to checkout my latest dev version to use as a starting
> point [0]
>
> Another issue is how to deal with parameter values:
> Say, I have a variable with "np.pi" as value. Or specify some filter
> coeffs using a list [1, 1, 1, 1,...]. Or so some calculation "2 ** 4 + 1".
> Those usually end up in the generated code somewhere. For C++ that
> would fail...
> I suggest, that at least some simple expressions should be transpiled
> for the C++ code generation.
>
> The alternative, writing all parameter values in C++ code, would
> require a separate eval, validation,  - basically a C++ version of
> GRC.
> I'd rather do everything in Python and get the C++ output as a bonus
> on top. This means that all blocks must still be available in Python -
> even if they are just in output C++. This way we can load and
> instantiate things like filter and constellation objects during design
> time (before you hit generate) and do validation with those.
>
> Sebastian
>
> [0]
> https://github.com/skoslowski/gnuradio/blob/df1e94831c05e3b8a25e5490f50ebf9e98795182/grc/core/generator/top_block.py
>
>
>
> On 03/31/2017 02:07 PM, Håkon Vågsether wrote:
>> Hi Marcus,
>>
>> thank you for your feedback.
>>
>> Also, would kind of had preferred to read "I've not used GNU
>> Radio much before, but I've played around with the LiveDVD (or
>> whatever you'd have done)" instead of reading "I've not used GNU
>> Radio before(at all)" and seeing you use pretty dated screenshots
>> from Josh's website instead of familiarizing yourself quickly, so
>> that you could leave us with the certainty that hey, we don't
>> have to teach you how to even start GRC ... not that I really
>> think this will be any trouble for you, but the ease of getting
>> started with GNU Radio, considering ready-made packages and the
>> bootable liveDVD and the guided tutorials make me wonder much
>> more why you didn't demonstrate you've played with GNU Radio before.
>>
>> Haha, I understand what you mean, and you're right! I 

Re: [Discuss-gnuradio] How to know that the last sample has arrived

[Ruben Undheim]

Thank you both for answering.

> I would totally agree with Marcus. Especially you first approach can't
> work reliably.

It appeared quite stable for file_source, but I got some problems
today with one of my custom blocks which suddenly caused the following
block to be called with ninput_items[0] == 1, without it being the
last sample...

> What about using tagged streams or just a tag on the last sample? Is
> that an option?

The reason for posting the question was mainly to make sure I am not
missing something obvious. Putting a tag on the last sample sounds
like the best solution so far. Thanks. The only complication is that
then I will have to CLONE the implementations for vector_source,
file_source, random_source...  Would it be an idea to modify these
blocks so that they always add an "END" tag on the last sample in the
main code base?

I am just wondering, how would one go about to make blocks for
"concatenating" input streams, or "repeating" the finite-length input
stream, or "zero-padding" finite-length input streams if we do not
have such an "END" tag? I am a bit surprised if nobody has never
wanted to do this before.

An example is if I want to make an input signal which consists of 100
zeros, followed by 1000 random bits, then followed by the content of a
file?
With a concatenation block, it could be done with 4 blocks:
vector_source, random_source, file_source, contatenate_inputs_ff.


Cheers,
Ruben

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

Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code

[Koslowski, Sebastian (CEL)]

Dear Håkon,

I am very excited to see interest in this topic! A few additional comments:

- Any new templating should be done using Mako. The new YAML format
Martin mentioned roughly looks like this:
"""
id: blocks_add_const_vxx
label: Add Const

parameters:
-   id: type
label: IO Type
dtype: enum
options: [complex, float, int, short]
option_attributes:
const_type: [complex_vector, real_vector, int_vector, int_vector]
fcn: [cc, ff, ii, ss]
hide: part
-   id: const
label: Constant
dtype: ${ type.const_type }
default: '0'
-   id: vlen
label: Vec Length
dtype: int
default: '1'
hide: ${ 'part' if vlen == 1 else 'none' }

inputs:
-   dtype: ${ type }
vlen: ${ vlen }

outputs:
-   dtype: ${ type }
vlen: ${ vlen }

templates:
imports: from gnuradio import blocks
make: blocks.add_const_v${type.fcn}(${const})
callbacks:
- set_k(${const})
"""

C++ specific templates could be added under "cpp_templates" or sth.
The main part of your work would be to implement a Generator subclass.
You maybe want to checkout my latest dev version to use as a starting
point [0]

Another issue is how to deal with parameter values:
Say, I have a variable with "np.pi" as value. Or specify some filter
coeffs using a list [1, 1, 1, 1,...]. Or so some calculation "2 ** 4 + 1".
Those usually end up in the generated code somewhere. For C++ that would
fail...
I suggest, that at least some simple expressions should be transpiled
for the C++ code generation.

The alternative, writing all parameter values in C++ code, would require
a separate eval, validation,  - basically a C++ version of GRC.
I'd rather do everything in Python and get the C++ output as a bonus on
top. This means that all blocks must still be available in Python - even
if they are just in output C++. This way we can load and instantiate
things like filter and constellation objects during design time (before
you hit generate) and do validation with those.

Sebastian

[0]
https://github.com/skoslowski/gnuradio/blob/df1e94831c05e3b8a25e5490f50ebf9e98795182/grc/core/generator/top_block.py



On 03/31/2017 02:07 PM, Håkon Vågsether wrote:
> Hi Marcus,
>
> thank you for your feedback.
>
> Also, would kind of had preferred to read "I've not used GNU Radio
> much before, but I've played around with the LiveDVD (or whatever
> you'd have done)" instead of reading "I've not used GNU Radio
> before(at all)" and seeing you use pretty dated screenshots from
> Josh's website instead of familiarizing yourself quickly, so that
> you could leave us with the certainty that hey, we don't have to
> teach you how to even start GRC ... not that I really think this
> will be any trouble for you, but the ease of getting started with
> GNU Radio, considering ready-made packages and the bootable
> liveDVD and the guided tutorials make me wonder much more why you
> didn't demonstrate you've played with GNU Radio before.
>
> Haha, I understand what you mean, and you're right! I naturally
> wouldn't post my proposal draft for this project without knowing how
> to even start GRC :) I have spent the last few weeks tinkering and
> trying to gain some familiarity with GRC and its source. I could (and
> should) have just taken a screenshot myself! I will include this in my
> next draft.
>
> Big Plus is of course that you mention Cheetah, which proves
> you've actually looked at the source code, I guess! This is
> probably not going to hurt at this stage, but as Ben said, we're
> currently replacing that with Mako (Cheetah is kinda Python2 only,
> and we're making things work with Py3).
>
> So, I hope this is not asking too much from your time right now
> (you might be busy with exams for all I know about studying), but
> I'd recommend you checkout the "next" branch of the gnuradio
> repository, and try to build it with GRC enabled, and maybe add
> some "change  to include " to
> your timeline after getting a rough idea of how code gen works there.
>
> Right! I had already built it from source, but I was on the master
> branch. I've built the next branch now, and I've noticed the addition
> of the GRCC compiler.py in the grc/ directory. I suppose the GSoC
> project might as well include adding the build options as command line
> arguments to this while I'm at it.
>
> I like your block diagram, it clarifies a few things, and
> generally, I prefer reading a concise chart instead of a wall of
> text, and I think that "writing down" the current code generation
> process in terms of who-calls-what in Python in that shape would
> be awesome, because that would allow you to make a second,
> modified chart that shows what you'd like to add/change to that,
> and would also be a great starting point for the (relatively
> compact) documentation we'd like you to deliver in the end.
>
> I've made another diagram to 

Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code

[Håkon Vågsether]

Hi Martin,

okay, I see. This is useful information, thanks a lot!

Best regards,
Håkon Vågsether

There's another thing: On 3.8, we'll be going to a different model of
> writing GRC bindings (YAML-based). It's difficult to summarize the
> changes, but basically, don't assume that we'll be using XML files forever.
>
> -- M
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code

[Håkon Vågsether]

Hi Marcus,

thank you for your feedback.

> Also, would kind of had preferred to read "I've not used GNU Radio much
> before, but I've played around with the LiveDVD (or whatever you'd have
> done)" instead of reading "I've not used GNU Radio before(at all)" and
> seeing you use pretty dated screenshots from Josh's website instead of
> familiarizing yourself quickly, so that you could leave us with the
> certainty that hey, we don't have to teach you how to even start GRC ...
> not that I really think this will be any trouble for you, but the ease of
> getting started with GNU Radio, considering ready-made packages and the
> bootable liveDVD and the guided tutorials make me wonder much more why you
> didn't demonstrate you've played with GNU Radio before.
>
Haha, I understand what you mean, and you're right! I naturally wouldn't
post my proposal draft for this project without knowing how to even start
GRC :) I have spent the last few weeks tinkering and trying to gain some
familiarity with GRC and its source. I could (and should) have just taken a
screenshot myself! I will include this in my next draft.

> Big Plus is of course that you mention Cheetah, which proves you've
> actually looked at the source code, I guess! This is probably not going to
> hurt at this stage, but as Ben said, we're currently replacing that with
> Mako (Cheetah is kinda Python2 only, and we're making things work with Py3).
>
> So, I hope this is not asking too much from your time right now (you might
> be busy with exams for all I know about studying), but I'd recommend you
> checkout the "next" branch of the gnuradio repository, and try to build it
> with GRC enabled, and maybe add some "change  to
> include " to your timeline after getting a rough idea of how
> code gen works there.
>
Right! I had already built it from source, but I was on the master branch.
I've built the next branch now, and I've noticed the addition of the GRCC
compiler.py in the grc/ directory. I suppose the GSoC project might as well
include adding the build options as command line arguments to this while
I'm at it.

> I like your block diagram, it clarifies a few things, and generally, I
> prefer reading a concise chart instead of a wall of text, and I think that
> "writing down" the current code generation process in terms of
> who-calls-what in Python in that shape would be awesome, because that would
> allow you to make a second, modified chart that shows what you'd like to
> add/change to that, and would also be a great starting point for the
> (relatively compact) documentation we'd like you to deliver in the end.
>
I've made another diagram to visualise this, the dotted lined objects are
objects that I'm planning to implement. I've tried to leave out the
non-essential details to reduce complexity. As Ben pointed out (if I
understood him correctly), it might not be worthwhile to create Makefiles
directly from the templates, rather just leave it all to CMake. This does
make sense and will save me some work.
​
 call_diag.png

​

Best regards,
Håkon Vågsether
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] File sink question

[Marcus Müller]

Hi Ellie,


On 31.03.2017 02:52, Ellie White wrote:
> Thank you for the quick response. I guess I had been confused and had
> set the sampling rate far too high! I think the right sampling rate
> should be 2 MHz for the RTL-SDR dongle, based on what I’ve seen online
> – does that sound more appropriate to you?
Well, *you* are the one designing your signal processing application, so
you tell me what's appropriate for your /purpose/. But yes, the SDR
dongles can typically operate at such sampling rates.
>
>  
>
> Regarding the rest of my question, if I am understanding this
> correctly, the file sink stores data read in from the source (in my
> case, the SDR dongle) as a 2d array, containing frequency and time
> information.
>
No, not at all!
The file sink just stores data. Just as it comes. Every stream
connection in GNU Radio really just transports numbers – and you're
storing only these numbers, in raw binary format, and nothing more!
>
> So, if I would run my flowgraph for some amount of time, I am
> accumulating time samples in the destination file via the file sink
> (each time sample containing 1024 values representing the power of
> each frequency channel produced by the FFT block) – is that correct? #
>
So, what your flow graph does is it takes 1024-element vectors of the
complex input signal coming from your RTL-SDR (which then really are
just 1024 complex values in memory, each of which is a float32 real, and
a float32 imaginary part, directly after each other, in machine format),
subjects them to an FFT, which does something "logically" to these
vectors, but doesn't change the fact that they're still 1024-vectors of
complexes, then subjects these to a transformation from complex values
to magnitude squares, which changes them to 1024-vectors of floats, and
then just writes them to a file.

That file will just contain floats. There's absolutely no indication of
time or frequency in these – just numbers. The fact that they're
1024-vectors, of float32, with a special meaning, generated from a 
signal with a specific sampling rate, is something that is not stored in
the file. Again: the file really just contains the raw numbers, one
after the other, with no dimensionality or annotations.
>
>  
>
> To clarify a bit further, my aim is to make a plot of power vs. time
> for one particular frequency channel using python. So I want to be
> able to tell how many seconds of data I am looking at, rather than how
> many time samples I am looking at.
>
But that's trivial, because t = N_samples / f_sample !!
>
> I attached a plot to illustrate what I mean: right now, the x-axis is
> labeled based on time samples (I think),
>
Well, it's labeled with the index of the number numpy read.
>
> and I would like to label it with the corresponding time stamp instead.
>
So, generate an index vector with numpy, for example

idx = numpy.linspace(0,len(samples_read_from_file)/f_sample,
len(samples_read_from_file))
pyplot.plot(idx, samples_read_from_file)

No magic involved! :)
>
> So the question is, how do I convert number of time samples into an
> indication of time intervals?
>
>  
>
> Hopefully this makes sense and isn’t too convoluted…let me know if I
> need to clarify anything further or provide any other information.
>
>  
>
No, everything's fine so far. You're clearly entering the field of DSP
in a very cool way, and I'd say: go for it!

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

Re: [Discuss-gnuradio] How to know that the last sample has arrived

[Julian Arnold]

Hey,

> I honestly think that way is at least more reliable than the one you
> sketched above, but probably still not all that reliable.
I would totally agree with Marcus. Especially you first approach can't
work reliably.
What about using tagged streams or just a tag on the last sample? Is
that an option?

Cheers,
Julian

On 03/31/2017 01:47 PM, Marcus Müller wrote:
>
> Hi Ruben,
>
>> If I consume (ninput_items[0] - 1) samples every time general_work is
>> called, I will eventually get general_work called with ninput_items[0]
>> == 1. Would this be a reliable way to do it? Or is there a more
>> straightforward way which I cannot see?
> Oh, I *think* that might work, but really you shouldn't rely on the
> scheduler never calling you with a single sample – we nowhere say it
> wouldn't do that during normal operation.
>
>> The goal is to have a block which reliably appends something specific
>> after the last incoming sample. When I detect that the last sample has
>> arrived, the following call to forecast will return 0, causing
>> general_work to be called again even when ninput_items[0] == 0, and I
>> then return -1 when all the appended samples have been produced. That
>> seems to work fine, but I am unsure if there is a more straight
>> forward way.
> I honestly think that way is at least more reliable than the one you
> sketched above, but probably still not all that reliable.
>
> I think we'll need input from the others on this, but I think we do
> /not/ have a "guaranteed" way of making this work without adding hooks
> to the scheduler that we do not have yet.
>
> I'd rather find a way to access the block executor of the next block
> upstream and ask it whether it is done.
>
> Best regards,
> Marcus
>
> On 31.03.2017 12:06, Ruben Undheim wrote:
>> Hi,
>>
>> Is there a good way to find out from inside general_work that the last
>> sample has arrived? (such as from vector_source_X or file_source)
>>
>> If I consume (ninput_items[0] - 1) samples every time general_work is
>> called, I will eventually get general_work called with ninput_items[0]
>> == 1. Would this be a reliable way to do it? Or is there a more
>> straightforward way which I cannot see?
>>
>> The goal is to have a block which reliably appends something specific
>> after the last incoming sample. When I detect that the last sample has
>> arrived, the following call to forecast will return 0, causing
>> general_work to be called again even when ninput_items[0] == 0, and I
>> then return -1 when all the appended samples have been produced. That
>> seems to work fine, but I am unsure if there is a more straight
>> forward way.
>>
>> Best regards
>>
>> Ruben
>>
>> ___
>> 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

-- 
Julian Arnold, M.Sc.

Institute for Networked Systems
RWTH Aachen University

Kackertstrasse 9
52072 Aachen
Germany


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

Re: [Discuss-gnuradio] How to know that the last sample has arrived

[Marcus Müller]

Hi Ruben,

> If I consume (ninput_items[0] - 1) samples every time general_work is
> called, I will eventually get general_work called with ninput_items[0]
> == 1. Would this be a reliable way to do it? Or is there a more
> straightforward way which I cannot see?
Oh, I *think* that might work, but really you shouldn't rely on the
scheduler never calling you with a single sample – we nowhere say it
wouldn't do that during normal operation.

> The goal is to have a block which reliably appends something specific
> after the last incoming sample. When I detect that the last sample has
> arrived, the following call to forecast will return 0, causing
> general_work to be called again even when ninput_items[0] == 0, and I
> then return -1 when all the appended samples have been produced. That
> seems to work fine, but I am unsure if there is a more straight
> forward way.
I honestly think that way is at least more reliable than the one you
sketched above, but probably still not all that reliable.

I think we'll need input from the others on this, but I think we do
/not/ have a "guaranteed" way of making this work without adding hooks
to the scheduler that we do not have yet.

I'd rather find a way to access the block executor of the next block
upstream and ask it whether it is done.

Best regards,
Marcus

On 31.03.2017 12:06, Ruben Undheim wrote:
> Hi,
>
> Is there a good way to find out from inside general_work that the last
> sample has arrived? (such as from vector_source_X or file_source)
>
> If I consume (ninput_items[0] - 1) samples every time general_work is
> called, I will eventually get general_work called with ninput_items[0]
> == 1. Would this be a reliable way to do it? Or is there a more
> straightforward way which I cannot see?
>
> The goal is to have a block which reliably appends something specific
> after the last incoming sample. When I detect that the last sample has
> arrived, the following call to forecast will return 0, causing
> general_work to be called again even when ninput_items[0] == 0, and I
> then return -1 when all the appended samples have been produced. That
> seems to work fine, but I am unsure if there is a more straight
> forward way.
>
> Best regards
>
> Ruben
>
> ___
> 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] How to know that the last sample has arrived

[Ruben Undheim]

Hi,

Is there a good way to find out from inside general_work that the last
sample has arrived? (such as from vector_source_X or file_source)

If I consume (ninput_items[0] - 1) samples every time general_work is
called, I will eventually get general_work called with ninput_items[0]
== 1. Would this be a reliable way to do it? Or is there a more
straightforward way which I cannot see?

The goal is to have a block which reliably appends something specific
after the last incoming sample. When I detect that the last sample has
arrived, the following call to forecast will return 0, causing
general_work to be called again even when ninput_items[0] == 0, and I
then return -1 when all the appended samples have been produced. That
seems to work fine, but I am unsure if there is a more straight
forward way.

Best regards

Ruben

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

Re: [Discuss-gnuradio] File sink question

[Ellie White]

Hello Marcus -

Thank you for the quick response. I guess I had been confused and had set the 
sampling rate far too high! I think the right sampling rate should be 2 MHz for 
the RTL-SDR dongle, based on what I've seen online - does that sound more 
appropriate to you?

Regarding the rest of my question, if I am understanding this correctly, the 
file sink stores data read in from the source (in my case, the SDR dongle) as a 
2d array, containing frequency and time information. So, if I would run my 
flowgraph for some amount of time, I am accumulating time samples in the 
destination file via the file sink (each time sample containing 1024 values 
representing the power of each frequency channel produced by the FFT block) - 
is that correct?

To clarify a bit further, my aim is to make a plot of power vs. time for one 
particular frequency channel using python. So I want to be able to tell how 
many seconds of data I am looking at, rather than how many time samples I am 
looking at. I attached a plot to illustrate what I mean: right now, the x-axis 
is labeled based on time samples (I think), and I would like to label it with 
the corresponding time stamp instead. So the question is, how do I convert 
number of time samples into an indication of time intervals?

Hopefully this makes sense and isn't too convoluted...let me know if I need to 
clarify anything further or provide any other information.

Thanks so much!

Ellie

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+orionnebula42=outlook@gnu.org] On Behalf 
Of Marcus Müller
Sent: Thursday, March 30, 2017 7:02 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] File sink question


Dear Ellie,

I'm not aware of any GNU Radio-compatible SDR receiver with a sampling rate of 
300 MHz - that is very high - are you perhaps confusing sampling rate and 
center frequency?

How do you "measure" 5min? GNU Radio doesn't "run" at the sampling rate you set 
in things like the signal source - that is really just a number, a parameter, 
that the signal source uses together with the signal frequency you configure to 
calculate how long a period is in samples. Samples will be produced as fast as 
your computer is - which is probably less then 300 MS/s.

So, if you'd want 5mins of "simulated signal", you'd use a "head" block, with 
the number of samples being set to 300,000,000·60·5. Notice that you **do not** 
want to do that, usually. In GNU Radio's default complex signal type, which is 
complex numbers composed of 32 bit real and 32bit imaginary float, that's 720 
GB.

Best regards,

Marcus

On 03/31/2017 12:13 AM, Ellie White wrote:

Hello again,



I have a quick question to ask about how the file sink works (since this was 
slightly unrelated to the other question I thought I should put it under a 
different subject line). To provide some background info, my sampling rate is 
set at 300e6, and I recorded data for (I'm guessing) about 5 minutes. Based on 
some fiddling around in Python with a data file I saved from a file sink, it 
appears that just 426,152 time samples were recorded to file, so I am 
wondering, first, why are there so few samples recorded (i.e. why wasn't the 
number of samples recorded 300e6*seconds)? And second, how does the file sink 
"decide" which samples to keep, and which not to keep?



Thank you in advance for any help/explanations!



Ellie




___

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