Re: [Discuss-gnuradio] gr-osmosdr issues ?

[Chris Kuethe]

After finding this some of the sample rates make more sense:

> The sample rates are dictated by the RTL2832U chip, not the tuner chip.
> The RTL2832U can sample from two ranges ...
> 225001 to 30 and 91 to 320.
> Pick any number that lies in either of those two ranges.
> (http://forums.radioreference.com/software-defined-radio/305969-rtl-sdr-sample-rate-calculations.html#post2322632)

I am able to reproduce your audio problem using the uhd source
directly, or an osmocom source with either usrp or rtlsdr hardware. I
think this is a pulseaudio problem; specifying the audio device to
"hw:1,0" for direct access gives me good audio.

With or without an audio sink, I get the PLL message at flowgraph
startup. I'm not sure the PLL message means much if there are only one
or two messages, and the recording looks sane.


On Mon, Jan 11, 2016 at 1:08 PM, Jean-Michel FRIEDT
 wrote:
> Thanks for the answers. All sampling rates are in the 1.5-2.5 MHz range,
> namely 11025*128=1.4112 MHz when decoding POCSAG, or 48000*32=1.536 MHz when
> decoding commercial FM (for these trivial tests). The issue about
> synchronization only arises when an audio sink is used: sending the data to
> a named pipe or scope sink displays the "PLL not locked" message but the
> decoding/display look fine. I should emphasize that
> rtl_fm -f 104.4e6 -M wbfm -s 20 -r 48000 - | aplay -r 48k -f S16_LE
> (running a friend's computer) works perfectly well, hence my concern about
> gr-osmosdr at opposed to the RTL libs.
>
> JM
>
>
>> It's hardly a trivial report; RTL devices with gr-osmosdr are a very
>> commonly used platform.
>>
>> I've seen similar messages from gqrx, but sound quality has not been
>> impacted. My guess is that this may be related to rapid retuning for
>> rtl devices, which basically involves not waiting for the PLL to lock.
>>
>> Does osmosdr-->nullsink display the same message?
>> What about rtl_sdr ... > /dev null?
>> Does this only happen at certain sample rates or at any rate? And are
>> you using a supported sample rate?
>>
>> https://github.com/csete/gqrx/commit/d805c426f24f987cdb16e37bbab564d30da473c2
>>
>> On Mon, Jan 11, 2016 at 11:16 AM, jmfriedt
>>  wrote:
>>>
>>> My apologies for such a trivial bug report, but has anyone experienced
>>> issues with gr-osmosdr
>>> "lately" (not sure when the problem started) about "PLL not locked" and
>>> data flow rate mismatch
>>> in gnuradio data flows ?
>>>
>>> I have a couple dozen RTL2832U based dongles used for various SDR
>>> activities which have been
>>> working quite flawlessly until this summer at least. Being currently in
>>> the process of preparing
>>> the new teaching semester, I just discovered that *all* dongles (E4k,
>>> R820T or R820T2) experience
>>> the same lack of PLL locking and data flow rate mismatch when connected
>>> to USB ports *on laptops*
>>> (tested on four different laptop models, yet all running Debian/GNU Linux
>>> distributions, testing
>>> and sid releases). The audio output in such a simple decoding stream as
>>> Osmosdr Source - Low pass
>>> filter - WBFM decoder - audio output is not continuous and of very bad
>>> quality. The *same* dongles
>>> connected to desktop setups with the same Debian/GNU Linux distribution
>>> exhibit no issue: stream
>>> rate is consistent and sound quality excellent. Of course searching on
>>> the web for "PLL not locked"
>>> yields a couple of million hits explaining that the tuned frequency range
>>> is not within the
>>> bandwidth of the dongle VCO, which is not the case here.
>>>
>>> Has anyone seen reports of this issue before ?
>>>
>>> Thanks, JM
>>>
>>> --
>>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000
>>> Besancon, France
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>> --
>> GDB has a 'break' feature; why doesn't it have 'fix' too?
>>
>
>
>
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000
> Besancon, France
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Testing crystal accuracy

[Marcus Müller]

Hi Jason,

I shouldn't have hit the send button yesterday and went to bed right after.
Had a night of bad sleep; I realized my formulas only applied to the
case of real valued signals.
Your dongles won't be giving you cosines in complex baseband for a
signal they see at $f_\text{offset}$;
they will give you complex sinusoids
$e^{jf_{\text{offset},1}t}$ and $e^{jf_{\text{offset},2}t}$, respectively.
To be complete, there'd also be a phase offset, so it'd be
$e^{j(f_{\text{offset},1}t+\varphi_1)}$, and
$e^{j(f_{\text{offset},2}t+\varphi_2)}$.

Now, multiplication of these really just is addition of the exponents, so
$e^{j(f_{\text{offset},1}t+\varphi_1)}
e^{j(f_{\text{offset},2}t+\varphi_2)} =
e^{j((f_{\text{offset},1}+f_{\text{offset},1})t+\varphi_1+\varphi_2)}$
which means you'll only see the "sum frequency".
That's why you'd use the "multiply conjugate" block instead:
\documentclass{article} \usepackage[utf8x]{inputenc}
\usepackage{amsmath} \usepackage{amsfonts} \usepackage{amssymb}
\usepackage{trfsigns} \DeclareMathOperator*{\argmin}{arg\,min}
\usepackage{tikz} \usepackage{circuitikz}
\usepackage[binary-units=true]{siunitx} \sisetup{exponent-product =
\cdot} \DeclareSIUnit{\dBm}{dBm} \newcommand{\imp}{\SI{50}{\ohm}}
\newcommand{\wrongimp}{\SI{75}{\ohm}} \pagestyle{empty} \begin{document}
\begin{align*} e^{j(f_{\text{offset},1}t+\varphi_1)}
\overline{e^{j(f_{\text{offset},2}t+\varphi_2)}} &=
e^{j(f_{\text{offset},1}t+\varphi_1)}
e^{-j(f_{\text{offset},2}t+\varphi_2)}\\ &=
e^{j(f_{\text{offset},1}t+\varphi_1)}
e^{j((-f_{\text{offset},2})t-\varphi_2)}\\
&=e^{j((f_{\text{offset},1}-f_{\text{offset},2})t+\varphi_1-\varphi_2)}
\end{align*} \end{document}

Regarding your splitter:
Usually, splitters don't introduce nonlinearities, so you should be fine.

Best regards,
Marcus

On 12.01.2016 19:47, Jason Matusiak wrote:
> Thanks Marcus, that helps a lot.  
>
> Since I have to multiply the resulting offsets against each other, that
> means I will need to run a splitter from my sig-gen to the two dongles. 
> Is there any concern that non-linearities in the two legs of the
> splitter would effect the results?
>
> Also, what should I do about the transition width on the LPF?
>
> Thanks for the thorough math explanation, that was a good lesson in what
> is going on.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Correct multiple audio cards clock differences

[Murray Thomson]

Hi,

I'm using three audio cards in my flow graph. The internal and a USB audio
cards run at 96 kHz and I use a virtual audio card with 5 subdevices
loading the snd_aloop kernel module that runs at 48 kHz.

I've noticed that after some days of running there seems to be a delay
(around 1 second) processing the signal.

I was wondering if this could be due to the differences in the clocks of
the audio cards. Is there a way to correct these differences? I can afford
losing data every now and again, but an increasing delay it's a problem for
me.

Thanks,
Murray
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Testing crystal accuracy

[Marcus Müller]

Oh, sorry, I forgot to hit the "replace LaTeX by rendered formulas"; let
me re-do that, before I comment on your comments :)

Capture the same reference tone at $f_\text{ref}$ with both dongles,
tuned to $f_\text{tune} = f_\text{ref}-f_\text{offset}$, choose
$f_\text{offset}\approx \frac{f_\text{sample}}3$.
You would see a baseband tone at $f_{\text{offset},1}$ and
$f_{\text{offset},2}$, respectively, and since no two oscillators are
identical, $f_{\text{offset},1}\ne f_{\text{offset},2}$.
W.l.o.g., let $f_{\text{offset},1}$ be the tone as seen by your
"improved" dongle.

Multiply both signals; what should happen is intermodulation; use a
low-pass filter with a cutoff of ca $\frac{f_\text{sample}}4$, so that
you just get the difference frequency at $f_{\text{offset},2}\pm
f_{\text{offset},2}$.

Qt frequency sink, or quadrature demod->Qt time sink.

Cheers,
Marcus
On 12.01.2016 18:43, Jason Matusiak wrote:
> Thanks for the quick response Marcus
>
> Since my Latex isn't very good (as in pretty much non-existent). Let me
> see if I can rewrite what you recommended in my dumbed down language and
> see if I am close.:
>
> *I have two dongles, dongle 1 will be my modified dongle, dongle 2 will
> be my un-modified dongle.
>
> *Put a a known reference tone into each of the dongles where Ftune =
> Fref - Foffset
> ** Foffset should be roughly a third of the sample rate
> **An example at a sample rate of 1.024Msps would be a reference tone at
> 98MHz, and then tune the dongles to 97.659MHz
>
> *I'll now see a baseband signal for both dongles whose offsets won't be
> exactly the same.
>
> *Multiple the resulting signals found above against each other (offset,1
> * offset,2)
> *Pass that through a LPF with a cutoff of Fsample/4, or 256khZ in this
> case
> **This will give the difference between the frequencies at frequency at
> Foffset,1 +/- Foffset,2
>
> *perform a QT freq sync or a quad demod into a QT time sink to compare.
>
> Is that close?  I think I am missing something in there, and I have a
> feeling that it has to do with the multiplication step as that makes the
> least amount of sense to me.  Any way to enlighten me on what I am
> missing above?  Thanks!

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] use of CCSDS 27 encoder-decoder blocks

