I'm experiencing an INTERNAL COMPILER ERROR in MSVC-2017
(latest version 19.13.26129 for x86) when compiling
volk/lib/volk_machine_sse2_mmx.c.
Function volk_32f_index_max_16u_a_sse(), ref:
https://www.gnuradio.org/doc/doxygen-3.7.2.1/volk__32f__index__max__16u_8h_source.html
at lines 70 - 12
Hello greatest SDR community to roam the earth,
as we're progressing towards a merge of the next branch into master,
which will actually bring us new features and challenges like Python3,
QT5, YAML instead of XML in GRC and many, many specific improvements,
I'll announce that we're switching over
On 06/24/2018 07:41 AM, Ivan Zahartchuk wrote:
> Hello. I'm interested in the principle of UHD_Source. "Start continuous"
> tells the device to make the streams of samples infinite. "Continuous
> stop" tells the device to stop the continuous transmission. "Num sams
> and done" reports that it is wo
It would be great to have both. Even if you can't do real-time decoding,
you can get pretty far with non-realtime decoding. And at least, we'd
have a reference design (even it's too slow). Although of course, I'd
very much love to see RFNoC blocks for various other reasons :)
-- M
On 06/21/2018 0
There's the possibility that you have old images somewhere. Try running
`uhd_images_downloader --refetch` to force refetching, and take a note
of the destination (it's the first line of the output).
Then, run uhd_image_loader with the --fpga-src option, and point it
directly to the file you want to
Can you try recv_frame_size=1024 as part of the device args?
-- M
On 06/13/2018 03:23 PM, Ayaz Mahmud wrote:
> Hi,
>
>
>
> Yes, Its B210 and works with other example like tx_ofdm.
>
>
>
> Ayaz
>
>
>
>
> *From:* M
Ubuntu 16.04.3
GRC 3.7.11.1 (from git)
I was on 3.7.13 couple of weeks ago, completely removed all of gnuradio
and rebuilt trying to debug this. 3.7.11.1 had same problem.
Got back to the problem of several weeks ago.
1. When I try to use a QT GUI sink (such as frequency) the invocation of
th
GPS playback or simulation is *really* sensitive to underflows. If you have
them, you're hosed. When playing back a GPS recording, I always read the
file from a RAMdisk. SSDs (generally) and spinning disks just aren't fast
enough usually, and sometimes your OS even gets in the way.
On Sat, Jun 23,
Absolutely. It's kind of insane to build an RFNOC system without first
having a software implementation. This will be exciting!
On Mon, Jun 25, 2018 at 5:22 PM Martin Braun wrote:
> It would be great to have both. Even if you can't do real-time decoding,
> you can get pretty far with non-realtim
