Re: [Discuss-gnuradio] Concurrent Rx on USRP E312

On 03/01/2018 01:04 AM, kailash kumar wrote:

Hi,

I am trying to explore the possibility of using Rx channels(0,1) independently and concurrently on Ettus USRP E312.

Here is what I am trying:

USRP 1  --> Rx Freq 1 --> Filter --> Demodulation and Decode 1 --> Audio Sink
             --> Rx Freq 2 --> Filter --> Demodulation and Decode 2 --> Audio Sink

When transmit at frequency 2, Data gets received on both Rx channels and gets processed even though center freq is different.

Attached is the flow graph.

Is it possible to use both Rx concurrently? If yes, anything that I am missing wrt flowgraph?

Thanks
Kailash

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

You're missing the fact that the AD9361 front-end on the E312 uses a *shared* LO for both RX channels.  The LO physically cannot be tuned to different
  frequencies, although differences of up to 30Mhz or so can be arranged by using DSP tunings, your tunings of 96MHz and 710MHz simply cannot be
  achieved by the hardware.

Further discussion might be more useful on the usrp-users mailing list, instead of here.

[Discuss-gnuradio] Concurrent Rx on USRP E312

Hi,

I am trying to explore the possibility of using Rx channels(0,1) independently and concurrently on Ettus USRP E312.

Here is what I am trying:

USRP 1  --> Rx Freq 1 --> Filter --> Demodulation and Decode 1 --> Audio Sink
             --> Rx Freq 2 --> Filter --> Demodulation and Decode 2 --> Audio Sink

When transmit at frequency 2, Data gets received on both Rx channels and gets processed even though center freq is different.

Attached is the flow graph.

Is it possible to use both Rx concurrently? If yes, anything that I am missing wrt flowgraph?

Thanks
Kailash

Re: [Discuss-gnuradio] Regarding the updating and extending gr-radar idea for GSoc 2018

On 02/24/2018 05:34 AM, suraj hanchinal wrote:
> Hello Everyone,
> I am planning to apply for GSoc 2018. I was very interested and would
> love to work on the gr-radar toolbox. I was interested specifically in
> implementing passive-radar and multi-antenna support to gr-radar. Since
> a passive radar system would need a multi-antenna support anyways, I
> think they could be implemented together. I have been reading some
> research papers regarding passive radars to get a better understanding
> and I think implementing a passive radar to use FM transmitters nearby
> to locate objects as a good starting point and then turn to using wifi
> access points in an area as the next step. I am currently developing a
> proper write-up as well for the same. I would kindly request you to
> point out any things I should know of or just general suggestions on the
> subject. I would also kindly request the mentors Martin Braun and Stefan
> Wansch to enlighten me on this.

Suraj,

thanks for your interest in GSoC and gr-radar! Passive radar would
indeed be a pretty nifty addition. It's probably easier to get better
results using more high-bandwidth signals with better cross-correlation
properties, such as terrestrial TV stations.

Note that I assume that you have some familiarity with the signal
processing fundamentals of passive radar. That said, you can do a lot
better than cross-correlating when doing passive radar with OFDM
signals, but that's a little too much to lay out in a short email (in a
nutshell, you can recreate the original tx'd signal and use symbols as
samples in the time-frequency domain to generate range/Doppler diagrams
without having to worry about cross-correlation artefacts).

Also go check out Juha Vierinen's work (e.g., this:
https://hackaday.com/2015/06/05/building-your-own-sdr-based-passive-radar-on-a-shoestring/,
an old blog post I googled real quick). And of course Jean-Michel's work
that Phil mentioned.

-- M

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

Re: [Discuss-gnuradio] Introduction for GSoC participation

On 02/26/2018 06:53 AM, swapnil negi wrote:
> Hi,
> I am Swapnil Negi, an Electronics and Communication undergraduate at
> Indian Institute of Technology Roorkee, India. I am highly interested in
> contributing towards GNU Radio as my GSoC project. 
> [...]
> I have checked out the ideas list. Two of the ideas suit me:
> 1. CtrlPort backend implementation: I, myself faced issues with the
> thrift version so I really wish to improvise this. I have started
> reading about remote procedural calls, message queues, etc, the
> differences and benefits of different message queues like level of
> abstraction, ease of implementation, etc. It seems interesting to me.

Hi Swapnil,

very welcome to this list, and we do appreciate people getting to know
the community before applying.

We recently talked about some changes to ctrlport, and the end result is
that we need to think about that part a bit more. So unless you already
have a specific project in mind, I would recommend you focus on your
second idea...

> 2. gr-modtool overhaul: I haven't gone through the code structure of
> gr-modtool but the concept is really interesting. It will also help me
> get the real feeling of GNU Radio. I saw the present series of if's and
> else's and would like to work on improvising this. 

...and I'm very glad you immediately identified the biggest issue with
modtool. Nicolas already gave you some really good responses, so I'll
try and not repeat them.

FYI, I wrote modtool a long time ago and thus can attest that it hasn't
aged well. It's not easy to extend, it's a long set of statically
checked rules, etc.

If you're interested in improving this tool, I would recommend starting
to play around with it and see which shortcomings it has. For a start,
I'm pretty sure it doesn't work with Python 3 (that's actually on the
ideas list too, but it's an easy place to start).

As a side note, we're always *extremely* happy when GSoC students
volunteer to work on tooling and/or GUIs.

Cheers,
Martin

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

Re: [Discuss-gnuradio] [GNU-Radio] Regarding Transfer of files using GNU-Radio and USRP-N210

Dear VijayKrishnan,

you use multiple blocks from the "deprecated" category, and these are
deprecated because they have systematic bugs. Don't use them, we can't
help you, that's why they are "deprecated".

So, replace the DPSK block with a simple "Constellation Modulator" on
TX, and do the clock recovery like in our PSK mod tutorial on
tutorials.gnuradio.org

Best regards,
Marcus

On Wed, 2018-02-28 at 09:01 -0700, Vijaykrishnan Sarangarajan wrote:
> Hello everyone,
>
> I am Vijay and I am a graduate student at University of Colorado-Boulder. I am trying to transfer a text file using a pair of USRP-N210s. I am pretty certain that the transmission is happening ( I checked with a Spectrum Analyser) but I am not able receive the text-file properly.
>
> I have put a Wx-FFT GUI after every block in the Rx to check the flow of data and I feel that the flow is as expected till the Low-pass filter. After the Packet Decoder, there is nothing written in the text-file (size = 0 Bytes).
>
> Frequency = 950 MHz
> Sampling Rate = 500K
>
>
> I have attached the Tx and Rx snippets and any guidance would be greatly appreciated.
>
> Thanks and Regards,
> VijayKrishnan
>
> VijayKrishnan Sarangarajan
> Fall-16 Graduate Student,
> ITP Department,
> University of Colorado Boulder
> Ph : 720-325-7449
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GNU-Radio] Regarding Transfer of files using GNU-Radio and USRP-N210

Hello everyone,

I am Vijay and I am a graduate student at University of Colorado-Boulder. I am trying to transfer a text file using a pair of USRP-N210s. I am pretty certain that the transmission is happening ( I checked with a Spectrum Analyser) but I am not able receive the text-file properly.

I have put a Wx-FFT GUI after every block in the Rx to check the flow of data and I feel that the flow is as expected till the Low-pass filter. After the Packet Decoder, there is nothing written in the text-file (size = 0 Bytes). 

Frequency = 950 MHz

Sampling Rate = 500K

I have attached the Tx and Rx snippets and any guidance would be greatly appreciated.

Thanks and Regards,

VijayKrishnan

VijayKrishnan Sarangarajan

Fall-16 Graduate Student,

ITP Department,

University of Colorado Boulder

Ph : 720-325-7449

Re: [Discuss-gnuradio] An Old Idea for GSoC 2018

Hi Sakthivel,

great to hear that you are interested in contributing to GNU Radio! I'm sure GNU Radio would benefit from a well-written gr-mimo module.

Practical difficulties are very likely to appear during the design and the implementation, how problematic that is for the feasibility of the project, however, mainly depends on you. :) Synchronization and channel estimation will be one issue you have to deal with, and if you use multiple USRPs for the trasnmitter or the receiver, you will have to deal with the inter-device synchronization, too. The latter could, e.g., be alleviated by simply using USRP B210s and restricting the system to 2x2 antennas as you wrote yourself.

At your stage, I think it's most important to get a clear idea of what you would like to implement. As this is not one of our ideas from the list, the acceptance of the project does not only depend on your proposal and the idea itself, we would also have to find a mentor for that and this is much easier with a clearly scoped proposal.

So make a plan with deliverables you think you can actually realize in the given time and come back to this list so we can discuss it further.

If anybody here on this list thinks he'd want to mentor such a project, feel free to chime in!

Cheers,
Felix

On 02/27/2018 02:53 PM, Sakthivel Velumani wrote:

Hi all,

I am a graduate student at Technische Universitat Darmstadt, Germany, majoring in signal processing for wireless communication. I am originally form India and did my bachelors there. I haven't heard about GNU Radio until a few months back and I regret for that, as I had more time in my undergrad and now graduate study is quite intense.

But still I managed to play with GR for few months now and also trying to build a block for carrier sync for OQPSK signals.

I saw MIMO transceiver idea in the GSoCOldIdeas page and I found it interesting and it suits me. I have done projects on solving problems in MIMO networks but the works were purely theoretical and simulation based. So I am eager to try out MIMO stuffs with hardware. As mentioned in the idea, I too feel that it would be nice for beginners to enjoy the effect of MIMO practically for a better understanding of the subject. So a standard gr-mimo module with a simple MRC decoder and a multi user beamforming encoder would do the job.

I further saw some discussion in the mailing list from 2014 regarding the same idea, and there were concerns (by Micheal Dickens) about the feasibility and practical difficulties in implementation as 3 months would not be sufficient. I am a bit confused as I think 3 months would be sufficient to implement the stuffs mentioned in the idea, or may be I am missing something here. I even saw Alick Zhoa and some others saying that they had already implemented 2x2 MIMO system in GR without OFDM but might have got obsolete. 

However it has been few years since then and I hope someone could give more insight on implementing a practical MIMO transceiver and difficulties in it.

So my concerns are

• I would be glad if someone could explain the possible difficulties in implementing a practical 2x2 MIMO system in GNU Radio and with USRPs
• Considering the difficulties, is it doable in a span of 3 months?
• If someone had already worked on similar stuffs, their help would be appreciated.
• Will the standard MIMO module (gr-mimo) be really beneficial to the project? If not, I would rather work on it at my leisure than for GSoC as the idea would be less likely to be accepted.

Regarding the hardware, my university laboratory has several USRPs and I can use them.

Best regards,

Sakthivel Velumani

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

--   Karlsruhe Institute of Technology (KIT)  Communications Engineering Lab (CEL)    Felix Wunsch, M.Sc.  Research Associate    Kaiserstraße 12  Building 05.01  76131 Karlsruhe    Phone: +49 721 608-46276  Fax: +49 721 608-46071  E-Mail: Felix.Wunsch@kit.edu    www.cel.kit.edu    KIT -- University of the State of Baden-Württemberg and  National Laboratory of the Helmholtz Association

[Discuss-gnuradio] QPSK correlator

Hi community!

I'm writing a QPSK demodulator for Meteor-M satellite. I followed tutorial on https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation and got the bits, which I was able to parse and restore the image. However I'm using sync word correlator with only 4 phase ambiguities (I wrote it myself). According to this doc: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19890016010.pdf there are 8 phase ambiguity possible.

My question is: if there any block in gnuradio, which could resolve all 8 phase ambiguities?

Best Regards,
Andrey
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Playing with gr-bokehgui

On 02/27/2018 03:41 PM, Kartik Patel wrote:

Hello Marcus,

So, the Waterfall sink is a custom plot that the Bokeh does not provide by default. Because of this error and the warning, I think Bokeh v0.12.6 and the current recent version has significant API changes. I may need to look at it in detail. Is it fine if I look at it in this weekend?

For now, it would suggest you downgrade the Bokeh to version 0.12.6, and NodeJS version to v6.6? Those were the versions I tested everything with. Let me know if that solves the issue (temporarily). If you don't 

Thanks.

Regards,

Kartik Patel

Take your time, dude!

None of this is mission-critical at the moment, I'm just exploring web-based visualization options for future work.

I was able to get nodeJS upgraded and now things "work" (after I manually removed the "resize" entry from utils.py).

On Tue, Feb 27, 2018 at 10:49 AM, Marcus D. Leech <mleech@ripnet.com> wrote:

On 02/27/2018 02:13 AM, Kartik Patel wrote:

Hello Marcus, 

During my testing, I think, I set the time.sleep function by try and error. I didn't check for different PC. I will update it after testing it on my too slow AWS may be. 

Also, this resize issue is because Bokeh stopped the support of resize feature. If you can, use Bokeh V0.12.6, and tornado v4.4. I have to Port the code to recent Bokeh version. 

Thanks for the extensive verifications. I will try to update the basic suggestions this weekend probably.

On Tue, Feb 27, 2018, 1:06 AM Marcus D. Leech <mleech@ripnet.com> wrote:

On 02/27/2018 01:25 AM, Marcus D. Leech wrote:

On 02/27/2018 12:15 AM, Kartik Patel wrote:

Hello Marcus,

Just for starters, make sure you have v3.7.12 of GNU Radio. In particular, your GR should contain the commit `3c989f9`. Also, make sure you select Bokeh GUI instead of QT GUI in Generate Options field in Options block. For Bokeh GUI we have a different `main()` function template that has necessary procedure to start the server and the stream.

Also, thank you very much for the suggestions about the vector plotter. In addition to the vector plotter, the Histogram plotter and BER curve are also in pipeline. I am too busy with several deadlines and projects. But I will try to incorporate the things as soon as possible (maybe in summer). Sorry for the loong promise! 

Let me know if you still have trouble working with the module.

Thanks.

Regards,

Kartik Patel

Thanks for the very-prompt response.  I know that you're probably very busy.

I managed to get to the point of GRC generating the correct startup code, with the "Bokeh GUI".  My repo was up-to-date, it's just that I hadn't actually built it.  Too many distractions...

But when I got to start now, I get:

Traceback (most recent call last):
  File "./top_block.py", line 153, in <module>
    main()
  File "./top_block.py", line 136, in main
    url = "http://localhost:" + port + "/bokehgui")
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/client/session.py", line 161, in push_session
    session.push(document)
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/client/session.py", line 370, in push
    raise IOError("Cannot push session document because we failed to connect to the server (to start the server, try the 'bokeh serve' command)")
IOError: Cannot push session document because we failed to connect to the server (to start the server, try the 'bokeh serve' command)

I can get past this error by setting a longer "time.sleep()" in the generated "main" -- I guess it takes a bit for the server to come up to a state where it can accept connections.

But now:

 File "./top_block.py", line 140, in main
    tb = top_block_cls(doc)
  File "./top_block.py", line 65, in __init__
    legend_list = legend_list)
  File "/usr/local/lib64/python2.7/site-packages/bokehgui/freq_sink_f.py", line 63, in initialize
    active_scroll = 'ywheel_zoom', )
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/figure.py", line 793, in figure
    return Figure(**kwargs)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/figure.py", line 149, in __init__
    tool_objs, tool_map = _process_tools_arg(self, opts.tools)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/helpers.py", line 530, in _process_tools_arg
    tool_obj = _tool_from_string(tool)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/helpers.py", line 467, in _tool_from_string
    raise ValueError("unexpected tool name '%s', %s tools are %s" % (name, text, nice_join(matches)))
ValueError: unexpected tool name 'resize', similar tools are reset

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

OK, so, I removed the reference to 'resize' in the default tools list.  Now, it's complaining about nodejs:

[mleech@laptop ~]$ ./top_block.py
Port is set to 5007

['bokeh', 'serve', '--port', '5007', '--allow-websocket-origin=*', '/usr/local/lib64/python2.7/site-packages/bokehgui/plots/bokehgui.py']
Port in main is 5007
Pid is 14986
2018-02-27 11:47:54,580 Starting Bokeh server version 0.12.14 (running on Tornado 4.5.3)
2018-02-27 11:47:54,583 Host wildcard '*' will allow connections originating from multiple (or possibly all) hostnames or IPs. Use non-wildcard values to restrict access explicitly
2018-02-27 11:47:54,594 Bokeh app running at: http://localhost:5007/bokehgui
2018-02-27 11:47:54,594 Starting Bokeh server with process id: 14986
2018-02-27 11:47:55,039 101 GET /bokehgui/ws?bokeh-protocol-version=1.0&bokeh-session-id=top_block (127.0.0.1) 2.38ms
2018-02-27 11:47:55,039 WebSocket connection opened
2018-02-27 11:47:55,045 ServerConnection created
INFO: Audio sink arch: alsa
/usr/lib/python2.7/site-packages/bokeh/client/session.py:316: UserWarning:

    !!!! PLEASE NOTE !!!!

