[Discuss-gnuradio] Software Defined Radio Academy Recordings
Dear lists, please find the recordings of the recent Software Defined Radio Academy 2016 available online: http://video.sdra-2016.de Alltogether, we have now 31 recorded high level talks you can enjoy! I hereby want to express our gratitude to Prof. Dr. Ulrich Rohde DL1R, KA2WEU for supporting us and facilitating this year's video recording with a professional camera and the production by a video company. I also take the opportunity to emphasize our gratitude to Mika Kjellmann who volunteered and helped us out to produce our last year's videos for free and did a great job to get the best out of the corrupted recordings with a small low quality / broken camera. And I thank the HAMRADIO organizers of Deutscher Amateur Radio Club to host the SDRA as part of the HAMRADIO fair. @Renate: BIG thanks, great co-operation! The SDRA-2016 has grown from an audience of 65 to 105. We have identified several points where the SDRA will need to change: * We would like to offer an introductory practical workshop on Friday and reserve the Saturday track for non-introductory talks. * We intend to raise more funds and place announcements in major tech magazines. * We will send out the Call For Papers / Contributions already in November/December, so be warned! :-) We will ensure that our talks will be listed in the official HAMRADIO programme individually, and no more just as *one* SDRA block. Please note that the date of the SDRA will be slightly postponed in 2017: The HAMRADIO will take place 14.-16. July 2017, thus the SDRA will be on July 15. In summary, it was a great event, enjoy the vidos, and see you next year! vy73 Markus Heller dl8rds ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CppUnit Issue
I am trying to test out my OOT module with CppUnit tests, but I am not able
to get the message from CPPUNIT_ASSERT_MESSAGE("moo", 1 == 2) to output.
All I get is that the test failed (F). Just getting that message is
terrible for debugging. Is there a flag I missed somewhere or some
configuration that isn't set right? The only option I have right now is to
use an if statement to check the condition, print out a message if the
condition fails, and then call CPPUNIT_FAIL() to bomb out.
Thank you!
-Dave
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio "competitors" in pybombs?
Also, for what it's worth, I wouldn't consider 'liquid-dsp' a "competitor" to GNU Radio. I realize you also had "competitor" in quotes in your title, likely for the same reason, hah. I know of a number of folks that have used liquid blocks within GNU Radio, actually. Anyway, thanks for the contribution, Chris. Cheers, Ben On Tue, Jul 12, 2016 at 6:24 PM, Martin Braun wrote: > Yeah, you can post a PR for liquid-dsp recipe. > > M > > On 07/12/2016 12:03 PM, Chris Kuethe wrote: > > The inspectrum recipe is kind of broken right now since it's switched > > to using liquid-dsp. Unless I hear some really compelling arguments > > to the contrary, I'm planning to add a recipe for liquid to the > > etcetera repository because: > > - it fits my mental model of pybombs being the go-to place for radio > > and dsp packages > > - it fixes an existing recipe > > - it doesn't break existing apps > > - we have other radio apps that don't use gnuradio but are somewhat > related > > > > > ___ > 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] CppUnit Issue
The actual output is written to XML logs – but if you're interested in
seeing it live, I'd recommend just running "ctest -v" from your build
directory.
Best regards,
Marcus
On 07/13/2016 03:39 PM, Dave NotTelling wrote:
> I am trying to test out my OOT module with CppUnit tests, but I am not
> able to get the message from CPPUNIT_ASSERT_MESSAGE("moo", 1 == 2) to
> output. All I get is that the test failed (F). Just getting that
> message is terrible for debugging. Is there a flag I missed somewhere
> or some configuration that isn't set right? The only option I have
> right now is to use an if statement to check the condition, print out
> a message if the condition fails, and then call CPPUNIT_FAIL() to bomb
> out.
>
> Thank you!
>
> -Dave
>
>
> ___
> 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] Implementing timed transmission: UHD API or Stream Tags?
Hi Martin, Appreciate your reply to my questions. I agree that I cannot do better than a clock cycle, so that is settled. Let us say that I use GPSDO for my reference and I wish to transmit at GPS time t. Is it possible to control the transmit time to within (t plus/minus 1 clock cycle)? I have read other threads on this topic and it looks like the "tx_time" tag controls the time at which the packet is released to the DSP on-board USRP. So it would take some additional time for the packet to go through the DSP, DAC, and the antenna. Now I would like to perform the experiment myself and see if this delay is something that I can calibrate out, but unfortunately we do not have the hardware on hand (I currently have DBSRX2 which cannot transmit). So I was wondering if you have some intuition about the kind of consistent/variable delays I would be seeing, and how bad you would expect the variation to be (~10 ns, ~100 ns, ~1 ms)? Thanks, Lakshay. > Hello, > > > > I am a new GNU Radio user. I am looking to build a system that can > > transmit a packet at a pre-defined time with very high accuracy (about 1 > > nanosecond). Having gone through the mailing list I am aware that timed > > transmission is a common task and many people have asked similar > > questions. However, I am still a bit confused. > > > > 1. I see that there is an example tx_timed_samples that comes with the > > UHD source code. This is in C++ and uses the UHD API. Am I right in > > thinking that when implemented this way, it has nothing to do with GNU > > Radio at all? Is there any "reported accuracy" of this method in terms > > of difference between actual and required time of transmission? > > Yes, that's accurate. This is more of a UHD/USRP issue. Note that you > can time to a clock cycle, which is longer than a nanosecond. Whether or > not your sample is lined up with a time reference of your choice to > sufficient accuracy also depends on the reference signal you're providing. > > > 2. I also see that it is possible to achieve similar objectives using > > tx_time stream tags in GNU Radio. My question is if this method is > > equivalent to method 1 in terms of what goes on "under the hood"? If > > not, how do these differ, and which method would provide better accuracy > > in terms of agreement between actual and required time of transmission. > > Does GNU Radio use the UHD API "under the hood"? > > Yes, it does, and tags are no better or worse than the API calls. They > may be more convenient, depending on your software. Internally, the UHD > send() call (which is how samples get to devices) is populated with a > timestamp in both cases. > > > Please feel free to point me to resources I can read to get a better > > understanding of this architecture and relationship between UHD, GNU > > Radio, and USRP. > > There's also the usrp-users mailing list, and UHD has a bunch of > examples. gr-uhd code is also a useful reference. > > Cheers, > M > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-psk31
Hey there! Boy, it's been a long time since I touched that code. It's very "hacked together", and needs some love! I'd recommend trying psk31_rx.grc with this video[1]. If you have youtube-dl, you can save it to a wav file. For the TX side, I didn't really get that flushed out properly. The audio sink doesn't like it when you stop sending samples to it, and I couldn't figure out a tidy way to clean things up. In the mean time, look at the vector source in psk31_tx.grc. \x80 is the "preamble" byte, and everything else is just plain ASCII. That should get you up and running! Maybe if I have some time later, I can get a transmitter block up and running with the osmocom sink. It's just a simple AM transmitter. - Tim [1] https://www.youtube.com/watch?v=qHNvp7FfP6E On Sun, Jul 10, 2016 at 1:12 AM, Eoin 0w3n wrote: > Hi, > I've been having some fun with gr-psk32 ( > https://github.com/tkuester/gr-psk31). > > The aim is to be able to send ascii with a hackrf nd then receive with > an rtlsdr. > >For now, I would just like to get the rx and tx examples working over > audio/soundcard. > >I just added an audio source block to the "psk_rx.grc" and left the > "psk_tx.grc" example as-is. > >When trying to tune on the right hand wide waterfall, I seem to get > something close around 1850. I end up receiving "holmoewnrmg\n" which looks > to be something related to the transmitted "hello world!\n" vector in the > example. > >Has anyone got the tx and rx working for gr-psk32? Im sure its just a > small setting somewhere. > >Thank you :-) > > > ___ > 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] CppUnit Issue
Marcus,
I was not aware of the ctest application. Thank you for that! Sadly
'ctest -v', 'ctest -V', 'ctest -VV', 'ctest --output-on-failure' and 'ctest
--debug' all fail to print the message or line number. Seems the only
thing that I can do is dump the XML file in lib/.unittests. Not ideal, but
workable.
Thanks!
-Dave
On Wed, Jul 13, 2016 at 11:57 AM, Marcus Müller
wrote:
> The actual output is written to XML logs – but if you're interested in
> seeing it live, I'd recommend just running "ctest -v" from your build
> directory.
>
> Best regards,
> Marcus
>
>
> On 07/13/2016 03:39 PM, Dave NotTelling wrote:
>
> I am trying to test out my OOT module with CppUnit tests, but I am not
> able to get the message from CPPUNIT_ASSERT_MESSAGE("moo", 1 == 2) to
> output. All I get is that the test failed (F). Just getting that message
> is terrible for debugging. Is there a flag I missed somewhere or some
> configuration that isn't set right? The only option I have right now is to
> use an if statement to check the condition, print out a message if the
> condition fails, and then call CPPUNIT_FAIL() to bomb out.
>
> Thank you!
>
> -Dave
>
>
> ___
> 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] CppUnit Issue
Maybe it was 'ctest -V' ? inconsistent capitalization always confuses me...
On 07/13/2016 06:44 PM, Dave NotTelling wrote:
> Marcus,
>
> I was not aware of the ctest application. Thank you for that!
> Sadly 'ctest -v', 'ctest -V', 'ctest -VV', 'ctest --output-on-failure'
> and 'ctest --debug' all fail to print the message or line number.
> Seems the only thing that I can do is dump the XML file in
> lib/.unittests. Not ideal, but workable.
>
> Thanks!
>
> -Dave
>
> On Wed, Jul 13, 2016 at 11:57 AM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> The actual output is written to XML logs – but if you're
> interested in seeing it live, I'd recommend just running "ctest
> -v" from your build directory.
>
> Best regards,
> Marcus
>
>
> On 07/13/2016 03:39 PM, Dave NotTelling wrote:
>> I am trying to test out my OOT module with CppUnit tests, but I
>> am not able to get the message from CPPUNIT_ASSERT_MESSAGE("moo",
>> 1 == 2) to output. All I get is that the test failed (F). Just
>> getting that message is terrible for debugging. Is there a flag
>> I missed somewhere or some configuration that isn't set right?
>> The only option I have right now is to use an if statement to
>> check the condition, print out a message if the condition fails,
>> and then call CPPUNIT_FAIL() to bomb out.
>>
>> Thank you!
>>
>> -Dave
>>
>>
>> ___
>> 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] CppUnit Issue
That one doesn't output the message or line number either. Event '-VV'
doesn't show the message.
On Wed, Jul 13, 2016 at 12:47 PM, Marcus Müller
wrote:
> Maybe it was 'ctest -V' ? inconsistent capitalization always confuses me...
>
>
> On 07/13/2016 06:44 PM, Dave NotTelling wrote:
>
> Marcus,
>
> I was not aware of the ctest application. Thank you for that! Sadly
> 'ctest -v', 'ctest -V', 'ctest -VV', 'ctest --output-on-failure' and 'ctest
> --debug' all fail to print the message or line number. Seems the only
> thing that I can do is dump the XML file in lib/.unittests. Not ideal, but
> workable.
>
> Thanks!
>
> -Dave
>
> On Wed, Jul 13, 2016 at 11:57 AM, Marcus Müller
> wrote:
>
>> The actual output is written to XML logs – but if you're interested in
>> seeing it live, I'd recommend just running "ctest -v" from your build
>> directory.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 07/13/2016 03:39 PM, Dave NotTelling wrote:
>>
>> I am trying to test out my OOT module with CppUnit tests, but I am not
>> able to get the message from CPPUNIT_ASSERT_MESSAGE("moo", 1 == 2) to
>> output. All I get is that the test failed (F). Just getting that message
>> is terrible for debugging. Is there a flag I missed somewhere or some
>> configuration that isn't set right? The only option I have right now is to
>> use an if statement to check the condition, print out a message if the
>> condition fails, and then call CPPUNIT_FAIL() to bomb out.
>>
>> Thank you!
>>
>> -Dave
>>
>>
>> ___
>> 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] Installation of GNU Radio/UHD on Windows
Derek/Dave, My development equipment is still in transit so I can't look at anything until Monday, but... The UHD build should be 64-bit, so it is mostly likely a labelling issue. But I will check to be sure. If you want to run -any- GNURadio utilities, I recommend doing so from the GNURadio Command Prompt (shortcut in start menu or run_gr.bat in the /bin subdir) ... that will set all the Python/etc environment variables up correctly. Then you should not need to specify where the UHD images are. Geof On Tue, Jul 12, 2016 at 10:11 PM, Derek Kozel wrote: > Hi Dave, > > Yes, there is no state held in UHD so you will always need to include the > --args "fw.." in your UHD commands. I should have also mentioned that > this means you will need to add that exact "fw= D:\Program > Files\GNURadio-3.7\share\uhd\images\usrp_b100_fw.ihx,fpga= D:\Program > Files\GNURadio-3.7\share\uhd\images\usrp_b100_fpga.bin" string in the USRP > Source or Sink block Device Arguments field for any GNU Radio flowgraph. > You can try modifying the wbfm example for instance. > > The ability to specify specific FPGA and firmware images is usually a > development feature if you have multiple versions of UHD installed > alongside each other or are building custom images. In this case we are > using it to get around a path problem. > > If you create the D:\Program Files\UHD\share\uhd\images\... folder with > images UHD will hopefully pick them up automatically. I have not tried a > Windows install where D is the system drive so I'm unsure of the exact > behavior. > > Ok, I had the wrong python command there, but python itself did run. > Here's a line which certainly should work, but there's likely nothing > additional to be gained by running it. > python -c "import gnuradio; print gnuradio" > > Regards, > Derek > > On Tue, Jul 12, 2016 at 7:02 PM, Dave wrote: > >> Derek, >> >> >> >> I ran rx_samles _*to*_file. Although using the location arrguments you >> gave me for uhd_find_devices allows for the B100 to be found it does not >> look like the knowledge of where the images are located is retained. >> Running the samles_to_file command again results in a condition where >> firmware could not be found. >> >> >> >> D:\Program Files\GNURadio-3.7\share\uhd\examples>rx_samples_to_file >> >> Win32; Microsoft Visual C++ version 14.0; Boost_106000; >> UHD_003.009.003-0-unknown >> >> >> >> >> >> Creating the usrp device with: ... >> >> >> >> UHD Warning: >> >> Could not locate B100 firmware. As an Administrator, please run: >> >> "C:\Program Files\UHD\lib\uhd\utils\uhd_images_downloader.py" >> >> Error: LookupError: KeyError: No devices found for -> >> >> Empty Device Address >> >> >> >> I also ran the python command you gave me with the results to follow: >> >> >> >> >> >> D:\Program Files\GNURadio-3.7>python.exe -c "from gruel import pmt; print >> pmt" >> >> Traceback (most recent call last): >> >> File "", line 1, in >> >> ImportError: No module named gruel >> >> >> >> D:\Program Files\GNURadio-3.7> >> >> >> >> If there is anything else you want me to run, I will do so. >> >> >> >> Dave >> >> >> >> *From:* Derek Kozel [mailto:derek.ko...@ettus.com] >> *Sent:* Tuesday, July 12, 2016 6:29 PM >> >> *To:* Dave >> *Cc:* GNURadio Discussion List >> *Subject:* Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on >> Windows >> >> >> >> Hi Dave, >> >> I'm glad that the B100 was able to be detected. If you want to confirm >> that it is fully operating you could run any of the examples included with >> UHD, for instance uhd_benchmark_rate or rx_samples_to_file. These are >> standalone from GNU Radio so should avoid whatever Python issue may exist. >> >> I've just noticed, the UHD version installed is Win32. I'm surprised at >> this as the GNU Radio binary builds are all 64 bit. If the developer of >> these Windows binary installers sees the thread hopefully he can comment. >> >> GNU Radio is certainly easier to use on Linux or OS X, but there is a >> desire to see Windows support improve over time. This may not happen >> quickly, but it's a great sign that binary installers exist at all and I >> believe that most if not all of the changes which were needed to make that >> possible are now in the latest releases. >> >> The binary installer at the moment includes it's own Python install in >> order to minimize external dependencies and possible conflicts. I haven't >> seen the "Stopped working" error before, it would be interesting to find >> out why. If you have the time and curiosity, could you try running a super >> simple flow graph such as a signal source into a null sink? This will have >> minimal complexity and test if GNU Radio runs on it's own without any >> hardware interactions. The gr_fftw_wisdom warning can be ignored. >> >> Can you test the Python install? Here is a very simple command which >> should execute. I'm on Linux so cannot test it at the moment. >> python.exe -c "from gruel import pmt; print pmt" >> >> >
Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows
Hi Geof, Thanks. If the Win32 label is incorrect and it's a build error I'll take a look into that. Also thank you for pointing out the GNU Radio Command Prompt, that looks very helpful. Regards, Derek On Wed, Jul 13, 2016 at 2:04 PM, Geof Nieboer wrote: > Derek/Dave, > > My development equipment is still in transit so I can't look at anything > until Monday, but... > > The UHD build should be 64-bit, so it is mostly likely a labelling issue. > But I will check to be sure. > > If you want to run -any- GNURadio utilities, I recommend doing so from the > GNURadio Command Prompt (shortcut in start menu or run_gr.bat in the /bin > subdir) ... that will set all the Python/etc environment variables up > correctly. Then you should not need to specify where the UHD images are. > > Geof > > > On Tue, Jul 12, 2016 at 10:11 PM, Derek Kozel > wrote: > >> Hi Dave, >> >> Yes, there is no state held in UHD so you will always need to include the >> --args "fw.." in your UHD commands. I should have also mentioned that >> this means you will need to add that exact "fw= D:\Program >> Files\GNURadio-3.7\share\uhd\images\usrp_b100_fw.ihx,fpga= D:\Program >> Files\GNURadio-3.7\share\uhd\images\usrp_b100_fpga.bin" string in the USRP >> Source or Sink block Device Arguments field for any GNU Radio flowgraph. >> You can try modifying the wbfm example for instance. >> >> The ability to specify specific FPGA and firmware images is usually a >> development feature if you have multiple versions of UHD installed >> alongside each other or are building custom images. In this case we are >> using it to get around a path problem. >> >> If you create the D:\Program Files\UHD\share\uhd\images\... folder with >> images UHD will hopefully pick them up automatically. I have not tried a >> Windows install where D is the system drive so I'm unsure of the exact >> behavior. >> >> Ok, I had the wrong python command there, but python itself did run. >> Here's a line which certainly should work, but there's likely nothing >> additional to be gained by running it. >> python -c "import gnuradio; print gnuradio" >> >> Regards, >> Derek >> >> On Tue, Jul 12, 2016 at 7:02 PM, Dave wrote: >> >>> Derek, >>> >>> >>> >>> I ran rx_samles _*to*_file. Although using the location arrguments you >>> gave me for uhd_find_devices allows for the B100 to be found it does not >>> look like the knowledge of where the images are located is retained. >>> Running the samles_to_file command again results in a condition where >>> firmware could not be found. >>> >>> >>> >>> D:\Program Files\GNURadio-3.7\share\uhd\examples>rx_samples_to_file >>> >>> Win32; Microsoft Visual C++ version 14.0; Boost_106000; >>> UHD_003.009.003-0-unknown >>> >>> >>> >>> >>> >>> Creating the usrp device with: ... >>> >>> >>> >>> UHD Warning: >>> >>> Could not locate B100 firmware. As an Administrator, please run: >>> >>> "C:\Program Files\UHD\lib\uhd\utils\uhd_images_downloader.py" >>> >>> Error: LookupError: KeyError: No devices found for -> >>> >>> Empty Device Address >>> >>> >>> >>> I also ran the python command you gave me with the results to follow: >>> >>> >>> >>> >>> >>> D:\Program Files\GNURadio-3.7>python.exe -c "from gruel import pmt; >>> print pmt" >>> >>> Traceback (most recent call last): >>> >>> File "", line 1, in >>> >>> ImportError: No module named gruel >>> >>> >>> >>> D:\Program Files\GNURadio-3.7> >>> >>> >>> >>> If there is anything else you want me to run, I will do so. >>> >>> >>> >>> Dave >>> >>> >>> >>> *From:* Derek Kozel [mailto:derek.ko...@ettus.com] >>> *Sent:* Tuesday, July 12, 2016 6:29 PM >>> >>> *To:* Dave >>> *Cc:* GNURadio Discussion List >>> *Subject:* Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on >>> Windows >>> >>> >>> >>> Hi Dave, >>> >>> I'm glad that the B100 was able to be detected. If you want to confirm >>> that it is fully operating you could run any of the examples included with >>> UHD, for instance uhd_benchmark_rate or rx_samples_to_file. These are >>> standalone from GNU Radio so should avoid whatever Python issue may exist. >>> >>> I've just noticed, the UHD version installed is Win32. I'm surprised at >>> this as the GNU Radio binary builds are all 64 bit. If the developer of >>> these Windows binary installers sees the thread hopefully he can comment. >>> >>> GNU Radio is certainly easier to use on Linux or OS X, but there is a >>> desire to see Windows support improve over time. This may not happen >>> quickly, but it's a great sign that binary installers exist at all and I >>> believe that most if not all of the changes which were needed to make that >>> possible are now in the latest releases. >>> >>> The binary installer at the moment includes it's own Python install in >>> order to minimize external dependencies and possible conflicts. I haven't >>> seen the "Stopped working" error before, it would be interesting to find >>> out why. If you have the time and curiosity, could you try running a super >
[Discuss-gnuradio] Today's building-gnuradio pleasure
This is on an F20 machine. An Intel Core i5 lappy. /home/mleech/gnuradio/gr-blocks/lib/divide_cc_impl.cc: In member function ‘virtual int gr::blocks::divide_cc_impl::work(int, gr_vector_const_void_star&, gr_vector_void_star&)’: /home/mleech/gnuradio/gr-blocks/lib/divide_cc_impl.cc:58:105: error: ‘volk_32fc_x2_divide_32fc’ was not declared in this scope volk_32fc_x2_divide_32fc(optr, numerator, (gr_complex*) input_items[inp], noutput_items * d_vlen); ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Today's building-gnuradio pleasure
Stupid question (why is it always that things break as soon as I touch them?): you did "git submodule update", right? Volk builds without failure, too? Cheers, Marcus On 07/14/2016 12:15 AM, Marcus D. Leech wrote: > > > This is on an F20 machine. An Intel Core i5 lappy. > > /home/mleech/gnuradio/gr-blocks/lib/divide_cc_impl.cc: In member > function ‘virtual int gr::blocks::divide_cc_impl::work(int, > gr_vector_const_void_star&, gr_vector_void_star&)’: > /home/mleech/gnuradio/gr-blocks/lib/divide_cc_impl.cc:58:105: error: > ‘volk_32fc_x2_divide_32fc’ was not declared in this scope > volk_32fc_x2_divide_32fc(optr, numerator, (gr_complex*) > input_items[inp], noutput_items * d_vlen); > > > ___ > 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] Today's building-gnuradio pleasure
On 07/13/2016 06:27 PM, Marcus Müller wrote: Stupid question (why is it always that things break as soon as I touch them?): you did "git submodule update", right? Volk builds without failure, too? Cheers, I realized that about two minutes ago. Rebuilding now. I was going to post a self-deriding diatribe about what a micro-cephalic idiot I am. Marcus On 07/14/2016 12:15 AM, Marcus D. Leech wrote: This is on an F20 machine. An Intel Core i5 lappy. /home/mleech/gnuradio/gr-blocks/lib/divide_cc_impl.cc: In member function ‘virtual int gr::blocks::divide_cc_impl::work(int, gr_vector_const_void_star&, gr_vector_void_star&)’: /home/mleech/gnuradio/gr-blocks/lib/divide_cc_impl.cc:58:105: error: ‘volk_32fc_x2_divide_32fc’ was not declared in this scope volk_32fc_x2_divide_32fc(optr, numerator, (gr_complex*) input_items[inp], noutput_items * d_vlen); ___ 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] Today's building-gnuradio pleasure
Don't forget I still have caused a broken gr-prefs on still-supported old Ubuntu, which I've yet to fix – don't deride yourself without need :) Cheers, Marcus On 14.07.2016 00:44, Marcus D. Leech wrote: > On 07/13/2016 06:27 PM, Marcus Müller wrote: >> Stupid question (why is it always that things break as soon as I touch >> them?): >> you did "git submodule update", right? Volk builds without failure, too? >> >> Cheers, > I realized that about two minutes ago. Rebuilding now. > > I was going to post a self-deriding diatribe about what a > micro-cephalic idiot I am. > > >> Marcus >> >> On 07/14/2016 12:15 AM, Marcus D. Leech wrote: >>> >>> This is on an F20 machine. An Intel Core i5 lappy. >>> >>> /home/mleech/gnuradio/gr-blocks/lib/divide_cc_impl.cc: In member >>> function ‘virtual int gr::blocks::divide_cc_impl::work(int, >>> gr_vector_const_void_star&, gr_vector_void_star&)’: >>> /home/mleech/gnuradio/gr-blocks/lib/divide_cc_impl.cc:58:105: error: >>> ‘volk_32fc_x2_divide_32fc’ was not declared in this scope >>> volk_32fc_x2_divide_32fc(optr, numerator, (gr_complex*) >>> input_items[inp], noutput_items * d_vlen); >>> >>> >>> ___ >>> 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