[Hitesh Kasera]

hello tom,
i tried to put a block of packing bits after FEC decoder block but still
received data is not same as transmitted. here i am working in simulation
environment not on air so i think there will not be any delay problems.

Hitesh

On Mon, Jan 11, 2016 at 10:54 PM, Tom Rondeau  wrote:

> On Fri, Jan 8, 2016 at 12:44 PM, Hitesh Kasera 
> wrote:
>
>> thanks tom for your reply. as you told me to use fec api blocks i tried
>> to use fec encoder and decoder blocks but still my output is not same as
>> input. may be i am missing something while i am using these blocks. i have
>> attached the image and .grc file of my flowgraph.
>>
>> Hitesh
>>
>
>
> You probably need to pack your bits after the FEC decoder block. There
> might also be some offsets that'll you'll need to deal with, though
> probably not in this case. If you add anything with a filter (like a
> modulator/demodulator), there will be a group delay you'll need to deal
> with and figure out where the start of your actual information bits is.
>
> Tom
>
>
>
>
>
>> On Mon, Jan 4, 2016 at 8:30 PM, Tom Rondeau  wrote:
>>
>>> On Fri, Jan 1, 2016 at 3:17 AM, Hitesh Kasera 
>>> wrote:
>>>
 Hi everyone,

 I am trying to use ccsds 27 encoder-decoder to transmit some data. The
 decoded data is not same as transmitted. As a source i am transmitting ones
 and zeros but after decoding sometimes i am receiving values which are
 greater than 1.  i am not able to recognize where am i going wrong. if
 anyone has any idea please tell me. i have attached both grc file and png
 image of my flow graph.

 Best Regards,
 Hitesh

