> It'd certainly be interesting to compare the performance of both those
> backends in training.
>
> Cheers
> Chris
>
> On Mon, Aug 8, 2016 at 2:44 PM, Stefan Wunsch
> <stefan.wun...@student.kit.edu <mailto:stefan.wun...@student.kit.edu>>
> wrote:
>
> Hi
Hi,
Keras is a very good choice! Does the Theano backend still work? So can
you switch seamlessly between Tensorflow and Theano (altering the
.keras/keras.json)?
I've experienced that getting the GPU support running with Theano was
much easier when using Keras (export THEANO_FLAGS is enough),
This helps a lot to find all installations:
$ sudo find / -name libuhd*.so*
If the path is not inside a pybombs prefix, it is most likely an
installation by your package manager.
I had this problem as well :P
Greetings
Stefan
On 08/04/2016 06:56 PM, Jason Matusiak wrote:
>> For some reason,
ackager.source - ERROR - Build failed. See output above for
> error messages.
> PyBOMBS.Packager.source - ERROR - Problem occurred while building
> package gnuradio:
> Build failed.
> PyBOMBS.install_manager - ERROR - Error installing package gnuradio.
> Aborting.
>
> Cyri
Best regards,
>
> Marcus
>
>
> On 02.08.2016 09:03, Stefan Wunsch wrote:
>> And btw, it worked some month ago, when I implemented the pacman support
>> in pybombs. So the changes has to be somewhen since then.
>>
>> On 08/01/2016 10:38 PM, Cyrille DERORY wrote:
&g
Hi,
I can confirm this problem. But it doesn't seem to be Arch Linux
specific (more a UHD problem).
Can someone confirm that it works on the other systems? UHD is build
from source, so the root of the problem are not the pacman packages.
My first guess would be the gcc6 compiler shipped with
Hi,
Please submit the pullrequest! The package is definetely missing.
Greetings
Stefan
On 08/01/2016 05:55 PM, Andrej Rode wrote:
> Hey Cyrille,
>
>
> On 01/08/16 17:20, Cyrille DERORY wrote:
>> Thank you for your reply,
>>
>> my distro/OS is archlinux and package manager is pacman:
>>
And btw, it worked some month ago, when I implemented the pacman support
in pybombs. So the changes has to be somewhen since then.
On 08/01/2016 10:38 PM, Cyrille DERORY wrote:
> Hi,
>
> with PyBOMBS, I'm compiling gnuradio on archlinux:
> sudo pybombs -v install gnuradio
> and I get errors with
Hi,
Please run ctest -V and give the verbose error output. You give too
little information to guess what went wrong!
Greetings,
Stefan
On 07/29/2016 01:04 AM, Abhinav Jadon wrote:
> Hi ,
> I use an Ubuntu 14.04 machine. 64 bit processor.
> UHD version 003.010 | QWT version 6.0.0 | Boost
Hi,
The classification accuracy looks good! But some questions:
Will you compare the performance with non-tensorflow machine learning
algorithms such as boosted decision trees or support vector machines
(e.g. provided by scikit-learn or xgboost)?
Your model is a deep neural network, so there is
Hey all,
gcc6 uses std=gnu++14 as default (compared to std=gnu++98 up to gcc5.3)
[0]. This causes a lot of warnings during building gnuradio due to the
deprecated auto_ptr (unique_ptr is the way to go now) and gr-zeromq
fails building completely.
Probably the used c++ standard should be set in
Hi,
Try to use the echotimer shipped with gr-radar. Actually, for FMCW you
don't need a tight TX/RX sync, but probably that fixes it.
As well, have a look at the spectrum and check the output of the peak
detector. Do you have a high enough SNR for an unambigious peak
detection? Or you are just
Keep in mind the automated build service of hub.docker.com! For those
who don't know how it works:
It is connected to the github repo and rebuilds after each new commit
the needed images (or layers) automatically.
As well, it would be possible to build automatically images for each
release of
I think (but I am not totally sure) that you can target multiple cores
from a single container. So the -j option should work on your local
machine. But not on hub.docker.com, because you have only one core on
the server machine.
Greetings
On 04/08/2016 05:08 PM, Kevin Hofschröer wrote:
> Also,
Hi,
That's true for now, but ubuntu's repos aren't made for developing. The
repos are just too old within a few month. And then recent (or self
developed) OOTs won't work.
Regarding running the GUI: In the readme I've included the commands for
X forwarding (that's your approach). Works fine on
e hardware that can stream at
> higher rates, I'd be interested in how those perform in the container,
> as well.
>
> Cheers,
> Ben
>
> On Wed, Apr 6, 2016 at 4:23 AM, Stefan Wunsch
> <stefan.wun...@student.kit.edu <mailto:stefan.wun...@student.kit.edu>>
> wrote
Hi all!
I have build a docker tool-chain for an image with GNU Radio and UHD
installed via PyBOMBS on top of Ubuntu. It's even possible to run it
dockerized with a GUI using VNC and it should work as well on windows
and mac (so far, not tested). The build files are available on github
and the
din <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169>
>
> *******
>
> On Wed, Mar 30, 2016 at 10:16 PM, Stefan Wunsch
> <stefan.wun...@student.kit.edu <mailto:stefan.wun...@student.kit.edu>>
> wrote:
Hi,
Sebastian is right, it's most likely a dependency problem. I've tested
the source from git and it compiles fine with following dependencies:
- gnuradio 3.7.9.1
- uhd 3.9.2
- boost 1.60.0
First check boost, old versions don't have the strerror function. If
boost is the problem, I should
different sizes of matrices/vectors,
>>> different proto-kernels are called (including the CPU SIMDized call,
>>> instead of the OpenCL call for smaller input sizes, etc.).
>>>
>>> Anyways - I definitely think this is something that should be l
I don't want to destroy your idea, but GRAB sounds like CRAP as well and
you can think of the associated sentences ;)
On 12/22/2015 09:31 PM, Richard Bell wrote:
> GRAB = Gnu RAdio Basic installer
>
> Then we can say things like "Go GRAB it" when referring to a needed module
>
> On Tue, Dec 22,
Hi!
I've played around with GPU computing using OpenCL and thought about an
integration in VOLK. Actually, I have implemented a proof of concept [0]
and as example a kernel, which multiplies two NxN matrices.
The result of running volk_profile using my GeForce GT 730M looks like this:
[blub
Hey,
You are completely right, that's the point. The matrix is of the size
1000x1000 and it is faster than the generic implementation above 500x500
(just a rough estimate). Most use-cases in gnuradio do not exploit this
case.
But, if you want to promote VOLK outside the gnuradio context, this
On 12/18/2015 12:30 AM, Tom Rondeau wrote:
> On Thu, Dec 17, 2015 at 1:14 PM, Sylvain Munaut <246...@gmail.com> wrote:
>
>> Hi,
>>
>>> RUN_VOLK_TESTS: volk_32f_x2_matrix_nxn_multiply_puppet_32f(100,10)
>>> generic completed in 28482ms
>>> a_opencl completed in 13364.3ms
>>
>> Question is
that the VOLK ctest checks
input and output buffer (which is a good feature!) but I haven't seen a
hint in the error message which assert failed. Could have been my fault
as well!
Greetings
Stefan
On 11/12/2015 04:29 AM, Tom Rondeau wrote:
> On Wed, Nov 11, 2015 at 8:32 AM, Stefan Wunsch <
> s
About the use of VOLK (and random number generators):
I see two large groups of users. The one group knows everything about
their CPU but little about SIMD, the other one knows all about SIMD but
almost nothing about their CPU.
The first group uses VOLK because they call a VOLK function and get
Aaaah I solved it. Never ever write in a VOLK kernel to your input
buffer! This throws no errors but it fails during the ctest. So I
suppose the first test compares the output and the second one the input
buffers?
Greetings
Stefan
On 11/11/2015 01:45 PM, Stefan Wunsch wrote:
> Hi!
>
&g
Hi!
I have some issues with the (understanding of the) behaviour of the VOLK
test-cases (defined in kernel_tests.h).
Each test defined in kernel_tests.h runs two times. Now I have the
problem that the first one succeeds but the second one fails.
I do not understand why the icompare function
Hi!
I have implemented a SIMD accelerated Mersenne-Twister as a VOLK kernel.
The performance is pretty good with up to 350% performance increase
compared to a conventional Mersenne-Twister (used is the boost.random
implementation with O3 compiler flag).
Now the problem: The code isn't completely
em.
>
> Of course, that's not really a benchmark for all systems. What about 32
> bit? What about ARM? What about clang? Can anyone try to make a Windows
> build?
>
> Best regards,
> Marcus
>
> On 02.09.2015 14:10, Stefan Wunsch wrote:
>> Hi!
>&
Hi!
I have discovered that the implemented random number generator in
gnuradio (see file [0]) is almost older than me. As written in the code,
the implementation is taken from 'Numerical recipes in C' (see version
from 1992). The problem is that this algorithm is really bad compared to
current
Hi!
I want to present you a OOT module which provides the functionality of
the NaCl crypto library for GNU Radio. The NaCl library is a well known
library written by Daniel J. Bernstein, Tanja Lange and Peter Schwabe
[0]. Because the library is not maintained by themselves, I have chosen
the well
Hi,
looks great! gnuradio.org in this style would be awesome ;)
But I have a question about the update mechanism. If I change or add the
manifest file in my repo on github (gr-radar), how does cgran update its
database? Are there any update cycles or is it done manually?
Greetings
Stefan
On
Hi!
As a former GSoC student I can give you some advice ;)
Actually there are some wiki pages about GSoC. Check out [0]. If you
don't have an idea for a project, there are some suggestions.
But I like to cite the wiki: 'Remember that these are ideas and are
merely meant as an inspiration for you
. But I need continuous streaming and not burst.
Any help in this direction is much appreciated.
Thanks. Best,
Daniele
On 22/07/2014 19:14, Stefan Wunsch wrote:
Hey Daniele,
I have done the radar toolbox and implemented a synced USRP interface
(USRP Echotimer).
You are right
Hey Daniele,
I have done the radar toolbox and implemented a synced USRP interface
(USRP Echotimer).
You are right, the USRP Echotimer does align the timestamps of the TX/RX
commands on both USRPs. But if you connect them by MIMO, the time and
clock are pretty good in sync. Therefore I think the
differ from a target of the range R modulus R_max.
Greetings!
Am 16.07.2014 08:08, schrieb Vanush Vaswani:
Nice. I don't know much about radar. Is range related to EIRP?
On Wed, Jul 16, 2014 at 1:14 AM, Stefan Wunsch
stefan.wun...@student.kit.edu wrote:
Hi,
The Radar Toolbox has new features
Hi,
The Radar Toolbox has new features!
First new feature of the Radar Toolbox is a Dual CW Radar. It is
implemented as simulation and tested with USRPs. This setup is much more
better than the previous FSK Radar!
Check out my development blog for a demonstration video and further
information.
Hi!
The radar toolbox has new features! GUIs for scatter plots of two target
attributes and time plots of a single target attribute are implemented.
All GUIs are real time and multi target capable.
Check out my blog [0] and the demonstration video [1] with target
trajectory video and a screen
Hi!
I try to add a QT GUI to my OOT module (gr-radar). I have some issues
with including the QT stuff in cmake and swig.
The problem is this error:
## /gr-radar/swig/../lib/range_velocity_diagram.h:45: Error: Syntax
error in input(3).
## make[2]: *** [swig/radar_swigPYTHON_wrap.cxx] Error 1
##
Stefan Wunsch:
Hi!
I try to add a QT GUI to my OOT module (gr-radar). I have some issues
with including the QT stuff in cmake and swig.
The problem is this error:
## /gr-radar/swig/../lib/range_velocity_diagram.h:45: Error: Syntax
error in input(3).
## make[2]: *** [swig
Hi!
The GNU Radio Radar Toolbox has some nice new features!
First the USRP interface for synchronized TX/RX streams is finished. It
ensures that any waveform given by a tagged stream is received with only
a constant delay due to hardware delays. Therefore a MIMO connection
between two USRPs is
Hi!
First of all thanks to all of you for the acceptance, I am very glad to
work on this great project!
Finally I gathered all information! I'll publish my gr-radar toolbox
within the kit-cel account [0]. This link will be permanent.
Furthermore I will blog about my progress [1] that you can
Hi!
Thanks a lot for the feedback on the mailings list and on Google
Melange! I have integrated your suggestions in the actual proposal on
github [1].
Comments are still welcome! I left a note on the Melange page as well.
Best regards
Stefan W.
[1] https://github.com/stwunsch/gsoc-proposal
Hi!
My name is Stefan Wunsch and I would like to make a proposal for GSoC
2014. My project of interest is the radar toolbox as mentioned on the
wiki page on gnuradio.org.
I am a fifth semester student in physics at the Karlsruhe Institute of
Technology (KIT) in Germany
45 matches
Mail list logo