The use of `session.loop_until_closed` and `push_session` to run Bokeh
application code outside a Bokeh server is **HIGHLY DISCOURAGED** for any real
use.

Running application code outside a Bokeh server with bokeh.client in this way
has (and always will have) several intrinsic drawbacks:

* Fast binary array transport is NOT available! Base64 fallback is much slower
* All network traffic is DOUBLED due to extra hop between client and server
* Server *and* client process must be running at ALL TIMES for callbacks to work
* App code run outside the Bokeh server is NOT SCALABLE behind a load balancer

The bokeh.client API is recommended to use ONLY for testing, or for customizing
individual sessions running in a full Bokeh server, before passing on to viewers.

For information about different ways of running apps in a Bokeh server, see:

    http://bokeh.pydata.org/en/latest/docs/user_guide/server.html

  warnings.warn(_BOKEH_CLIENT_APP_WARNING_FULL)
2018-02-27 11:48:02,506 Uncaught exception GET /bokehgui?bokeh-session-id=top_block (127.0.0.1)
HTTPServerRequest(protocol='http', host='localhost:5006', method='GET', uri='/bokehgui?bokeh-session-id=top_block', version='HTTP/1.1', remote_ip='127.0.0.1', headers={'Accept-Language': 'en-US,en;q=0.5', 'Accept-Encoding': 'gzip, deflate', 'Host': 'localhost:5006', 'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 'User-Agent': 'Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0', 'Connection': 'keep-alive'})
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/tornado/web.py", line 1512, in _execute
    result = yield result
  File "/usr/lib64/python2.7/site-packages/tornado/gen.py", line 1055, in run
    value = future.result()
  File "/usr/lib64/python2.7/site-packages/tornado/concurrent.py", line 238, in result
    raise_exc_info(self._exc_info)
  File "/usr/lib64/python2.7/site-packages/tornado/gen.py", line 1069, in run
    yielded = self.gen.send(value)
  File "/usr/lib/python2.7/site-packages/bokeh/server/views/doc_handler.py", line 26, in get
    template_variables=session.document.template_variables)
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/embed/server.py", line 231, in server_html_page_for_session
    return html_page_for_render_items(bundle, {}, render_items, title, template=template, template_variables=template_variables)
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/embed/util.py", line 147, in html_page_for_render_items
    script = bundle_all_models()
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 514, in bundle_all_models
    _bundle_cache[key] = bundle = bundle_models(Model.model_class_reverse_map.values()) or ""
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 400, in bundle_models
    compiled = nodejs_compile(impl.code, lang=impl.lang, file=impl.file)
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 189, in nodejs_compile
    output = _run_nodejs([compilejs_script], dict(code=code, lang=lang, file=file))
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 168, in _run_nodejs
    return _run(_nodejs_path(), argv, input)
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 149, in _nodejs_path
    _nodejs = _detect_nodejs()
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 141, in _detect_nodejs
    '("conda install nodejs" or follow https://nodejs.org/en/download/)')
RuntimeError: node.js v6.10.0 or higher is needed to allow compilation of custom models ("conda install nodejs" or follow https://nodejs.org/en/download/)
2018-02-27 11:48:02,510 500 GET /bokehgui?bokeh-session-id=top_block (127.0.0.1) 71.08ms

Re: [Discuss-gnuradio] Playing with gr-bokehgui

Hello Marcus,

So, the Waterfall sink is a custom plot that the Bokeh does not provide by default. Because of this error and the warning, I think Bokeh v0.12.6 and the current recent version has significant API changes. I may need to look at it in detail. Is it fine if I look at it in this weekend?

For now, it would suggest you downgrade the Bokeh to version 0.12.6, and NodeJS version to v6.6? Those were the versions I tested everything with. Let me know if that solves the issue (temporarily). If you don't 

Thanks.

Regards,

Kartik Patel

On Tue, Feb 27, 2018 at 10:49 AM, Marcus D. Leech <mleech@ripnet.com> wrote:

On 02/27/2018 02:13 AM, Kartik Patel wrote:

Hello Marcus, 

During my testing, I think, I set the time.sleep function by try and error. I didn't check for different PC. I will update it after testing it on my too slow AWS may be. 

Also, this resize issue is because Bokeh stopped the support of resize feature. If you can, use Bokeh V0.12.6, and tornado v4.4. I have to Port the code to recent Bokeh version. 

Thanks for the extensive verifications. I will try to update the basic suggestions this weekend probably.

On Tue, Feb 27, 2018, 1:06 AM Marcus D. Leech <mleech@ripnet.com> wrote:

On 02/27/2018 01:25 AM, Marcus D. Leech wrote:

On 02/27/2018 12:15 AM, Kartik Patel wrote:

Hello Marcus,

Just for starters, make sure you have v3.7.12 of GNU Radio. In particular, your GR should contain the commit `3c989f9`. Also, make sure you select Bokeh GUI instead of QT GUI in Generate Options field in Options block. For Bokeh GUI we have a different `main()` function template that has necessary procedure to start the server and the stream.

Also, thank you very much for the suggestions about the vector plotter. In addition to the vector plotter, the Histogram plotter and BER curve are also in pipeline. I am too busy with several deadlines and projects. But I will try to incorporate the things as soon as possible (maybe in summer). Sorry for the loong promise! 

Let me know if you still have trouble working with the module.

Thanks.

Regards,

Kartik Patel

Thanks for the very-prompt response.  I know that you're probably very busy.

I managed to get to the point of GRC generating the correct startup code, with the "Bokeh GUI".  My repo was up-to-date, it's just that I hadn't actually built it.  Too many distractions...

But when I got to start now, I get:

Traceback (most recent call last):
  File "./top_block.py", line 153, in <module>
    main()
  File "./top_block.py", line 136, in main
    url = "http://localhost:" + port + "/bokehgui")
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/client/session.py", line 161, in push_session
    session.push(document)
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/client/session.py", line 370, in push
    raise IOError("Cannot push session document because we failed to connect to the server (to start the server, try the 'bokeh serve' command)")
IOError: Cannot push session document because we failed to connect to the server (to start the server, try the 'bokeh serve' command)

I can get past this error by setting a longer "time.sleep()" in the generated "main" -- I guess it takes a bit for the server to come up to a state where it can accept connections.

But now:

 File "./top_block.py", line 140, in main
    tb = top_block_cls(doc)
  File "./top_block.py", line 65, in __init__
    legend_list = legend_list)
  File "/usr/local/lib64/python2.7/site-packages/bokehgui/freq_sink_f.py", line 63, in initialize
    active_scroll = 'ywheel_zoom', )
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/figure.py", line 793, in figure
    return Figure(**kwargs)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/figure.py", line 149, in __init__
    tool_objs, tool_map = _process_tools_arg(self, opts.tools)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/helpers.py", line 530, in _process_tools_arg
    tool_obj = _tool_from_string(tool)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/helpers.py", line 467, in _tool_from_string
    raise ValueError("unexpected tool name '%s', %s tools are %s" % (name, text, nice_join(matches)))
ValueError: unexpected tool name 'resize', similar tools are reset

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

OK, so, I removed the reference to 'resize' in the default tools list.  Now, it's complaining about nodejs:

[mleech@laptop ~]$ ./top_block.py
Port is set to 5007

['bokeh', 'serve', '--port', '5007', '--allow-websocket-origin=*', '/usr/local/lib64/python2.7/site-packages/bokehgui/plots/bokehgui.py']
Port in main is 5007
Pid is 14986
2018-02-27 11:47:54,580 Starting Bokeh server version 0.12.14 (running on Tornado 4.5.3)
2018-02-27 11:47:54,583 Host wildcard '*' will allow connections originating from multiple (or possibly all) hostnames or IPs. Use non-wildcard values to restrict access explicitly
2018-02-27 11:47:54,594 Bokeh app running at: http://localhost:5007/bokehgui
2018-02-27 11:47:54,594 Starting Bokeh server with process id: 14986
2018-02-27 11:47:55,039 101 GET /bokehgui/ws?bokeh-protocol-version=1.0&bokeh-session-id=top_block (127.0.0.1) 2.38ms
2018-02-27 11:47:55,039 WebSocket connection opened
2018-02-27 11:47:55,045 ServerConnection created
INFO: Audio sink arch: alsa
/usr/lib/python2.7/site-packages/bokeh/client/session.py:316: UserWarning:

    !!!! PLEASE NOTE !!!!

The use of `session.loop_until_closed` and `push_session` to run Bokeh
application code outside a Bokeh server is **HIGHLY DISCOURAGED** for any real
use.

Running application code outside a Bokeh server with bokeh.client in this way
has (and always will have) several intrinsic drawbacks:

* Fast binary array transport is NOT available! Base64 fallback is much slower
* All network traffic is DOUBLED due to extra hop between client and server
* Server *and* client process must be running at ALL TIMES for callbacks to work
* App code run outside the Bokeh server is NOT SCALABLE behind a load balancer

The bokeh.client API is recommended to use ONLY for testing, or for customizing
individual sessions running in a full Bokeh server, before passing on to viewers.

For information about different ways of running apps in a Bokeh server, see:

    http://bokeh.pydata.org/en/latest/docs/user_guide/server.html

  warnings.warn(_BOKEH_CLIENT_APP_WARNING_FULL)
2018-02-27 11:48:02,506 Uncaught exception GET /bokehgui?bokeh-session-id=top_block (127.0.0.1)
HTTPServerRequest(protocol='http', host='localhost:5006', method='GET', uri='/bokehgui?bokeh-session-id=top_block', version='HTTP/1.1', remote_ip='127.0.0.1', headers={'Accept-Language': 'en-US,en;q=0.5', 'Accept-Encoding': 'gzip, deflate', 'Host': 'localhost:5006', 'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 'User-Agent': 'Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0', 'Connection': 'keep-alive'})
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/tornado/web.py", line 1512, in _execute
    result = yield result
  File "/usr/lib64/python2.7/site-packages/tornado/gen.py", line 1055, in run
    value = future.result()
  File "/usr/lib64/python2.7/site-packages/tornado/concurrent.py", line 238, in result
    raise_exc_info(self._exc_info)
  File "/usr/lib64/python2.7/site-packages/tornado/gen.py", line 1069, in run
    yielded = self.gen.send(value)
  File "/usr/lib/python2.7/site-packages/bokeh/server/views/doc_handler.py", line 26, in get
    template_variables=session.document.template_variables)
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/embed/server.py", line 231, in server_html_page_for_session
    return html_page_for_render_items(bundle, {}, render_items, title, template=template, template_variables=template_variables)
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/embed/util.py", line 147, in html_page_for_render_items
    script = bundle_all_models()
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 514, in bundle_all_models
    _bundle_cache[key] = bundle = bundle_models(Model.model_class_reverse_map.values()) or ""
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 400, in bundle_models
    compiled = nodejs_compile(impl.code, lang=impl.lang, file=impl.file)
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 189, in nodejs_compile
    output = _run_nodejs([compilejs_script], dict(code=code, lang=lang, file=file))
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 168, in _run_nodejs
    return _run(_nodejs_path(), argv, input)
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 149, in _nodejs_path
    _nodejs = _detect_nodejs()
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 141, in _detect_nodejs
    '("conda install nodejs" or follow https://nodejs.org/en/download/)')
RuntimeError: node.js v6.10.0 or higher is needed to allow compilation of custom models ("conda install nodejs" or follow https://nodejs.org/en/download/)
2018-02-27 11:48:02,510 500 GET /bokehgui?bokeh-session-id=top_block (127.0.0.1) 71.08ms

Re: [Discuss-gnuradio] Regarding high radar cross-section area in gr-radar simulation

Hah yeah,

I just realized that too. However, this is what we're dealing with in
the radar world. We compensate high attenuations by high processing
gains. I'm still looking at the simulations, and will see if we can get
more realistic values in there.

-- M

On 02/27/2018 11:10 AM, suraj hanchinal wrote:
> Yes, I forgot to mention that. But even if that is done. That eventually
> only decreases the numerator. And further reduces the scaling factor.
>
> regards,
> Suraj Hanchinal
>
> On Wed, Feb 28, 2018 at 12:37 AM, Martin Braun <martin.braun@ettus.com
> <mailto:martin.braun@ettus.com>> wrote:
>
> On 02/27/2018 09:54 AM, suraj hanchinal wrote:
> > Hello everyone,
> > I was looking through the code of the gr-radar toolbox because I was
> > thinking about contributing to this toolbox for GSoc 18. I noticed the
> > high radar cross-section area for the simulations. This was also pointed
> > out by Martin Braun in is talk about the toolbox in FOSDEM 18. I was
> > thinking about a possible solution but turns out it is not possible due
> > to the high center frequency chosen in the simulation and the inverse
> > square dependency on it. Unless the cross section area is very large,
> > the simulated reflected signal is very weak. Can there be any other
> > solution except maybe changing the point-scatter model. I would request
> > Martin Braun Stefan Waunch to please also look into this..
>
> I'm currently working on this code and I think it's a bug -- The speed
> of light should have been sqrt()'d but wasn't.
>
> -- M
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> <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] Regarding high radar cross-section area in gr-radar simulation

On 02/27/2018 09:54 AM, suraj hanchinal wrote:
> Hello everyone,
> I was looking through the code of the gr-radar toolbox because I was
> thinking about contributing to this toolbox for GSoc 18. I noticed the
> high radar cross-section area for the simulations. This was also pointed
> out by Martin Braun in is talk about the toolbox in FOSDEM 18. I was
> thinking about a possible solution but turns out it is not possible due
> to the high center frequency chosen in the simulation and the inverse
> square dependency on it. Unless the cross section area is very large,
> the simulated reflected signal is very weak. Can there be any other
> solution except maybe changing the point-scatter model. I would request
> Martin Braun Stefan Waunch to please also look into this..

I'm currently working on this code and I think it's a bug -- The speed
of light should have been sqrt()'d but wasn't.

-- M

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

[Discuss-gnuradio] Regarding high radar cross-section area in gr-radar simulation

Hello everyone,

I was looking through the code of the gr-radar toolbox because I was thinking about contributing to this toolbox for GSoc 18. I noticed the high radar cross-section area for the simulations. This was also pointed out by Martin Braun in is talk about the toolbox in FOSDEM 18. I was thinking about a possible solution but turns out it is not possible due to the high center frequency chosen in the simulation and the inverse square dependency on it. Unless the cross section area is very large, the simulated reflected signal is very weak. Can there be any other solution except maybe changing the point-scatter model. I would request Martin Braun Stefan Waunch to please also look into this..

Regards,

Suraj Hanchinal  

Re: [Discuss-gnuradio] Playing with gr-bokehgui

On 02/27/2018 02:13 AM, Kartik Patel wrote:

Hello Marcus, 

During my testing, I think, I set the time.sleep function by try and error. I didn't check for different PC. I will update it after testing it on my too slow AWS may be. 

Also, this resize issue is because Bokeh stopped the support of resize feature. If you can, use Bokeh V0.12.6, and tornado v4.4. I have to Port the code to recent Bokeh version. 

Thanks for the extensive verifications. I will try to update the basic suggestions this weekend probably.

On Tue, Feb 27, 2018, 1:06 AM Marcus D. Leech <mleech@ripnet.com> wrote:

On 02/27/2018 01:25 AM, Marcus D. Leech wrote:

On 02/27/2018 12:15 AM, Kartik Patel wrote:

Hello Marcus,

Just for starters, make sure you have v3.7.12 of GNU Radio. In particular, your GR should contain the commit `3c989f9`. Also, make sure you select Bokeh GUI instead of QT GUI in Generate Options field in Options block. For Bokeh GUI we have a different `main()` function template that has necessary procedure to start the server and the stream.

Also, thank you very much for the suggestions about the vector plotter. In addition to the vector plotter, the Histogram plotter and BER curve are also in pipeline. I am too busy with several deadlines and projects. But I will try to incorporate the things as soon as possible (maybe in summer). Sorry for the loong promise! 

Let me know if you still have trouble working with the module.

Thanks.

Regards,

Kartik Patel

Thanks for the very-prompt response.  I know that you're probably very busy.

I managed to get to the point of GRC generating the correct startup code, with the "Bokeh GUI".  My repo was up-to-date, it's just that I hadn't actually built it.  Too many distractions...

But when I got to start now, I get:

Traceback (most recent call last):
  File "./top_block.py", line 153, in <module>
    main()
  File "./top_block.py", line 136, in main
    url = "http://localhost:" + port + "/bokehgui")
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/client/session.py", line 161, in push_session
    session.push(document)
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/client/session.py", line 370, in push
    raise IOError("Cannot push session document because we failed to connect to the server (to start the server, try the 'bokeh serve' command)")
IOError: Cannot push session document because we failed to connect to the server (to start the server, try the 'bokeh serve' command)

I can get past this error by setting a longer "time.sleep()" in the generated "main" -- I guess it takes a bit for the server to come up to a state where it can accept connections.

But now:

 File "./top_block.py", line 140, in main
    tb = top_block_cls(doc)
  File "./top_block.py", line 65, in __init__
    legend_list = legend_list)
  File "/usr/local/lib64/python2.7/site-packages/bokehgui/freq_sink_f.py", line 63, in initialize
    active_scroll = 'ywheel_zoom', )
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/figure.py", line 793, in figure
    return Figure(**kwargs)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/figure.py", line 149, in __init__
    tool_objs, tool_map = _process_tools_arg(self, opts.tools)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/helpers.py", line 530, in _process_tools_arg
    tool_obj = _tool_from_string(tool)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/helpers.py", line 467, in _tool_from_string
    raise ValueError("unexpected tool name '%s', %s tools are %s" % (name, text, nice_join(matches)))
ValueError: unexpected tool name 'resize', similar tools are reset

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

OK, so, I removed the reference to 'resize' in the default tools list.  Now, it's complaining about nodejs:

[mleech@laptop ~]$ ./top_block.py
Port is set to 5007

['bokeh', 'serve', '--port', '5007', '--allow-websocket-origin=*', '/usr/local/lib64/python2.7/site-packages/bokehgui/plots/bokehgui.py']
Port in main is 5007
Pid is 14986
2018-02-27 11:47:54,580 Starting Bokeh server version 0.12.14 (running on Tornado 4.5.3)
2018-02-27 11:47:54,583 Host wildcard '*' will allow connections originating from multiple (or possibly all) hostnames or IPs. Use non-wildcard values to restrict access explicitly
2018-02-27 11:47:54,594 Bokeh app running at: http://localhost:5007/bokehgui
2018-02-27 11:47:54,594 Starting Bokeh server with process id: 14986
2018-02-27 11:47:55,039 101 GET /bokehgui/ws?bokeh-protocol-version=1.0&bokeh-session-id=top_block (127.0.0.1) 2.38ms
2018-02-27 11:47:55,039 WebSocket connection opened
2018-02-27 11:47:55,045 ServerConnection created
INFO: Audio sink arch: alsa
/usr/lib/python2.7/site-packages/bokeh/client/session.py:316: UserWarning:

    !!!! PLEASE NOTE !!!!

The use of `session.loop_until_closed` and `push_session` to run Bokeh
application code outside a Bokeh server is **HIGHLY DISCOURAGED** for any real
use.

Running application code outside a Bokeh server with bokeh.client in this way
has (and always will have) several intrinsic drawbacks:

* Fast binary array transport is NOT available! Base64 fallback is much slower
* All network traffic is DOUBLED due to extra hop between client and server
* Server *and* client process must be running at ALL TIMES for callbacks to work
* App code run outside the Bokeh server is NOT SCALABLE behind a load balancer

The bokeh.client API is recommended to use ONLY for testing, or for customizing
individual sessions running in a full Bokeh server, before passing on to viewers.

For information about different ways of running apps in a Bokeh server, see:

    http://bokeh.pydata.org/en/latest/docs/user_guide/server.html

  warnings.warn(_BOKEH_CLIENT_APP_WARNING_FULL)
2018-02-27 11:48:02,506 Uncaught exception GET /bokehgui?bokeh-session-id=top_block (127.0.0.1)
HTTPServerRequest(protocol='http', host='localhost:5006', method='GET', uri='/bokehgui?bokeh-session-id=top_block', version='HTTP/1.1', remote_ip='127.0.0.1', headers={'Accept-Language': 'en-US,en;q=0.5', 'Accept-Encoding': 'gzip, deflate', 'Host': 'localhost:5006', 'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 'User-Agent': 'Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0', 'Connection': 'keep-alive'})
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/tornado/web.py", line 1512, in _execute
    result = yield result
  File "/usr/lib64/python2.7/site-packages/tornado/gen.py", line 1055, in run
    value = future.result()
  File "/usr/lib64/python2.7/site-packages/tornado/concurrent.py", line 238, in result
    raise_exc_info(self._exc_info)
  File "/usr/lib64/python2.7/site-packages/tornado/gen.py", line 1069, in run
    yielded = self.gen.send(value)
  File "/usr/lib/python2.7/site-packages/bokeh/server/views/doc_handler.py", line 26, in get
    template_variables=session.document.template_variables)
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/embed/server.py", line 231, in server_html_page_for_session
    return html_page_for_render_items(bundle, {}, render_items, title, template=template, template_variables=template_variables)
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/embed/util.py", line 147, in html_page_for_render_items
    script = bundle_all_models()
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 514, in bundle_all_models
    _bundle_cache[key] = bundle = bundle_models(Model.model_class_reverse_map.values()) or ""
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 400, in bundle_models
    compiled = nodejs_compile(impl.code, lang=impl.lang, file=impl.file)
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 189, in nodejs_compile
    output = _run_nodejs([compilejs_script], dict(code=code, lang=lang, file=file))
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 168, in _run_nodejs
    return _run(_nodejs_path(), argv, input)
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 149, in _nodejs_path
    _nodejs = _detect_nodejs()
  File "/usr/lib/python2.7/site-packages/bokeh/util/compiler.py", line 141, in _detect_nodejs
    '("conda install nodejs" or follow https://nodejs.org/en/download/)')