>>>
>>>
>>> Changing the problem a bit, I'd recommend moving away from the CCSDS
>>> encoder/decoder blocks and using the FEC API blocks, instead. See:
>>>
>>> http://gnuradio.org/doc/doxygen/page_fec.html
>>>
>>> The CC Encoder and CC Decoder are basically the CCSDS codes (you might
>>> have to swap the two polynomials; I always forget off the top of my head
>>> which is called which code here).
>>>
>>> Tom
>>>
>>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Testing crystal accuracy

[Jason Matusiak]

I have a handful of the NooElec blue USB DVB-T receivers that we
occasionally use at work.  I managed to get a hold of a TCXO to replace
the crystal on the board for an attempt at better accuracy (with less
drift).

The dongle seems to be functioning fine (so I know that the oscillator
is functioning OK), but I can't seem to figure out a way to quantify how
much of an improvement I can realize from the swap (if at all).

Is there something simple I am missing that I can do in a GRC script to
test the difference between a modified and unmodified dongle to compare
the benefits of the TCXO?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Testing crystal accuracy

[Marcus Müller]

Capture the same reference tone at $f_\text{ref}$ with both dongles,
tuned to $f_\text{tune} = f_\text{ref}-f_\text{offset}$, choose
$f_\text{offset}\approx \frac{f_\text{sample}}3$.
You would see a baseband tone at $f_{\text{offset},1}$ and
$f_{\text{offset},2}$, respectively, and since no two oscillators are
identical, $f_{\text{offset},1}\ne f_{\text{offset},2}$. W.l.o.g., let
$f_{\text{offset},1}$ be the tone as seen by your "improved" dongle.

