Re: [Discuss-gnuradio] GRC 3.7.11 on Windows crashes python.exe

[Cinaed Simson]

You should post this on

   https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

mailing list.

Indicate the color of the LED and it's position relative to the antenna,
post the output of

  hackrf_info

and a copy of your flowchart - the XML file with the

  .GRC

extension.

I know next to nothing about Windows 10 but there were some problems
with the drivers - possibly the Windows USB driver - but I thought they
were resolved. I'm assuming you installed the Windows 10 USB driver.

And try different USB ports - there's a rumor that the Windows driver
may only work on a single port - but then I know next to nothing.

-- Cinaed


On 04/14/2017 09:40 AM, Marcus Müller wrote:
> Hi Martijn,
> 
> "Illegal Instruction" is actually a proper processor fault (ie. your
> processor noticed a problem, and jumped to an interrupt routine telling
> your OS that hey, things need to be handled) that happens when one tries
> to execute code that isn't actually code or uses an instruction that
> your CPU doesn't have.
> 
> I'm pretty optimistic that hackrf.dll wasn't compiled for a CPU that's
> incompatible to yours, so this might essentially be a bug – either in
> the hackrf driver dll (which might be jumping into machine code that
> isn't code), or in the way the windows DLL loader is used. Hm. Maybe
> even a compiler bug.
> 
> Now, I have to admit that under Unixes, I'd know how to debug this, but
> under Windows, I'm out of my depth. So if you happen to be more capable
> than I am with that, you could try to run "python
> C:\path\to\your\flow_graph_python_file.py" in a debugger and see where
> it crashes. But even then, I don't know if things would be easy to
> figure out.
> 
> Best regards,
> Marcus
> On 14.04.2017 16:34, Martijn Scale wrote:
>>
>> Trying to use a HackRF One with GNU Radio on Windows 10 (64-bits),
>> installed from gnuradio_3.7.11_win64.msi.
>>
>> When using osmocom Source and executing the flow graph, execution
>> halts with message: python.exe has stopped working. GRC remains alive.
>>
>> Crashes happen both with WX and QT. The HackRF One module is put into
>> Receive mode (Rx Led of HackRF One is on).
>>
>>  
>>
>> GNU Radio, GRC, Hack RF and computer do work as expected with the
>> GNURadioLiveDVD .
>>
>>  
>>
>> Debugging shows: Unhandled exception at 0x7FFCCDDD3CCB
>> (hackrf.dll) in python.exe: 0xC01D: Illegal Instruction.
>>
>> Additional info from Event Viewer:
>>
>> Faulting application path: C:\Program
>> Files\GNURadio-3.7\gr-python27\python.exe
>>
>> Faulting module path: C:\Program Files\GNURadio-3.7\bin\hackrf.dll
>>
>> And info from Console Panel in GRC:
>>
>> Win32; Microsoft Visual C++ version 14.0; Boost_106000;
>> UHD_003.010.001.001-0-unknown
>>
>>  
>>
>> hackrf.dll info: 2017-03-03, 66.560 Bytes
>>
>>  
>>
>> gr-osmosdr ae686c46 (0.1.5git) gnuradio 3.7.11
>>
>> built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
>> airspy redpitaya
>>
>> Number of USB devices: 17
>>
>> USB device 1d50:: a06063c82xxx match
>>
>> Using HackRF One with firmware 2017.02.1
>>
>>  
>>
>> Hardware:
>>
>> Processor   Intel(R) Core(TM) i7 CPU 860  @ 2.80GHz,
>> 2794 Mhz, 4 Core(s), 8 Logical Processor(s)
>>
>> Display adapterAMD Radeon HD 5700 Series
>>
>>  
>>
>> Your support is highly appreciated (I tried building GNU Radio from
>> sources, which failed as “gr-newmod/CMakeLists.txt was not found and
>> is required”, but I decided not to pursue the building path any
>> further as it exceeds my knowledge).
>>
>>  
>>
>>  
>>
>>
>>
>> ___
>> 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] GRC 3.7.11 on Windows crashes python.exe

[Geof Nieboer]

Martjin,

On the windows build, most likely the problem is in the build scripts... we
build two versions, one with maximum optimizations for AVX2 capable CPUs,
and a generic one.  Sometimes, however, AVX2 instructions get into the
regular build for a number of reasons (qwt in particular has been an issue
because of qmake's build system).  That will cause the "illegal
instruction" error.

SO, if you can confirm the below:
1- The machine you are running on has a somewhat older CPU
2- You downloaded the installer from the "any CPU" link.

If those cases are true, then the bug is in my scripts.  As I don't have a
HackRF, it's difficult to test.  Please let me know the answer to the
above.  In the meantime, download the HackRF dll directly from
www.gcndevelopment.com/gnuradio/downloads.htm (near the bottom), and drop
that in the /bin directory to see if that fixes the problem (renaming the
old version to .old just in case), and see if that patches things up.
That's the DLL from the last build, but I don't believe the driver has
changed so it should work.

Geof

On Fri, Apr 14, 2017 at 12:40 PM, Marcus Müller 
wrote:

> Hi Martijn,
>
> "Illegal Instruction" is actually a proper processor fault (ie. your
> processor noticed a problem, and jumped to an interrupt routine telling
> your OS that hey, things need to be handled) that happens when one tries to
> execute code that isn't actually code or uses an instruction that your CPU
> doesn't have.
>
> I'm pretty optimistic that hackrf.dll wasn't compiled for a CPU that's
> incompatible to yours, so this might essentially be a bug – either in the
> hackrf driver dll (which might be jumping into machine code that isn't
> code), or in the way the windows DLL loader is used. Hm. Maybe even a
> compiler bug.
> Now, I have to admit that under Unixes, I'd know how to debug this, but
> under Windows, I'm out of my depth. So if you happen to be more capable
> than I am with that, you could try to run "python
> C:\path\to\your\flow_graph_python_file.py" in a debugger and see where it
> crashes. But even then, I don't know if things would be easy to figure out.
>
> Best regards,
> Marcus
>
> On 14.04.2017 16:34, Martijn Scale wrote:
>
> Trying to use a HackRF One with GNU Radio on Windows 10 (64-bits),
> installed from gnuradio_3.7.11_win64.msi.
>
> When using osmocom Source and executing the flow graph, execution halts
> with message: python.exe has stopped working. GRC remains alive.
>
> Crashes happen both with WX and QT. The HackRF One module is put into
> Receive mode (Rx Led of HackRF One is on).
>
>
>
> GNU Radio, GRC, Hack RF and computer do work as expected with the
> GNURadioLiveDVD .
>
>
>
> Debugging shows: Unhandled exception at 0x7FFCCDDD3CCB (hackrf.dll) in
> python.exe: 0xC01D: Illegal Instruction.
>
> Additional info from Event Viewer:
>
> Faulting application path: C:\Program Files\GNURadio-3.7\gr-
> python27\python.exe
>
> Faulting module path: C:\Program Files\GNURadio-3.7\bin\hackrf.dll
>
> And info from Console Panel in GRC:
>
> Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_003.010.001.001-0-unknown
>
>
>
> hackrf.dll info: 2017-03-03, 66.560 Bytes
>
>
>
> gr-osmosdr ae686c46 (0.1.5git) gnuradio 3.7.11
>
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
> airspy redpitaya
>
> Number of USB devices: 17
>
> USB device 1d50:: a06063c82xxx match
>
> Using HackRF One with firmware 2017.02.1
>
>
>
> Hardware:
>
> Processor   Intel(R) Core(TM) i7 CPU 860  @ 2.80GHz, 2794
> Mhz, 4 Core(s), 8 Logical Processor(s)
>
> Display adapterAMD Radeon HD 5700 Series
>
>
>
> Your support is highly appreciated (I tried building GNU Radio from
> sources, which failed as “gr-newmod/CMakeLists.txt was not found and is
> required”, but I decided not to pursue the building path any further as it
> exceeds my knowledge).
>
>
>
>
>
>
> ___
> 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] Is 100 Mbps PSK demodulation in GNU RADIO possible? (x310 HW)

[Marcus Müller]

Dear Mehmeto,

need to stress one thing, here:

Your "assuming that the HW support such a speed" is kind of doing the
wrong thing – you need to make your software run fast enough on your
hardware, which very, very likely is too slow, and as far as I can tell,
that's a real challenge at these rates. The USRP will happily flood your
PC with 100MS/s or more – the hard thing is keeping up with that.

As Dan highlights, you/might/ be able to do that with GNU Radio blocks –
there's no inherent limit on "how fast they can go". The question is
just: how well does your transceiver (mainly: the decoder, synchronizer)
work on general-purpose CPUs, and can you maybe split it to make use of
more processor parallelism (especially when you go to the GPU); that's
programming, and we can't tell you how well you'll do with that.

