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

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. >

Re: [Discuss-gnuradio] Testing crystal accuracy

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

[Discuss-gnuradio] Correct multiple audio cards clock differences

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)

Re: [Discuss-gnuradio] Testing crystal accuracy

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

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

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

[Discuss-gnuradio] Testing crystal accuracy

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

Re: [Discuss-gnuradio] Testing crystal accuracy

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

Re: [Discuss-gnuradio] Testing crystal accuracy

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

Re: [Discuss-gnuradio] Testing crystal accuracy

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

[Discuss-gnuradio] CMake Error

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

Re: [Discuss-gnuradio] Gnuradio 802.11g

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

Re: [Discuss-gnuradio] Moving Average Block

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

Re: [Discuss-gnuradio] Gnuradio 802.11g

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

Re: [Discuss-gnuradio] Gnuradio 802.11g

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

Re: [Discuss-gnuradio] Moving Average Block

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

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

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

Re: [Discuss-gnuradio] Testing crystal accuracy

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