Multiply both signals; what should happen is intermodulation; use a
low-pass filter with a cutoff of ca $\frac{f_\text{sample}}4$, so that
you just get the difference frequency at $f_{\text{offset},2}\pm
f_{\text{offset},2}$. Qt frequency sink, or quadrature demod->Qt time sink.

Best regards,
Marcus


On 12.01.2016 16:07, Jason Matusiak wrote:
> I have a handful of the NooElec blue USB DVB-T receivers that we
> occasionally use at work.  I managed to get a hold of a TCXO to replace
> the crystal on the board for an attempt at better accuracy (with less
> drift).
>
> The dongle seems to be functioning fine (so I know that the oscillator
> is functioning OK), but I can't seem to figure out a way to quantify how
> much of an improvement I can realize from the swap (if at all).
>
> Is there something simple I am missing that I can do in a GRC script to
> test the difference between a modified and unmodified dongle to compare
> the benefits of the TCXO?
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Testing crystal accuracy

[Marcus Müller]

Hi Jason,
now to comments to your comments:

On 12.01.2016 18:43, Jason Matusiak wrote:
> Thanks for the quick response Marcus
>
> Since my Latex isn't very good (as in pretty much non-existent). Let me
> see if I can rewrite what you recommended in my dumbed down language and
> see if I am close.:
>
> *I have two dongles, dongle 1 will be my modified dongle, dongle 2 will
> be my un-modified dongle.
>
> *Put a a known reference tone into each of the dongles where Ftune =
> Fref - Foffset
> ** Foffset should be roughly a third of the sample rate
Exactly what I had in mind.
> **An example at a sample rate of 1.024Msps would be a reference tone at
> 98MHz, and then tune the dongles to 97.659MHz
>
> *I'll now see a baseband signal for both dongles whose offsets won't be
> exactly the same.
Yep.
>
> *Multiple the resulting signals found above against each other (offset,1
> * offset,2)
> *Pass that through a LPF with a cutoff of Fsample/4, or 256khZ in this
> case
> **This will give the difference between the frequencies at frequency at
> Foffset,1 +/- Foffset,2
>
> *perform a QT freq sync or a quad demod into a QT time sink to compare.
>
> Is that close?
For close being identical , yes :)
>   I think I am missing something in there, and I have a
> feeling that it has to do with the multiplication step as that makes the
> least amount of sense to me.  Any way to enlighten me on what I am
> missing above?  Thanks!
That's modulation. So, the math behind that is:

Let's consider both tones to be cosines. Thanks to Euler, we know we can
express a cosine as ($j$ is the imaginary unit, $j=\sqrt{-1}$)

$\cos x = \frac{1}{2}\left(e^{j x}+e^{-j x}\right)$; therefore, $\cos
\left( f_1 x \right) = \frac{1}{2}\left(e^{j f_1 x}+e^{-j f_1 x}\right)$.

Now, $\cos \left( f_1 x \right) \cos \left( f_2 x \right) = \frac14
\left(e^{j f_1 x}+e^{-j f_1 x}\right)\left(e^{j f_2 x}+e^{-j f_2 x}\right)$.

Let's expand the multiplication of the two (), and use the fact that
$a^b a^c = a^{b+c}$:


\documentclass{article} \usepackage[utf8x]{inputenc}
\usepackage{amsmath} \usepackage{amsfonts} \usepackage{amssymb}
\usepackage[usenames,dvipsnames]{xcolor} \usepackage{trfsigns}
\DeclareMathOperator*{\argmin}{arg\,min} \usepackage{tikz}
\usepackage{circuitikz} \usepackage[binary-units=true]{siunitx}
\sisetup{exponent-product = \cdot} \DeclareSIUnit{\dBm}{dBm}
\newcommand{\imp}{\SI{50}{\ohm}} \newcommand{\wrongimp}{\SI{75}{\ohm}}
\pagestyle{empty} \begin{document} \begin{align*} e^{j f_1 x}e^{j f_2
x}&+e^{j f_1 x}e^{-j f_2 x}&+ e^{-j f_1 x}e^{j f_2 x}&+ e^{-j f_1
x}e^{-j f_1 x}\\ =e^{j f_1 x+j f_2 x}&+e^{j f_1 x-j f_2 x}&+ e^{-j f_1
x+j f_2 x}&+ e^{-j f_1 x+-j f_2 x}\\ = e^{j ( f_1 +f_2)x}&+e^{j( f_1 -
f_2)x}&+ e^{j( -f_1+ f_2)x}&+ e^{j(- f_1 - f_2)x}\\ = {\color{blue}e^{j
( f_1 +f_2)x}}&+{\color{OliveGreen}e^{j( f_1 -
f_2)x}}&+{\color{OliveGreen} e^{-j( f_1- f_2)x}}&+ {\color{blue} e^{-j(
f_1 + f_2)x}}\\ \end{align*} \end{document}

Now, let's sort this, and lo!
\documentclass{article} \usepackage[utf8x]{inputenc}
\usepackage{amsmath} \usepackage{amsfonts} \usepackage{amssymb}
\usepackage[usenames,dvipsnames]{xcolor} \usepackage{trfsigns}
\DeclareMathOperator*{\argmin}{arg\,min} \usepackage{tikz}
\usepackage{circuitikz} \usepackage[binary-units=true]{siunitx}
\sisetup{exponent-product = \cdot} \DeclareSIUnit{\dBm}{dBm}
\newcommand{\imp}{\SI{50}{\ohm}} \newcommand{\wrongimp}{\SI{75}{\ohm}}
\pagestyle{empty} \begin{document} \begin{align*} = {\color{blue}e^{j (
f_1 +f_2)x}}+ {\color{blue} e^{-j( f_1 + f_2)x}}
&+{\color{OliveGreen}e^{j( f_1 - f_2)x}}+{\color{OliveGreen} e^{-j( f_1-
f_2)x}}\\ = \left( {\color{blue}e^{j ( f_1 +f_2)x} + e^{-j( f_1 +
f_2)x}} \right)&+\left({\color{OliveGreen}e^{j( f_1 - f_2)x} +e^{-j(
f_1- f_2)x}}\right)\\ = 2 \cos\left((f_1+f_2)x\right) &+
2\cos\left((f_1-f_2)x\right)\text. \end{align*} \end{document}
Which means that
\documentclass{article} \usepackage[utf8x]{inputenc}
\usepackage{amsmath} \usepackage{amsfonts} \usepackage{amssymb}
\usepackage[usenames,dvipsnames]{xcolor} \usepackage{trfsigns}
\DeclareMathOperator*{\argmin}{arg\,min} \usepackage{tikz}
\usepackage{circuitikz} \usepackage[binary-units=true]{siunitx}
\sisetup{exponent-product = \cdot} \DeclareSIUnit{\dBm}{dBm}
\newcommand{\imp}{\SI{50}{\ohm}} \newcommand{\wrongimp}{\SI{75}{\ohm}}
\pagestyle{empty} \begin{document} \begin{align*} \cos \left( f_1 x
\right) \cos \left( f_2 x \right) &= \frac14 \left[ 2
\cos\left((f_1+f_2)x\right) + 2\cos\left((f_1-f_2)x\right)\right]\\
&=\frac12 \cos\left((f_1+f_2)x\right) +
\frac12\cos\left((f_1-f_2)x\right) \end{align*} \end{document}

Now you see where the low pass filter comes into play:
it filters out the $\cos\left((f_1+f_2)x\right)$ component, leaving you
with $\frac12 \cos\left((f_1-f_2)x\right)$, which is an oscillation with
the difference frequency.

Best regards,
Marcus


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] Testing crystal accuracy

[Jason Matusiak]

Thanks Marcus, that helps a lot.  

Since I have to multiply the resulting offsets against each other, that
means I will need to run a splitter from my sig-gen to the two dongles. 
Is there any concern that non-linearities in the two legs of the
splitter would effect the results?

Also, what should I do about the transition width on the LPF?

Thanks for the thorough math explanation, that was a good lesson in what
is going on.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] CMake Error

[shortwavedude]

Hello! 

Wondering if anyone can comment on this error. I'm running Ubuntu 14.04 which I 
installed gnuradio using apt. The problem that I see is that it's looking for 
gnuradio version 3.7.2. This is the version that got installed when I used apt 
to install. Do I need to provide a path name back to gnuradio?? Any help would 
be appreciated. Thanks!! 


-- Build type not specified: defaulting to release. 
-- Boost version: 1.54.0 
-- Found the following Boost libraries: 
-- filesystem 
-- system 
CMake Error at CMakeLists.txt:94 (find_package): 
By not providing "FindGnuradio.cmake" in CMAKE_MODULE_PATH this project has 
asked CMake to find a package configuration file provided by "Gnuradio", 
but CMake did not find one. 

