Hi,
I'm new to gnuradio and want to do some wireless communication experiments
with it. I runned OFDM examples(rx_ofdm.grc & tx_ofdm.grc) and tried to use
the *tag debug* block to retrieve the CIR information generated during
receiving procedure. Yet what tag debug block outputs is the key-value p
As most of you likely have seen, I've been working on a flowhraph for quite
some time. Using gr-drm and an external FM processor, I have made a sort of
open alternative to HD Radio...because fun.
Anyway, the DRM signals are sampled at 48khz and the FM portion at 192. The
remainder of the graph is
You can count me in too, even if I just sit back and listen, and learn.
I am at least good for a second round.
John
On Fri, Apr 11, 2014 at 11:15 AM, Michael Ossmann wrote:
> On Thu, Apr 10, 2014 at 11:26:54AM -0600, Eric Schneider wrote:
> >
> > Is anyone doing a GnuRadio / SDR meetup in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ken,
welcome to the community!
I'll go ahead and answer in-line, since this seems to make sense here:
On 11.04.2014 23:16, Ken Adams wrote:
> I recently graduated with my degree in Computer Engineering, and
> the GNU Radio project is by far the mos
I recently graduated with my degree in Computer Engineering, and the GNU
Radio project is by far the most complex thing I've desired to work on. I'm
looking for tips on how to get started learning GNU Radio from the ground
up, build custom modules, and help develop the source.
For example, an know
Not a problem - It was under a VM, so that is probably what was causing it.
I ran it at home on bare metal with a HackRF and didn't have any issues.
On Fri, Apr 11, 2014 at 4:10 PM, Tom Rondeau wrote:
> On Wed, Mar 26, 2014 at 4:28 PM, Luke Berndt wrote:
>
>> I get the following error when try
On Wed, Mar 26, 2014 at 4:28 PM, Luke Berndt wrote:
> I get the following error when trying to the run gr-perf-monitorx against
> a flow graph that has an RTL_SDR radio as the source. I recompiled both
> rtl_sdr and gr_osmosdr after enabling performance counters in gnuradio.
>
> The odd thing is
On Fri, Apr 11, 2014 at 1:34 PM, Nick Foster wrote:
> That's very likely it. It's effectively starting with a random guess as to
> the bit timing, and it locks exponentially faster the closer it is to
> correct. So for a worst-case guess, it'll take significantly longer to lock.
>
> --n
>
I woul
That's very likely it. It's effectively starting with a random guess as to
the bit timing, and it locks exponentially faster the closer it is to
correct. So for a worst-case guess, it'll take significantly longer to lock.
--n
On Fri, Apr 11, 2014 at 10:33 AM, Francois Gervais <
francoisgerv...@g
That could explain it. However most of the time it locks just fine even for
the preamble with the same block parameters. I'm not sure what causes this
variability and if I have control over it of not.
Might be related to when the MM clock recovery starts sampling the signal.
Sometimes it's lucky a
To me it looks like it's taking some time to acquire, which is normal for a
closed-loop timing recovery algorithm. This is one reason packets have
preambles. If you need it to lock faster and don't mind some self-noise,
and if the SNR is high enough, you can turn up the gain of the M&M block
(chang
On Thu, Apr 10, 2014 at 11:26:54AM -0600, Eric Schneider wrote:
>
> Is anyone doing a GnuRadio / SDR meetup in the Denver Area?
Count me in, but it may just be the two of us as usual. :-)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https
I'm not sure how the GSOC thing works, but if there is anything I can do
to help make this project happen, let me know!
This very idea has been on my "some day" shelf for far to long...
--Eric
On 03/13/2014 11:41 AM, MITUL VEKARIYA wrote:
Hi
Here's the link for my proposal for the project "Ve
Any idea on this? Should I post the images somewhere else?
On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais <
francoisgerv...@gmail.com> wrote:
> I tried using the M&M clock recovery block as suggested and I have a
> little fidelity problem. I added two screenshot links below which show the
>
Yeah, I'll do the same; enter a variable I haven't created yet. I'm afraid of putting pop-up boxes like this, though. You'll still see the red text in the block and the GRC error button will be enabled to help you track things down, so there will be an indication that you've done something
Sorry to dig up an old thread, but does anyone know of anyone who's
implemented a polyphase filter bank on a USRP FPGA?
John
On Thu, May 9, 2013 at 12:02 AM, Marcus D. Leech wrote:
> Or am I wrong that the resource is in the computer and not in the USRP?
>
>
>
> LD
>
>
>
> It's all in the co
On Thu, Apr 10, 2014 at 7:00 PM, Marcus D. Leech wrote:
> On 04/10/2014 04:13 PM, Ed Criscuolo wrote:
>
>>
>>
>> How hard would it be to pop up a bother box if you attempt
>> to enter with outstanding parameter error(s). Give you
>> a chance to confirm or cancel the enter, because you may want t
On Fri, Apr 11, 2014 at 3:29 AM, Koslowski, Sebastian (CEL) <
sebastian.koslow...@kit.edu> wrote:
> Same here. Thanks for reporting. I pushed a fix to the GRCWG repo,
> should make it into the mainline soon.
>
> Sebastian
I just merged and pushed Sebastian's quick fix for the issue.
Tom
>
On 04/10/2014 01:33 PM, Piotr Potocki wrote:
> First thanks for helping me out!
>
> 1. I found out that in file 'ofdm_equalizer_simpledfe' there is a part
> concerning mapping samples into correct positions (-1,1).
>
> //
> d_constellation->map_to_points(d_constellation->decision_maker(&sym_eq),
Same here. Thanks for reporting. I pushed a fix to the GRCWG repo,
should make it into the mainline soon.
Sebastian
On 04/11/2014 04:27 AM, Dan CaJacob wrote:
> I think this change might be breaking a few things. If anyone else can
> check, please let me know if I'm nuts:
>
> I am running v3.7.
20 matches
Mail list logo