RuntimeError: node.js v6.10.0 or higher is needed to allow compilation of custom models ("conda install nodejs" or follow https://nodejs.org/en/download/)
2018-02-27 11:48:02,510 500 GET /bokehgui?bokeh-session-id=top_block (127.0.0.1) 71.08ms

[Discuss-gnuradio] An Old Idea for GSoC 2018

Hi all,

I am a graduate student at Technische Universitat Darmstadt, Germany, majoring in signal processing for wireless communication. I am originally form India and did my bachelors there. I haven't heard about GNU Radio until a few months back and I regret for that, as I had more time in my undergrad and now graduate study is quite intense.

But still I managed to play with GR for few months now and also trying to build a block for carrier sync for OQPSK signals.

I saw MIMO transceiver idea in the GSoCOldIdeas page and I found it interesting and it suits me. I have done projects on solving problems in MIMO networks but the works were purely theoretical and simulation based. So I am eager to try out MIMO stuffs with hardware. As mentioned in the idea, I too feel that it would be nice for beginners to enjoy the effect of MIMO practically for a better understanding of the subject. So a standard gr-mimo module with a simple MRC decoder and a multi user beamforming encoder would do the job.

I further saw some discussion in the mailing list from 2014 regarding the same idea, and there were concerns (by Micheal Dickens) about the feasibility and practical difficulties in implementation as 3 months would not be sufficient. I am a bit confused as I think 3 months would be sufficient to implement the stuffs mentioned in the idea, or may be I am missing something here. I even saw Alick Zhoa and some others saying that they had already implemented 2x2 MIMO system in GR without OFDM but might have got obsolete. 

However it has been few years since then and I hope someone could give more insight on implementing a practical MIMO transceiver and difficulties in it.

So my concerns are

• I would be glad if someone could explain the possible difficulties in implementing a practical 2x2 MIMO system in GNU Radio and with USRPs
• Considering the difficulties, is it doable in a span of 3 months?
• If someone had already worked on similar stuffs, their help would be appreciated.
• Will the standard MIMO module (gr-mimo) be really beneficial to the project? If not, I would rather work on it at my leisure than for GSoC as the idea would be less likely to be accepted.

Regarding the hardware, my university laboratory has several USRPs and I can use them.

Best regards,

Sakthivel Velumani

Re: [Discuss-gnuradio] Playing with gr-bokehgui

Hello Marcus, 

During my testing, I think, I set the time.sleep function by try and error. I didn't check for different PC. I will update it after testing it on my too slow AWS may be. 

Also, this resize issue is because Bokeh stopped the support of resize feature. If you can, use Bokeh V0.12.6, and tornado v4.4. I have to Port the code to recent Bokeh version. 

Thanks for the extensive verifications. I will try to update the basic suggestions this weekend probably.

On Tue, Feb 27, 2018, 1:06 AM Marcus D. Leech <mleech@ripnet.com> wrote:

On 02/27/2018 01:25 AM, Marcus D. Leech wrote:

On 02/27/2018 12:15 AM, Kartik Patel wrote:

Hello Marcus,

Just for starters, make sure you have v3.7.12 of GNU Radio. In particular, your GR should contain the commit `3c989f9`. Also, make sure you select Bokeh GUI instead of QT GUI in Generate Options field in Options block. For Bokeh GUI we have a different `main()` function template that has necessary procedure to start the server and the stream.

Also, thank you very much for the suggestions about the vector plotter. In addition to the vector plotter, the Histogram plotter and BER curve are also in pipeline. I am too busy with several deadlines and projects. But I will try to incorporate the things as soon as possible (maybe in summer). Sorry for the loong promise! 

Let me know if you still have trouble working with the module.

Thanks.

Regards,

Kartik Patel

Thanks for the very-prompt response.  I know that you're probably very busy.

I managed to get to the point of GRC generating the correct startup code, with the "Bokeh GUI".  My repo was up-to-date, it's just that I hadn't actually built it.  Too many distractions...

But when I got to start now, I get:

Traceback (most recent call last):
  File "./top_block.py", line 153, in <module>
    main()
  File "./top_block.py", line 136, in main
    url = "http://localhost:" + port + "/bokehgui")
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/client/session.py", line 161, in push_session
    session.push(document)
  File "/usr/lib/python2.7/site-packages/bokeh/util/api.py", line 190, in wrapper
    return obj(*args, **kw)
  File "/usr/lib/python2.7/site-packages/bokeh/client/session.py", line 370, in push
    raise IOError("Cannot push session document because we failed to connect to the server (to start the server, try the 'bokeh serve' command)")
IOError: Cannot push session document because we failed to connect to the server (to start the server, try the 'bokeh serve' command)

I can get past this error by setting a longer "time.sleep()" in the generated "main" -- I guess it takes a bit for the server to come up to a state where it can accept connections.

But now:

 File "./top_block.py", line 140, in main
    tb = top_block_cls(doc)
  File "./top_block.py", line 65, in __init__
    legend_list = legend_list)
  File "/usr/local/lib64/python2.7/site-packages/bokehgui/freq_sink_f.py", line 63, in initialize
    active_scroll = 'ywheel_zoom', )
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/figure.py", line 793, in figure
    return Figure(**kwargs)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/figure.py", line 149, in __init__
    tool_objs, tool_map = _process_tools_arg(self, opts.tools)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/helpers.py", line 530, in _process_tools_arg
    tool_obj = _tool_from_string(tool)
  File "/usr/lib/python2.7/site-packages/bokeh/plotting/helpers.py", line 467, in _tool_from_string
    raise ValueError("unexpected tool name '%s', %s tools are %s" % (name, text, nice_join(matches)))
ValueError: unexpected tool name 'resize', similar tools are reset

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