Could not find a package configuration file provided by "Gnuradio" 
(requested version 3.7.2) with any of the following names: 

GnuradioConfig.cmake 
gnuradio-config.cmake 

Add the installation prefix of "Gnuradio" to CMAKE_PREFIX_PATH or set 
"Gnuradio_DIR" to a directory containing one of the above files. If 
"Gnuradio" provides a separate development package or SDK, be sure it has 
been installed. 


-- Configuring incomplete, errors occurred! 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnuradio 802.11g

[Saulo Queiroz]

Also, in [1]  authors claim a version of gr-ieee802-11 that is
CSMA-CA-capable on N210
(i think you have to switch from master to the agc_and_csma branch in [2]).
However the solution does not implement ACKs i.e. it is suitable only for
WiFi broadcast
communications as is the case of some 802.11p scenarios. Check whether it
can
be adapted to your need.

[1]
https://ssl.webpack.de/www.puschmann.net/download/paper/Bloessl2014_timings.pdf
[2] https://github.com/bastibl/gr-ieee802-11

On 12 January 2016 at 16:46, Marcus Müller  wrote:

> Well, if you implement a lot of the IEEE802.11 in the FPGA, yes, that
> could work. But: then it would hardly be a GNU Radio implementation.
> Also, please don't expect the poor CPU of the E310 to process 20MHz of
> bandwidth itself; it's a power-efficient ARM, and you'll need a relatively
> new PC CPU to run things like FFTs at that rate.
>
> Best regards,
> Marcus
>
> On 12.01.2016 17:40, Gabriel Pechiarovich wrote:
>
> Hi thank you for the reply.
> I have acces to the USRP E310, is it posible that this hardware will
> support the correct timings using the RFNoC?
>
> 2016-01-08 12:59 GMT-05:00 Saulo Queiroz :
>
>> Hi Gabriel,
>> No. In most of boards, the delay between PC and device turns unfeasible
>> the work of critical time operations like csma count down. Depend on your
>> hardware, you can get that with RFNoC module from Ettus, but with hard
>> work.
>>
>>
>> On 8 January 2016 at 17:45, Gabriel Pechiarovich <
>> gaps.18.2...@gmail.com> wrote:
>>
>>> Hi
>>> Is there any fully working implementation for the 802.11g protocol in
>>> gnuradio capable of working as an access point?
>>>
>>> I was wondering if there exist one with the MAc layer fully developed,
>>> since i've only seen simplyfied MAC layers, or is there a software/hardware
>>> limitation.
>>>
>>> Thanks in advance
>>> 
>>> Gabriel Pechiarovich Salas
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>> --
>> Saulo Jorge bq
>> - "Beware of bugs in the above code; I have only proved it correct, not
>> tried it."
>> Donald Knuth.
>>
>
>
>
> --
> Gabriel Pechiarovich Salas
> Red Dragon Games
> Designers and game developers
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Saulo Jorge bq
- "Beware of bugs in the above code; I have only proved it correct, not
tried it."
Donald Knuth.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving Average Block

[Pedro Gabriel Adami]

Dear all,

In addition to my previous response, I'm attaching an image that shows the
formula I'm trying to build in gnuradio (using blocks). But instead of n =
0 and N-1, I need n = 1 and 100 (100 samples). The second picture shows how
I tried to do in Gnuradio, but the moving average block does not get 100
samples the way I need (as we could see in the previous answers).

Timothée told me to use stream to vector, but if I pack them, each 100
samples will become one single information, right? What I need is more like
a controller that gives me 100 samples at a time.

Please, I appreciate if you could give me some tips.

Thanks in advance.

2016-01-08 14:47 GMT-02:00 Timothée COCAULT :

> Whoops, just noticed I didn't reply to all when I answered so my message
> and Pedro's response were not forwarded to the mailing list :
>
> Le jeu. 7 janv. 2016 à 20:28, Pedro Gabriel Adami <
> pedrogabriel.ad...@gmail.com> a écrit :
>
> Dear, Timothée,
>
> Thank you so much. I am doing some tests and I've realized that the
> results are a little strange. That is why I asked.
>
> Let me ask you one more thing: Do you know some block that is capable to
> retain N samples, so I can use them and after that, it retains the next N
> samples? Like a variable where I can "save" the information for a short
> period of time, but my Gnuradio does not have a "variable sink".
>
> Thanks in advance.
> Em 07/01/2016 17:18, "Timothée COCAULT" 
> escreveu:
>
>> Hi Pedro,
>>
>> When you're not sure, the best solution is often to look at the code.
>> If you look at the work function in
>> gr-blocks/lib/moving_average_XX_impl.cc.t, you see that the block first
>> sums the history (of length 100 in your case).
>> For each additional input items, it adds the new item and subtracts the
>> n-100 item, and outputs the current sum.
>>
>> So it will first calculate 1+...+100, then 2+...+101 and so on.
>>
>> Regards,
>> Timothée.
>>
>
>>
>
>
> I don't understand exactly your question but you can use a stream to
> vector to group your items in packets of size N, and plug it into a probe
> signal
>



-- 
Atenciosamente,
Pedro Gabriel Adami
Graduando do 5º período de Engenharia de Controle e Automação no Instituto
Nacional de Telecomunicações - Inatel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnuradio 802.11g

[Gabriel Pechiarovich]

Hi thank you for the reply.
I have acces to the USRP E310, is it posible that this hardware will
support the correct timings using the RFNoC?

2016-01-08 12:59 GMT-05:00 Saulo Queiroz :

> Hi Gabriel,
> No. In most of boards, the delay between PC and device turns unfeasible
> the work of critical time operations like csma count down. Depend on your
> hardware, you can get that with RFNoC module from Ettus, but with hard
> work.
>
>
> On 8 January 2016 at 17:45, Gabriel Pechiarovich 
> wrote:
>
>> Hi
>> Is there any fully working implementation for the 802.11g protocol in
>> gnuradio capable of working as an access point?
>>
>> I was wondering if there exist one with the MAc layer fully developed,
>> since i've only seen simplyfied MAC layers, or is there a software/hardware
>> limitation.
>>
>> Thanks in advance
>> 
>> Gabriel Pechiarovich Salas
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Saulo Jorge bq
> - "Beware of bugs in the above code; I have only proved it correct, not
> tried it."
> Donald Knuth.
>



-- 
Gabriel Pechiarovich Salas
Red Dragon Games
Designers and game developers
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnuradio 802.11g

[Marcus Müller]

Well, if you implement a lot of the IEEE802.11 in the FPGA, yes, that
could work. But: then it would hardly be a GNU Radio implementation.
Also, please don't expect the poor CPU of the E310 to process 20MHz of
bandwidth itself; it's a power-efficient ARM, and you'll need a
relatively new PC CPU to run things like FFTs at that rate.

Best regards,
Marcus

On 12.01.2016 17:40, Gabriel Pechiarovich wrote:
> Hi thank you for the reply.
> I have acces to the USRP E310, is it posible that this hardware will
> support the correct timings using the RFNoC?
>
> 2016-01-08 12:59 GMT-05:00 Saulo Queiroz  >:
>
> Hi Gabriel,
> No. In most of boards, the delay between PC and device turns
> unfeasible
> the work of critical time operations like csma count down. Depend
> on your
> hardware, you can get that with RFNoC module from Ettus, but with
> hard work.
>  
>
> On 8 January 2016 at 17:45, Gabriel Pechiarovich
> > wrote:
>
> Hi
> Is there any fully working implementation for the 802.11g
> protocol in gnuradio capable of working as an access point?
>
> I was wondering if there exist one with the MAc layer fully
> developed, since i've only seen simplyfied MAC layers, or is
> there a software/hardware limitation.
>
> Thanks in advance
> 
> Gabriel Pechiarovich Salas
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> -- 
> Saulo Jorge bq
> - "Beware of bugs in the above code; I have only proved it
> correct, not tried it." 
> Donald Knuth.
>
>
>
>
> -- 
> Gabriel Pechiarovich Salas
> Red Dragon Games
> Designers and game developers
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving Average Block

[Marcus Müller]

Hi Pedro,

