|
| From: | chandan kumar |
| Subject: | Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 155, Issue 40 |
| Date: | Sat, 31 Oct 2015 10:20:24 +0530 |
Send Discuss-gnuradio mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Re: DBPSK and USRPs (Richard Bell)
2. Re: Error when running GRC (Nemanja Savic)
3. Has anyone implemented your own module into real hardware? (Jeon)
4. Re: forecast and general work function (Marcus M?ller)
5. Re: Error when running GRC (Marcus M?ller)
6. Re: Python block with vector input and vector output
(Marcus M?ller)
7. Is there an alternative of sending message upstream?
(ratnesh kumbhkar)
8. Re: Has anyone implemented your own module into real
hardware? (john)
9. out-of-tree module development on mac (chandan kumar)
10. Re: Is there an alternative of sending message upstream?
(Johannes Demel)
11. Re: Python block with vector input and vector output
(Marcus M?ller)
12. Re: Error when running GRC (Nemanja Savic)
13. Re: Error when running GRC (Marcus M?ller)
14. Re: out-of-tree module development on mac (Michael Dickens)
----------------------------------------------------------------------
Message: 1
Date: Thu, 29 Oct 2015 09:04:20 -0700
From: Richard Bell <address@hidden>
To: "Marcus D. Leech" <address@hidden>
Cc: discuss-gnuradio-bounces+mleech=address@hidden, GNURadio
Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] DBPSK and USRPs
Message-ID:
<CAMMoi3t+71c+Jh4KP66S=address@hidden>
Content-Type: text/plain; charset="utf-8"
Hey Logan,
There are sum fundamental principals I think you're overlooking when you
say "the Rx side still looks very noisy". You cannot just pipe the output
of the USRP into a sink and expect to get anywhere near a perfect
constellation ever. There are a lot of effects that need to be fixed before
a perfect constellation exists. The DPSK Demod block is supposed to do
these things for you. But only after this block should you expect to see
anything you're used to seeing. Out of the USRP, all bets are off.
I still don't see a Tx side constellation that looks correct. And I
emphasize to you that until you get a perfect BPSK constellation plot on
the Tx side, don't debug the Rx side. One because you could waste your time
trying to fix a problem on the Rx that exists on the Tx. Two, because if
you don't have the understanding needed to make the Tx work, you don't have
much hope with the Rx.
You shouldn't just be decimating into the constellation on the Tx side.
It's true that I said that in the previous email, but I assumed you knew
what I really meant. You should be aware that pulse shaping has occurred in
the DPSK Mod block using a root raised cosine. If you don't undue this,
your Tx constellation is going to look very noisy, not because it is, but
because it's been shaped. To do the decimation on the Tx side that feeds
into the Constellation sink, you should use a root raised cosine filter to
undue the shaping. This will decimate for you as well. Going this route,
get two perfect BPSK constellation points to come out.
v/r,
Rich
On Thu, Oct 29, 2015 at 8:48 AM, <address@hidden> wrote:
> Your center frequency is in the 2.4GHz WiFi band. So, yeah, you could be
> seeing lots of interference.
>
>
>
>
>
>
> On 2015-10-29 11:41, Washbourne, Logan wrote:
>
> So I decimated both sides, right in front of the constellation plots. The
> TX side looks a lot better, no zero groupings. The RX side still looks very
> noisy. Could this be a product of my environment?
>
> Logan Washbourne
> Electrical Engineering Graduate Student
> (Electromagnetics)
>
> On Tue, Oct 27, 2015 at 11:33 AM, Richard Bell <address@hidden>
> wrote:
>
>> To sanity check the transmitter, instead of showing the constellation of
>> every sample, show every other sample, i.e. decimate by 2 going into the
>> constellation plot. The two comes from the fact you use 2 samples/symbol.
>> We don't want to see the every sample on a constellation, only symbols.
>> That's why the transmitter block has the grouping it does. Once you've
>> confirmed you see the expected BPSK constellation, you can move on to the
>> receiver.
>>
>> On Tue, Oct 27, 2015 at 9:08 AM, <address@hidden> wrote:
>>
>>> Try cranking your RX gain up/down 5dB and see how that affects your
>>> constellation.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2015-10-27 11:55, Washbourne, Logan wrote:
>>>
>>> Ok, that sampling rate mismatch was my fault. The RX spectrum looks
>>> better after that fix. The unpacked to packed bits didn't seem to remove
>>> the zero grouping on the constellation plot. Here are pictures of the setup
>>> now.
>>>
>>>
>>>
>>> Logan Washbourne
>>> Electrical Engineering Graduate Student
>>> (Electromagnetics)
>>>
>>> On Tue, Oct 27, 2015 at 10:34 AM, Richard Bell <address@hidden>
>>> wrote:
>>>
>>>> Logan, make sure you're feeding packed bytes into the DPSK Mod block.
>>>> That's probably why you're seeing a constellation point at zero, you're
>>>> feeding in unpacked bytes. That might fix everything.
>>>>
>>>> Rich
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Oct 27, 2015, at 8:16 AM, address@hidden wrote:
>>>>
>>>> What does the spectral plot look like? It should look very similar to
>>>> the TX side of the house.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 2015-10-27 11:10, Washbourne, Logan wrote:
>>>>
>>>> Thanks for the info guys! They are both using antennas btw. I came in
>>>> this morning and turned the RX gain up pretty high, roughly 45dB, and the
>>>> constellation plot on the RX side is starting to look pretty square, which
>>>> I think is a bad sign. My thoughts are that with the increase in gain,
>>>> there is too much noise coming through.
>>>>
>>>> I've been toying with adding in a frequency offset on the TX side. I've
>>>> been adding and subtracting up to 30kHz from the center frequency and I
>>>> haven't seen any improvement in the constellation plot on the RX side.
>>>>
>>>> Another thing that is confusing me, on the TX constellation plot,
>>>> before it gets sent to the USRP, there are 3 groupings, -.5, 0, .5. I'm not
>>>> sure where the 0 points are coming from. Since this is DBPSK, there should
>>>> only be -.5 and .5 groupings right?
>>>>
>>>> Should this exercise be pretty straightforward?
>>>>
>>>> Logan Washbourne
>>>> Electrical Engineering Graduate Student
>>>> (Electromagnetics)
>>>>
>>>> On Mon, Oct 26, 2015 at 3:12 PM, <address@hidden> wrote:
>>>>
>>>>> Consulting now, the book of armaments, errr, UHD manual:
>>>>>
>>>>>
>>>>>
>>>>> http://files.ettus.com/manual/page_dboards.html#dboards_rfx
>>>>>
>>>>>
>>>>>
>>>>> The RFX series has no TX RF gain control, output magnitude is entirely
>>>>> dependent on baseband magnitude.
>>>>>
>>>>> There's 70dB of gain range on RX, however. So, crank up the RX gain.
>>>>>
>>>>> Also, across 1m, the path loss is about 40dB at 2.5GHz, your TX is
>>>>> probably putting out 5dBm, so at the RX end, that's maybe as much as
>>>>> -35dBm. If your RX is set properly, should be enough to see the signal.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2015-10-26 15:46, Marcus M?ller wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> * looking at your constellation, relief comes setting in: It looks
>>>>> pretty circular to me; notice how the axes are scaled differently. So no
>>>>> catastrophic IQ imbalance.
>>>>> * the fact that it's circular and not a line is probably the result of
>>>>> the constellation sink not being able to achieve timing synchronization,
>>>>> i.e. it doesn't "know" when a symbol starts
>>>>> * You're right, RX SNR is terrible. However, RX power is very little
>>>>> indeed
>>>>> * Rule of thumb: if(not clipping && in doubt) increase gain;
>>>>> * What exactly is your "RF channel": antennas, direct cable with
>>>>> attenuator?
>>>>> * The mistake I do every few months: Did you connect the
>>>>> antenna/cable to the wrong SMA port?
>>>>>
>>>>> Best regards,
>>>>> Marcus
>>>>> On 26.10.2015 20:33, Washbourne, Logan wrote:
>>>>>
>>>>> I looked at the spectrums of both sides and the RX side looks to be
>>>>> inundated with a lot of noise. I'm not sure if its my environment or my
>>>>> USRPs, but I really expected to see some resemblance of a signal. I am
>>>>> posting links to screencaps of the TX and RX sides.
>>>>>
>>>>> http://imgur.com/GBTHw8T- TX
>>>>> http://imgur.com/DBy8gqs - RX
>>>>>
>>>>> Logan Washbourne
>>>>> Electrical Engineering Graduate Student
>>>>> (Electromagnetics)
>>>>>
>>>>> On Mon, Oct 26, 2015 at 1:31 PM, Marcus M?ller <
>>>>> address@hidden> wrote:
>>>>>
>>>>>> Can you compare the TX spectrum with the RX spectrum? Maybe it'd
>>>>>> worthwhile to first look at at e.g. 500kHz of RX spectrum to see whether,
>>>>>> due to frequency offset, some of the wanted signal simply gets cut off;
>>>>>> admittedly, with 2S/sym that's not too likely...
>>>>>>
>>>>>> Best regards,
>>>>>> Marcus
>>>>>>
>>>>>>
>>>>>> On 26.10.2015 19:16, Washbourne, Logan wrote:
>>>>>>
>>>>>> I am using 250k!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Logan Washbourne
>>>>>> Electrical Engineering Graduate Student
>>>>>> (Electromagnetics)
>>>>>>
>>>>>> On Mon, Oct 26, 2015 at 1:05 PM, Marcus M?ller <
>>>>>> address@hidden> wrote:
>>>>>>
>>>>>>> Hello!
>>>>>>> what's the sampling rate you're using?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Marcus
>>>>>>>
>>>>>>>
>>>>>>> On 26.10.2015 18:38, Washbourne, Logan wrote:
>>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I'm trying to take a step back from my previous postings and try a
>>>>>>> simple approach to try and understand working with over the air
>>>>>>> communications with the USRPs. Let me know if it would be better to post
>>>>>>> this in the USRPs-Users list.
>>>>>>>
>>>>>>> I'm trying to have a simple TX and simple RX side so I can eliminate
>>>>>>> and unnecessary complications.
>>>>>>>
>>>>>>> The TX side has the following flowgraph: Vector
>>>>>>> Source(preamble+data)->DPSK Mod(DBPSK,2samples/symbol)-> Multiply
>>>>>>> Const(.707) -> UHD:USRP SINK(2.448GHz center freq, 10dB default gain)
>>>>>>>
>>>>>>> RX Side: UHD:USRP Source(2.448GHz center freq, 10dB gain default) ->
>>>>>>> DPSK DEMOD(DBPSK, 2 samples/ symbol, rest default values) - > file sink
>>>>>>>
>>>>>>> I'm checking the progress of the communication by looking at a
>>>>>>> constellation plot that is connected directly to the USRP SOURCE block on
>>>>>>> the receiver side. I'm getting a very elliptical shape, more spread out in
>>>>>>> the horizontal direction but not by much. I'm also looking at the bits from
>>>>>>> the receiver side in matlab and my preamble is not showing up.
>>>>>>>
>>>>>>> These were the same problems I had when trying to use a correlated
>>>>>>> system for OTA communications. I feel like I'm missing something really
>>>>>>> simple.
>>>>>>>
>>>>>>> Does anyone know of a simple TX, RX grc setup that I can use to test
>>>>>>> my USRPs?
>>>>>>>
>>>>>>> Again, I really appreciate the help you guys give.
>>>>>>>
>>>>>>> Logan Washbourne
>>>>>>> Electrical Engineering Graduate Student
>>>>>>> (Electromagnetics)
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Discuss-gnuradio mailing address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Discuss-gnuradio mailing list
>>>>>>> address@hidden
>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Discuss-gnuradio mailing address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Discuss-gnuradio mailing list
>>>>>> address@hidden
>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>> address@hidden
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
> _______________________________________________
> Discuss-gnuradio mailing address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151029/cf5a5d43/attachment.html>
------------------------------
Message: 2
Date: Thu, 29 Oct 2015 17:46:56 +0100
From: Nemanja Savic <address@hidden>
To: Marcus M?ller <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Error when running GRC
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Hello,
well Marcus, you were right (like usual) ...
I don't know what exactly problem was, but concerning GRC, it looks like in
my first attempt to buld sphinx executable couldn't be found.
As for the min test, it doesn't work, it just stays blocked, no particular
output.
I tried GRC and it worked. What was strange for me is that flowchart was
not terminated when I closed QT scope.
Best,
Nemanja
On Mon, Oct 26, 2015 at 6:19 PM, Marcus M?ller <address@hidden>
wrote:
> First, try to run the test in isolation:
> in your build/ directory,
>
> ctest -V -R min
>
> should run your test alone. If that doesn't give you additional insight,
> try running
> ./gr-blocks/python/blocks/qa_min_test.sh
> directly.
>
> You should also inspect the reason GRC core dumps, there's a small wiki
> page for that [1]; but to be completely honest: qa_min failing and GRC
> segfaulting sounds like there's some mismatch between the libraries used at
> build time and the libraries loaded at run time, in my experience.
>
> Best regards,
> Marcus
>
> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
>
> On 26.10.2015 11:42, Nemanja Savic wrote:
>
> Hi,
>
> as for the test, I didn't copy correct lines. My test literally blocks in
> test 11 and never get out of that.
> test 11
> Start 11: qa_min
>
> 11: Test command: /bin/sh
> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/python/blocks/qa_min_test.sh"
> 11: Test timeout computed to be: 9.99988e+06
>
> Yes, when I remove keyword argument it finishes with core dumped.
> No, my previous Gnuradio installation is there, but with another prefix.
> My machine runs on RHEL6, so can't really change python cause, it makes a
> lot of trouble with administrators.
>
> How can I trace more what cases this error. Few days ago I built gnuradio
> usinc anaconda python, but had some issues with graphics and then I moved
> back to my native python.
>
> Nemanja
>
>
> On Mon, Oct 26, 2015 at 10:23 AM, Marcus M?ller <address@hidden>
> wrote:
>
>> Hi,
>> I think this is what that test is supposed to look like, so reading that
>> is a good sign!
>> You say you get a segfault when running GRC, right? That's a bit
>> surprising, because GRC is pure Python, so it's probably something that
>> gets loaded along the way. Have you uninstalled your previous GNU Radio
>> installation?
>> By the way, I thought pre-2.7 Python was practically extinct; out of
>> curiosity: which OS are you on?
>>
>> Best regards,
>> Marcus
>>
>>
>> Am 26. Oktober 2015 09:10:04 MEZ, schrieb Nemanja Savic <
>> <address@hidden>address@hidden>:
>>>
>>> Hello,
>>>
>>> I use Python 2.6.6.
>>> When I make suggested change I got Segmentation Fault error.
>>> I don't know if it is connected with this, but when I run test, it
>>> blocks in test n. 10. with this output:
>>>
>>> 10: Test command: /bin/sh
>>> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/lib/test_gr_blocks_test.sh"
>>> 10: Test timeout computed to be: 9.99988e+06
>>> 10:
>>> 10: NOTE: This is supposed to produce an error from block_executor
>>> 10: Error: block_executor: propagation_policy 'ONE-TO-ONE' requires
>>> ninputs == noutputs
>>> 10: ........Using Volk machine: avx_64_mmx_orc
>>> 10: ......................
>>> 10:
>>> 10/170 Test #10: test_gr_blocks ....................... Passed
>>> 0.86 sec
>>> test 11
>>> Start 11: qa_min
>>>
>>>
>>> Can these two be connected?
>>>
>>> Nemanja
>>>
>>> On Mon, Oct 26, 2015 at 2:25 AM, Marcus M?ller <
>>> <address@hidden>address@hidden> wrote:
>>>
>>>> Hi!
>>>>
>>>> First intuition is that there might be something wrong with the Python
>>>> version in use. Which is it? Python pre-2.7 doesn't know the keyword
>>>> arguments, so it would have to read
>>>> .decode('utf-8','replace')
>>>> Instead of
>>>> .decode('utf-8',errors='replace')
>>>>
>>>> Cheetah is, as far as I know, not Python 3 compatible.
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>>
>>>> Am 26. Oktober 2015 01:46:09 MEZ, schrieb Nemanja Savic <
>>>> <address@hidden>address@hidden>:
>>>>
>>>>> Hi all guys,
>>>>>
>>>>> i built yesterday 3.7.8. When I wanted to run GRC the following error
>>>>> occured:
>>>>>
>>>>> Traceback (most recent call last):
>>>>> File "/scr1/nemanja/install/bin/gnuradio-companion", line 128, in
>>>>> <module>
>>>>> main()
>>>>> File "/scr1/nemanja/install/bin/gnuradio-companion", line 121, in
>>>>> main
>>>>> ActionHandler(args, Platform())
>>>>> File
>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
>>>>> line 62, in __init__
>>>>> self.main_window = MainWindow(platform)
>>>>> File
>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/MainWindow.py",
>>>>> line 96, in __init__
>>>>> self.btwin = BlockTreeWindow(platform, self.get_flow_graph);
>>>>> File
>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>>>>> line 107, in __init__
>>>>> self.platform.load_block_tree(self)
>>>>> File
>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/base/Platform.py",
>>>>> line 228, in load_block_tree
>>>>> block_tree.add_block(block.get_category(), block)
>>>>> File
>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>>>>> line 144, in add_block
>>>>> treestore.set_value(iter, DOC_INDEX,
>>>>> Utils.parse_template(DOC_MARKUP_TMPL, doc=block.get_doc()))
>>>>> File
>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
>>>>> line 116, in parse_template
>>>>> return str(Template(tmpl_str, kwargs))
>>>>> File "/usr/lib64/python2.6/site-packages/Cheetah/Template.py", line
>>>>> 1003, in __str__
>>>>> rc = getattr(self, mainMethName)()
>>>>> File
>>>>> "cheetah_DynamicallyCompiledCheetahTemplate_1445820074_12_55642.py", line
>>>>> 83, in respond
>>>>> File
>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
>>>>> line 100, in encode
>>>>> valid_utf8 = value.decode('utf-8',
>>>>> errors='replace').encode('utf-8')
>>>>> TypeError: decode() takes no keyword arguments
>>>>>
>>>>>
>>>>> It looks like Cheetah problem but can't make it work. There was
>>>>> suggestion few years ago to remove errors='replace', but it didn't work for
>>>>> me.
>>>>>
>>>>> THanx
>>>>> --
>>>>> Nemanja Savi?
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Discuss-gnuradio mailing address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>>
>>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
> --
> Nemanja Savi?
>
>
--
Nemanja Savi?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151029/f2ad9745/attachment.html>
------------------------------
Message: 3
Date: Fri, 30 Oct 2015 02:34:34 +0900
From: Jeon <address@hidden>
To: Discuss GNU Radio mailing list <address@hidden>
Subject: [Discuss-gnuradio] Has anyone implemented your own module
into real hardware?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
I am sorry for posting some irrelevant question to GR, USRP nor programming.
Just curious.
No matter which applications, technologies, standards,
(Ham, GPS, cellular, Wi-Fi, customed RF Tx/Rx, etc.)
has anyone implemented your own module into real hardware?
That is, transforming GNU radio flow graph into chips and circuits?
As far as GNU Radio is concerned, we don't need to focus much on circuit
things.
We only need to focus on digital signal processing and logic/algorithm
design based on C++ and Python.
(Of course, some fundamental analog RF knowledge is required)
However, when hardware implementation is concerned, we would get new
challenges,
PCB design, looking for DSP chips (from TI, etc.).
Even worse, you have to design your chips, in some cases.
(But I think it may never happen since lots of chips have various purposes
and functionalities already)
It can be easier if you co-work with others with different fields of
knowledge (+ some basic and common backgrounds).
But if you are a one(or a few)-man team, getting a deep and wide knowledge
would be a great obstacle.
Thus, I'd like to hear your experiences, difficulties, challenges and
advices who have turned your GR module into a real machine.
Regards,
Jeon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151030/af87db75/attachment.html>
------------------------------
Message: 4
Date: Thu, 29 Oct 2015 19:44:35 +0100
From: Marcus M?ller <address@hidden>
To: address@hidden
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] forecast and general work function
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8
As mentioned, the stream-to-message-passing gr-eventstream approach is
right for you.
Best regards,
Marcus
On 10/29/2015 01:47 PM, address@hidden wrote:
> Thank you Marcus. I am trying to simulate a network with 2 transmitters and one receiver. The TX's transmit streams at random times and the RX receives the sum of the signals from both the TX's. The adder block however doesn't give any output when one of its input stream is empty (i.e. when both the inputs are not available at the same time) . That's why I'm trying to create an intermediate block for each TX that takes in an input and outputs zeros if the input is empty. This way the adder block would always have something to add. Thanks.
>
> Subrata
>
>> On Oct 28, 2015, at 17:36, Marcus M?ller <address@hidden> wrote:
>>
>> Hi Subrata,
>>
>> while what you plan to do is possible if you build a block with a
>> general_work method and a forecast. In fact, here the forecast
>> implementation will probably be pretty crucial, but also be pretty
>> simple -- just always require the same amount of samples from input0 as
>> you're asked to produce output, and don't require anything from input1.
>>
>> However, I'm pretty certain GNU Radio won't schedule your block as you
>> want to (in fact, I just wrote a minimal test case to verify[1]).
>>
>> My general recommendation would be to write a minimal block that takes a
>> stream and converts it to messages, and passes those to
>> gr-eventstream[2]. gr-eventstream has blocks to do exactly that: produce
>> a zero-signal when there's no (message) input, produce the content of
>> the message input otherwise; you could just take that output and add it
>> to your input1, and be done :)
>>
>> Best regards,
>> Marcus
>>
>>
>> [1] https://github.com/marcusmueller/gr-demo_assymetric_input clone, and
>> run ./qa_prioritizer.py in the python/ folder
>> [2] http://oshearesearch.com/tag/gr-eventstream/
>>> On 28.10.2015 21:26, address@hidden wrote:
>>> I am trying to create a block that has two input and one output. Its like a priority multiplexer; if input0 is empty then output = input1 else output = input0 ( input0 always has samples) its a stream based block.
>>> How do I declare the work function, because the number of samples needed from each input to produce noutput_items depends on whether input0 is empty.
>>> Any help in the general work function is also greatly appreciated.
>>>
>>> Thanks
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 5
Date: Thu, 29 Oct 2015 19:46:29 +0100
From: Marcus M?ller <address@hidden>
To: Nemanja Savic <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Error when running GRC
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi Nemanja,
> well Marcus, you were right (like usual) ...
ha! I wish that was true! Usually I'm not right, trust me.
> I tried GRC and it worked. What was strange for me is that flowchart
> was not terminated when I closed QT scope.
That's a bit surprising; you don't happen to have a .grc with which I
can recreate that?
Cheers,
Marcus
On 10/29/2015 05:46 PM, Nemanja Savic wrote:
> Hello,
>
> well Marcus, you were right (like usual) ...
> I don't know what exactly problem was, but concerning GRC, it looks
> like in my first attempt to buld sphinx executable couldn't be found.
> As for the min test, it doesn't work, it just stays blocked, no
> particular output.
>
> I tried GRC and it worked. What was strange for me is that flowchart
> was not terminated when I closed QT scope.
>
> Best,
> Nemanja
>
> On Mon, Oct 26, 2015 at 6:19 PM, Marcus M?ller
> <address@hidden <mailto:address@hidden>> wrote:
>
> First, try to run the test in isolation:
> in your build/ directory,
>
> ctest -V -R min
>
> should run your test alone. If that doesn't give you additional
> insight, try running
> ./gr-blocks/python/blocks/qa_min_test.sh
> directly.
>
> You should also inspect the reason GRC core dumps, there's a small
> wiki page for that [1]; but to be completely honest: qa_min
> failing and GRC segfaulting sounds like there's some mismatch
> between the libraries used at build time and the libraries loaded
> at run time, in my experience.
>
> Best regards,
> Marcus
>
> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
>
> On 26.10.2015 11:42, Nemanja Savic wrote:
>> Hi,
>>
>> as for the test, I didn't copy correct lines. My test literally
>> blocks in test 11 and never get out of that.
>> test 11
>> Start 11: qa_min
>>
>> 11: Test command: /bin/sh
>> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/python/blocks/qa_min_test.sh"
>> 11: Test timeout computed to be: 9.99988e+06
>>
>> Yes, when I remove keyword argument it finishes with core dumped.
>> No, my previous Gnuradio installation is there, but with another
>> prefix. My machine runs on RHEL6, so can't really change python
>> cause, it makes a lot of trouble with administrators.
>>
>> How can I trace more what cases this error. Few days ago I built
>> gnuradio usinc anaconda python, but had some issues with graphics
>> and then I moved back to my native python.
>>
>> Nemanja
>>
>>
>> On Mon, Oct 26, 2015 at 10:23 AM, Marcus M?ller
>> <address@hidden <mailto:address@hidden>> wrote:
>>
>> Hi,
>> I think this is what that test is supposed to look like, so
>> reading that is a good sign!
>> You say you get a segfault when running GRC, right? That's a
>> bit surprising, because GRC is pure Python, so it's probably
>> something that gets loaded along the way. Have you
>> uninstalled your previous GNU Radio installation?
>> By the way, I thought pre-2.7 Python was practically extinct;
>> out of curiosity: which OS are you on?
>>
>> Best regards,
>> Marcus
>>
>>
>> Am 26. Oktober 2015 09:10:04 MEZ, schrieb Nemanja Savic
>> <address@hidden <mailto:address@hidden>>:
>>
>> Hello,
>>
>> I use Python 2.6.6.
>> When I make suggested change I got Segmentation Fault error.
>> I don't know if it is connected with this, but when I run
>> test, it blocks in test n. 10. with this output:
>>
>> 10: Test command: /bin/sh
>> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/lib/test_gr_blocks_test.sh"
>> 10: Test timeout computed to be: 9.99988e+06
>> 10:
>> 10: NOTE: This is supposed to produce an error from
>> block_executor
>> 10: Error: block_executor: propagation_policy
>> 'ONE-TO-ONE' requires ninputs == noutputs
>> 10: ........Using Volk machine: avx_64_mmx_orc
>> 10: ......................
>> 10:
>> 10/170 Test #10: test_gr_blocks
>> ....................... Passed 0.86 sec
>> test 11
>> Start 11: qa_min
>>
>>
>> Can these two be connected?
>>
>> Nemanja
>>
>> On Mon, Oct 26, 2015 at 2:25 AM, Marcus M?ller
>> <address@hidden
>> <mailto:address@hidden>> wrote:
>>
>> Hi!
>>
>> First intuition is that there might be something
>> wrong with the Python version in use. Which is it?
>> Python pre-2.7 doesn't know the keyword arguments, so
>> it would have to read
>> .decode('utf-8','replace')
>> Instead of
>> .decode('utf-8',errors='replace')
>>
>> Cheetah is, as far as I know, not Python 3 compatible.
>>
>> Best regards,
>> Marcus
>>
>>
>> Am 26. Oktober 2015 01:46:09 MEZ, schrieb Nemanja
>> Savic <address@hidden <mailto:address@hidden>>:
>>
>> Hi all guys,
>>
>> i built yesterday 3.7.8. When I wanted to run GRC
>> the following error occured:
>>
>> Traceback (most recent call last):
>> File
>> "/scr1/nemanja/install/bin/gnuradio-companion",
>> line 128, in <module>
>> main()
>> File
>> "/scr1/nemanja/install/bin/gnuradio-companion",
>> line 121, in main
>> ActionHandler(args, Platform())
>> File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
>> line 62, in __init__
>> self.main_window = MainWindow(platform)
>> File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/MainWindow.py",
>> line 96, in __init__
>> self.btwin = BlockTreeWindow(platform,
>> self.get_flow_graph);
>> File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>> line 107, in __init__
>> self.platform.load_block_tree(self)
>> File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/base/Platform.py",
>> line 228, in load_block_tree
>> block_tree.add_block(block.get_category(), block)
>> File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>> line 144, in add_block
>> treestore.set_value(iter, DOC_INDEX,
>> Utils.parse_template(DOC_MARKUP_TMPL,
>> doc=block.get_doc()))
>> File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
>> line 116, in parse_template
>> return str(Template(tmpl_str, kwargs))
>> File
>> "/usr/lib64/python2.6/site-packages/Cheetah/Template.py",
>> line 1003, in __str__
>> rc = getattr(self, mainMethName)()
>> File
>> "cheetah_DynamicallyCompiledCheetahTemplate_1445820074_12_55642.py",
>> line 83, in respond
>> File
>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
>> line 100, in encode
>> valid_utf8 = value.decode('utf-8',
>> errors='replace').encode('utf-8')
>> TypeError: decode() takes no keyword arguments
>>
>>
>> It looks like Cheetah problem but can't make it
>> work. There was suggestion few years ago to
>> remove errors='replace', but it didn't work for me.
>>
>> THanx
>> --
>> Nemanja Savi?
>>
>> ------------------------------------------------------------------------
>>
>> Discuss-gnuradio mailing list
>> address@hidden <mailto:address@hidden>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> -- Sent from my Android device with K-9 Mail. Please
>> excuse my brevity.
>>
>> -- Sent from my Android device with K-9 Mail. Please excuse
>> my brevity.
>>
>> --
>> Nemanja Savi?
>
>
>
>
> --
> Nemanja Savi?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151029/fae405fe/attachment.html>
------------------------------
Message: 6
Date: Thu, 29 Oct 2015 20:04:06 +0100
From: Marcus M?ller <address@hidden>
To: Chad R <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Python block with vector input and
vector output
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi Chad,
thanks for re-posting your code; it's much clearer to read now.
I'm not quite sure what I'm looking at now: Is this your own
implementation of the yall1 minimization function, or something that can
be tested?
If I remember correctly, the matlab call has a matrix input, and a
"target" vector, and an options argument. Is there some accessible
documentation.
Other than my confusion whether this is a GNU Radio or a general yall1
question, your code looks pretty good. A few thing's I'd note:
* self.alpha.shape should be right
* check that input_items.shape and in0.shape are as you expect them
Best regards,
Marcus
On 10/29/2015 01:27 PM, Chad R wrote:
> Sorry. Something went wrong when I copied pasted it but my actual code is:
>
> import numpy
> from gnuradio import gr
> from yall1 import *
>
> class yall1_reconstruction_cc(gr.sync_block):
> """
> Yall1_reconstruction_block
> """
> def __init__(self,n,m):
> self.N = n
> self.M = m
> phi = np.load("/home/chad/Desktop/PROJECT/Python/Matrices/phi_mtx%(M)dx%(N)d.npy" %{"M":self.M,"N":self.N})
> psi = np.load("/home/chad/Desktop/PROJECT/Python/Matrices/psi_mtx%(N)dx%(N)d.npy" %{"N":self.N})
> self.alpha = np.dot(phi,psi)
> gr.sync_block.__init__(self,
> name="yall1_reconstruction",
> in_sig=[(np.complex64,self.M)],
> out_sig=[(np.complex64,self.N)])
>
> def work(self, input_items, output_items):
> in0 = input_items[0]
> size = np.shape(in0)[0]
> out = np.zeros((size,self.N),dtype = np.complex64)
> #out = yall1(self.alpha,in0[0]).reshape(self.N,)
> for i in range(0,size):
> recon = yall1(self.alpha, in0[i].reshape(self.M,1))*4.6
> out[i] = recon.reshape(self.N,)
> output_items[0][:] = out
> return len(output_items[0])
>
>
> On Thu, Oct 29, 2015 at 2:08 PM, Marcus M?ller
> <address@hidden <mailto:address@hidden>> wrote:
>
> Hi Chad,
>
> there's something wrong with the indention of the lines between
> "def __init__" and "g.sync_block", and the same goes for your work
> function; so that's my first stab at explaining misbehaviour.
>
>
> Best regards,
> Marcus
>
>
> On 29.10.2015 13:01, Chad R wrote:
>> Good day every one
>>
>> I have implemented a Python block but I am not getting the
>> results I expected. I get the results I expect at any
>> frequency=samp_rate/2^n where n is any integer. My block makes
>> use of a yall1 reconstruction algorithm to reconstruct a signal
>> from M=100 to N=1024 vector.
>> The code for my block is shown below:
>>
>> class yall1_reconstruction_cc(gr.sync_block):
>> """
>> Yall1_reconstruction_block
>> """
>> def __init__(self,n,m):
>> self.N = n
>> self.M = m
>> phi =
>> np.load("/home/chad/Desktop/PROJECT/Python/Matrices/phi_mtx%(M)dx%(N)d.npy"
>> %{"M":self.M,"N":self.N})
>> psi =
>> np.load("/home/chad/Desktop/PROJECT/Python/Matrices/psi_mtx%(N)dx%(N)d.npy"
>> %{"N":self.N})
>> self.alpha = np.dot(phi,psi)
>> gr.sync_block.__init__(self,
>> name="yall1_reconstruction",
>> in_sig=[(np.complex64,self.M)],
>> out_sig=[(np.complex64,self.N)])
>>
>> def work(self, input_items, output_items):
>> in0 = input_items[0]
>> size = np.shape(in0)[0]
>> out = np.zeros((size,self.N),dtype = np.complex64)
>> #out = yall1(self.alpha,in0[0]).reshape(self.N,)
>> for i in range(0,size):
>> recon = yall1(self.alpha, in0[i].reshape(self.M,1))*4.7
>> out[i] = recon.reshape(self.N,)
>> output_items[0][:] = out
>> return len(output_items[0])
>>
>> Have I implemented it right? or is my issue with my
>> implementation? I read through the tutorials but I feel some
>> aspects are quiet hard to follow.
>>
>> Thank you in advance for your help
>>
>> Chad Richs
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden <mailto:address@hidden>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden <mailto:address@hidden>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151029/dd3be38a/attachment.html>
------------------------------
Message: 7
Date: Thu, 29 Oct 2015 16:22:26 -0400
From: ratnesh kumbhkar <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Is there an alternative of sending message
upstream?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi all,
I am trying to make a receiver on gnuradio where one block '*A' *uses
dynamic "threshold" and this threshold is determined by another downstream
block *'B' *and is fed back to *'A'* as a message. I use "msg_connect" to
connect both message port. However there is considerable amount of delay
between "the time a change is made" to "the time that change actually takes
place". Please see the attached picture. The red curve is the thershold
changed in block *'B'* and blue curve is the threshold after the message
received at block *'A'*.
Is there an alternative method to do the process? Or can I somehow speed up
this message passing process?
Thanks in advance for your suggestions
Ratnesh Kumbhkar
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151029/087d6eaf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: msgfeedback.png
Type: image/png
Size: 11873 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151029/087d6eaf/attachment.png>
------------------------------
Message: 8
Date: Thu, 29 Oct 2015 17:52:08 -0500
From: john <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Has anyone implemented your own module
into real hardware?
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252; format=flowed
I have no practical experience in this area but you may want to check
out this approach (or similar):
http://www.ettus.com/sdr-software/detail/rf-network-on-chip
------------------------------
Message: 9
Date: Fri, 30 Oct 2015 15:49:57 +0530
From: chandan kumar <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] out-of-tree module development on mac
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
sir,
I have install gnuradio on mac. I am trying to build a out-of-tree module,
followed the procedure as given on website. Every command run good but the
module does not appear in GRC. I am not able to figure out the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151030/001cc1bf/attachment.html>
------------------------------
Message: 10
Date: Fri, 30 Oct 2015 12:57:14 +0100
From: Johannes Demel <address@hidden>
To: <address@hidden>
Subject: Re: [Discuss-gnuradio] Is there an alternative of sending
message upstream?
Message-ID: <address@hidden>
Content-Type: text/plain; charset="windows-1252"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Ratnesh,
GR operates on chunks of items. Every block adds some delay. I suggest
you design your system in a way that parallelizes threshold estimation
and the rest of your flowgraph. Or think of a way to pseudo
parallelize them.
happy hacking
Johannes
On 29.10.2015 21:22, ratnesh kumbhkar wrote:
> Hi all, I am trying to make a receiver on gnuradio where one block
> '*A' *uses dynamic "threshold" and this threshold is determined by
> another downstream block *'B' *and is fed back to *'A'* as a
> message. I use "msg_connect" to connect both message port. However
> there is considerable amount of delay between "the time a change is
> made" to "the time that change actually takes place". Please see
> the attached picture. The red curve is the thershold changed in
> block *'B'* and blue curve is the threshold after the message
> received at block *'A'*.
>
> Is there an alternative method to do the process? Or can I somehow
> speed up this message passing process?
>
> Thanks in advance for your suggestions
>
> Ratnesh Kumbhkar ?
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJWM1saAAoJEO7fmkDsqywMnHUP/0qa8GEhc4BLfmIqLsM61kfI
ClzApqGwfN2t1fVWUNBdioRA5GW6+JV18RmiUDVwmYc5hLiBj5p2hOBgFy4IEpmg
sDGOJkzEDC95EfkzCR2PPhfWHL/wX0eaYzojPcMYVn3fgW8/wBhvbtAivKWn6oW6
gmwqgEDyuU4YLv/T7uT/Ga/uQWcwjUugFuy0iT49/kQ/nbJJBwJpgxFUrKscbkSv
pBzylga/98PGmjwiU9kHonxWA9pMdcMbT28mZXG9rZGQBKCX0J/zx9xVKo9zV8Kn
N09rzMBXJKn+9nz/t1TA47zS7HHGm10vi4g8D2ndeIT75XiBdluSyI6sqFqNWM5T
3Go59G5D8XpzMwYnNclFncoP1oyrAqP4fslZxBn2AA0xtEaU2L6lyc3wZIrlSz+t
HM6lYdQ/snVHxdKMCYTD5i7/ud9Zuxl1FYKEcnnc8Gr4YKeNIhIkyQAMIN0X0Rd1
sZU0nNPtTQmMteVVP8oalKtHzuM75cuRH8+pJWQ1lmEYXJlypGcqFPTaQQ3JaQif
ExzVMOA58i4v/6OpCyg09ocwSh0p1RQqkHZLhaRHCEPnsIV7rC8vIp35ZOsN3bX6
KaTvJeubI14rnG0en1ehzz7V/3B+JdswUtzWS+Eo6MtaW2+fXPGWuwiVWAUpglnV
RZQ40F5ysRUIJUN/k0om
=ujpx
-----END PGP SIGNATURE-----
------------------------------
Message: 11
Date: Fri, 30 Oct 2015 14:26:43 +0100
From: Marcus M?ller <address@hidden>
To: Chad R <address@hidden>, GNURadio Discussion List
<address@hidden>
Subject: Re: [Discuss-gnuradio] Python block with vector input and
vector output
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi Chad,
so in that case, the trick would probably be writing good unit tests!
For example, you could take the `for` loop out of your work, and put it
into a method of its own:
import numpy
from gnuradio import gr
from yall1 import *
class yall1_reconstruction_cc(gr.sync_block):
"""
Yall1_reconstruction_block
"""
def __init__(self,n,m):
self.N = n
self.M = m
phi = np.load("/home/chad/Desktop/PROJECT/Python/Matrices/phi_mtx%(M)dx%(N)d.npy" %{"M":self.M,"N":self.N})
psi = np.load("/home/chad/Desktop/PROJECT/Python/Matrices/psi_mtx%(N)dx%(N)d.npy" %{"N":self.N})
self.alpha = np.dot(phi,psi)
gr.sync_block.__init__(self,
name="yall1_reconstruction",
in_sig=[(np.complex64,self.M)],
out_sig=[(np.complex64,self.N)])
def work(self, input_items, output_items):
in0 = input_items[0]
output_items[0][:] = self._algo(in0)
return len(output_items[0])
def _algo(self, in):
out = np.zeros((size,self.N),dtype = np.complex64)
for i, vector in enumerate(in):
recon = yall1(self.alpha, vector.reshape(self.M,1))*4.6
out[i] = recon.reshape(self.N,)
return out
That way, you can write a unit test that first checks whether your for
loop does exactly what you think it does for "artificial" input, without
having to use the block in a GNU Radio flow graph.
It is does, the next step would be to write a unit test that uses
well-known input in a vector source, connects that to your block, and
connects that to a vector sink; validate .data() of that sink.
Best regards,
Marcus
On 10/30/2015 11:38 AM, Chad R wrote:
> Hi Marcus
>
> It's and adaption of the YALL1 Basis Pursuit Algorithm[1]. I
> simplified it a lot as I knew the case of signals I would be using so
> I have no need to parse it opts at run-time and can just leave those
> parameters constant. So I've adapted it that all I need to pass is the
> compressed vector and compression matrix. My Python implementation of
> the YALL1 algorithm works fine when I run it in a Python program but
> gives funny results in the GRC implementation. I'll look at what you
> said and get back to you if I don't understand something. Thanks for
> your help.
>
> Kind Regards
> Chad Richts
>
> [1] User?s Guide for YALL1: Your ALgorithms for L1
> Optimization: http://www.caam.rice.edu/~zhang/reports/tr0917.pdf
> <http://www.caam.rice.edu/%7Ezhang/reports/tr0917.pdf>
>
> On Thu, Oct 29, 2015 at 9:04 PM, Marcus M?ller
> <address@hidden <mailto:address@hidden>> wrote:
>
> Hi Chad,
>
> thanks for re-posting your code; it's much clearer to read now.
> I'm not quite sure what I'm looking at now: Is this your own
> implementation of the yall1 minimization function, or something
> that can be tested?
> If I remember correctly, the matlab call has a matrix input, and a
> "target" vector, and an options argument. Is there some accessible
> documentation.
>
> Other than my confusion whether this is a GNU Radio or a general
> yall1 question, your code looks pretty good. A few thing's I'd note:
>
> * self.alpha.shape should be right
> * check that input_items.shape and in0.shape are as you expect them
>
> Best regards,
> Marcus
>
>
> On 10/29/2015 01:27 PM, Chad R wrote:
>> Sorry. Something went wrong when I copied pasted it but my actual
>> code is:
>>
>> import numpy
>> from gnuradio import gr
>> from yall1 import *
>>
>> class yall1_reconstruction_cc(gr.sync_block):
>> """
>> Yall1_reconstruction_block
>> """
>> def __init__(self,n,m):
>> self.N = n
>> self.M = m
>> phi = np.load("/home/chad/Desktop/PROJECT/Python/Matrices/phi_mtx%(M)dx%(N)d.npy" %{"M":self.M,"N":self.N})
>> psi = np.load("/home/chad/Desktop/PROJECT/Python/Matrices/psi_mtx%(N)dx%(N)d.npy" %{"N":self.N})
>> self.alpha = np.dot(phi,psi)
>> gr.sync_block.__init__(self,
>> name="yall1_reconstruction",
>> in_sig=[(np.complex64,self.M)],
>> out_sig=[(np.complex64,self.N)])
>>
>> def work(self, input_items, output_items):
>> in0 = input_items[0]
>> size = np.shape(in0)[0]
>> out = np.zeros((size,self.N),dtype = np.complex64)
>> #out = yall1(self.alpha,in0[0]).reshape(self.N,)
>> for i in range(0,size):
>> recon = yall1(self.alpha, in0[i].reshape(self.M,1))*4.6
>> out[i] = recon.reshape(self.N,)
>> output_items[0][:] = out
>> return len(output_items[0])
>>
>>
>> On Thu, Oct 29, 2015 at 2:08 PM, Marcus M?ller
>> <address@hidden <mailto:address@hidden>> wrote:
>>
>> Hi Chad,
>>
>> there's something wrong with the indention of the lines
>> between "def __init__" and "g.sync_block", and the same goes
>> for your work function; so that's my first stab at explaining
>> misbehaviour.
>>
>>
>> Best regards,
>> Marcus
>>
>>
>> On 29.10.2015 13:01, Chad R wrote:
>>> Good day every one
>>>
>>> I have implemented a Python block but I am not getting the
>>> results I expected. I get the results I expect at any
>>> frequency=samp_rate/2^n where n is any integer. My block
>>> makes use of a yall1 reconstruction algorithm to reconstruct
>>> a signal from M=100 to N=1024 vector.
>>> The code for my block is shown below:
>>>
>>> class yall1_reconstruction_cc(gr.sync_block):
>>> """
>>> Yall1_reconstruction_block
>>> """
>>> def __init__(self,n,m):
>>> self.N = n
>>> self.M = m
>>> phi =
>>> np.load("/home/chad/Desktop/PROJECT/Python/Matrices/phi_mtx%(M)dx%(N)d.npy"
>>> %{"M":self.M,"N":self.N})
>>> psi =
>>> np.load("/home/chad/Desktop/PROJECT/Python/Matrices/psi_mtx%(N)dx%(N)d.npy"
>>> %{"N":self.N})
>>> self.alpha = np.dot(phi,psi)
>>> gr.sync_block.__init__(self,
>>> name="yall1_reconstruction",
>>> in_sig=[(np.complex64,self.M)],
>>> out_sig=[(np.complex64,self.N)])
>>>
>>> def work(self, input_items, output_items):
>>> in0 = input_items[0]
>>> size = np.shape(in0)[0]
>>> out = np.zeros((size,self.N),dtype = np.complex64)
>>> #out = yall1(self.alpha,in0[0]).reshape(self.N,)
>>> for i in range(0,size):
>>> recon = yall1(self.alpha, in0[i].reshape(self.M,1))*4.7
>>> out[i] = recon.reshape(self.N,)
>>> output_items[0][:] = out
>>> return len(output_items[0])
>>>
>>> Have I implemented it right? or is my issue with my
>>> implementation? I read through the tutorials but I feel some
>>> aspects are quiet hard to follow.
>>>
>>> Thank you in advance for your help
>>>
>>> Chad Richs
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden <mailto:address@hidden>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden <mailto:address@hidden>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151030/65539471/attachment.html>
------------------------------
Message: 12
Date: Fri, 30 Oct 2015 14:28:24 +0100
From: Nemanja Savic <address@hidden>
To: Marcus M?ller <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Error when running GRC
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi,
so, the flowgraph is very simple. Just signal generator, throttle and gui
qt sink (it is attached).
When I close GUI, the flowgraph isn't terminated, but in order to do so, I
have to press rex button in GRC to kill it. The return code is -9.
>>> Done (return code -9)
Also, when I close GRC it is not closed properly but with Seg fault.
Best,
Nemanja
On Thu, Oct 29, 2015 at 7:46 PM, Marcus M?ller <address@hidden>
wrote:
> Hi Nemanja,
>
> well Marcus, you were right (like usual) ...
>
> ha! I wish that was true! Usually I'm not right, trust me.
>
> I tried GRC and it worked. What was strange for me is that flowchart was
> not terminated when I closed QT scope.
>
> That's a bit surprising; you don't happen to have a .grc with which I can
> recreate that?
>
> Cheers,
> Marcus
>
>
>
> On 10/29/2015 05:46 PM, Nemanja Savic wrote:
>
> Hello,
>
> well Marcus, you were right (like usual) ...
> I don't know what exactly problem was, but concerning GRC, it looks like
> in my first attempt to buld sphinx executable couldn't be found.
> As for the min test, it doesn't work, it just stays blocked, no particular
> output.
>
> I tried GRC and it worked. What was strange for me is that flowchart was
> not terminated when I closed QT scope.
>
> Best,
> Nemanja
>
> On Mon, Oct 26, 2015 at 6:19 PM, Marcus M?ller <address@hidden>
> wrote:
>
>> First, try to run the test in isolation:
>> in your build/ directory,
>>
>> ctest -V -R min
>>
>> should run your test alone. If that doesn't give you additional insight,
>> try running
>> ./gr-blocks/python/blocks/qa_min_test.sh
>> directly.
>>
>> You should also inspect the reason GRC core dumps, there's a small wiki
>> page for that [1]; but to be completely honest: qa_min failing and GRC
>> segfaulting sounds like there's some mismatch between the libraries used at
>> build time and the libraries loaded at run time, in my experience.
>>
>> Best regards,
>> Marcus
>>
>> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
>>
>> On 26.10.2015 11:42, Nemanja Savic wrote:
>>
>> Hi,
>>
>> as for the test, I didn't copy correct lines. My test literally blocks in
>> test 11 and never get out of that.
>> test 11
>> Start 11: qa_min
>>
>> 11: Test command: /bin/sh
>> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/python/blocks/qa_min_test.sh"
>> 11: Test timeout computed to be: 9.99988e+06
>>
>> Yes, when I remove keyword argument it finishes with core dumped.
>> No, my previous Gnuradio installation is there, but with another prefix.
>> My machine runs on RHEL6, so can't really change python cause, it makes a
>> lot of trouble with administrators.
>>
>> How can I trace more what cases this error. Few days ago I built gnuradio
>> usinc anaconda python, but had some issues with graphics and then I moved
>> back to my native python.
>>
>> Nemanja
>>
>>
>> On Mon, Oct 26, 2015 at 10:23 AM, Marcus M?ller <address@hidden
>> > wrote:
>>
>>> Hi,
>>> I think this is what that test is supposed to look like, so reading that
>>> is a good sign!
>>> You say you get a segfault when running GRC, right? That's a bit
>>> surprising, because GRC is pure Python, so it's probably something that
>>> gets loaded along the way. Have you uninstalled your previous GNU Radio
>>> installation?
>>> By the way, I thought pre-2.7 Python was practically extinct; out of
>>> curiosity: which OS are you on?
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> Am 26. Oktober 2015 09:10:04 MEZ, schrieb Nemanja Savic <
>>> address@hidden>:
>>>>
>>>> Hello,
>>>>
>>>> I use Python 2.6.6.
>>>> When I make suggested change I got Segmentation Fault error.
>>>> I don't know if it is connected with this, but when I run test, it
>>>> blocks in test n. 10. with this output:
>>>>
>>>> 10: Test command: /bin/sh
>>>> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/lib/test_gr_blocks_test.sh"
>>>> 10: Test timeout computed to be: 9.99988e+06
>>>> 10:
>>>> 10: NOTE: This is supposed to produce an error from block_executor
>>>> 10: Error: block_executor: propagation_policy 'ONE-TO-ONE' requires
>>>> ninputs == noutputs
>>>> 10: ........Using Volk machine: avx_64_mmx_orc
>>>> 10: ......................
>>>> 10:
>>>> 10/170 Test #10: test_gr_blocks ....................... Passed
>>>> 0.86 sec
>>>> test 11
>>>> Start 11: qa_min
>>>>
>>>>
>>>> Can these two be connected?
>>>>
>>>> Nemanja
>>>>
>>>> On Mon, Oct 26, 2015 at 2:25 AM, Marcus M?ller <
>>>> address@hidden> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> First intuition is that there might be something wrong with the Python
>>>>> version in use. Which is it? Python pre-2.7 doesn't know the keyword
>>>>> arguments, so it would have to read
>>>>> .decode('utf-8','replace')
>>>>> Instead of
>>>>> .decode('utf-8',errors='replace')
>>>>>
>>>>> Cheetah is, as far as I know, not Python 3 compatible.
>>>>>
>>>>> Best regards,
>>>>> Marcus
>>>>>
>>>>>
>>>>> Am 26. Oktober 2015 01:46:09 MEZ, schrieb Nemanja Savic <
>>>>> address@hidden>:
>>>>>
>>>>>> Hi all guys,
>>>>>>
>>>>>> i built yesterday 3.7.8. When I wanted to run GRC the following error
>>>>>> occured:
>>>>>>
>>>>>> Traceback (most recent call last):
>>>>>> File "/scr1/nemanja/install/bin/gnuradio-companion", line 128, in
>>>>>> <module>
>>>>>> main()
>>>>>> File "/scr1/nemanja/install/bin/gnuradio-companion", line 121, in
>>>>>> main
>>>>>> ActionHandler(args, Platform())
>>>>>> File
>>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
>>>>>> line 62, in __init__
>>>>>> self.main_window = MainWindow(platform)
>>>>>> File
>>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/MainWindow.py",
>>>>>> line 96, in __init__
>>>>>> self.btwin = BlockTreeWindow(platform, self.get_flow_graph);
>>>>>> File
>>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>>>>>> line 107, in __init__
>>>>>> self.platform.load_block_tree(self)
>>>>>> File
>>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/base/Platform.py",
>>>>>> line 228, in load_block_tree
>>>>>> block_tree.add_block(block.get_category(), block)
>>>>>> File
>>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>>>>>> line 144, in add_block
>>>>>> treestore.set_value(iter, DOC_INDEX,
>>>>>> Utils.parse_template(DOC_MARKUP_TMPL, doc=block.get_doc()))
>>>>>> File
>>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
>>>>>> line 116, in parse_template
>>>>>> return str(Template(tmpl_str, kwargs))
>>>>>> File "/usr/lib64/python2.6/site-packages/Cheetah/Template.py", line
>>>>>> 1003, in __str__
>>>>>> rc = getattr(self, mainMethName)()
>>>>>> File
>>>>>> "cheetah_DynamicallyCompiledCheetahTemplate_1445820074_12_55642.py", line
>>>>>> 83, in respond
>>>>>> File
>>>>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
>>>>>> line 100, in encode
>>>>>> valid_utf8 = value.decode('utf-8',
>>>>>> errors='replace').encode('utf-8')
>>>>>> TypeError: decode() takes no keyword arguments
>>>>>>
>>>>>>
>>>>>> It looks like Cheetah problem but can't make it work. There was
>>>>>> suggestion few years ago to remove errors='replace', but it didn't work for
>>>>>> me.
>>>>>>
>>>>>> THanx
>>>>>> --
>>>>>> Nemanja Savi?
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> Discuss-gnuradio mailing address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>
>>>>>> -- Sent from my Android device with K-9 Mail. Please excuse my
>>>>> brevity.
>>>>>
>>>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>
>> --
>> Nemanja Savi?
>>
>>
>
>
> --
> Nemanja Savi?
>
>
>
--
Nemanja Savi?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151030/df1b73cc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled.grc
Type: application/gnuradio-grc
Size: 11377 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151030/df1b73cc/attachment.bin>
------------------------------
Message: 13
Date: Fri, 30 Oct 2015 14:43:01 +0100
From: Marcus M?ller <address@hidden>
To: Nemanja Savic <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Error when running GRC
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi Nemanja,
sorry, can't reproduce that behaviour -- on my system, the flow graph
exits immediately when I close the window.
If this is an ongoing bother to you, we should look into finding out
what is still active in your process -- but that's bound to become
"multithreading with GDB", and I'm not overly confident that's what I'd
consider a fun Friday...
Best regards,
Marcus
On 10/30/2015 02:28 PM, Nemanja Savic wrote:
> Hi,
>
> so, the flowgraph is very simple. Just signal generator, throttle and
> gui qt sink (it is attached).
> When I close GUI, the flowgraph isn't terminated, but in order to do
> so, I have to press rex button in GRC to kill it. The return code is -9.
>
> >>> Done (return code -9)
>
> Also, when I close GRC it is not closed properly but with Seg fault.
>
> Best,
> Nemanja
>
> On Thu, Oct 29, 2015 at 7:46 PM, Marcus M?ller
> <address@hidden <mailto:address@hidden>> wrote:
>
> Hi Nemanja,
>
>> well Marcus, you were right (like usual) ...
> ha! I wish that was true! Usually I'm not right, trust me.
>> I tried GRC and it worked. What was strange for me is that
>> flowchart was not terminated when I closed QT scope.
> That's a bit surprising; you don't happen to have a .grc with
> which I can recreate that?
>
> Cheers,
> Marcus
>
>
>
> On 10/29/2015 05:46 PM, Nemanja Savic wrote:
>> Hello,
>>
>> well Marcus, you were right (like usual) ...
>> I don't know what exactly problem was, but concerning GRC, it
>> looks like in my first attempt to buld sphinx executable couldn't
>> be found.
>> As for the min test, it doesn't work, it just stays blocked, no
>> particular output.
>>
>> I tried GRC and it worked. What was strange for me is that
>> flowchart was not terminated when I closed QT scope.
>>
>> Best,
>> Nemanja
>>
>> On Mon, Oct 26, 2015 at 6:19 PM, Marcus M?ller
>> <address@hidden <mailto:address@hidden>> wrote:
>>
>> First, try to run the test in isolation:
>> in your build/ directory,
>>
>> ctest -V -R min
>>
>> should run your test alone. If that doesn't give you
>> additional insight, try running
>> ./gr-blocks/python/blocks/qa_min_test.sh
>> directly.
>>
>> You should also inspect the reason GRC core dumps, there's a
>> small wiki page for that [1]; but to be completely honest:
>> qa_min failing and GRC segfaulting sounds like there's some
>> mismatch between the libraries used at build time and the
>> libraries loaded at run time, in my experience.
>>
>> Best regards,
>> Marcus
>>
>> [1]
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
>>
>> On 26.10.2015 11:42, Nemanja Savic wrote:
>>> Hi,
>>>
>>> as for the test, I didn't copy correct lines. My test
>>> literally blocks in test 11 and never get out of that.
>>> test 11
>>> Start 11: qa_min
>>>
>>> 11: Test command: /bin/sh
>>> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/python/blocks/qa_min_test.sh"
>>> 11: Test timeout computed to be: 9.99988e+06
>>>
>>> Yes, when I remove keyword argument it finishes with core
>>> dumped.
>>> No, my previous Gnuradio installation is there, but with
>>> another prefix. My machine runs on RHEL6, so can't really
>>> change python cause, it makes a lot of trouble with
>>> administrators.
>>>
>>> How can I trace more what cases this error. Few days ago I
>>> built gnuradio usinc anaconda python, but had some issues
>>> with graphics and then I moved back to my native python.
>>>
>>> Nemanja
>>>
>>>
>>> On Mon, Oct 26, 2015 at 10:23 AM, Marcus M?ller
>>> <address@hidden <mailto:address@hidden>>
>>> wrote:
>>>
>>> Hi,
>>> I think this is what that test is supposed to look like,
>>> so reading that is a good sign!
>>> You say you get a segfault when running GRC, right?
>>> That's a bit surprising, because GRC is pure Python, so
>>> it's probably something that gets loaded along the way.
>>> Have you uninstalled your previous GNU Radio installation?
>>> By the way, I thought pre-2.7 Python was practically
>>> extinct; out of curiosity: which OS are you on?
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> Am 26. Oktober 2015 09:10:04 MEZ, schrieb Nemanja Savic
>>> <address@hidden <mailto:address@hidden>>:
>>>
>>> Hello,
>>>
>>> I use Python 2.6.6.
>>> When I make suggested change I got Segmentation
>>> Fault error.
>>> I don't know if it is connected with this, but when
>>> I run test, it blocks in test n. 10. with this output:
>>>
>>> 10: Test command: /bin/sh
>>> "/scr1/nemanja/tools/gnuradio-3.7.8/build/gr-blocks/lib/test_gr_blocks_test.sh"
>>> 10: Test timeout computed to be: 9.99988e+06
>>> 10:
>>> 10: NOTE: This is supposed to produce an error from
>>> block_executor
>>> 10: Error: block_executor: propagation_policy
>>> 'ONE-TO-ONE' requires ninputs == noutputs
>>> 10: ........Using Volk machine: avx_64_mmx_orc
>>> 10: ......................
>>> 10:
>>> 10/170 Test #10: test_gr_blocks
>>> ....................... Passed 0.86 sec
>>> test 11
>>> Start 11: qa_min
>>>
>>>
>>> Can these two be connected?
>>>
>>> Nemanja
>>>
>>> On Mon, Oct 26, 2015 at 2:25 AM, Marcus M?ller
>>> <address@hidden
>>> <mailto:address@hidden>> wrote:
>>>
>>> Hi!
>>>
>>> First intuition is that there might be something
>>> wrong with the Python version in use. Which is
>>> it? Python pre-2.7 doesn't know the keyword
>>> arguments, so it would have to read
>>> .decode('utf-8','replace')
>>> Instead of
>>> .decode('utf-8',errors='replace')
>>>
>>> Cheetah is, as far as I know, not Python 3
>>> compatible.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> Am 26. Oktober 2015 01:46:09 MEZ, schrieb
>>> Nemanja Savic <address@hidden
>>> <mailto:address@hidden>>:
>>>
>>> Hi all guys,
>>>
>>> i built yesterday 3.7.8. When I wanted to
>>> run GRC the following error occured:
>>>
>>> Traceback (most recent call last):
>>> File
>>> "/scr1/nemanja/install/bin/gnuradio-companion",
>>> line 128, in <module>
>>> main()
>>> File
>>> "/scr1/nemanja/install/bin/gnuradio-companion",
>>> line 121, in main
>>> ActionHandler(args, Platform())
>>> File
>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py",
>>> line 62, in __init__
>>> self.main_window = MainWindow(platform)
>>> File
>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/MainWindow.py",
>>> line 96, in __init__
>>> self.btwin = BlockTreeWindow(platform,
>>> self.get_flow_graph);
>>> File
>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>>> line 107, in __init__
>>> self.platform.load_block_tree(self)
>>> File
>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/base/Platform.py",
>>> line 228, in load_block_tree
>>>
>>> block_tree.add_block(block.get_category(),
>>> block)
>>> File
>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/BlockTreeWindow.py",
>>> line 144, in add_block
>>> treestore.set_value(iter, DOC_INDEX,
>>> Utils.parse_template(DOC_MARKUP_TMPL,
>>> doc=block.get_doc()))
>>> File
>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
>>> line 116, in parse_template
>>> return str(Template(tmpl_str, kwargs))
>>> File
>>> "/usr/lib64/python2.6/site-packages/Cheetah/Template.py",
>>> line 1003, in __str__
>>> rc = getattr(self, mainMethName)()
>>> File
>>> "cheetah_DynamicallyCompiledCheetahTemplate_1445820074_12_55642.py",
>>> line 83, in respond
>>> File
>>> "/scr1/nemanja/install/lib64/python2.6/site-packages/gnuradio/grc/gui/Utils.py",
>>> line 100, in encode
>>> valid_utf8 = value.decode('utf-8',
>>> errors='replace').encode('utf-8')
>>> TypeError: decode() takes no keyword arguments
>>>
>>>
>>> It looks like Cheetah problem but can't make
>>> it work. There was suggestion few years ago
>>> to remove errors='replace', but it didn't
>>> work for me.
>>>
>>> THanx
>>> --
>>> Nemanja Savi?
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Discuss-gnuradio mailing list
>>> address@hidden <mailto:address@hidden>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>> -- Sent from my Android device with K-9 Mail.
>>> Please excuse my brevity.
>>>
>>> -- Sent from my Android device with K-9 Mail. Please
>>> excuse my brevity.
>>>
>>> --
>>> Nemanja Savi?
>>
>>
>>
>>
>> --
>> Nemanja Savi?
>
>
>
>
> --
> Nemanja Savi?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151030/28cf1579/attachment.html>
------------------------------
Message: 14
Date: Fri, 30 Oct 2015 10:07:49 -0400
From: Michael Dickens <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] out-of-tree module development on mac
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="us-ascii"
Hi Chandan - What procedure did you follow? And, how is GNU Radio
installed on your Mac? When you write that every command runs, do you
mean that you have QA code that works? We need a little more info before
we can really provide you assistance here. Feel free to email me
directly & we can report back to this list if there's anything new
and/or different from the various install guides info. - MLD
On Fri, Oct 30, 2015, at 06:19 AM, chandan kumar wrote:
> I have install gnuradio on mac. I am trying to build a out-of-tree
> module, followed the procedure as given on website. Every command run
> good but the module does not appear in GRC. I am not able to figure
> out the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20151030/94a70fc2/attachment.html>
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
End of Discuss-gnuradio Digest, Vol 155, Issue 40
*************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |