Hi all..Thanks Ron and Federico for your replies. Federico I am now using
a USRP N210 to do the recording. The console doesn't outputs any 'O's but
instead it outputs a series of 'D's. Now I am also getting synchronized
when I use a live signal but after few samples my Gnu Radio's light is dim
and
Stefan,
First off I definitely want to encourage investigations of this sort: so
even though I have some thoughts similar to Sylvains/Tom's about whether
VOLK is the right place to do this, I definitely want to encourage *trying*
this, since you never know - we could be entirely wrong about whethe
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 how
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
fea
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 how does that number change for smaller problem sizes ?
This reminds me of http://bash.org/?5273
Just to make this answer not completely pointless:
* Did you search google for narrowing your search to the UMTS uplink
channels? https://en.wikipedia.org/wiki/UMTS_frequency_bands
* Did you try raising the RX Gain? Try something like 50 dB. 76 is the
maxi
Probably the best way to do this is to get your phone to either tell you
the ARFCN it's on (and not many do), or the cell ID. If you get a cell ID,
you'd need to scan the downlink frequencies for that particular cell ID.
Once you find the downlink frequency, the uplink should be a constant
offset a
Thanks for your reply,
I forgot to mention-
is there a way to do so without touching the phone at all?
the phone is hidden for all i know, my goal is to find it.
Thanks again,
Meny
2015-12-17 23:13 GMT+02:00 Karl Koscher :
> Probably the best way to do this is to get your phone to either tell yo
I don't want to speak for Vingnu but I believe there might be some confusion in
terminology here.
I think Vingnu is trying to accomplish the following:
Sweep from 1GHz to 2GHz with constant tones increasing in steps of 60Mhz, with
each tone held for 250usecs, and that is all.
So 1GHz held for 2
Hi guys,
I want to know which frequency my cellular phone is using (for uplink -
UMTS).
I'm using USRP B210, i tried the spectrum analyzer tool but i don't really
know what to expect- isn't the transmitting power of my cellular supposed
to be higher (in a single frequency) than all other frequencie
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 how does that number change for smaller problem sizes ?
And what would be the average problem size encountered in real env.
For SIMD optimizat
If you're still seeing O's, but they are getting rare, this might be a
good time to play the buffer increase tricks again.
Cheers,
Marcus
On 17.12.2015 18:21, Saulo Queiroz wrote:
> thanks for the explanation ;)
>
> On 17 December 2015 at 15:10, Marcus Müller
> wrote:
>
>> ha! "O"s in your outp
Yes, that is what i'm doing now.
On 17 December 2015 at 16:43, Marcus Müller-3 [via GnuRadio] <
ml-node+s4n57347...@n7.nabble.com> wrote:
> If you're still seeing O's, but they are getting rare, this might be a
> good time to play the buffer increase tricks again.
>
>
> Cheers,
> Marcus
>
> On 17
thanks for the explanation ;)
On 17 December 2015 at 15:10, Marcus Müller
wrote:
> ha! "O"s in your output mean that the USRP source had to drop samples,
> because your computer was slower at processing them than the USRP was at
> producing them, filling up the buffers, until they were full to t
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 buil
ha! "O"s in your output mean that the USRP source had to drop samples,
because your computer was slower at processing them than the USRP was at
producing them, filling up the buffers, until they were full to the brim
and nothing more would fit.
Of course, reducing the CPU load in this scenario, e.g
Yes.
I forgot to mention that I used QPSK 1/2 in the experiments.
On 17 December 2015 at 14:01, Marcus Müller-3 [via GnuRadio] <
ml-node+s4n57342...@n7.nabble.com> wrote:
> Hm, do you see "O"s on the output?
>
> On 17.12.2015 15:39, Saulo Queiroz wrote:
>
> > well, I tried again and, again, FFT
Hm, do you see "O"s on the output?
On 17.12.2015 15:39, Saulo Queiroz wrote:
> well, I tried again and, again, FFT behaved better.
> In case someone else wanna give a try, flowgraphs are attached.
>
>
> On 17 December 2015 at 12:34, Marcus Müller
> wrote:
>
>> Hm, that is an interesting result.
>
Hi,
To complement Ron's answer, when working with a recording, there is no need
to use the stream to vector -> vector to stream "trick" (at least in my
experience). It should be used when making the recording instead. Regarding
your recording in particular, how did you obtain it? Are you sure no
sa
Hi Ahsan, hi list,
because this happens very often (not primarily because of you, Ahsan,
don't worry :) ! ):
If you want to share textual information, please copy the *text* to the
clipboard and paste it to your emails as text, and do not make a
screenshot of text; that's just hard to use and/or i
It looks like it's doing a little better. I would try deleting (or
bypassing) that Multiply Const block. It may actually be causing trouble
for the gr-isdbt OFDM acquisition block.
If you do get things running, the viterbi_decoder block needs to be set
to Code rate 2/3.
Ron
On 12/17/2015 05
German DVB-T is 1/4 guard interval since they're using SFN's. In the
flow graph picture that Ahsan sent previously, not all of the blocks are
visible, but the disabled gr-isdbt Ofdm sym acquisition block is
configured incorrectly.
For either OFDM acquisition block, the CP length should be 2048
Thank you Tom for the reply. The problem came from pybombs. Seems that in
the pybombs version I had, the recipe for gnuradio had -DENABLE_GR_LOG=Off.
So a clean build with the ...GR_LOG=On fixed it. Plus in the latest pybombs
version the recipe has been updated and most of the var config_opt's have
Hi Ahsan,
The signal does look good indeed. I'm guessing the problem is that nothing
is output from the OFDM sym acquisition blocks (both from gr-dvbt and
gr-isdbt?). In any case, are you sure about those transmission parameters?
Did you check other CP lengths? gr-isdbt includes a small grc file to
Hm, that is an interesting result.
The point is that the polyphase "magic" that allows decimation before
pushing samples through a FIR is mathematically 100% equivalent to doing
the decimation after the FIR.
Nearly the same goes for (non-decimating) FIR vs FFT filter: whereas the
FIR really just
Hi
In my "through-the-air" tests with a couple of B210s the FFT filters
presented much lower
FER in comparison to the FIR filters at the Rx side. According to [1], the
"FFT filters"
downsamples after filtering while FIR downsamples before filtering.
cheers
[1]
http://www.trondeau.com/blog/2014/2
Thanks a lot for that solution! I'll try it :)
Best regards,
Israel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Marcus,
That extremely low signal level is due to a Multiply Const block in the
flow graph set to 0.00055242272. In the gr-dtv in-tree version, I've
deleted that block.
Ron
On 12/17/2015 02:25 AM, Marcus Müller wrote:
Can you crank up the USRP gain further? An average PSD value of 10^-14
in
Can you crank up the USRP gain further? An average PSD value of 10^-14
indicates there's still room for amplification, maybe. What
Daughterboard are you using?
Just out of interest, because improvised a ~760MHz monopole antenna not
so long ago: What kind of antenna are you using?
Best regards,
Mar
Hi Vingnu,
> you are right I hope now you came to know my problem,I have got same
> question when i have seen those examples so I had asked question,
> whether am I able to generate such kind of continuous wave from gnuradio(I
> am having hardware USRP E310) or not?
To be honest, you don't really
30 matches
Mail list logo