Regarding the "PSK demodulator" blocks:
Those are really pretty general purpose blocks that make a few "typical"
choices (a specific digital AGC, and for timing recovery, for example,
they use a RRC filter in a PFB filterbank clock sync, and for frequency
recovery, a FLL band edge approach). I don't think these fit your
high-bandwidth case overly well. You'd probably not make the same
assumptions!

So, no, out of the box you can't simply click this together and let it
run at these high rates; you'll have to dig a bit deeper into GNU Radio,
and the DSP theory and possible optimizations within.

Luckily, GNU Radio lends itself greatly to that:

Start with 5 MS/s, so something like 2.5 Mbd, make it work with bare
minimum functionality, e.g. without channel coding, framing. Identify
the CPU hogs. Increase to 10 MS/s, 5 Mbd, experiment with alternatives
for the different elements in the receiver chain. Maybe optimize
something manually (write better code – much of GNU Radio is
hand-optimized including custom assembler kernels (see VOLK), but far
from all), move up again, to maybe 25 MS/s. Identify whether your
choices regarding frequency and timing recovery still make sense, and so
on. Add Channel Coding (you probably want that for a high-rate link,
right?!), rinse, repeat. Identify components of your system where
acceleration, be it your own code on the X310's FPGA, be it something on
the GPU, be it a custom accelerator card, or be it by simple
optimization of software, makes most sense. Don't forget that copying
data to and from the GPU puts additional load on your system! It might
be a good idea to consider your PC's bus layout.

The point here really is that you're very much working on the edge of
the bandwidths that PC-architecture buses can carry around, and will be
doing a lot of more or less strictly sequential algorithms on millions
of elements per second – it's hence always going to be a bit "custom"
what you're doing (noone else knows the channel and desired ROCs you're
working with as good as you!), and it's kind of hard to offer the
"universally great" transceiver for that.


Best regards,
Marcus

On 14.04.2017 20:16, Dan CaJacob wrote:
>
> I am working on a similar system.  In short, the answer is no, your i7
> won't keep up that fast.  But you could if you push some processing
> down into the FPGA.
>
> For example, my non optimized QPSK modem with 1/2 rate convolutional
> coding + RS coding only works up to about 1 Mbps without over/under
> flowing.
>
> While optimization will help, 100 Mbps seems like too much of a
> stretch for real-time on normal CPUs, but possible on FPGA.  Or maybe
> possible with like 40 i7s.
>
>
> On Fri, Apr 14, 2017, 5:30 AM Mehmeto  > wrote:
>
> Dear All,
>  We just bought an Ettus X310 with PCIe interface.
> We will try to transmit a 100 Mbps OQPSK signal and receive it
> back using
> the PSK demodulator blocks.
> In your opinion is this possible. Assuming that the HW support
> such a speed,
> will the speed of the GNU Radio Blocks be sufficient? (We will be
> using one
> of the latest i7 processors.)
>  We couldn't find any max. speed data on these blocks.
> We are also considering to use some high speed GPU but could not
> find any
> CUDA/ OpenCL based GNU Radio blocks.
>
>
>
> --
> View this message in context:
> 
> http://gnuradio.4.n7.nabble.com/Is-100-Mbps-PSK-demodulation-in-GNU-RADIO-possible-x310-HW-tp63527.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
>
> -- 
> Very Respectfully,
>
> Dan CaJacob
>
>
> ___
> 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-gn

Re: [Discuss-gnuradio] Is 100 Mbps PSK demodulation in GNU RADIO possible? (x310 HW)

[Dan CaJacob]

I am working on a similar system.  In short, the answer is no, your i7
won't keep up that fast.  But you could if you push some processing down
into the FPGA.

For example, my non optimized QPSK modem with 1/2 rate convolutional coding
+ RS coding only works up to about 1 Mbps without over/under flowing.

While optimization will help, 100 Mbps seems like too much of a stretch for
real-time on normal CPUs, but possible on FPGA.  Or maybe possible with
like 40 i7s.

On Fri, Apr 14, 2017, 5:30 AM Mehmeto  wrote:

