Re: [Discuss-gnuradio] ferna...@samara.com.es,

> From: > Fernando > Subject: > [Discuss-gnuradio] WBFM > modulation/demodulation high > frequencies highly attenuated > Date: > Wed, 26 Apr 2017 20:02:29 +0200 > > > >

[Discuss-gnuradio] GR-UHD detected ABI compatibility mismatch with UHD Solved

Hi. I had this issue on GNU Radio: - Using Volk machine: avx_64_mmx Traceback (most recent call last): File "/home/tojo/top_block.py", line 118, in tb = top_block() File "/home/tojo/top_block.py", line 81, in __init__ channels=range(1), File

Re: [Discuss-gnuradio] pybombs install with a space in directory name

OK, I see where things are bailing now (I added verbosity to the install). It seems like the offending command is: PyBOMBS.Inventory - DEBUG - Setting state to `fetched' PyBOMBS.Inventory - DEBUG - Saving inventory to file /sharing/shared/Research

Re: [Discuss-gnuradio] WARN: transport stream sync error

Are you saying that there are no sync bytes in my stream? or should i wait until i get byte 0x47 in my udp packet, wait till i get 188 bytes, and send them as an array of bytes in the zeroMQ? Van: "Ron Economos" Aan: "discuss-gnuradio"

Re: [Discuss-gnuradio] WARN: transport stream sync error

The BBheader block expects the Transport Stream to start with a sync byte (0x47) and that a sync byte appears every 188 bytes. There's no sync byte synchronization in the BBheader block, so if the stream doesn't start with a sync byte, you'll get continuous errors. Ron On 04/26/2017 10:56

[Discuss-gnuradio] WBFM modulation/demodulation high frequencies highly attenuated

I'm modulating/demodulating a wide band FM signal and I observe that high frequencies are highly attenuated. This is the diagram And this is the spectrum High frequencies are attenuated more than 40dB over low frequencies. It seems to happen for frequencies above 20Khz. Changing max

Re: [Discuss-gnuradio] Visualizing Amplitude spectrum instead of power spectrum

> I call it simply spectrum too, maybe I should have said > magnitude/phase spectrum. Now I'm confused. Magnitude spectrum is definitely my $|\text{DFT}|$; but you're just looking for a plot of the DFT, right? > Indeed i don't need imaginary part in this case because the spectrum > is real That

[Discuss-gnuradio] WARN: transport stream sync error

Hi, My setup: Linux gnuradio with dvb-s2 tx sample code. adjusted to read from ZeroMQ pull source 5M symbol. in 8psk dvb-s2 3/4 code rate Windows side: 2 programs: 1) program to make udpts stream from webcam(5M) -> send udp stream to 127.0.0.1:1234 2) program to listen to udp port 1234

Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?

Another possibility is to look at the HMM patches for Linux to reduce OpenCL copy load. I read the patches were proposed for 4.11 but didn't make it into that revision. On Wed, 2017-04-26 at 07:01 -0400, GhostOp14 wrote: > Thanks Marcus!  I have been going back and forth with testing still >

Re: [Discuss-gnuradio] Visualizing Amplitude spectrum instead of power spectrum

Hm, I'd call that /spectrum/, simply :) In any case, I don't fully understand, then, how you'd circumvent the need for a real and imaginary part. Your $X_k$ is complex! Cheers, Marcus On 04/26/2017 03:46 PM, Fernando wrote: > Hi!. > > I think the amplitude spectrum is the DFT: > {\displaystyle

Re: [Discuss-gnuradio] Visualizing Amplitude spectrum instead of power spectrum

Hi!. I think the amplitude spectrum is the DFT: {\displaystyle {\begin{aligned}X_{k}&=\sum _{n=0}^{N-1}x_{n}\cdot e^{-i2\pi kn/N}\\&=\sum _{n=0}^{N-1}x_{n}\cdot [\cos(2\pi kn/N)-i\cdot \sin(2\pi kn/N)],\end{aligned}}} So, it has sign. The power spectrum is the absolute value so it has no sign.

Re: [Discuss-gnuradio] ATSC Decode Issues

Getting this conversation back into the discuss-gnuradio thread. Looks like on Kali/debian linux running the latest updates that for some reason the PFB arbitrary resampler is producing the correct number of output samples but incorrect values (confirmed on both Ubuntu and Windows where it

Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?

Thanks Marcus! I do know what the root cause is in the OpenCL implementation of the poor performance. Maybe it'll help provide some background. (I've actually been working on the gr-clenabled GNURadio blocks [in pybombs now] OpenCL study I published a month or so ago for about 4 months). For

Re: [Discuss-gnuradio] What do I do with this alert?

Darn it, your right. On Apr 26, 2017 2:31 AM, "Marcus Müller" wrote: > ... which we can rule out by the Gnome/Unity window decorator in his > screenshot :) > > On 26.04.2017 05:02, Anon Lister wrote: > > Unless he is running on Windows? > > On Apr 25, 2017 6:56 AM,

Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?

Dear Ghost, On 04/26/2017 01:01 PM, GhostOp14 wrote: > I tested it as a single task in OpenCL on a GPU and the performance > was horrible so I want to get the same algorithm running on an FPGA > and see if the performance significantly improves. Gut feeling: I wouldn't spend any money on an FPGA

Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?

Thanks Marcus! I have been going back and forth with testing still within the OpenCL framework versus straight FPGA with an interface. Where OpenCL starts to fall down from a speed improvement persepective for signal processing is when the data streams have to be processed sequentially due to

Re: [Discuss-gnuradio] Visualizing Amplitude spectrum instead of power spectrum

Hey Fernando, not quite sure I get what you need; I'd say the Amplitude Spectrum you'd be looking for is $$A_{|\cdot|}[f]=|X[f]| = \left\lvert\sum_{n=0}^{N-1} x[n]\cdot e^{j2\pi \frac {nf}N}\right\rvert $$ or, rather, the decibel representation of that. There's no way to get a negative number

Re: [Discuss-gnuradio] Speed test went wrong.

Hi Booth, the throttle block is an "average rate" limiter, not a measurement block - it simply pauses copying the input to the output if your sample generation is faster on long-term average than set in the throttle rate. So, if you set a throttle rate that is higher than what your PC can do,

Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?

Hey, just a general recommendation: you might want to define a few edge specs of your accelerator first – I'd start with the acceptable interfaces to a PC (I think that brings it down to PCIe cards and FPGA/CPU SoCs pretty much). Then: You might want to consider why specifically you want to use

Re: [Discuss-gnuradio] What is wrong with my grc program?

Hi Lee, is it really surprising that a channel simulator or a physical channel makes transmission harder? What have you tried to solve this? It's hard to help you without knowing what *exactly* goes wrong, so I'd recommend you use your Digital Communication knowledge and the graphical sinks to

Re: [Discuss-gnuradio] What do I do with this alert?

... which we can rule out by the Gnome/Unity window decorator in his screenshot :) On 26.04.2017 05:02, Anon Lister wrote: > Unless he is running on Windows? > > On Apr 25, 2017 6:56 AM, "Johannes Demel" > wrote: > > Hi Fred, > >