How can we diagnose make test failures? All tests passed initially, but I
had GRC disabled, so I recompiled everything w/ GRC enabled and this test
failed.
Also, is there a way to re-compile just parts of gnuradio, instead of
recompiling everything?
99% of tests past, only qa_fft_filter failed on
Hi, I am having a basic question about the WX GUI Slider
I am wondering why the Num Steps in WX GUI Slider have to be double the
value than I calculate.
For example, if I have minimum set at 86 MHz and maximum at 108 MHz and I
want steps of 100 kHz I distract 86 from 108 which leaves me with 22 M
On Tue, Jan 21, 2014 at 5:45 AM, Robert Light wrote:
> I thought OpenBTS would use Transceiver52MHz to communicate with B100 and to
> configure the AD9522 to output 52MHz sampling clock. However, with OpenBTS
> working with B100 and WBX I measure 64MHz sampling clock. And I am confused
> here. I d
>
> Aditya - am I to understand that you want to have perfect timing sync?
>
Correct. This is because I want to study how the channel changes across
OFDM subcarriers (caused due to multi-path). Having rotations in the
channel across subcarriers caused by trigger timing offsets is what I want
to el
On Tue, Jan 21, 2014 at 1:03 PM, David Halls
wrote:
> Ah, I see. You want to isolate the effect of the channel. I believe it
> will be difficult, if not impossible, to remove the slight jitter of the
> trigger, even in very high SNR - perhaps others can comment/help?
>
Yes, that is correct. It is
...having said that, I never saw the trigger jitter until I started using a
random data source rather than 'range(packet_len)', do you get jitter in this
case?
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
[discuss-gnuradio-bounces+d
Ah, I see. You want to isolate the effect of the channel. I believe it will be
difficult, if not impossible, to remove the slight jitter of the trigger, even
in very high SNR - perhaps others can comment/help?
From: Aditya Dhananjay [adi...@cs.nyu.edu]
Sen
sorry - I meant to say that adding the additional hack removed the rotation on
the constellation eq'd by h2_est but not the rotation on the constellation eq'd
by h1_est, thus there is still some timing issue. This can seen in the *.png
Aditya - am I to understand that you want to have perfect ti
>
>
>
>
> For the record: The default is 8 bits CRC, so there's a 1/256th chance a
> packet will fail and pass. But then there's also the payload CRC, which
> has 32 bits. Unlikely they'll both pass.
>
I agree. While false positives in the header CRC so happen from time to
time, I've never noticed
>
>
>
> Your solution will work, but you have to admit it's a hack. Who says my
> payload is 3 or 4 symbols long? I'm currently working on the HPD, and
> I'll figure out a way to get this in.
>
Absolutely; this is an unclean hack.
> I guess not consuming the last symbol would be sufficient in mos
Oops, that was a typo. Sorry. I meant 200KHz.
On Tue, Jan 21, 2014 at 12:17 PM, Martin Braun wrote:
> On 01/21/2014 04:23 PM, Aditya Dhananjay wrote:
> > Thanks for trying, Martin.
> >
> > My OFDM Specs are:
> >
> > FFT size = 64
> > CP length = 16
> > bandwidth = 2KHz
>
> Sure you don't mean 2
On 01/21/2014 05:55 PM, Aditya Dhananjay wrote:
> Hello David,
>
> I was facing the exact same issue, and the fix I use is identical to
> yours. I consume 4 symbols less than I need to, so the subsequent packet
> is not lost.
>
> Best,
> Aditya
>
> On Tue, Jan 21, 2014 at 11:14 AM, David Halls
>
On 01/15/2014 09:26 PM, Aditya Dhananjay wrote:
> Issue B: Additionally, I notice that sometimes the header gets so
> corrupted that the CRC check passes (I suppose these false positives
> cannot be helped, unless we have a longer CRC for the header, but that's
> probably a waste).
For the record:
On 01/21/2014 04:23 PM, Aditya Dhananjay wrote:
> Thanks for trying, Martin.
>
> My OFDM Specs are:
>
> FFT size = 64
> CP length = 16
> bandwidth = 2KHz
> carrier freq: centered around 2.437GHz
Do you see these only over-the-air, or only in simulation?
MB
On 01/21/2014 04:23 PM, Aditya Dhananjay wrote:
> Thanks for trying, Martin.
>
> My OFDM Specs are:
>
> FFT size = 64
> CP length = 16
> bandwidth = 2KHz
Sure you don't mean 2 MHz? At this BW, I'm surprised if it worked at all.
MB
___
Discuss-gnurad
Hello David,
I was facing the exact same issue, and the fix I use is identical to yours.
I consume 4 symbols less than I need to, so the subsequent packet is not
lost.
Best,
Aditya
On Tue, Jan 21, 2014 at 11:14 AM, David Halls
wrote:
> Hi Martin,
>
> Making good progress with the relay but on
Hi Martin,
Making good progress with the relay but on another topic, I find if I use a
random data source (rather than the 1...range in the original example) the
trigger signal arrives occasionally one or two samples earlier than expected.
Say we have 96B data this gives 768/48 = 16 data symbol
On 21 jan 2014, at 15:55, Michael Dickens wrote:
> Volker (dl1ksv) and I fixed the build issues with gr-fcdproplus on OSX in the
> past couple of days, and this morning I pushed the gr-fcdproplus port to
> MacPorts < https://trac.macports.org/changeset/116194 >; I also changed the
> gr-osmosdr
Thanks for trying, Martin.
My OFDM Specs are:
FFT size = 64
CP length = 16
bandwidth = 2KHz
carrier freq: centered around 2.437GHz
It is easier to reproduce if I replace the noise block with one that adds
CFO errors.
a) Increase this CFO error until header CRCs fail. Let this stand for a few
se
Volker (dl1ksv) and I fixed the build issues with gr-fcdproplus on OSX in the
past couple of days, and this morning I pushed the gr-fcdproplus port to
MacPorts < https://trac.macports.org/changeset/116194 >; I also changed the
gr-osmosdr port to by default include this new gr-fcdproplus port <
Koslowski, Sebastian (CEL) schreef op 2014-01-21 15:16:
Hi Jeroen,
On 01/21/2014 01:57 PM, jer...@boschma.com wrote:
* I changed the XML file to reflect the additional parameter
...
It boils down to top_block.py, where I see a call to my block with
only 3 parameters while in all files I can
Hi Jeroen,
On 01/21/2014 01:57 PM, jer...@boschma.com wrote:
> * I changed the XML file to reflect the additional parameter
>
> ...
>
> It boils down to top_block.py, where I see a call to my block with
> only 3 parameters while in all files I can see, 4 parameters are
> defined.
Sounds like yo
Hi all,
I just installed the latest stable GNURadio and GRC on windows 7. I am
having problems running the fm radio example on GRC. The error shown on
runtime is "Cannot import name wx-gui". I have PYTHONPATH configured with
"C:\Program Files (x86)\gnuradio\lib\site-packages" and I have wx-gui
pack
Hi all,
I got my things working, up to the point where I decided that an
additional parameter in my custom block would be very helpful. But for
some reason, GRC keeps holding on to my previous version of the block
with 3 parameters instead of my new one with 4 parameters. In the end,
after nu
I thought OpenBTS would use Transceiver52MHz to communicate with B100 and to configure the AD9522 to output 52MHz sampling clock. However, with OpenBTS working with B100 and WBX I measure 64MHz sampling clock. And I am confused here. I didn't compile OpenBTS with resampling option. So where does t
25 matches
Mail list logo