> Dear All,
>  We just bought an Ettus X310 with PCIe interface.
> We will try to transmit a 100 Mbps OQPSK signal and receive it back using
> the PSK demodulator blocks.
> In your opinion is this possible. Assuming that the HW support such a
> speed,
> will the speed of the GNU Radio Blocks be sufficient? (We will be using one
> of the latest i7 processors.)
>  We couldn't find any max. speed data on these blocks.
> We are also considering to use some high speed GPU but could not find any
> CUDA/ OpenCL based GNU Radio blocks.
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Is-100-Mbps-PSK-demodulation-in-GNU-RADIO-possible-x310-HW-tp63527.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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Embedded GR-IEEE802-11

[Marcus Müller]

Hi Tom,

define "embedded". If you use an x86 or powerful multi-core ARM
Single-Board-Computer, which I'd argue can be an embedded device, then
sure, I don't see any limitations with that compared to what you can do
on a PC. Of course, dealing with 20 MHz channels on a poor ARM processor
is very hard, so this might or might not work out, and might require
hand-tweaking system performance. Don't forget that if using
gr-ieee-802-11, you'll need a high-bandwidth link to your SDR hardware –
typically, Gigabit Ethernet or USB3, the CPU power to handle the torrent
of data that enters and leaves your computer as samples through that
link, the power to process that data, and only if you've got all that
covered and still have CPU to spare to actually do something with your
data payload, you might consider doing a sensible network data rate
benchmark.

Generally, regarding rate: This is not 100.0% true, but in essence:
Either your computer is fast enough to run the flow graph at the
sampling rate you need to cover the full channel, or not. It's not like
"my slow computer can reliably use gr-ieee-802-11, but to get great
rates, I'll need a slightly faster one".
It's more like "my computer is too slow, the CPU can't keep up with the
millions of samples needing processing per second, so it totally does
not work", or "my computer is fast enough, it reliably works in all modes".

Best regards,

Marcus


On 14.04.2017 18:58, Thomas Wilkinson wrote:
> Just wanted to push this inquiry back to the surface:
>
> Is anyone aware of GR-IEEE802-11 having been implemented with an
> embedded system? If so, what is the maximum data rate achieved?
>
> Thanks,
>
> Tom
>
> On Wed, Apr 12, 2017 at 3:22 PM, Thomas Wilkinson  > wrote:
>
> Is anyone aware of GR-IEEE802-11 having been implemented with an
> embedded system? If so, what is the maximum data rate achieved?
>
> Thanks,
>
> Tom
>
>
>
>
> -- 
> Regards,
>
> Tom Wilkinson
> SMART Scholar 
> MS Student, Electrical Engineering
> NC State University
> c: 919.951.4449 
> e: tbwil...@ncsu.edu 
>
>
> ___
> 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] Embedded GR-IEEE802-11

[Thomas Wilkinson]

Just wanted to push this inquiry back to the surface:

Is anyone aware of GR-IEEE802-11 having been implemented with an embedded
system? If so, what is the maximum data rate achieved?

Thanks,

Tom

On Wed, Apr 12, 2017 at 3:22 PM, Thomas Wilkinson  wrote:

> Is anyone aware of GR-IEEE802-11 having been implemented with an embedded
> system? If so, what is the maximum data rate achieved?
>
> Thanks,
>
> Tom
>



-- 
Regards,

Tom Wilkinson
SMART Scholar 
MS Student, Electrical Engineering
NC State University
c: 919.951.4449 <(919)%20951-4449>
e: tbwil...@ncsu.edu
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC 3.7.11 on Windows crashes python.exe

[Marcus Müller]

Hi Martijn,

"Illegal Instruction" is actually a proper processor fault (ie. your
processor noticed a problem, and jumped to an interrupt routine telling
your OS that hey, things need to be handled) that happens when one tries
to execute code that isn't actually code or uses an instruction that
your CPU doesn't have.

I'm pretty optimistic that hackrf.dll wasn't compiled for a CPU that's
incompatible to yours, so this might essentially be a bug – either in
the hackrf driver dll (which might be jumping into machine code that
isn't code), or in the way the windows DLL loader is used. Hm. Maybe
even a compiler bug.

Now, I have to admit that under Unixes, I'd know how to debug this, but
under Windows, I'm out of my depth. So if you happen to be more capable
than I am with that, you could try to run "python
C:\path\to\your\flow_graph_python_file.py" in a debugger and see where
it crashes. But even then, I don't know if things would be easy to
figure out.

Best regards,
Marcus
On 14.04.2017 16:34, Martijn Scale wrote:
>
> Trying to use a HackRF One with GNU Radio on Windows 10 (64-bits),
> installed from gnuradio_3.7.11_win64.msi.
>
> When using osmocom Source and executing the flow graph, execution
> halts with message: python.exe has stopped working. GRC remains alive.
>
> Crashes happen both with WX and QT. The HackRF One module is put into
> Receive mode (Rx Led of HackRF One is on).
>
>  
>
> GNU Radio, GRC, Hack RF and computer do work as expected with the
> GNURadioLiveDVD .
>
>  
>
> Debugging shows: Unhandled exception at 0x7FFCCDDD3CCB
> (hackrf.dll) in python.exe: 0xC01D: Illegal Instruction.
>
> Additional info from Event Viewer:
>
> Faulting application path: C:\Program
> Files\GNURadio-3.7\gr-python27\python.exe
>
> Faulting module path: C:\Program Files\GNURadio-3.7\bin\hackrf.dll
>
> And info from Console Panel in GRC:
>
> Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_003.010.001.001-0-unknown
>
>  
>
> hackrf.dll info: 2017-03-03, 66.560 Bytes
>
>  
>
> gr-osmosdr ae686c46 (0.1.5git) gnuradio 3.7.11
>
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
> airspy redpitaya
>
> Number of USB devices: 17
>
> USB device 1d50:: a06063c82xxx match
>
> Using HackRF One with firmware 2017.02.1
>
>  
>
> Hardware:
>
> Processor   Intel(R) Core(TM) i7 CPU 860  @ 2.80GHz,
> 2794 Mhz, 4 Core(s), 8 Logical Processor(s)
>
> Display adapterAMD Radeon HD 5700 Series
>
>  
>
> Your support is highly appreciated (I tried building GNU Radio from
> sources, which failed as “gr-newmod/CMakeLists.txt was not found and
> is required”, but I decided not to pursue the building path any
> further as it exceeds my knowledge).
>
>  
>
>  
>
>
>
> ___
> 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] GRC 3.7.11 on Windows crashes python.exe

[Martijn Scale]

Trying to use a HackRF One with GNU Radio on Windows 10 (64-bits), installed 
from gnuradio_3.7.11_win64.msi.
When using osmocom Source and executing the flow graph, execution halts with 
message: python.exe has stopped working. GRC remains alive.
Crashes happen both with WX and QT. The HackRF One module is put into Receive 
mode (Rx Led of HackRF One is on).

GNU Radio, GRC, Hack RF and computer do work as expected with the 
GNURadioLiveDVD.

Debugging shows: Unhandled exception at 0x7FFCCDDD3CCB (hackrf.dll) in 
python.exe: 0xC01D: Illegal Instruction.
Additional info from Event Viewer:
Faulting application path: C:\Program Files\GNURadio-3.7\gr-python27\python.exe
Faulting module path: C:\Program Files\GNURadio-3.7\bin\hackrf.dll
And info from Console Panel in GRC:
Win32; Microsoft Visual C++ version 14.0; Boost_106000; 
UHD_003.010.001.001-0-unknown

hackrf.dll info: 2017-03-03, 66.560 Bytes

gr-osmosdr ae686c46 (0.1.5git) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf airspy 
redpitaya
Number of USB devices: 17
USB device 1d50:: a06063c82xxx match
Using HackRF One with firmware 2017.02.1

Hardware:
Processor   Intel(R) Core(TM) i7 CPU 860  @ 2.80GHz, 2794 Mhz, 
4 Core(s), 8 Logical Processor(s)
Display adapterAMD Radeon HD 5700 Series

Your support is highly appreciated (I tried building GNU Radio from sources, 
which failed as "gr-newmod/CMakeLists.txt was not found and is required", but I 
decided not to pursue the building path any further as it exceeds my knowledge).


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

[Discuss-gnuradio] Is 100 Mbps PSK demodulation in GNU RADIO possible? (x310 HW)

[Mehmeto]

Dear All,
 We just bought an Ettus X310 with PCIe interface.
We will try to transmit a 100 Mbps OQPSK signal and receive it back using
the PSK demodulator blocks.
In your opinion is this possible. Assuming that the HW support such a speed,
will the speed of the GNU Radio Blocks be sufficient? (We will be using one
of the latest i7 processors.)
 We couldn't find any max. speed data on these blocks.
We are also considering to use some high speed GPU but could not find any
CUDA/ OpenCL based GNU Radio blocks. 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Is-100-Mbps-PSK-demodulation-in-GNU-RADIO-possible-x310-HW-tp63527.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