Hi folks, just pushed a beta of a new OOT module set (gr-guiextra) for GR
3.8 on github. Bringing more GUI widgets to the interface. More to come
but here's what's included so far:
Dial - Think of this as your volume dial control. Supports both variables
and messages.
Digital Number Control (Fr
or not for recording purposes
(better yet preventing huge blind-saving files), and to better pass the
doppler frequency through to GNURadio. So I've forked it (
https://github.com/ghostop14/gr-gpredict-doppler.git) and added a bunch of
new features:
doppler block:
- Now adds freq output b
e sense, 500 GB file but you only want a minute or two of the
sample rather than having to go through the whole thing. So I put one
together and posted up on github
(https://github.com/ghostop14/gr-sql).
Basic to start. Has a command-line tool called grsql (the readme has
some examples) to extrac
I ran into it earlier today with the gr-osmosdr module and libfreesrp that
produced errors, but I had run into it in some of the modules I had
developed that are up in pybombs (gr-clenabled, gr-lfast, and gr-grnet)
when I first moved to Ubuntu from a straight debian install. As soon as I
realized
I had messed with psk31 a while back. There's a gnuradio module to decode
and some example GRC's to send and receive that I had used here:
https://github.com/tkuester/gr-psk31 that may help you out. The flowgraphs
in the examples directory already have all the blocks set up to receive.
On Thu,
Took your advice on the cmake OpenCL magic and incorporated it. Let me
know how it works for you. Verified it worked correctly on Ubuntu 16.04
and debian.
On Mon, May 8, 2017 at 6:18 AM, GhostOp14 wrote:
> Looks like the last batch of filter updates missed uploading that file.
> It&#x
commit? It is, indeed, not there:
>
> anon@anon:~/gr-clenabled$ find . -name "fir_filter.h"
> anon@anon:~/gr-clenabled$
>
> On Sun, May 7, 2017 at 5:44 PM, GhostOp14 wrote:
> > Hi Anon. I set it up for 1.2. The biggest gotcha I've run into in the
> > buil
Hi Anon. I set it up for 1.2. The biggest gotcha I've run into in the
build process is missing the cl.hpp file, but how to get it can vary by
OS. There's some setup notes in the setup_help directory for debian and
Ubuntu that may help you out. What OS are you running it on?
On Sun, May 7, 2017
1, 2017 at 5:38 PM
Subject: Re: [Discuss-gnuradio] Fwd: What value is in in[noutput_items+1]?
To: GhostOp14
Cc: GNURadio Discussion List
First, set_history(2) means there will be 1 old sample, not two. (yeah
go figure ... but the default value is '1' and means "no history"
Nathan, thanks for the reply. This can actually explain a discrepency I
see in another custom quad demod block I have.
So what does that mean in terms of the value when I access
in[noutput_items]?
If I get noutput_items=8192, does it align like this?
in[0] = history1
in[1] = history2
in[2..8191]
I was just looking at that tutorial for something else. May take me a
couple weeks to dig into it but I'll tackle that one next and see what I
can do with it.
-- Forwarded message --
From: sdrgpu
Date: Fri, Apr 28, 2017 at 9:51 AM
Subject: Re: [ghostop14/gr-clenabled] PFB
I can definitely take a look at it. Is it the block that comes up as
"Polyphase Clock Sync" in the block search?
-- Forwarded message --
From: sdrgpu
Date: Fri, Apr 28, 2017 at 8:28 AM
Subject: [ghostop14/gr-clenabled] PFB Clock Recovery Block (#1)
To: ghostop14/gr-cle
t: Re: [ghostop14/gr-lfast] Is gr-lfast now faster than gr-clenabled?
(#1)
To: ghostop14/gr-lfast
Cc: ghostop14 , Comment
I see. Page 40 of your article "Study on Implementing OpenCL in Common
GNURadio Blocks" showed 378 MSPS performance for a block size of 24576. I
assume that did not inc
-- Forwarded message --
From: GhostOp14
Date: Thu, Apr 27, 2017 at 3:52 PM
Subject: Re: [ghostop14/gr-lfast] Is gr-lfast now faster than gr-clenabled?
(#1)
To: ghostop14/gr-lfast <
reply+00c635150808fd20a8da1fa32ba004859c8b21e902b86b2a92cf00011519f1eb92a169ce0d
SLv23_method'. Go into the src directory and manually
finish the apache thrift build then go back to the pybombs install and
everything will run through fine.
Now that I know the combo to consistently reproduce the issue that should
help hunt it down.
Thanks!
-- Forwarded message --
AM
Subject: Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?
To: discuss-gnuradio@gnu.org
Dear Ghost,
On 04/26/2017 01:01 PM, GhostOp14 wrote:
> I tested it as a single task in OpenCL on a GPU and the performance
> was horrible so I want to get the same algorithm running on an FPGA
> and se
- Forwarded message --
From: Marcus Müller
Date: Wed, Apr 26, 2017 at 6:52 AM
Subject: Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?
To: GhostOp14
Hi Ghost,
would you mind sending that mail to the mailing list instead of me in
private? I'm certainly not the only one that can
17 matches
Mail list logo
