[Discuss-gnuradio] [volk] MSVC optimizer bug

[Gisle Vanem]

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

Is anybody else having troubles with this?

A fix for me was to remove all '-O..'  flags when compiling
this file. No problems with any other files. Or use the attached patch.

This "optimizer bug" has been reported here:

https://developercommunity.visualstudio.com/content/problem/237802/optimizer-bug-still-persists.html

--
--gv


--- a/kernels/volk/volk_32f_index_max_16u.h 2016-07-28 15:53:26
+++ b/kernels/volk/volk_32f_index_max_16u.h 2018-06-25 11:28:31
@@ -143,6 +143,23 @@

 #include 

+/*
+ * To bypass an Optimizer bug in MSVC-2017.
+ * Ref:
+ *   
https://developercommunity.visualstudio.com/content/problem/215602/new-optimizer-code-generation-bug.html
+ *
+ * Turn off all optimizations for this function.
+ */
+#if defined(_MSC_VER) && !defined(__clang__)
+  #define OPTIMIZE_OFF()  __pragma (optimize ("g", off));
+  #define OPTIMIZE_DEF()  __pragma (optimize ("", on));
+#else
+  #define OPTIMIZE_OFF()
+  #define OPTIMIZE_DEF()
+#endif
+
+OPTIMIZE_OFF()
+
 static inline void
 volk_32f_index_max_16u_a_sse(uint16_t* target, const float* src0,
  uint32_t num_points)
@@ -200,6 +217,8 @@
   target[0] = (uint16_t)index;
 }

+OPTIMIZE_DEF()
+
 #endif /*LV_HAVE_SSE*/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Project Announcement: "master" will require C++11 soon

[CEL]

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 to mandatory C++11 on master.

This allows for a lot less verbose coding style in many places, and
gives us a whole load of language features that we formerly had to
import through Boost, which has the tendency to change API without
notice (we've been bitten by that, for example, in the shape of
random::mt19937, and other namespaces).

It was becoming "kind of a requirement, anyway" through cppunit, as
that switched to C++11 recently. Luckily, on machines with a "fresh
enough" cppunit to require C++11, we also were able to rely on a
compiler for that standard, and we figured out that for most systems,
getting a C++11 compiler means no extra effort.

Older systems will continue to be able to build the maint-3.7 branch,
which we still actively maintain and to which we add bugfixes.

Master will, in the closer future, look like next looks now, as we're
moving towards a 3.8 release. That will undoubtedly mean we'll have
quite a bit of application breakage with master. That is not
intentional, but might very well be inevitable, as the changes we're
making to the code base are quite fundamental, and thus we'll have to
understand master as what it was meant to be: the main development
branch. Releases from that branch are to be assumed "end-user
compatible", but not every intermediate state, at every cost. As said,
the upcoming release from master will be 3.8! 

Now, to get to that release, and we really *have* to, we'll need a
large set of good bug reports! So, whether you're working on next,
master or with the latest 3.7 release, and something doesn't work like
it should, please do file an issue with GNU Radio on github, and if
possible, make a test case; if you need help with any of that, please
do reach out!


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

Re: [Discuss-gnuradio] UHD_Source.USRP N310

[Martin Braun]

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 working, and does not expect a future
> thread command for contiguous samples. "Num samps and more" reports the
> following: And is it possible to switch between the modes in the
> UHD_Source and RFNoc_radio ?? In the pure uhd code I used Num sams and
> done but now I want to try using FPGA for FFT processing and so I use
> GNURadio. Thanks for the help

If you use a 'head' block in GNU Radio, it has the same effect. Or, you
can set `issue_stream_cmd_on_start` to false, and then call
`issue_stream_cmd()` where you can set num_samps_and_done.

-- M

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

Re: [Discuss-gnuradio] DVB-S2/X Block Party at GNU Radio Conference 2018

[Martin Braun]

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 08:30 AM, Michelle Thompson wrote:
> "Enthusiastic Yes" on RFNoC. 
> 
> Our assumption is that we will need RFNoC. I think we could certainly
> use some advice on workflow. 
> 
> The LDPC FEC decode effort right now includes attempts with Xilinx SDSoC
> to convert functions from the GPU codebase into hardware accelerated
> FPGA code. From there, package for RFNoC.
> 
> This plan has advantages and disadvantages. We're here to learn and
> contribute whatever we can. 
> 
> We have several SDSoC licenses and several full Vivado licenses. We have
> at least one X310, several B210s, and a variety of other FPGA dev boards
> (Snickerdoodls, Ultra96, etc).
> 
> We have plenty of Plutos and some LimeSDRs. 
> 
> -Michelle W5NYV
> 
> 
> On Wed, Jun 20, 2018 at 3:42 PM, Dan CaJacob  > wrote:
> 
> I'd suggest incorporating RFNOC at least as an option. I suspect
> actual use of DVBS2X might be rather boring if you're stuck on a
> processor.
> 
> On Wed, Jun 20, 2018 at 4:38 PM Michelle Thompson
> mailto:mountain.miche...@gmail.com>>
> wrote:
> 
> Hello everyone,
> 
> GNU Radio Conference is coming up in September. If you haven't
> registered and want to go, please do at
> https://www.gnuradio.org/grcon-2018/
> 
> 
> There's a special event this year called Block Party.
> 
> It's an effort to get DVB-S2 and DVB-S2X receivers in GNU Radio.
> 
> We will have our own room and tables and swag. We will have
> docents enthusiasm and test equipment. We're looking for more!
> We'll have documentation and refreshments. 
> 
> We need blocks! 
> 
> Most blocks needed for DVB-S2/X receive do, in some form,
> already exist. Some do not. Some just need additional modulation
> and codings added to them. 
> 
> Receiver design is hard, but breaking it up into small blocks
> makes it tractable. 
> 
> The DVB protocol documents are all open. There are
> implementation guidelines. See https://www.dvb.org/
> 
> There are several community members that are experts in this
> area. There is a team (Phase 4 Ground - find out more at
> https://phase4ground.github.io/
> ) that needs DVB-S2/X to work
> in GNU Radio. There is a lot of interest from a variety of other
> groups including Libre Space, ARRL, AMSAT, and TAPR.
> 
> If you are able to contribute to this effort, I want to know
> about it! I am here to support it. I'd like nothing better than
> to complete the Block Party at GNU Radio Conference with
> working, tested, documented blocks for a DVB-S2/X receiver. This
> contribution makes our open source terrestrial and space radio
> designs for Phase 4 Ground possible, and also opens up a lot of
> other work. 
> 
> The thing that is considered the hardest part is the LDPC FEC
> decode. We have an open source implementation that targets GPUs.
> We want to take this and get it into RFNoC. If you are working
> on this as well, we want to collaborate and support and combine
> and promote. 
> 
> The GPU implementation (by Charles Brain G4GUO) of LDPC decode
> can be found at our repository folder here:
> 
> https://github.com/phase4ground/DVB-receiver/tree/master/G4GUO-LDPC-on-GPU/DVB-S2XTxRx
> 
> 
> 
> Phase 4 Ground is devoted to an open source implementation of
> DVB-S2 and DVB-S2X for amateur radio terrestrial and space use.
> We are part of Open Research Institute. Learn more about this
> non-profit here: https://openresearch.institute/
> 
> 
> -Michelle W5NYV
> 
> ___
> 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-gnur

Re: [Discuss-gnuradio] Expected FPGA compatibility number 35, but got 33

[Martin Braun]

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

-- M

On 06/20/2018 09:21 AM, Mir Muhammad Lodro wrote:
> Hi All,
> I have installed gnuradio from source as instructed on gnuradio webpage.
> I have Ubuntu 18.04 on my host PC. I can ping USRP x310 and can also do
> uhd_find_devices, however when I use "uhd_usrp_probe --args
> "addr=192.168.10.2" it return FPGA compatibility issue. In repose to
> this I have done uhd_images_downloader, uhd_image_loader and
> power-cycled USRP x310. However, it repeats with the same FPGA
> incompatibility issue. Why it happens despite I follows proper steps. Is
> it because of outdated FPGA image not compatible with latest UHD
> release. If yes then what's the solution.
> Thanks
> Mir Lodro
> 
> mirlodro@eexmmlo:~$ uhd_find_devices
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_3.12.0.0-release
> --
> -- UHD Device 0
> --
> Device Address:
>     serial: 30C098D
>     addr: 192.168.10.2
>     fpga: HG
>     name:
>     product: X310
>     type: x300
> 
> 
> mirlodro@eexmmlo:~$ uhd_usrp_probe --args "addr=192.168.10.2"
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_3.12.0.0-release
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> Error: RuntimeError: Expected FPGA compatibility number 35, but got 33:
> The FPGA image on your device is not compatible with this host code build.
> Download the appropriate FPGA images for this version of UHD.
> Please run:
> 
>  "/usr/lib/uhd/utils/uhd_images_downloader.py"
> 
> Then burn a new image to the on-board flash storage of your
> USRP X3xx device using the image loader utility. Use this command:
> 
> "/usr/bin/uhd_image_loader" --args="type=x300,addr=192.168.10.2"
> 
> For more information, refer to the UHD manual:
> 
>  http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_flash
> 
> 
> 
> 
> ___
> 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] [USRP-users] TX-RX file through OFDM errors

[Martin Braun]

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:* Martin Braun 
> *Sent:* Wednesday, June 13, 2018 3:22:57 PM
> *To:* Ayaz Mahmud; discuss-gnuradio@gnu.org; usrp-us...@lists.ettus.com
> *Subject:* Re: [USRP-users] TX-RX file through OFDM errors
>  
> On 06/12/2018 10:28 AM, Ayaz Mahmud via USRP-users wrote:
>> Hi,
>> 
>>  
>> 
>> I am trying to transmit and receive a .png file through OFDM (*Block
>> diagram attached*). The file size is only 1.5kB. While running I am
>> getting the below warning & error in console. Can someone point out the
>> reason behind the error and what I am doing wrong. I am a beginner and
>> just started to learn the Gnuradio from tutorials.
>> 
>>  
>> 
>> linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
>> [...]
>> UHD Error:
>> 
>>     recv packet demuxer unexpected sid 0x330006
>> 
>>  
>> 
>> UHD Error:
>> 
>>     recv packet demuxer unexpected sid 0x49bf846e
> 
> Is this a B210/B200, and does it work with other examples?
> 
> -- M


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

[Discuss-gnuradio] QT Gui mem alloc error - runs OK if R, C hints deleted

[Tom McDermott]

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
the QT Gui Frequency sink in this example throws a memory allocation error.

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

2. If I remove the Row, Column GUI hints from just that one QT GUI item,
then it
comes up and runs OK. The other 9 of the QT controls (sliders, choosers,
entry,
ranges) still have their R,C hints.

3. Went back to the GRC file in step 1 that still has the R,C hints in it
and it still fails with the error as shown in step 1.  It did come up and
run
one time showing 'unable to set locale' error, but still ran.  Never seen
that before.


Is there some limitation against using R,C hints on the QT displays (time,
frequency, etc.)?

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

Re: [Discuss-gnuradio] USRP N210 Not transmitting simulated satellite signals

[Dan CaJacob]

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, 2018 at 6:58 AM Marcus Müller 
wrote:

> underruns mean your computer isn't fast enough at supplying samples to
> the SDR device.
> In other words, you can only solve that by optimizing performance of
> you computer. You might need a better computer, or set up your computer
> more efficiently; this might or might not be solvable by following the
> windows-specific tips on http://files.ettus.com/manual/page_transport.h
> tml#transport_udp
>  .
> Chances are you just need a faster computer.
>
> Best regards,
> Marcus
> On Sat, 2018-06-23 at 13:28 +0300, evans ryanada wrote:
> > i  have cloned gps-sdr-sim and i have taken all the steps towards
> > achieving GPS simulated signals unfortunately upon typing this
> > command prompt . My micro controller can receive simulated GPS
> > signals.
> >
> > working environment
> > Windows 8
> > Gnurado companion 3.7.11
> >
> > On the command prompt it is displaying U this i understand this
> > is all about underan
> > how can i sort my problem
> > ___
> > 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] DVB-S2/X Block Party at GNU Radio Conference 2018

[Dan CaJacob]

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-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 08:30 AM, Michelle Thompson wrote:
> > "Enthusiastic Yes" on RFNoC.
> >
> > Our assumption is that we will need RFNoC. I think we could certainly
> > use some advice on workflow.
> >
> > The LDPC FEC decode effort right now includes attempts with Xilinx SDSoC
> > to convert functions from the GPU codebase into hardware accelerated
> > FPGA code. From there, package for RFNoC.
> >
> > This plan has advantages and disadvantages. We're here to learn and
> > contribute whatever we can.
> >
> > We have several SDSoC licenses and several full Vivado licenses. We have
> > at least one X310, several B210s, and a variety of other FPGA dev boards
> > (Snickerdoodls, Ultra96, etc).
> >
> > We have plenty of Plutos and some LimeSDRs.
> >
> > -Michelle W5NYV
> >
> >
> > On Wed, Jun 20, 2018 at 3:42 PM, Dan CaJacob  > > wrote:
> >
> > I'd suggest incorporating RFNOC at least as an option. I suspect
> > actual use of DVBS2X might be rather boring if you're stuck on a
> > processor.
> >
> > On Wed, Jun 20, 2018 at 4:38 PM Michelle Thompson
> > mailto:mountain.miche...@gmail.com>>
> > wrote:
> >
> > Hello everyone,
> >
> > GNU Radio Conference is coming up in September. If you haven't
> > registered and want to go, please do at
> > https://www.gnuradio.org/grcon-2018/
> > 
> >
> > There's a special event this year called Block Party.
> >
> > It's an effort to get DVB-S2 and DVB-S2X receivers in GNU Radio.
> >
> > We will have our own room and tables and swag. We will have
> > docents enthusiasm and test equipment. We're looking for more!
> > We'll have documentation and refreshments.
> >
> > We need blocks!
> >
> > Most blocks needed for DVB-S2/X receive do, in some form,
> > already exist. Some do not. Some just need additional modulation
> > and codings added to them.
> >
> > Receiver design is hard, but breaking it up into small blocks
> > makes it tractable.
> >
> > The DVB protocol documents are all open. There are
> > implementation guidelines. See https://www.dvb.org/
> >
> > There are several community members that are experts in this
> > area. There is a team (Phase 4 Ground - find out more at
> > https://phase4ground.github.io/
> > ) that needs DVB-S2/X to work
> > in GNU Radio. There is a lot of interest from a variety of other
> > groups including Libre Space, ARRL, AMSAT, and TAPR.
> >
> > If you are able to contribute to this effort, I want to know
> > about it! I am here to support it. I'd like nothing better than
> > to complete the Block Party at GNU Radio Conference with
> > working, tested, documented blocks for a DVB-S2/X receiver. This
> > contribution makes our open source terrestrial and space radio
> > designs for Phase 4 Ground possible, and also opens up a lot of
> > other work.
> >
> > The thing that is considered the hardest part is the LDPC FEC
> > decode. We have an open source implementation that targets GPUs.
> > We want to take this and get it into RFNoC. If you are working
> > on this as well, we want to collaborate and support and combine
> > and promote.
> >
> > The GPU implementation (by Charles Brain G4GUO) of LDPC decode
> > can be found at our repository folder here:
> >
> https://github.com/phase4ground/DVB-receiver/tree/master/G4GUO-LDPC-on-GPU/DVB-S2XTxRx
> > <
> https://github.com/phase4ground/DVB-receiver/tree/master/G4GUO-LDPC-on-GPU/DVB-S2XTxRx
> >
> >
> > Phase 4 Ground is devoted to an open source implementation of
> > DVB-S2 and DVB-S2X for amateur radio terrestrial and space use.
> > We are part of Open Research Institute. Learn more about this
> > non-profit here: https://openresearch.institute/
> > 
> >
> > -Michelle W5NYV
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> >
> > --
> > Very Respectfully,
> >