|
| From: | Fei Yang |
| Subject: | Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 149, Issue 24 |
| Date: | Wed, 22 Apr 2015 02:26:06 +0800 |
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: gr-display-master install (was Re: Writing text to a QT
GUI Window) (Michael Dickens)
2. error 127 (Fei Yang)
3. Re: Some misconceptions about the "peak_detector2" block
(Frank Fu)
4. Re: CMake and CUDA (marco Ribero)
5. Re: New UHD seems to break a lot... (Ian Buckley)
6. gr::buffer::allocate_buffer: warning (Ali Riaz)
7. Re: New UHD seems to break a lot... (Ralph A. Schmid, dk5ras)
8. Re: Bidirectional communication between attached blocks
(marco Ribero)
9. Re: gr::buffer::allocate_buffer: warning (Martin Braun)
10. Re: Undefined reference to
`gr::blocks::vector_source_b::make()' (Martin Braun)
11. Announcing NEWSDR at WPI on Thr/Fri May 21/22 (Neel Pandeya)
12. looking for gnuradio coding style template
(=?ISO-8859-1?B?VHJlaw==?=)
13. RSS measurement in time domain (Jay Prakash)
14. Re: looking for gnuradio coding style template (Richard Bell)
15. Re: looking for gnuradio coding style template (Ron Economos)
16. How to receive message from subblock using topblock?
(Luong Tan Phong)
17. Re: How to receive message from subblock using topblock?
(Marcus M?ller)
18. GNURadio scheduler (=?ISO-8859-1?B?VHJlaw==?=)
19. Re: GNURadio scheduler (Marcus M?ller)
20. Re: Bitbaking GnuRadio with meta-sdr master issues
(Murray Thomson)
21. Re: How to receive message from subblock using topblock?
(Tom Rondeau)
22. Re: Bitbaking GnuRadio with meta-sdr master issues
(Philip Balister)
23. Re: Some misconceptions about the "peak_detector2" block
(Tom Rondeau)
24. Re: CMake and CUDA (Tom Rondeau)
25. Re: streams are not aligned properly in wx time sink (Tom Rondeau)
26. Re: streams are not aligned properly in wx time sink
(address@hidden)
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Apr 2015 12:20:08 -0400
From: Michael Dickens <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] gr-display-master install (was Re:
Writing text to a QT GUI Window)
Message-ID:
<address@hidden>
Content-Type: text/plain
Execute "gnuradio-config-info --prefix" to see the PREFIX into which GNU
Radio was installed.
The default PREFIX is /usr/local, yes. - MLD
On Mon, Apr 20, 2015, at 11:54 AM, Murphy, John wrote:
> Saw the item below on the archive page (I get the digest).
> And, yes, /usr/local is correct, /usr/local/bin builds but gets runtime
> errors.
> So many thanks MLD.
> Now, the next time I get stuck doing this on some random system in the
> future, how do I know what that directory location is for the gnuradio
> install?
> It looks on the wiki like this is always /usr/local if you did not do
> something to set a specific custom directory in the gnuradio install
> process (by PyBombs or build-gnuradio or most of the other methods
> that are described).
> Is that the case?
------------------------------
Message: 2
Date: Tue, 21 Apr 2015 01:03:53 +0800
From: Fei Yang <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] error 127
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
my system is
cubieboard
sdr is usrp1
my os is
Distributor ID: Ubuntu
Description: Ubuntu 12.04.4 LTS
Release: 12.04
Codename: precise
kernel is
Linux Qbee-X 3.4.79-sun7i+ #39 SMP PREEMPT Wed Feb 12 19:20:27 EST 2014
armv7l armv7l armv7l GNU/Linux
git clone git://github.com/ttsou/gnuradio
check out -b libusrp
this my configuretion
./configure --disable-all-components --with-fusb-tech=libusb1 --enable-usrp
--enable-gruel --enable-gnuradio-core --enable-gr-usrp --enable-config
CFLAGS="-march=armv7-a -mtune=cortex-a7 -mfpu=neon -mfloat-abi=hard"
CXXFLAGS="-march=armv7-a -mtune=cortex-a7 -mfpu=neon -mfloat-abi=hard"
make -j2
make check
make install
i use make install print this error
test -z "/usr/local/lib/python2.7/site-packages/usrpm" || /bin/mkdir -p
"/usr/local/lib/python2.7/site-packages/usrpm"
/usr/bin/install -c -m 644 usrp_dbid.py
'/usr/local/lib/python2.7/site-packages/usrpm'
/bin/bash: line 15: --destdir: command not found
make[7]: *** [install-usrppythonPYTHON] Error 127
make[6]: *** [install-am] Error 2
make[5]: *** [install] Error 2
make[4]: *** [install-recursive] Error 1
make[3]: *** [install-recursive] Error 1
make[2]: *** [install] Error 2
make[1]: *** [install-recursive] Error 1
make: *** [install] Error 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150421/a09654dd/attachment.html>
------------------------------
Message: 3
Date: Mon, 20 Apr 2015 16:47:59 +0000
From: Frank Fu <address@hidden>
To: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Some misconceptions about the
"peak_detector2" block
Message-ID: <address@hidden>
Content-Type: text/plain; charset="Windows-1252"
I?ve also been looking for an appropriate fix for peak_detector2. When I review this thread and the issue tracker, I?m uncertain how the block is supposed to behave. I think most of the developers have looked at the documentation in the header file, and have tried to make fixes in accordance with it. Specifically, that the peak search should only be restricted to the range within the look_ahead parameter. If so, then Achilleas is very close to an appropriate fix, needing only some additional calls to set_output_multiple to prevent hanging. The block would also work fine with a sine wave, as long as the look ahead value was appropriate, like half the period.
As mentioned previously, the QA test may not necessarily be useful, given that the input signal is much smaller than the window. Perhaps the test file can also be modified to get better results. I?m willing to contribute to a fix and help make the peak detector block more stable, but I would have to know more about how the block should behave. Any comments or insights are appreciated.
Frank Fu
-------
From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Some misconceptions about the "peak_detector2" block
Date: Mon, 13 Apr 2015 16:54:47 -0400
Achilleas,
I think you've completely failed to understand the issue from my perspective. I do NOT disagree that there is a bug in the code. I also do NOT disagree that most of what you've tried to do in the rewrite is the correct way to rethink the block. What I have a problem with is that you've provided me with a fix that breaks applications that used to run fine, including the QA test.
As for the applications, there's a really simple test you can perform. Apply the peak detector to a sine wave. In the current code, it finds the peak of the sine wave. With the new version, it does not just find that as the peak, but it outputs as though it's found the peak for every length of the look-ahead value. This could be a valid design choice in a peak detector where given a window, always emit the highest value in the window. That is not what this block is supposed to do, nor is the new block behaving consistently in this manner.
As for the QA test, the current tests presents a vector to the block and the block finds the correct peak. With the new code, it doesn't complete. It just hangs. While it is true that stream-based blocks in GNU Radio expect a continuous stream of data, any block that simply fails to complete its processing when the rest of the flowgraph is done is a bug. Instead, we have hooks like set_output_multiple and overloading the forecast function that help us work with the scheduler to make sure everyone gets the right amount of data they require. In this case, you make a good argument that the block should look beyond it's current window to see if the max is in fact reached. If that's the case, then we need to have the block tell the scheduler this. If less data is passed because there is no more data to process and the flowgraph is shutting down, this block too must shut down. It will then do so without providing the right answer. So the QA test will fail -- but it will complete and report failure in the data.
Please understand the above points when reworking your fix.
Thanks,
Tom
------
On Fri, Apr 10, 2015 at 4:22 PM, Achilleas Anastasopoulos <address@hidden> wrote:
Hi all,
recently there has been some discussion regarding the peak_detector2 block, both in the github/gnuradio (pull request 404) as well as in the issue tracker (issue 783).
It is now well accepted that this block is buggy: there are cases the work function returns -1, which is a bug (see issue 783 on how to recreate this bug).
I believe however that there is a DEEPER misconception about how this block works/should work that has resulted in some frustration on what an appropriate fix should be.
In particular there is an insistence that an appropriate bug fix should pass the qa_test of this block and it should be [in the spirit] of the existing algorithm.
In the following I will explain why passing the qa_test is a consequence of the buggy behaviour of this block and NOT its feature.
In addition I will suggest what a proper behaviour of this block should be, so that others who may want to write their own version of a peak detector find it useful.
--------
So the peak_detector block is very reasonable in its conception and its name is very informative and appropriate. It works as follows:
Reads the input and keeps track of a running average (through a single-pole iir filter)
When the current input crosses a threshold (= average * a user-defined factor) upwards the block enters a search state, where it looks for the maximum value of the input over a window of user-defined length.
This is clearly the intended behaviour of the block according to the documentation (I don't know who the original author is...).
----------
------------------------------
Message: 4
Date: Mon, 20 Apr 2015 19:42:50 +0200
From: marco Ribero <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] CMake and CUDA
Message-ID:
<CACB=4qGiVj4Sokqhs0L_CrC_M5aJFaO5kX=address@hidden>
Content-Type: text/plain; charset="utf-8"
I try to give more details.
In order to create blocks using the standard way(cmake/make/install) with
Cuda,I've modified the CMakeList in /lib as shown before. My block is
created using gr_modtool and the language is c++.
The fact is that "make test" works well,while in GnuRadio interface give me
the following error AttributeError: 'module' object has no attribute
'helloFunc_ff'.
Everything worked well before the addition of CUDA code(so it's not the
problem experienced by other users)
Thanks,
Marco
cmake_minimum_required(VERSION 2.8)
find_package(CUDA)
include(GrPlatform) #define LIB_SUFFIX
include_directories(${Boost_INCLUDE_DIR})
link_directories(${Boost_LIBRARY_DIRS})
list(APPEND helloBlock_sources
mod_ff_impl.cc helloCUDA.cu
)
set(helloBlock_sources "${helloBlock_sources}" PARENT_SCOPE)
cuda_add_library(gnuradio-helloBlock SHARED ${helloBlock_sources})
target_link_libraries(gnuradio-helloBlock ${Boost_LIBRARIES}
${GNURADIO_ALL_LIBRARIES}
${CUDA_LIBRARIES})
set_target_properties(gnuradio-helloBlock PROPERTIES DEFINE_SYMBOL
"gnuradio_helloBlock_EXPORTS")
......
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150420/dba02111/attachment.html>
------------------------------
Message: 5
Date: Mon, 20 Apr 2015 11:05:10 -0700
From: Ian Buckley <address@hidden>
To: "Ralph A. Schmid, dk5ras" <address@hidden>
Cc: address@hidden, 'GNU Radio Discussion List'
<address@hidden>
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Message-ID: <address@hidden>
Content-Type: text/plain; charset="windows-1252"
To close the loop on this thread, 3.8.3-RC1 has a bug in new code that automatically calculates master_clock_rates when they are not explicitly stated. This specifically affects B2x0 and E3x0 since they are AD9361 based with a very flexible master_clock_rate. In this case Ralph asked for a sample_rate of 9.142857 MHz and UHD erroneously forced a master_clock_rate of 8MHz. An explicit master_clcok_rate request (in this case for 9.142857MHz) works around the bug as shown (green without, yellow with): http://ianbuckley.net/ralph_spectrum.jpg. The master_clock_rate override does print a warning in the UHD log so you can see that this is happening:
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 9.142857 MSps
Actual sample rate: 8.000000 MSps
There is also another bug in RC1 that also prints incorrect warnings. Warnings of this form can currently be ignored until this is fixed should you know that you have actually set sensible sample_rates:
UHD Warning:
The requested decimation is odd; the user should expect CIC rolloff.
Select an even decimation to ensure that a halfband filter is enabled.
decimation = dsp_rate/samp_rate -> 37 = (9.142857 MHz)/(0.250000 MHz)
NOTE: Ralph, your flow graph used a TX gain of 99?this is way too high for the signal being driven to the USRP, you were driving the output amp into saturation.
-Ian
On Apr 18, 2015, at 12:24 AM, "Ralph A. Schmid, dk5ras" <address@hidden> wrote:
> Yes, I can confirm hash 2fe3..., and the images were downloaded with the supplied uhd_image_downloader, what is configured like this:
>
> _DEFAULT_BASE_URL = "http://files.ettus.com/binaries/images/"
> _AUTOGEN_IMAGES_FILENAME = "uhd-images_003.008.003-rc1.zip"
> _AUTOGEN_IMAGES_CHECKSUM = "8522b02386f5fe0bb51baa3ba0001ef0"
>
> The GRC filkes are accessible now, the only modifications I made were due to Ron Economos' hints regarding sampling rate, and I added a frequency slider to choose the correct European TV channel without having to know the frequency.
>
> Ralph.
>
>
> From: Ian Buckley [mailto:address@hidden]
> Sent: Saturday, April 18, 2015 03:45
> To: Ralph A. Schmid, dk5ras
> Cc: 'Martin Braun'; address@hidden; 'GNU Radio Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> Ralph,
> I'm not able to access either of the .grc files on your website, but using the original dvbt_tx_demo_8k flow graph from gr-dvbt, the spectrum I generate with 003.008.003-RC1 has a 3dB bandwidth of about ~7.5MHz the same as your uhd_master screen shot. I don't see the truncated bandwidth of your uhd_rc1 screenshot. http://ianbuckley.net/dvbt.jpg
> Can you verify please that you have UHD at the current 003.008.003-RC1 tag position git hash 2fe319d9790c7ec0bcdb9582c4fea95f3fd809b9, and that the downloaded FPGA images are from: http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip
>
> I'll need your exact flow graph if I'm to debug this anymore.
>
> -Ian
>
>
>
> On Apr 17, 2015, at 11:48 AM, "Ralph A. Schmid, dk5ras" <address@hidden> wrote:
>
>
> I have put it all here, flow graphs and screenshots of the flow graphs:
>
> http://dk5ras.dyndns.org/tmp/DVB/
>
> This way we can keep it on the list without sending attachments.
>
> They were taken from the VM container before all the upgrades were made, but
> I did not change anything when upgrading.
>
> Ralph.
>
>
>
> -----Original Message-----
> From: Ian Buckley [mailto:address@hidden]
> Sent: Friday, April 17, 2015 19:25
> To: Ralph A. Schmid, dk5ras
> Cc: 'Martin Braun'; address@hidden; 'GNU Radio Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> Great Ralph, thats a big help. Can you send me your exact flow graph used to
> generate these 2 plots off list please. I want to re run this scenario and
> see your exact configuration.
>
> Thanks
> -Ian
>
> On Apr 17, 2015, at 10:00 AM, "Ralph A. Schmid, dk5ras" <address@hidden>
> wrote:
>
>
> OK, here we go. The hotel TV was dvb-c only, so I had to do the tests
> back at home.
>
> I took my perfectly working Kubuntu 14.04 64 bit VM container together
> with my B210, made a copy and updated this one, first I made a git
> pull to get latest master, built it, rebuilt gnuradio, rebuilt
> gr-dvbt, updated the FPGA images, and everything still was fine. The
> chosen dvb-t bandwidth is 8 MHz.
>
>
> Then I changed to 003_008_003_rc1, did the same procedure, fired up
> grc, and the signal was not decodable both with a dvb-t PC receiver
> and with an dvb-x analyzer. The analyzer saw the RF level, but no
> data, no constellation, nothing, it looked to him like interference.
>
> When you have a look at the two "uhd" screenshots here
> http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then
> you will find that RC1 produces a somehow narrower signal, so it
> really looks something gets cut at the ends with all the filtering and DSP
> stuff.
>
> Adjusting the channel bandwidth in the uhd sink block from 0 to a
> sensible value changes nothing.
>
> Btw., the dvb-t2 package behaves identical.
>
> Ralph.
>
>
> -----Original Message-----
> From: Martin Braun [mailto:address@hidden]
> Sent: Wednesday, April 15, 2015 21:14
> To: Ralph A. Schmid, dk5ras; address@hidden; 'GNU Radio
> Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> master works, but RC1 does not? Huh, I'm confused now. Can you give
> some detail on what's going on, so we can try and reproduce this?
>
> Thanks,
> Martin
>
> On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
>
> RC1, master seems to work.
>
> Ralph.
>
> -----Original Message-----
> From: Martin Braun [mailto:address@hidden]
> Sent: Wednesday, April 15, 2015 15:44
> To: Ralph A. Schmid, dk5ras; address@hidden; 'GNU Radio
> Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
> 3.8.3-RC1, or latest master?
>
> Martin
>
> On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
>
> It is a B210, but as a note, due to the up to now missing FPGA
> images I used 003.008.003-RC1, not the latest master. Still I had no
> access to a spectrum and DVB-T analyzer, so I have no idea what is
> happening, I just can confirm that RF is transmitted, and the
> receiver doesn't get a picture, while with the snapshot of the same
> VM before the upgrade
> is received without problems.
>
> I will know more in about three hours.
>
> Ralph.
>
>
> -----Original Message-----
> From: Martin Braun [mailto:address@hidden]
> Sent: Wednesday, April 15, 2015 3:15 PM
> To: Ralph A. Schmid, dk5ras; address@hidden; 'GNU Radio
> Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
>
> Hi,
>
> Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
> with latest uhd. A quick check during lunch break showed, the
> produced output is not decodable any more. I will take a closer
> look this evening at home, where I have more and better equipment.
>
> Ralph,
>
> which device is this on?
>
> Thanks,
> Martin
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150420/a1fd8c57/attachment.html>
------------------------------
Message: 6
Date: Mon, 20 Apr 2015 13:16:02 -0500
From: Ali Riaz <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] gr::buffer::allocate_buffer: warning
Message-ID:
<CACq3jrmfbB0XzcGnGtarK9dXCqZicpDy2TH74+gN=address@hidden>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I'm getting the following warnings when running my application, does anyone
know what this means?
gr::buffer::allocate_buffer: warning: tried to allocate
41 items of size 1592. Due to alignment requirements
512 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
gr::buffer::allocate_buffer: warning: tried to allocate
82 items of size 796. Due to alignment requirements
1024 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
gr::buffer::allocate_buffer: warning: tried to allocate
82 items of size 796. Due to alignment requirements
1024 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
gr::buffer::allocate_buffer: warning: tried to allocate
82 items of size 796. Due to alignment requirements
1024 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes
Best,
Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150420/4c98add8/attachment.html>
------------------------------
Message: 7
Date: Mon, 20 Apr 2015 21:27:08 +0200
From: "Ralph A. Schmid, dk5ras" <address@hidden>
To: "'Ian Buckley'" <address@hidden>
Cc: address@hidden, 'GNU Radio Discussion List'
<address@hidden>
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
Thanks for all the research - sound reasonable, now I know what is going
wrong, great!
Regarding the TX gain, I was never able to see any nonlinearity from
saturation, the amp seems to be way below the critical input level. The
signal is 1a clean, no spurs and no excessive harmonics, no IM.
Ralph.
From: Ian Buckley [mailto:address@hidden]
Sent: Monday, April 20, 2015 20:05
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; address@hidden; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
To close the loop on this thread, 3.8.3-RC1 has a bug in new code that
automatically calculates master_clock_rates when they are not explicitly
stated. This specifically affects B2x0 and E3x0 since they are AD9361 based
with a very flexible master_clock_rate. In this case Ralph asked for a
sample_rate of 9.142857 MHz and UHD erroneously forced a master_clock_rate
of 8MHz. An explicit master_clcok_rate request (in this case for
9.142857MHz) works around the bug as shown (green without, yellow with):
http://ianbuckley.net/ralph_spectrum.jpg. The master_clock_rate override
does print a warning in the UHD log so you can see that this is happening:
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 9.142857 MSps
Actual sample rate: 8.000000 MSps
There is also another bug in RC1 that also prints incorrect warnings.
Warnings of this form can currently be ignored until this is fixed should
you know that you have actually set sensible sample_rates:
UHD Warning:
The requested decimation is odd; the user should expect CIC rolloff.
Select an even decimation to ensure that a halfband filter is enabled.
decimation = dsp_rate/samp_rate -> 37 = (9.142857 MHz)/(0.250000 MHz)
NOTE: Ralph, your flow graph used a TX gain of 99.this is way too high for
the signal being driven to the USRP, you were driving the output amp into
saturation.
-Ian
On Apr 18, 2015, at 12:24 AM, "Ralph A. Schmid, dk5ras" <address@hidden>
wrote:
Yes, I can confirm hash 2fe3..., and the images were downloaded with the
supplied uhd_image_downloader, what is configured like this:
_DEFAULT_BASE_URL = " <http://files.ettus.com/binaries/images/>
http://files.ettus.com/binaries/images/"
_AUTOGEN_IMAGES_FILENAME = "uhd-images_003.008.003-rc1.zip"
_AUTOGEN_IMAGES_CHECKSUM = "8522b02386f5fe0bb51baa3ba0001ef0"
The GRC filkes are accessible now, the only modifications I made were due to
Ron Economos' hints regarding sampling rate, and I added a frequency slider
to choose the correct European TV channel without having to know the
frequency.
Ralph.
From: Ian Buckley [mailto:ianb@ <http://ionconcepts.com> ionconcepts.com]
Sent: Saturday, April 18, 2015 03:45
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; <mailto:address@hidden>
address@hidden; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Ralph,
I'm not able to access either of the .grc files on your website, but using
the original dvbt_tx_demo_8k flow graph from gr-dvbt, the spectrum I
generate with 003.008.003-RC1 has a 3dB bandwidth of about ~7.5MHz the same
as your uhd_master screen shot. I don't see the truncated bandwidth of your
uhd_rc1 screenshot. <http://ianbuckley.net/dvbt.jpg>
http://ianbuckley.net/dvbt.jpg
Can you verify please that you have UHD at the current 003.008.003-RC1 tag
position git hash 2fe319d9790c7ec0bcdb9582c4fea95f3fd809b9, and that the
downloaded FPGA images are from:
<http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip>
http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip
I'll need your exact flow graph if I'm to debug this anymore.
-Ian
On Apr 17, 2015, at 11:48 AM, "Ralph A. Schmid, dk5ras" <
<mailto:address@hidden> address@hidden> wrote:
I have put it all here, flow graphs and screenshots of the flow graphs:
<http://dk5ras.dyndns.org/tmp/DVB/> http://dk5ras.dyndns.org/tmp/DVB/
This way we can keep it on the list without sending attachments.
They were taken from the VM container before all the upgrades were made, but
I did not change anything when upgrading.
Ralph.
-----Original Message-----
From: Ian Buckley [ <mailto:address@hidden>
mailto:address@hidden]
Sent: Friday, April 17, 2015 19:25
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; <mailto:address@hidden>
address@hidden; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Great Ralph, thats a big help. Can you send me your exact flow graph used to
generate these 2 plots off list please. I want to re run this scenario and
see your exact configuration.
Thanks
-Ian
On Apr 17, 2015, at 10:00 AM, "Ralph A. Schmid, dk5ras" <
<mailto:address@hidden> address@hidden>
wrote:
OK, here we go. The hotel TV was dvb-c only, so I had to do the tests
back at home.
I took my perfectly working Kubuntu 14.04 64 bit VM container together
with my B210, made a copy and updated this one, first I made a git
pull to get latest master, built it, rebuilt gnuradio, rebuilt
gr-dvbt, updated the FPGA images, and everything still was fine. The
chosen dvb-t bandwidth is 8 MHz.
Then I changed to 003_008_003_rc1, did the same procedure, fired up
grc, and the signal was not decodable both with a dvb-t PC receiver
and with an dvb-x analyzer. The analyzer saw the RF level, but no
data, no constellation, nothing, it looked to him like interference.
When you have a look at the two "uhd" screenshots here
<http://dk5ras.dyndns.org/tmp/DVB/> http://dk5ras.dyndns.org/tmp/DVB/ made
with my spectrum analyzer then
you will find that RC1 produces a somehow narrower signal, so it
really looks something gets cut at the ends with all the filtering and DSP
stuff.
Adjusting the channel bandwidth in the uhd sink block from 0 to a
sensible value changes nothing.
Btw., the dvb-t2 package behaves identical.
Ralph.
-----Original Message-----
From: Martin Braun [ <mailto:address@hidden>
mailto:address@hidden]
Sent: Wednesday, April 15, 2015 21:14
To: Ralph A. Schmid, dk5ras; <mailto:address@hidden>
address@hidden; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
master works, but RC1 does not? Huh, I'm confused now. Can you give
some detail on what's going on, so we can try and reproduce this?
Thanks,
Martin
On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
RC1, master seems to work.
Ralph.
-----Original Message-----
From: Martin Braun [ <mailto:address@hidden>
mailto:address@hidden]
Sent: Wednesday, April 15, 2015 15:44
To: Ralph A. Schmid, dk5ras; <mailto:address@hidden>
address@hidden; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
3.8.3-RC1, or latest master?
Martin
On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
It is a B210, but as a note, due to the up to now missing FPGA
images I used 003.008.003-RC1, not the latest master. Still I had no
access to a spectrum and DVB-T analyzer, so I have no idea what is
happening, I just can confirm that RF is transmitted, and the
receiver doesn't get a picture, while with the snapshot of the same
VM before the upgrade
is received without problems.
I will know more in about three hours.
Ralph.
-----Original Message-----
From: Martin Braun [ <mailto:address@hidden>
mailto:address@hidden]
Sent: Wednesday, April 15, 2015 3:15 PM
To: Ralph A. Schmid, dk5ras; <mailto:address@hidden>
address@hidden; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
Hi,
Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
with latest uhd. A quick check during lunch break showed, the
produced output is not decodable any more. I will take a closer
look this evening at home, where I have more and better equipment.
Ralph,
which device is this on?
Thanks,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150420/4ecbc35d/attachment.html>
------------------------------
Message: 8
Date: Mon, 20 Apr 2015 19:36:14 +0000
From: marco Ribero <address@hidden>
To: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Bidirectional communication between
attached blocks
Message-ID:
<CACB=address@hidden>
Content-Type: text/plain; charset="utf-8"
Il giorno lun 20 apr 2015 alle ore 16:30 Tom Rondeau <address@hidden> ha
scritto:
>
>>
> We've never been hot on the idea of using VOLK for GPU stuff. VOLK kernels
> tend to do one thing at a time and don't worry about data movement (too
> much) because the SIMD registers are right there. Going to GPUs takes a lot
> longer, so you want to spend more of your time there once you get the data
> moved across. With VOLK, we'd be going back and forth, which is a huge
> performance killer.
>
Exactly, unlucky I cannot make this kind of porting.
>
>>
>>
> I'm also not the biggest fan of CUDA for GNU Radio simply because it's too
> hardware specific. I'd be more interested in seeing OpenCL implementations
> -- but even that has it's limitations for support. Theano looks nice from
> what I've heard (mostly from Tim and his gr-theano work), and I don't
> believe that it's necessarily CUDA.
>
> I'm agree with the fact that CUDA is not the best, because it's hardware
specific. But portability doesn't imply performance.
I had spent a look over gr-theano. It's a nice library based on CUDA which
give interesting blocks like FFT and FIR. One of its limitation is the
mandatory device-host memcpy, in my opinion.
An interesting library that I was not able to find is GRGPU. I've only read
about it on papers/forums, but I didn't found any repository still working,
unfortunally.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150420/a3692e9e/attachment.html>
------------------------------
Message: 9
Date: Mon, 20 Apr 2015 16:14:25 -0700
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] gr::buffer::allocate_buffer: warning
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252
On 20.04.2015 11:16, Ali Riaz wrote:
> Hello everyone,
>
> I'm getting the following warnings when running my application, does
> anyone know what this means?
>
> gr::buffer::allocate_buffer: warning: tried to allocate
> 41 items of size 1592. Due to alignment requirements
> 512 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
You get this when you're forcing buffers not to fit onto pages. You can
probably ignore it, but you might get some performance hits.
M
------------------------------
Message: 10
Date: Mon, 20 Apr 2015 16:20:59 -0700
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Undefined reference to
`gr::blocks::vector_source_b::make()'
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252
Not a lot to go with here, you'll need to post more info before anyone
can help you with this.
I recommend reading this:
http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors
As for your problem, it does look like a linker issue, so double-check
that the right gnuradio-blocks .so is linked.
M
On 20.04.2015 04:07, mohamedx wrote:
> Hi again,
>
> I managed to solve my initial issue (I just add double control of in/out
> item count), but still not able to run a flow graph from main, I got the
> undefined reference to what ever blocks other than mine.
> If someone has an idea to fix this, I'm still interested.
>
> Thanks,
> Mohamed
>
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.com/Undefined-reference-to-gr-blocks-vector-source-b-make-tp53327p53367.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 11
Date: Mon, 20 Apr 2015 20:02:00 -0700
From: Neel Pandeya <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Announcing NEWSDR at WPI on Thr/Fri May
21/22
Message-ID:
<CACaXmv8FNi-_mKXPW_rZadUV-nj_ccuFH=address@hidden>
Content-Type: text/plain; charset="utf-8"
*********************************************************************
* NEWSDR 2015 *
* *
* New England Workshop on Software-Defined Radio *
* *
* Fifth-Annual *
* *
* Main Event *
* Friday May 22, 7:30 AM - 4:00 PM *
* *
* GNU Radio Hacking Workshop *
* Thursday May 21, 5:00 PM - 9:30 PM *
* *
* Worcester Polytechnic Institute (WPI) *
* Worcester, MA, USA *
* *
* http://www.sdr-boston.org/ *
* *
* Free Registration *
* *
*********************************************************************
INVITATION TO PARTICIPATE
You are cordially invited to the 2015 New England Workshop on
Software Defined Radio (NEWSDR 2015), which is the fifth installment
of an annual series of workshops organized by the Boston SDR User
Group (SDR-Boston).
This year, NEWSDR will be held at the Rubin Campus Center of
Worcester Polytechnic Institute (WPI), and consists of a day-long
Main Event on Friday, and a GNU Radio Hacking Workshop (GRHW) on the
evening before. People are welcome to attend either or both.
*********************************************************************
MAIN EVENT
Friday May 22, 7:30 AM - 4 PM
KEYNOTE SPEAKER:
* Professor frederic harris, San Diego State University
INVITED SPEAKERS:
* Professor Miriam Leeser, Northeastern University
* Professor Mieczyslaw Kokar, Northeastern University
TECHNICAL POSTER PRESENTATIONS:
* Covering the recent work in SDR and cognitive radio technology
* Poster presentations are now being solicited
* See link at the bottom of this email to submit your abstract
SPONSORS:
* The MathWorks Inc.
* National Instruments / Ettus Research
* MediaTek Wireless Inc.
* Wireless Innovation Laboratory (WI Lab) at WPI
DEMOS & TECHNICAL SEMINARS FROM:
* The MathWorks Inc.
* National Instruments / Ettus Research
COMPLIMENTARY:
* Free parking
* Free breakfast, lunch, coffee provided
The Main Event features invited speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and two technical seminars, all focusing on recent
work in SDR and cognitive radio technology.
The event provides an excellent networking opportunity and a terrific
venue to exchange thoughts and ideas with other people working in
the SDR space.
*********************************************************************
GNU Radio Hacking Workshop (GRHW)
Thursday May 21, 5 PM - 9:30 PM
HOST:
* Dr. Tom Rondeau, Rondeau Research LLC
COMPLIMENTARY:
* Free parking
* Free pizza, drinks, and dessert provided
The GRHW is a great opportunity for people to learn about how to
productively use GNU Radio and USRP devices. The workshop is aimed
at both novice users as well as at those with some previous basic
experience.
The GRHW will be run by Dr. Tom Rondeau, who will briefly speak about
the current state and future directions of the GNU Radio project.
Afterwards, a brief GNU Radio tutorial will follow.
Then attendees will work individually or in groups to implement a
communications system from scratch, with guidance from on-hand staff
to answer questions and help with problems. A working system will be
presented at the end.
Attendees are required to bring their own laptops, but USRP radios as
well as bootable live USB flash drives will be provided. Nothing will
need to be installed on attendees' laptops.
*********************************************************************
REGISTRATION
* Registration is completely free
* Registration takes less than 5 minutes
* Registration includes free parking and free food
* You must register online in order to receive a voucher for
free parking and free food
* Attendance, food, parking are all limited, so please register
online as soon as possible to secure your spot
* Registration deadline is Friday May 15
* See link at the bottom of this announcement to register online
* Your registration information will be kept confidential and
private, and will *not* be shared with any other third-party
*********************************************************************
LINKS
REGISTRATION:
https://docs.google.com/forms/d/19sEkp0YOF17BGl_8wVCB2W66-entErgziyCEaY6Bi94/viewform
POSTER ABSTRACT SUBMISSION:
https://docs.google.com/forms/d/1UIixAhRdaTHP7eNDxD7kwwmKfFQlvXB-DKDFjJupwHo/viewform
*********************************************************************
ADDITIONAL INFORMATION
More information, and the event schedule,
for this event can be found at our website:
http://www.sdr-boston.org/
*********************************************************************
EOF
*********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150420/bf3fc4ea/attachment.html>
------------------------------
Message: 12
Date: Tue, 21 Apr 2015 11:11:08 +0800
From: "=?ISO-8859-1?B?VHJlaw==?=" <address@hidden>
To: "=?ISO-8859-1?B?ZGlzY3Vzcy1nbnVyYWRpbw==?="
<address@hidden>
Subject: [Discuss-gnuradio] looking for gnuradio coding style template
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Could someone point me to the right place? Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150421/4367b6f5/attachment.html>
------------------------------
Message: 13
Date: Tue, 21 Apr 2015 11:12:55 +0800
From: Jay Prakash <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] RSS measurement in time domain
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
I want to measure channel gain between rx-tx pair for a TDD system.( first
slot between A to B second slot between B to A with self switching of USRP).
Any suggested example to follow? Any reference design?
Packet based link should be a good idea I guess.
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150421/c80afaf2/attachment.html>
------------------------------
Message: 14
Date: Mon, 20 Apr 2015 20:25:59 -0700
From: Richard Bell <address@hidden>
To: Trek <address@hidden>
Cc: discuss-gnuradio <address@hidden>
Subject: Re: [Discuss-gnuradio] looking for gnuradio coding style
template
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
This might be what you're looking for:
https://gnuradio.org/redmine/projects/gnuradio/wiki/Coding_guide#C
Skip down to the C++ section.
v/r,
Rich
On Mon, Apr 20, 2015 at 8:11 PM, Trek <address@hidden> wrote:
> Could someone point me to the right place?
> Thanks,
>
> _______________________________________________
> 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/20150420/b97f6b78/attachment.html>
------------------------------
Message: 15
Date: Mon, 20 Apr 2015 20:35:10 -0700
From: Ron Economos <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] looking for gnuradio coding style
template
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
For curly brace formatting and spacing see the "Code Format" section of:
https://gnuradio.org/redmine/projects/gnuradio/wiki/Coding_guide_impl
Ron
On 04/20/2015 08:25 PM, Richard Bell wrote:
> This might be what you're looking for:
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Coding_guide#C
>
> Skip down to the C++ section.
>
> v/r,
> Rich
>
> On Mon, Apr 20, 2015 at 8:11 PM, Trek <address@hidden
> <mailto:address@hidden>> wrote:
>
> Could someone point me to the right place?
> Thanks,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150420/c00133ff/attachment.html>
------------------------------
Message: 16
Date: Tue, 21 Apr 2015 12:09:27 +0700
From: Luong Tan Phong <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] How to receive message from subblock using
topblock?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
Hi,
I'm newbie with PMT and I created a block was inherited from gr::sync_block
and sent out messages.
Could you tell me how to receive messages from my block on topblock to
process them, please?
With best regards,
LTP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150421/772d4396/attachment.html>
------------------------------
Message: 17
Date: Tue, 21 Apr 2015 09:21:27 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] How to receive message from subblock
using topblock?
Message-ID: <address@hidden>
Content-Type: text/plain; charset="windows-1252"
Dear LTP,
your top_block [1] is a msg_accepter, just like every other block in
your system, and a basic_block. Hence, it has a a post()[3] method, it
has a message_port_register_in()[4] etc.
You should be able to follow what's described in the Guided tutorials,
Part 5, section 5. [2] If you haven't already, I strongly recommend
reading Part 1-4 first -- they are a fun read (I hope), and they explain
a lot of the core concepts quite well.
Best regards,
Marcus M?ller
[1] http://gnuradio.org/doc/doxygen/classgr_1_1top__block.html
[2] https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
[3]
http://gnuradio.org/doc/doxygen/classgr_1_1msg__accepter.html#a03b0afcc820d3454d29f0ada3b89e2fc
[4]
http://gnuradio.org/doc/doxygen/classgr_1_1basic__block.html#a362b6de38292cca9c1d56439a6efad04
On 04/21/2015 07:09 AM, Luong Tan Phong wrote:
> Hi,
>
> I'm newbie with PMT and I created a block was inherited from
> gr::sync_block and sent out messages.
> Could you tell me how to receive messages from my block on topblock to
> process them, please?
>
> With best regards,
>
> LTP
>
>
> _______________________________________________
> 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/20150421/75d4c863/attachment.html>
------------------------------
Message: 18
Date: Tue, 21 Apr 2015 17:44:11 +0800
From: "=?ISO-8859-1?B?VHJlaw==?=" <address@hidden>
To: "=?ISO-8859-1?B?ZGlzY3Vzcy1nbnVyYWRpbw==?="
<address@hidden>
Subject: [Discuss-gnuradio] GNURadio scheduler
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Is there a sample routine, document or youtube video explaining the GNUradio scheduler? hard to fully understand Gnuradio without it. What are the files in the Gnuradio that are the core of the scheduler?
thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150421/c23d5957/attachment.html>
------------------------------
Message: 19
Date: Tue, 21 Apr 2015 12:46:25 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] GNURadio scheduler
Message-ID: <address@hidden>
Content-Type: text/plain; charset="windows-1252"
Hi Trek,
the scheduler and all the core components holding GNU Radio together are
in gnuradio/gnuradio-runtime. The scheduler is mainly composed of the
files starting with tpb (==thread per block), block_executor, and
block/buffer.
There's
http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html
, and especially the presentation linked therein. Though it's from 2013,
the flowcharts on the scheduler's workings are still valid; you'll have
to add message handling in the block iteration, but other than that, I
don't think much has changed.
Other than that: The source code is really its best documentation.
Really, compared to most projects I came across, our source files are
vividly commented, and the list is almost always eager to both explain
concepts and questions regarding any particular line of code, so just ask :)
Greetings,
Marcus
On 04/21/2015 11:44 AM, Trek wrote:
> Is there a sample routine, document or youtube video explaining the
> GNUradio scheduler? hard to fully understand Gnuradio without it. What
> are the files in the Gnuradio that are the core of the scheduler?
>
> thanks,
>
>
> _______________________________________________
> 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/20150421/f42282b0/attachment.html>
------------------------------
Message: 20
Date: Tue, 21 Apr 2015 14:43:08 +0100
From: Murray Thomson <address@hidden>
To: Philip Balister <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Bitbaking GnuRadio with meta-sdr
master issues
Message-ID:
<CALf1X5MRNS_RYU-rBzHFv8yobrWYKXp3wU_=sM4ds+2w=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On 20 April 2015 at 15:13, Philip Balister <address@hidden> wrote:
>
>
> On 04/19/2015 11:07 AM, Murray Thomson wrote:
> > Hello,
> >
> > I have built the gnuradio-dev-image for an arm machine and I wanted to
> > share a couple of small issues that I found in the process.
> >
> > - The meta-sdr/conf/bblayers.conf.sample doesn't include all the layers
> > needed. This is correctly warned in the README file of the layer. I've
> > attached the file that worked for me in case someone finds it useful.
>
> You layer.conf file has loads of layers the dev image shouldn't need? Do
> you know exactly which ones are missing? I'm setting the default for
> meta-sdr so you can build demo image out of the box. The demo + video
> layer recipe lists some additional layers you will need.
>
I didn't realize that the dependencies that I had missing were necessary
for my target machine, but not required for meta-sdr, sorry. I've checked
the dependencies with "bitbake -g gnuradio-demo-image" and the ones in
bblayers.conf.sample are correct. The only thing I would suggest is to
replace meta-oe for meta-openembedded as recommended in their github
<https://github.com/openembedded>.
> Philip
>
> >
> > - A couple of the layers include recipe.bbappend files for recipes that
> > have been updated recently. I solved this ignoring them with BBMASK as
> you
> > can see in the bblayers.conf file.
> >
> > - valgrind recipe failed. This seem to be a problem with the Yocto master
> > branch so I deleted it from the recipes and I built without it.
> >
> > - volk failed to compile for qemuarm machine. I couldn't work around this
> > one. I've attached the log file. Some of the recipes, including
> > gnuradio_git depend on it so I don't think I'll be able to ignore it.
> >
> > The only real issue is the last one. It would be great to be able to
> > compile for qemuarm. Could anyone give me a pointer to fix this? My
> machine
> > runs Ubuntu 12.04 32 bit and the master branch for all the BSPs.
> >
> > Thanks,
> > Murray
> >
> >
> >
> > _______________________________________________
> > 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/20150421/2637833f/attachment.html>
------------------------------
Message: 21
Date: Tue, 21 Apr 2015 10:12:38 -0400
From: Tom Rondeau <address@hidden>
To: Marcus M?ller <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] How to receive message from subblock
using topblock?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
On Tue, Apr 21, 2015 at 3:21 AM, Marcus M?ller <address@hidden>
wrote:
> Dear LTP,
>
> your top_block [1] is a msg_accepter, just like every other block in your
> system, and a basic_block. Hence, it has a a post()[3] method, it has a
> message_port_register_in()[4] etc.
>
> You should be able to follow what's described in the Guided tutorials,
> Part 5, section 5. [2] If you haven't already, I strongly recommend reading
> Part 1-4 first -- they are a fun read (I hope), and they explain a lot of
> the core concepts quite well.
>
> Best regards,
> Marcus M?ller
>
>
> [1] http://gnuradio.org/doc/doxygen/classgr_1_1top__block.html
> [2] https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
> [3]
> http://gnuradio.org/doc/doxygen/classgr_1_1msg__accepter.html#a03b0afcc820d3454d29f0ada3b89e2fc
> [4]
> http://gnuradio.org/doc/doxygen/classgr_1_1basic__block.html#a362b6de38292cca9c1d56439a6efad04
>
Adding to Marcus' list of references:
http://gnuradio.org/doc/doxygen/page_msg_passing.html
Tom
> On 04/21/2015 07:09 AM, Luong Tan Phong wrote:
>
> Hi,
>
> I'm newbie with PMT and I created a block was inherited from
> gr::sync_block and sent out messages.
> Could you tell me how to receive messages from my block on topblock to
> process them, please?
>
> With best regards,
>
> LTP
>
>
> _______________________________________________
> 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/20150421/fc29168e/attachment.html>
------------------------------
Message: 22
Date: Tue, 21 Apr 2015 10:26:23 -0400
From: Philip Balister <address@hidden>
To: Murray Thomson <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Bitbaking GnuRadio with meta-sdr
master issues
Message-ID: <address@hidden>
Content-Type: text/plain; charset=windows-1252
On 04/21/2015 09:43 AM, Murray Thomson wrote:
> On 20 April 2015 at 15:13, Philip Balister <address@hidden> wrote:
>
>>
>>
>> On 04/19/2015 11:07 AM, Murray Thomson wrote:
>>> Hello,
>>>
>>> I have built the gnuradio-dev-image for an arm machine and I wanted to
>>> share a couple of small issues that I found in the process.
>>>
>>> - The meta-sdr/conf/bblayers.conf.sample doesn't include all the layers
>>> needed. This is correctly warned in the README file of the layer. I've
>>> attached the file that worked for me in case someone finds it useful.
>>
>> You layer.conf file has loads of layers the dev image shouldn't need? Do
>> you know exactly which ones are missing? I'm setting the default for
>> meta-sdr so you can build demo image out of the box. The demo + video
>> layer recipe lists some additional layers you will need.
>>
>
> I didn't realize that the dependencies that I had missing were necessary
> for my target machine, but not required for meta-sdr, sorry. I've checked
> the dependencies with "bitbake -g gnuradio-demo-image" and the ones in
> bblayers.conf.sample are correct. The only thing I would suggest is to
> replace meta-oe for meta-openembedded as recommended in their github
> <https://github.com/openembedded>.
Thanks for checking the default is OK.
This should prevent trouble when the short named repos go away:
https://github.com/balister/oe-gnuradio-manifest/commit/9aaaa67909b59de87ad62462decac626d9637437
I left the directories they get checked out into the same for now. I
suppose I'll change the names at some point, maybe when I do the fido
branch.
Philip
Philip
>
>
>> Philip
>>
>>>
>>> - A couple of the layers include recipe.bbappend files for recipes that
>>> have been updated recently. I solved this ignoring them with BBMASK as
>> you
>>> can see in the bblayers.conf file.
>>>
>>> - valgrind recipe failed. This seem to be a problem with the Yocto master
>>> branch so I deleted it from the recipes and I built without it.
>>>
>>> - volk failed to compile for qemuarm machine. I couldn't work around this
>>> one. I've attached the log file. Some of the recipes, including
>>> gnuradio_git depend on it so I don't think I'll be able to ignore it.
>>>
>>> The only real issue is the last one. It would be great to be able to
>>> compile for qemuarm. Could anyone give me a pointer to fix this? My
>> machine
>>> runs Ubuntu 12.04 32 bit and the master branch for all the BSPs.
>>>
>>> Thanks,
>>> Murray
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>
------------------------------
Message: 23
Date: Tue, 21 Apr 2015 10:26:03 -0400
From: Tom Rondeau <address@hidden>
To: Frank Fu <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Some misconceptions about the
"peak_detector2" block
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
On Mon, Apr 20, 2015 at 12:47 PM, Frank Fu <address@hidden> wrote:
> I?ve also been looking for an appropriate fix for peak_detector2. When I
> review this thread and the issue tracker, I?m uncertain how the block is
> supposed to behave. I think most of the developers have looked at the
> documentation in the header file, and have tried to make fixes in
> accordance with it. Specifically, that the peak search should only be
> restricted to the range within the look_ahead parameter. If so, then
> Achilleas is very close to an appropriate fix, needing only some additional
> calls to set_output_multiple to prevent hanging. The block would also work
> fine with a sine wave, as long as the look ahead value was appropriate,
> like half the period.
>
> As mentioned previously, the QA test may not necessarily be useful, given
> that the input signal is much smaller than the window. Perhaps the test
> file can also be modified to get better results. I?m willing to contribute
> to a fix and help make the peak detector block more stable, but I would
> have to know more about how the block should behave. Any comments or
> insights are appreciated.
>
> Frank Fu
>
So I pretty much agree with this now. In the current form of the block, the
function of the look_ahead doesn't behave the way that you described here,
Frank. However, looking at the (sparse) documentation for this block, I can
now see why everyone thinks that's how it's supposed to behave. From [1]:
look_ahead: The look-ahead value is used when the threshold is found to
locate the peak within this range.
And if that's how everyone expects it to behave, which is what I'm hearing,
then we should correct that.
Here are a couple of points that I'd like to consider for reworking this
block. First, the flowgraph must finish no matter how many items are passed
to it. The block was initially designed for an OFDM preamble detector, so
we can't have it just waiting around for more samples to come in, which
will add to latency.
I think that the variable "look_ahead" should probably be renamed to
"window" or something. The documentation for this block also needs a lot of
work to avoid ambiguity or confusion about what it's really supposed to do
and how it works. Better QA code and an example would be really useful, too.
Finally, I don't think that set_output_multiple is the right answer here.
I'd rather it save state between calls to work if it's looking in the
current window. We shouldn't have a block wait for thousands of samples
(the default look_ahead is 1000) before making a decision. And using
set_output_multiple with large values has, in my experience, a performance
hit on a flowgraph.
Tom
[1]
http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1peak__detector2__fb.html
> -------
> From: Tom Rondeau
> Subject: Re: [Discuss-gnuradio] Some misconceptions about the
> "peak_detector2" block
> Date: Mon, 13 Apr 2015 16:54:47 -0400
> Achilleas,
>
> I think you've completely failed to understand the issue from my
> perspective. I do NOT disagree that there is a bug in the code. I also do
> NOT disagree that most of what you've tried to do in the rewrite is the
> correct way to rethink the block. What I have a problem with is that you've
> provided me with a fix that breaks applications that used to run fine,
> including the QA test.
>
> As for the applications, there's a really simple test you can perform.
> Apply the peak detector to a sine wave. In the current code, it finds the
> peak of the sine wave. With the new version, it does not just find that as
> the peak, but it outputs as though it's found the peak for every length of
> the look-ahead value. This could be a valid design choice in a peak
> detector where given a window, always emit the highest value in the window.
> That is not what this block is supposed to do, nor is the new block
> behaving consistently in this manner.
>
> As for the QA test, the current tests presents a vector to the block and
> the block finds the correct peak. With the new code, it doesn't complete.
> It just hangs. While it is true that stream-based blocks in GNU Radio
> expect a continuous stream of data, any block that simply fails to complete
> its processing when the rest of the flowgraph is done is a bug. Instead, we
> have hooks like set_output_multiple and overloading the forecast function
> that help us work with the scheduler to make sure everyone gets the right
> amount of data they require. In this case, you make a good argument that
> the block should look beyond it's current window to see if the max is in
> fact reached. If that's the case, then we need to have the block tell the
> scheduler this. If less data is passed because there is no more data to
> process and the flowgraph is shutting down, this block too must shut down.
> It will then do so without providing the right answer. So the QA test will
> fail -- but it will complete and report failure in the data.
>
> Please understand the above points when reworking your fix.
>
> Thanks,
>
> Tom
> ------
> On Fri, Apr 10, 2015 at 4:22 PM, Achilleas Anastasopoulos <address@hidden>
> wrote:
> Hi all,
>
> recently there has been some discussion regarding the peak_detector2
> block, both in the github/gnuradio (pull request 404) as well as in the
> issue tracker (issue 783).
>
> It is now well accepted that this block is buggy: there are cases the work
> function returns -1, which is a bug (see issue 783 on how to recreate this
> bug).
>
> I believe however that there is a DEEPER misconception about how this
> block works/should work that has resulted in some frustration on what an
> appropriate fix should be.
> In particular there is an insistence that an appropriate bug fix should
> pass the qa_test of this block and it should be [in the spirit] of the
> existing algorithm.
> In the following I will explain why passing the qa_test is a consequence
> of the buggy behaviour of this block and NOT its feature.
> In addition I will suggest what a proper behaviour of this block should
> be, so that others who may want to write their own version of a peak
> detector find it useful.
>
>
> --------
>
> So the peak_detector block is very reasonable in its conception and its
> name is very informative and appropriate. It works as follows:
>
> Reads the input and keeps track of a running average (through a
> single-pole iir filter)
>
> When the current input crosses a threshold (= average * a user-defined
> factor) upwards the block enters a search state, where it looks for the
> maximum value of the input over a window of user-defined length.
>
> This is clearly the intended behaviour of the block according to the
> documentation (I don't know who the original author is...).
>
> ----------
> _______________________________________________
> 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/20150421/65a97e17/attachment.html>
------------------------------
Message: 24
Date: Tue, 21 Apr 2015 10:37:28 -0400
From: Tom Rondeau <address@hidden>
To: marco Ribero <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] CMake and CUDA
Message-ID:
<CA+SzT6ikYD7WRk+1_a8ym1b=7=address@hidden>
Content-Type: text/plain; charset="utf-8"
On Mon, Apr 20, 2015 at 1:42 PM, marco Ribero <address@hidden>
wrote:
> I try to give more details.
> In order to create blocks using the standard way(cmake/make/install) with
> Cuda,I've modified the CMakeList in /lib as shown before. My block is
> created using gr_modtool and the language is c++.
> The fact is that "make test" works well,while in GnuRadio interface give
> me the following error AttributeError: 'module' object has no attribute
> 'helloFunc_ff'.
> Everything worked well before the addition of CUDA code(so it's not the
> problem experienced by other users)
>
> Thanks,
> Marco
>
>
>
> cmake_minimum_required(VERSION 2.8)
> find_package(CUDA)
>
> include(GrPlatform) #define LIB_SUFFIX
>
> include_directories(${Boost_INCLUDE_DIR})
> link_directories(${Boost_LIBRARY_DIRS})
>
> list(APPEND helloBlock_sources
> mod_ff_impl.cc helloCUDA.cu
> )
>
> set(helloBlock_sources "${helloBlock_sources}" PARENT_SCOPE)
>
>
> cuda_add_library(gnuradio-helloBlock SHARED ${helloBlock_sources})
> target_link_libraries(gnuradio-helloBlock ${Boost_LIBRARIES}
> ${GNURADIO_ALL_LIBRARIES}
> ${CUDA_LIBRARIES})
> set_target_properties(gnuradio-helloBlock PROPERTIES DEFINE_SYMBOL
> "gnuradio_helloBlock_EXPORTS")
> ......
>
Have you checked the library itself to see if the block exists there? 'nm
-C lib<project name>.so | grep helloBlock' should tell you if it was
properly built into your library.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150421/a438fbcd/attachment.html>
------------------------------
Message: 25
Date: Tue, 21 Apr 2015 10:40:50 -0400
From: Tom Rondeau <address@hidden>
To: "Marcus D. Leech" <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] streams are not aligned properly in wx
time sink
Message-ID:
<CA+SzT6gs8rhh=BSdQz_-9zaXiSyMasMB9WkVDeR_G2B=address@hidden>
Content-Type: text/plain; charset="utf-8"
On Sun, Apr 19, 2015 at 11:39 AM, Marcus D. Leech <address@hidden> wrote:
> On 04/19/2015 11:32 AM, Martin Braun wrote:
>
>> Yeah: Use the QT widgets.
>>
>> As we keep mentioning, the WX widgets will be going away in the future,
>> and no one wants to maintain them. Of course, if someone has a bug fix
>> for this, that would be even better, but please don't rely on the WX
>> GUIs in the long run.
>>
>> Cheers,
>> M
>>
>> _
>>
> Is there a stripchart implementation for Qt in the works?
Not yet. It's not a terribly difficult one to conceive of. My only issue is
trying to squash it into the current time_sink blocks or just create a
separate strip_chart class for this. The latter means more code to update
later, but it might simplify the logic that would appear in a work function
that's trying to be both things.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150421/87f99d2d/attachment.html>
------------------------------
Message: 26
Date: Tue, 21 Apr 2015 11:02:56 -0400
From: address@hidden
To: Tom Rondeau <address@hidden>
Cc: address@hidden, GNURadio Discussion List
<address@hidden>
Subject: Re: [Discuss-gnuradio] streams are not aligned properly in wx
time sink
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
Understood.
Most of my tuits are still all rectilinear as well....
On 2015-04-21 10:40, Tom Rondeau wrote:
> On Sun, Apr 19, 2015 at 11:39 AM, Marcus D. Leech <address@hidden> wrote:
> On 04/19/2015 11:32 AM, Martin Braun wrote:
> Yeah: Use the QT widgets.
>
> As we keep mentioning, the WX widgets will be going away in the future,
> and no one wants to maintain them. Of course, if someone has a bug fix
> for this, that would be even better, but please don't rely on the WX
> GUIs in the long run.
>
> Cheers,
> M
>
> _ Is there a stripchart implementation for Qt in the works?
Not yet. It's not a terribly difficult one to conceive of. My only issue
is trying to squash it into the current time_sink blocks or just create
a separate strip_chart class for this. The latter means more code to
update later, but it might simplify the logic that would appear in a
work function that's trying to be both things.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150421/671f1b44/attachment.html>
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
End of Discuss-gnuradio Digest, Vol 149, Issue 24
*************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |