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

[Andy Walls]

>  From: 
> Fernando
>   Subject: 
> [Discuss-gnuradio] WBFM
> modulation/demodulation high
> frequencies highly attenuated
>  Date: 
> Wed, 26 Apr 2017 20:02:29 +0200
> 
> 
> 
> __
> I'm modulating/demodulating a wide band FM signal and I observe that
> high frequencies are highly  attenuated.
> 
> This is the diagram
> 
> 
> High frequencies are attenuated more than 40dB over low frequencies.
> 
> It seems to happen for frequencies above 20Khz.
> 
> Changing max deviation in WBFM Transmit has no effect.
> 
> What am I doing wrong?

You are making a bad assumption about what the WBFM block actually does.

See the audio filter cutoff and attenuation level in the WBFM Tx block
here:

https://github.com/gnuradio/gnuradio/blob/master/gr-analog/python/analog/wfm_tx.py#L67

-Andy


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

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

[Andres Felipe Betancur Perez]

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 "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 1727, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError:
GR-UHD detected ABI compatibility mismatch with UHD library.
GR-UHD was build against ABI: 3.4.0-3,
but UHD library reports ABI: 3.4.0-0
Suggestion: install an ABI compatible version of UHD,
or rebuild GR-UHD component against this ABI version.
-

I used these slides to solve the problem:

http://files.meetup.com/18094742/Presentation_Cyberspectrum_20160203_GR_Tutorial_Part_1.pdf

Review the 22th slide

I installed the UHD from source code to force the needed version. The USRP
I've been using is the NI-2900 of National Instruments (actually is the
same as B200 from Ettus research).

I hope this can be helpful for all people with this driver problem.

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

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

[Jason Matusiak]

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 
Projects/Projects/projs/jmatus/prefixes/E310/.pybombs/inventory.yml...

PyBOMBS.prefix - INFO - Installing SDK `e3xx-release4-sdk'
PyBOMBS._process_thread() - DEBUG - Executing command `$ sh 
./oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh -y -d 
/sharing/shared/Research Projects/Projects/projs/jmatus/prefixes/E310'
You are about to install the SDK to "/sharing/shared/Research". 
Proceed[Y/n]?Y


And that is where it hangs (you'd notice the space in the directory is 
not longer escaped).  I might try to look into the underlying scripts to 
see if I can make a one-off change that can get me past this issue 
(unless someone has an environment variable or something like that I can 
run to make the command happy)



On 04/25/2017 01:05 PM, Jason Matusiak wrote:
Hey Nathan.  tried that as well (first actually since that is what 
tabbed out), no dice.  IT hangs right here:

PyBOMBS.prefix - INFO - Installing SDK `e3xx-release4-sdk'
You are about to install the SDK to "/sharing/shared/Research". 
Proceed[Y/n]?Y


I have a feeling that when I escape it the first time, it gets passed 
into pybombs correctly,  Then when something actually goes to use it, 
the escape sequence has been stripped and it sees the space and stops 
working.  That seem possible?



On 04/25/2017 12:56 PM, West, Nathan wrote:

Where do you actually get stuck? Try Research\ Projects

On Tue, Apr 25, 2017 at 12:20 PM, Jason Matusiak 
> wrote:


I am trying to do an install of gnuradio into a directory on my
company's share that I don't have the ability to change. I
thought it was working until it hung for a while.  After looking
at it a bit, I have a feeling that the issue is that there is a
folder called "Research Projects" in my directory structure.  I
am thinking that pybombs is having an issue with the space (which
I try to never use in Linux myself).  Is there a way to work
around that issue? (I tried putting the folder name in double
quotes, but that didn't helps any).

___
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] WARN: transport stream sync error

[on4bhm]

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"  
Verzonden: Woensdag 26 april 2017 20:16:10 
Onderwerp: 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 AM, [ mailto:on4...@telenet.be | on4...@telenet.be ] wrote: 



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 get udp packets and send them to ZeroMQ 
push socket 

gnuradio is complaining about transport stream sync error. 

What can be the reason for this? 






___ 
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] WARN: transport stream sync error

[Ron Economos]

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 AM, on4...@telenet.be wrote:

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 get udp packets and send them to 
ZeroMQ push socket


gnuradio is complaining about transport stream sync error.

What can be the reason for this?




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

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

[Fernando]

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 deviation in WBFM Transmit has no effect.

What am I doing wrong?


regards


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

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

[Marcus Müller]

> 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 implies that your time signal is 0-time-hermitian (symmetrical if
real)! In your /example/ that is the case, because you're only summing
up /cosines/, but it's not usually the case.

So I'd like to get back to my earlier question:

What is the purpose of this?

You can very simply implement this using

stream to vector -> FFT -> complex to real -> Qt Vector sink.

Again, not convinced that is what you actually *need*. It's just what I
understnad that you *ask* for.

Best regards,
Marcus

On 04/26/2017 07:23 PM, Fernando wrote:
> I call it simply spectrum too, maybe I should have said
> magnitude/phase spectrum.
> Indeed i don't need imaginary part in this case because the spectrum
> is real.  or not spectrum lines will be real numbers with + / -
> .. or complex numbers with 0º/180º phase
>
> The representation I would like to get is this one
>
>
>
> or like this other
>
>
>
>
> So, this way could do what I want to do
>
>
>
> But I would like to print the magnitude/phase spectrm, but QT
> Frequency sink prints only the power spectrum
>
> Is there any GUI sink wich can print this?
>
> regards
>
>
>
> El 26/04/17 a las 16:15, Marcus Müller escribió:
>>
>> 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 {\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.
>>>
>>>
>>> I wish to be able to see the difference in the spectrum between this
>>> two signals below.  If the signal generators are A and B, A+B and
>>> A-B are different signals, but in the power spectrum we see them as
>>> the same signal, so I woul like to be able to difference one from
>>> the other from their spectrum.
>>>
>>>
>>>
>>>
>>> regards
>>>
>>>
>>>
>>>
>>> El 26/04/17 a las 09:52, Marcus Müller escribió:

 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 out of the absolute of something – it's by
 definition a positive real number.

 Now, we could also use our freedoms to define our amplitude
 spectrum to take the shape

 $$A_\text{signed} = s(X[f]) |X[f]|\text{ with }
 s(X[f])=\begin{cases}1&\text{for } -\pi \le \angle X[f] < \pi \\ 0
 &\text{else.} \end{cases}$$

 But: that's really only useful if you have phase-coherent reception
 – as an analytic tool for an unsynchronized observation of the
 spectrum, it doesn't help you much, since you have a random
 $\angle$ due to having random relative phase.

 So, maybe it'd be a good idea to formulate what purpose you're
 doing this for :) You can, indeed, tell 180° out-of-phase signals
 apart by this, but I'd argue that being 180° out-of-phase, for the
 most things I can think of, is only meaningful on one and the same
 frequency – and hence, I'm not quite sure this is what you're
 looking for!

 Best regards,

 Marcus


 On 25.04.2017 12:01, Fernando wrote:
> Hello.
>
> Yes, with Time sink I can see the difference, but if the signal is
> compound of some other signals (for instance  signal=1K/amplitude
> +1 +2K/amplitude -1 +3K/qamplitude +1 +4K/amplitude +1 )  i would
> like to see the 2k signal as -1 amplitude, but in the power
> spectrum it will appear as possitive and in the QT time sink it is
> very difficult to see the signal as it is a complex one.
>
> regards
>
>
> El 25/04/17 a las 10:57, Jinyang Lee escribió:
>> Hello Fernando,
>>
>> I think the QT GUI time sink displays the relationship between
>> time and amplitude. You can see the signal through it. But when I
>> use the channel model block,the QT2 can see the signal which is zero.
>> Enclose is running result with channel model and with channel model.
>>
>> Regards,
>> Lee
>>
>> 2017-04-25 15:45 GMT+08:00 Fernando > >:
>>
>> Hi.
>>
>>
>> Is there a way of visualizing ampitude spectrum (with + and -
>> signals

[Discuss-gnuradio] WARN: transport stream sync error

[on4bhm]

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 get udp packets and send them to ZeroMQ 
push socket 

gnuradio is complaining about transport stream sync error. 

What can be the reason for this? 

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

Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?

[Dennis Glatting]

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
> 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 the algorithms (like a feedback
> loop).  So I wanted to try to get some blocks like a Costas Loop onto
> hardware.  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.
> 
> Given some high-bandwidth goals, I'm actually thinking either USB 3.0
> or PCIe would be the requirement.  I was looking at the Opal Kelly
> line like the one they have based on the Xilinx Artix-7.  I actually
> think the USB 3.0 interface if I can transfer runtime data to/from it
> at USB 3.0 speeds would be more portable (say laptop/desktop).  I'm
> still new to FPGA's so any other thoughts are much appreciated.  It
> looks like I may still have to work in Vivado and build the FPGA code
> but then I could interface with it from C++ and a GNURadio block?
> 
> Am I on the right track?
> 
> -- Forwarded message --
> From: Marcus Müller 
> Date: Wed, Apr 26, 2017 at 6:52 AM
> Subject: Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?
> To: GhostOp14 
> 
> 
> Hi Ghost, 
> would you mind sending that mail to the mailing list instead of me in
> private? I'm certainly not the only one that can contribute something
> to this, and it would probably help you most if the others get a
> chance to contribute their thoughts, too. 
> Thanks,
> Marcus
> 
> On 04/26/2017 12:50 PM, GhostOp14 wrote:
> > 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 the algorithms
> > (like a feedback loop).  So I wanted to try to get some blocks like
> > a Costas Loop onto hardware.  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.
> > 
> > Given some high-bandwidth goals, I'm actually thinking either USB
> > 3.0 or PCIe would be the requirement.  I was looking at the Opal
> > Kelly line like the one they have based on the Xilinx Artix-7.  I
> > actually think the USB 3.0 interface if I can transfer runtime data
> > to/from it at USB 3.0 speeds would be more portable (say
> > laptop/desktop).  I'm still new to FPGA's so any other thoughts are
> > much appreciated.  It looks like I may still have to work in Vivado
> > and build the FPGA code but then I could interface with it from C++
> > and a GNURadio block?
> > 
> > Am I on the right track?
> > 
> > 
> > 
> > 
> > On Wed, Apr 26, 2017 at 3:03 AM, Marcus Müller 
> > s.com> wrote:
> > > 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
> > > an
> > > FPGA to do openCL (as opposed to, say, a GPU), to further
> > > restrict the
> > > field; that might rule out one of the two options above.
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > On 25.04.2017 19:15, Ghost Op wrote:
> > > > Hi everyone!  I'm working on expanding the OpenCL modules for
> > > GNURadio
> > > > and I want to test them with some FPGA's that support OpenCL. 
> > > There's
> > > > a few from Xilinx and Altera it looks like, but the ones I've
> > > seen are
> > > > a bit pricey.
> > > >
> > > > Does anyone know of an OpenCL-capable FPGA card for under
> > > $1,000 for
> > > > some testing?
> > > >
> > > > ___
> > > > 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
> > > 
>  
> ___
> 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.o

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

[Marcus Müller]

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 {\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.
>
>
> I wish to be able to see the difference in the spectrum between this
> two signals below.  If the signal generators are A and B, A+B and A-B
> are different signals, but in the power spectrum we see them as the
> same signal, so I woul like to be able to difference one from the
> other from their spectrum.
>
>
>
>
> regards
>
>
>
>
> El 26/04/17 a las 09:52, Marcus Müller escribió:
>>
>> 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 out of the absolute of something – it's by
>> definition a positive real number.
>>
>> Now, we could also use our freedoms to define our amplitude spectrum
>> to take the shape
>>
>> $$A_\text{signed} = s(X[f]) |X[f]|\text{ with }
>> s(X[f])=\begin{cases}1&\text{for } -\pi \le \angle X[f] < \pi \\ 0
>> &\text{else.} \end{cases}$$
>>
>> But: that's really only useful if you have phase-coherent reception –
>> as an analytic tool for an unsynchronized observation of the
>> spectrum, it doesn't help you much, since you have a random $\angle$
>> due to having random relative phase.
>>
>> So, maybe it'd be a good idea to formulate what purpose you're doing
>> this for :) You can, indeed, tell 180° out-of-phase signals apart by
>> this, but I'd argue that being 180° out-of-phase, for the most things
>> I can think of, is only meaningful on one and the same frequency –
>> and hence, I'm not quite sure this is what you're looking for!
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 25.04.2017 12:01, Fernando wrote:
>>> Hello.
>>>
>>> Yes, with Time sink I can see the difference, but if the signal is
>>> compound of some other signals (for instance  signal=1K/amplitude +1
>>> +2K/amplitude -1 +3K/qamplitude +1 +4K/amplitude +1 )  i would like
>>> to see the 2k signal as -1 amplitude, but in the power spectrum it
>>> will appear as possitive and in the QT time sink it is very
>>> difficult to see the signal as it is a complex one.
>>>
>>> regards
>>>
>>>
>>> El 25/04/17 a las 10:57, Jinyang Lee escribió:
 Hello Fernando,

 I think the QT GUI time sink displays the relationship between time
 and amplitude. You can see the signal through it. But when I use
 the channel model block,the QT2 can see the signal which is zero.
 Enclose is running result with channel model and with channel model.

 Regards,
 Lee

 2017-04-25 15:45 GMT+08:00 Fernando >>> >:

 Hi.


 Is there a way of visualizing ampitude spectrum (with + and -
 signals)
 instead of power spectrum?


 regards



 ___
 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
>>
>>
>>
>> ___
>> 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] Visualizing Amplitude spectrum instead of power spectrum

[Fernando]

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.


I wish to be able to see the difference in the spectrum between this two
signals below.  If the signal generators are A and B, A+B and A-B are
different signals, but in the power spectrum we see them as the same
signal, so I woul like to be able to difference one from the other from
their spectrum.




regards




El 26/04/17 a las 09:52, Marcus Müller escribió:
>
> 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 out of the absolute of something – it's by
> definition a positive real number.
>
> Now, we could also use our freedoms to define our amplitude spectrum
> to take the shape
>
> $$A_\text{signed} = s(X[f]) |X[f]|\text{ with }
> s(X[f])=\begin{cases}1&\text{for } -\pi \le \angle X[f] < \pi \\ 0
> &\text{else.} \end{cases}$$
>
> But: that's really only useful if you have phase-coherent reception –
> as an analytic tool for an unsynchronized observation of the spectrum,
> it doesn't help you much, since you have a random $\angle$ due to
> having random relative phase.
>
> So, maybe it'd be a good idea to formulate what purpose you're doing
> this for :) You can, indeed, tell 180° out-of-phase signals apart by
> this, but I'd argue that being 180° out-of-phase, for the most things
> I can think of, is only meaningful on one and the same frequency – and
> hence, I'm not quite sure this is what you're looking for!
>
> Best regards,
>
> Marcus
>
>
> On 25.04.2017 12:01, Fernando wrote:
>> Hello.
>>
>> Yes, with Time sink I can see the difference, but if the signal is
>> compound of some other signals (for instance  signal=1K/amplitude +1
>> +2K/amplitude -1 +3K/qamplitude +1 +4K/amplitude +1 )  i would like
>> to see the 2k signal as -1 amplitude, but in the power spectrum it
>> will appear as possitive and in the QT time sink it is very difficult
>> to see the signal as it is a complex one.
>>
>> regards
>>
>>
>> El 25/04/17 a las 10:57, Jinyang Lee escribió:
>>> Hello Fernando,
>>>
>>> I think the QT GUI time sink displays the relationship between time
>>> and amplitude. You can see the signal through it. But when I use the
>>> channel model block,the QT2 can see the signal which is zero.
>>> Enclose is running result with channel model and with channel model.
>>>
>>> Regards,
>>> Lee
>>>
>>> 2017-04-25 15:45 GMT+08:00 Fernando >> >:
>>>
>>> Hi.
>>>
>>>
>>> Is there a way of visualizing ampitude spectrum (with + and -
>>> signals)
>>> instead of power spectrum?
>>>
>>>
>>> regards
>>>
>>>
>>>
>>> ___
>>> 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
>
>
>
> ___
> 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] ATSC Decode Issues

[GhostOp14]

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

Also in testing the atsctest.cfile I found that if you install the
gr-correctiq module and run the input through that first, you get much more
packet data out the other side (500+MB [I stopped it] versus 80 MB without
it).  For anyone else working on ATSC decoding it may help improve the
quality of the output IQ stream.

-- Forwarded message --

Sylvain, I've done some more debugging and the mystery only deepens.  I Ran
the flowgraph in an Ubuntu 14.04LTS VM with both 3.7.10.1 and a fully
pybombs updated version and the output worked fine.  My original test
system is Kali / debian linux fully updated.  I added some prints in the
pfb_arb_resampler to look at the taps that are used and the numbers all
match, however the output bytes are still different.  The debugging is
getting a bit deeper than my expertise into the filters and pfb code.
Nothing jumped out at me as to why the output calculations would be
different.

Would you be able to fire up a Kali VM to reproduce it?  This will get you
up and running pretty quickly... There's 2 quick things to do while
installing on Kali.  First, before starting run 'apt-get install
zlib1g-dev'.  It's a pre-req that didn't seem to be verified for one of the
header files.  Next, when pybombs gets to Apache thrift, when it starts to
build break the install and edit /src/apache-thrift/
lib/cpp/src/thrift/transport/TSSLSocket.cpp.  Search for 'SSLv3_method' and
change it to 'SSLv23_method'.  Go into the src directory and manually
finish the apache thrift build then go back to the pybombs install and
everything will run through fine.

Now that I know the combo to consistently reproduce the issue that should
help hunt it down.

Thanks!
-- Forwarded message --
From: GhostOp14 
Date: Mon, Apr 24, 2017 at 7:12 AM
Subject: Re: [Discuss-gnuradio] ATSC Decode Issues
To: Ron Economos 


I was playing with the no_pfb version of the flowgraph again now trying to
work on getting an input signal to a file and I had a couple of other
questions about the ATSC process.  Out of curiosity when you removed the
PFB resampler you used an FFT filter rather than a FIR filter for the RRC
filter.  From a signal-processing perspective what makes the FFT the
correct choice there rather than a FIR?

I was also trying to see if I could adjust the input rate to that 10.7622
Msps with a different resampler if I wanted to use the Airspy instead of my
hackrf.  If I drop a rational resampler after the throttle block and use
the interpolation/decimation to adjust the output rate to 10.7622 I don't
get good output (it was worth a shot right?).  Any math thought behind why
that approach doesn't work?

Thanks!


On Sun, Apr 23, 2017 at 4:13 PM, GhostOp14  wrote:

> I sent an email to you and Sylvan to see if he could figure it out.
>
> In the meantime if you want to see where I'm trying to go, if you take the
> working flowgraph that successfully produces the output file and go up to
> github and download/install this OOT module I'm working on:
> https://github.com/ghostop14/gr-atsc2.git.
>
> Drop the ATSC2 Streaming Server block in place of the output file, set a
> port number like 8800 and start the flowgraph.  Then open VLC, go under
> Media, select "Open Network Stream", put in http:// flowgraph>:8800/  and voila!  Streaming output.  With the non-PFB flowgraph
> I would suspect it'll work in real-time.  The TS Stream server block is a
> really low utilization block.
>
>
>
> On Fri, Apr 21, 2017 at 10:58 PM, Ron Economos  wrote:
>
>> Bummer! I do have something you can try. It's possible to eliminate the
>> PFB resampler from the flow. I've attached a flow graph that uses just an
>> RRC filter. The input file sample rate has to be 10.76 Msps, but you can
>> create that yourself with the ATSC transmitter (file_atsc_tx.grc).
>>
>> The test TS file for the ATSC transmitter is here:
>>
>> http://www.w6rz.net/advatsc.ts
>>
>> 256,952,572 bytes.
>>
>> BTW, without the PFB resampler the flow runs much faster. Real-time on my
>> modest E5-1607. It's too bad the Airspy can't do fractional sample rates.
>>
>> That reminds me. On your original flow graph, you had a rational
>> resampler. That's not needed, just set the sample_rate to 10 Msps and let
>> the PFB resampler do all the work. Also, the low-pass filter isn't
>> necessary either.
>>
>> Ron
>> On 04/21/2017 09:04 AM, GhostOp14 wrote:
>>
>> I have another clue I hope will be useful.  So I installed the latest
>> 3.7.11 windows binary on another box and the resulting .ts file actually
>> loaded and played.  Same flowgraph, same input file.  So I looked at the
>> output files with 3.7.12-git/linux and the 3.7.11 and they're the exact
>>

Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?

[GhostOp14]

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 OpenCL the massively parallel processing across a
number of lower-throughput cores on data sets where the data can all be
processed in parallel works well.  For instance calculations such as a[i] =
b[i] + c[i].  All calculations can be handled in parallel and the lower
performance of each core is offset by having 10's or 100's running at the
same time for a good throughput boost.

For calculations such as a Costas Loop where an error is calculated for
each point then used in the next calculation, you can't run the
calculations in parallel and they have to be done in order to get the right
results. You can switch OpenCL to a task-parallel mode with a work set size
of 1, but for GNURadio what it really amounts to because each block just
gets 1 thread is running the same function on a single lower performance
GPU core.  In that case the single-core GPU performance is an order of
magitude worse than a general CPU core for the same task.

I know there's a number of IP cores for FPGA's focused on DSP, so my
thought / hope was that for those algorithms that couldn't be done in
parallel, that moving from CPU-speed to hardware speed on the FPGA would
run faster.  Kind of like with RFNoC, just for more general purpose
FPGA's.

I think I'd still be okay if I had to pull the DSP blocks together in an
FPGA dev environment like Xilinx Vivado as long as it could help generate
the C++ interface code (I did see one article someone wrote on doing
something like this), then just having to write the GNURadio block to
interface with it.  I just don't know FPGA's well enough (and I know it's
not a simple learning curve) to know.


-- Forwarded message --
From: Marcus Müller 
Date: Wed, Apr 26, 2017 at 7:31 AM
Subject: Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?
To: discuss-gnuradio@gnu.org


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 implementation before
I have not understood why it worked so terribly on GPU, and have a good
reason why it should work better on FPGA. Frankly, I don't think you
realize how hard it is to properly optimize things for specific
architectures, and OpenCL on an FPGA will not be easier to "get right"
than OpenCL on a GPU.
>
> Given some high-bandwidth goals, I'm actually thinking either USB 3.0
> or PCIe would be the requirement.  I was looking at the Opal Kelly
> line like the one they have based on the Xilinx Artix-7.  I actually
> think the USB 3.0 interface if I can transfer runtime data to/from it
> at USB 3.0 speeds would be more portable (say laptop/desktop).  I'm
> still new to FPGA's so any other thoughts are much appreciated.  It
> looks like I may still have to work in Vivado and build the FPGA code
> but then I could interface with it from C++ and a GNURadio block?
Probably! Don't know the FPGA manufacturer's OpenCL tools and whether
they offer an easy-to-use interface to PC software.
>
> Am I on the right track?
Don't know – again, I'd recommend going into a much deeper analysis of
why things work badly on your CPU and GPU, and why an FPGA should make
that better.

Best regards,
Marcus


___
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] What do I do with this alert?

[Anon Lister]

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, "Johannes Demel"  wrote:
>
>> Hi Fred,
>>
>> this is a warning that you want to execute a 'No GUI' flowgraph without a
>> terminal.
>> GRC tries to run your flowgraph by opening a new terminal. All prints
>> etc. will go into this terminal. But GRC is missing the path to your
>> terminal application.
>>
>> How to fix this:
>> Go to ~/.gnuradio
>> edit 'config.conf' or create it if the file is not yet present.
>> Search for the section '[grc]' or add it if not present.
>> add a line in this section:
>> xterm_executable = /usr/bin/gnome-terminal
>> replace the part after '=' with the path to the shell of your choice.
>> Restart GRC!
>>
>> I hope this helps.
>> The result should be that a new terminal pops up as soon as you click on
>> EXECUTE in GRC if you want to run a 'no GUI' flowgraph.
>>
>> Cheers
>> Johannes
>>
>>
>> On 25.04.2017 04:53, Fred wrote:
>>
>>> Another newb question.  I received the enclosed alert and it looks like
>>> it is wanting me to change some profile setting in GNU Radio relating to
>>> xterm.  I closed it but dont know if I need to act on it (as if
>>> everything I do going forward will not work correctly) or if it is
>>> something I can just ignore.  Please let me know your thoughts.
>>>
>>> Best Regards-Fred
>>>
>>>
>>>
>>>
>>> ___
>>> 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
>>
>
>
> ___
> 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?

[Marcus Müller]

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 implementation before
I have not understood why it worked so terribly on GPU, and have a good
reason why it should work better on FPGA. Frankly, I don't think you
realize how hard it is to properly optimize things for specific
architectures, and OpenCL on an FPGA will not be easier to "get right"
than OpenCL on a GPU.
>
> Given some high-bandwidth goals, I'm actually thinking either USB 3.0
> or PCIe would be the requirement.  I was looking at the Opal Kelly
> line like the one they have based on the Xilinx Artix-7.  I actually
> think the USB 3.0 interface if I can transfer runtime data to/from it
> at USB 3.0 speeds would be more portable (say laptop/desktop).  I'm
> still new to FPGA's so any other thoughts are much appreciated.  It
> looks like I may still have to work in Vivado and build the FPGA code
> but then I could interface with it from C++ and a GNURadio block?
Probably! Don't know the FPGA manufacturer's OpenCL tools and whether
they offer an easy-to-use interface to PC software.
>
> Am I on the right track?
Don't know – again, I'd recommend going into a much deeper analysis of
why things work badly on your CPU and GPU, and why an FPGA should make
that better.

Best regards,
Marcus


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

Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?

[GhostOp14]

 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 the algorithms (like a feedback loop).  So I wanted to try to get some
blocks like a Costas Loop onto hardware.  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.

Given some high-bandwidth goals, I'm actually thinking either USB 3.0 or
PCIe would be the requirement.  I was looking at the Opal Kelly line like
the one they have based on the Xilinx Artix-7.  I actually think the USB
3.0 interface if I can transfer runtime data to/from it at USB 3.0 speeds
would be more portable (say laptop/desktop).  I'm still new to FPGA's so
any other thoughts are much appreciated.  It looks like I may still have to
work in Vivado and build the FPGA code but then I could interface with it
from C++ and a GNURadio block?

Am I on the right track?

-- Forwarded message --
From: Marcus Müller 
Date: Wed, Apr 26, 2017 at 6:52 AM
Subject: Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?
To: GhostOp14 


Hi Ghost,

would you mind sending that mail to the mailing list instead of me in
private? I'm certainly not the only one that can contribute something to
this, and it would probably help you most if the others get a chance to
contribute their thoughts, too.

Thanks,

Marcus

On 04/26/2017 12:50 PM, GhostOp14 wrote:

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 the algorithms (like a feedback loop).  So I wanted to try to get some
blocks like a Costas Loop onto hardware.  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.

Given some high-bandwidth goals, I'm actually thinking either USB 3.0 or
PCIe would be the requirement.  I was looking at the Opal Kelly line like
the one they have based on the Xilinx Artix-7.  I actually think the USB
3.0 interface if I can transfer runtime data to/from it at USB 3.0 speeds
would be more portable (say laptop/desktop).  I'm still new to FPGA's so
any other thoughts are much appreciated.  It looks like I may still have to
work in Vivado and build the FPGA code but then I could interface with it
from C++ and a GNURadio block?

Am I on the right track?




On Wed, Apr 26, 2017 at 3:03 AM, Marcus Müller 
wrote:

> 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 an
> FPGA to do openCL (as opposed to, say, a GPU), to further restrict the
> field; that might rule out one of the two options above.
>
> Best regards,
> Marcus
>
> On 25.04.2017 19:15, Ghost Op wrote:
> > Hi everyone!  I'm working on expanding the OpenCL modules for GNURadio
> > and I want to test them with some FPGA's that support OpenCL.  There's
> > a few from Xilinx and Altera it looks like, but the ones I've seen are
> > a bit pricey.
> >
> > Does anyone know of an OpenCL-capable FPGA card for under $1,000 for
> > some testing?
> >
> > ___
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Marcus Müller]

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 out of the absolute of something – it's by definition a
positive real number.

Now, we could also use our freedoms to define our amplitude spectrum to
take the shape

$$A_\text{signed} = s(X[f]) |X[f]|\text{ with }
s(X[f])=\begin{cases}1&\text{for } -\pi \le \angle X[f] < \pi \\ 0
&\text{else.} \end{cases}$$

But: that's really only useful if you have phase-coherent reception – as
an analytic tool for an unsynchronized observation of the spectrum, it
doesn't help you much, since you have a random $\angle$ due to having
random relative phase.

So, maybe it'd be a good idea to formulate what purpose you're doing
this for :) You can, indeed, tell 180° out-of-phase signals apart by
this, but I'd argue that being 180° out-of-phase, for the most things I
can think of, is only meaningful on one and the same frequency – and
hence, I'm not quite sure this is what you're looking for!

Best regards,

Marcus


On 25.04.2017 12:01, Fernando wrote:
> Hello.
>
> Yes, with Time sink I can see the difference, but if the signal is
> compound of some other signals (for instance  signal=1K/amplitude +1
> +2K/amplitude -1 +3K/qamplitude +1 +4K/amplitude +1 )  i would like to
> see the 2k signal as -1 amplitude, but in the power spectrum it will
> appear as possitive and in the QT time sink it is very difficult to
> see the signal as it is a complex one.
>
> regards
>
>
> El 25/04/17 a las 10:57, Jinyang Lee escribió:
>> Hello Fernando,
>>
>> I think the QT GUI time sink displays the relationship between time
>> and amplitude. You can see the signal through it. But when I use the
>> channel model block,the QT2 can see the signal which is zero.
>> Enclose is running result with channel model and with channel model.
>>
>> Regards,
>> Lee
>>
>> 2017-04-25 15:45 GMT+08:00 Fernando > >:
>>
>> Hi.
>>
>>
>> Is there a way of visualizing ampitude spectrum (with + and -
>> signals)
>> instead of power spectrum?
>>
>>
>> regards
>>
>>
>>
>> ___
>> 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

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

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

[Marcus Müller]

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,
the Throttle will just not pause and copy in- to output. It does
nothing. (Ok, it wastes CPU time and memory bandwidth...).

What you want is the "probe rate" block connected to a "message debug"
block, for an easy assessment.

PS: Don't subscribe using Nabble (this is not a forum, but an email
list), but simlpy directly via
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio using your email
address. It works much better and is easier to use. Nabble tends to not
correctly represent discussions.


Best regards,

Marcus


On 25.04.2017 12:18, Booth wrote:
> Dear all,
>  I wondered what would be the maximum sample rate that my PC can handle for
> a basic psk mod-demod. I have used the “prbs_test.grc” from gr-mapper as it
> contains all the necessary blocks. I changed the sample rate for the
> throttle to 32k, 320k,10M, 100M even 10G but the system did not break down.
> I repeated the experiment using different examples but the result was the
> same.
> What went wrong and do you know any appropriate projects for speed
> measurements.
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Speed-test-went-wrong-tp63632.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


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

Re: [Discuss-gnuradio] OpenCL FPGA Recommendation?

[Marcus Müller]

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 an
FPGA to do openCL (as opposed to, say, a GPU), to further restrict the
field; that might rule out one of the two options above.

Best regards,
Marcus

On 25.04.2017 19:15, Ghost Op wrote:
> Hi everyone!  I'm working on expanding the OpenCL modules for GNURadio
> and I want to test them with some FPGA's that support OpenCL.  There's
> a few from Xilinx and Altera it looks like, but the ones I've seen are
> a bit pricey.
>
> Does anyone know of an OpenCL-capable FPGA card for under $1,000 for
> some testing?
>
> ___
> 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] What is wrong with my grc program?

[Marcus Müller]

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 understand in which
way the received signal is a different one from the transmitted. You'll
have to play with the gain parameters of your USRP to optimize
transmission, and with the parameters of the blocks involved in forming
and receiving the waveform.

Best regards,

Marcus


On 25.04.2017 03:48, Jinyang Lee wrote:
> Hello,
>
> Recently I have designed a grc program and I want to use it to
> transform a picture(.jpg or .png) file.When I run this grc program
> without channel model, it works well and I can receive a complete
> picture which is transformed by transmitter. However when I add a
> channel model which one I set to ideal state and the receiver can not
> receive signal (you can see the signal from QT2). The same question
> occurs when I use USRP B210 to transform picture. 
>
> So I can not find where is wrong with my grc program. Is there someone
> who can help me?
>
> Thank you all in advance.
>
> Regards,
> Lee
>
>
> ___
> 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