$y[n]=\sum\limits_{i=n-N+1}^n {\left|x[i]\right|^2}$ is nothing but the
moving average over the squared magnitude.
Sadly, your formula
$T=\sum\limits_{n=0}^{N-1} {\left|Y[n]\right|^2}$ doesn't specify what T
signifies; is T used as a single sum over N samples' squared magnitudes,
or is it something running (i.e. you get as many Ts as you consider samples.

I just assume you really are looking for a moving average, in which case
your flow graph is correct.
> Timothée told me to use stream to vector, but if I pack them, each 100
> samples will become one single information, right? What I need is more
> like a controller that gives me 100 samples at a time.
Really, I'm not sure where the formula you attached came from, or what
you mean, or if what you mean is what you need...
Maybe you could just write down, explicitely, what *each* output sample
should be (which is why I wrote $y[n]$ rather than $y$).


Best regards,
Marcus


On 12.01.2016 17:27, Pedro Gabriel Adami wrote:
> Dear all,
>
> In addition to my previous response, I'm attaching an image that shows
> the formula I'm trying to build in gnuradio (using blocks). But
> instead of n = 0 and N-1, I need n = 1 and 100 (100 samples). The
> second picture shows how I tried to do in Gnuradio, but the moving
> average block does not get 100 samples the way I need (as we could see
> in the previous answers).
>
> Timothée told me to use stream to vector, but if I pack them, each 100
> samples will become one single information, right? What I need is more
> like a controller that gives me 100 samples at a time.
>
> Please, I appreciate if you could give me some tips.
>
> Thanks in advance.
>
> 2016-01-08 14:47 GMT-02:00 Timothée COCAULT
> >:
>
> Whoops, just noticed I didn't reply to all when I answered so my
> message and Pedro's response were not forwarded to the mailing list :
>
> Le jeu. 7 janv. 2016 à 20:28, Pedro Gabriel Adami
>  > a écrit :
>>
>> Dear, Timothée,
>>
>> Thank you so much. I am doing some tests and I've realized that
>> the results are a little strange. That is why I asked.
>>
>> Let me ask you one more thing: Do you know some block that is
>> capable to retain N samples, so I can use them and after that, it
>> retains the next N samples? Like a variable where I can "save"
>> the information for a short period of time, but my Gnuradio does
>> not have a "variable sink".
>>
>> Thanks in advance.
>>
>> Em 07/01/2016 17:18, "Timothée COCAULT"
>> >
>> escreveu:
>>
>> Hi Pedro,
>>
>> When you're not sure, the best solution is often to look at
>> the code.
>> If you look at the work function in
>> gr-blocks/lib/moving_average_XX_impl.cc.t, you see that the
>> block first sums the history (of length 100 in your case).
>> For each additional input items, it adds the new item and
>> subtracts the n-100 item, and outputs the current sum.
>>
>> So it will first calculate 1+...+100, then 2+...+101 and so on.
>>
>> Regards,
>> Timothée. 
>>
>>  
>>
>>
>
> I don't understand exactly your question but you can use a stream
> to vector to group your items in packets of size N, and plug it
> into a probe signal
>
>
>
>
> -- 
> Atenciosamente,
> Pedro Gabriel Adami
> Graduando do 5º período de Engenharia de Controle e Automação no
> Instituto Nacional de Telecomunicações - Inatel
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] R: Front Panel GPIO on Ettus X310

[Maurizio Crozzoli]

Marcus Müller-3 wrote
> So: you'll really have to define a maximum time that a GPIO toggle may
> stay undetected. This shouldn't be hard -- I mean, in the end, there's
> some application's needs that you'll want to satisfy.

Is it a way to suggest me to use a sleep instruction during the poll loop?

Another question is: why when I set a pin as input the READBACK attribute
says that the level of such pin is high (i.e. 1)? And it is, definitely, as
I can verify with a multimeter!

Maurizio



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979p57759.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Testing crystal accuracy

[Jason Matusiak]

Thanks for the quick response Marcus

Since my Latex isn't very good (as in pretty much non-existent). Let me
see if I can rewrite what you recommended in my dumbed down language and
see if I am close.:

*I have two dongles, dongle 1 will be my modified dongle, dongle 2 will
be my un-modified dongle.

*Put a a known reference tone into each of the dongles where Ftune =
Fref - Foffset
** Foffset should be roughly a third of the sample rate
**An example at a sample rate of 1.024Msps would be a reference tone at
98MHz, and then tune the dongles to 97.659MHz

*I'll now see a baseband signal for both dongles whose offsets won't be
exactly the same.

*Multiple the resulting signals found above against each other (offset,1
* offset,2)
*Pass that through a LPF with a cutoff of Fsample/4, or 256khZ in this
case
**This will give the difference between the frequencies at frequency at
Foffset,1 +/- Foffset,2

*perform a QT freq sync or a quad demod into a QT time sink to compare.

Is that close?  I think I am missing something in there, and I have a
feeling that it has to do with the multiplication step as that makes the
least amount of sense to me.  Any way to enlighten me on what I am
missing above?  Thanks!

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio