Re: [Discuss-gnuradio] GRAS build error on armv7
There is no equivalent instruction of pause in ARM that hints the following
loop is a spin-lock loop; However I just mapped pause into NOP and its not
throwing an error (yet) :D
Here's the diff:
diff --git a/Include/Theron/Detail/Threading/Utils.h
b/Include/Theron/Detail/Threading/Utils.h
index 8c6baf2..76947c7 100644
--- a/Include/Theron/Detail/Threading/Utils.h
+++ b/Include/Theron/Detail/Threading/Utils.h
@@ -168,8 +168,12 @@ THERON_FORCEINLINE void Utils::YieldToHyperthread()
YieldProcessor();
#elif THERON_GCC
+ #ifdef __arm__
+ __asm__ __volatile__ ("NOP");
+ #else
+ __asm__ __volatile__("pause");
+ #endif
-__asm__ __volatile__ ("pause");
#endif
Can anybody comment on performance degradation?
On Sun, Jul 28, 2013 at 8:37 PM, Ashton Mason wrote:
> Thanks Manoj!
>
>
>
> On 27 July 2013 05:16, Manoj Gudi wrote:
>
>> Yes I'll work on it and send you a patch with conditional preprocessors.
>>
>>
>> On Sat, Jul 27, 2013 at 3:06 AM, Ashton Mason wrote:
>>
>>> Hi guys
>>>
>>> Yes that line is no doubt the culprit; The 'pause' is intended to help
>>> prevent a spinning thread from burning a core that could be used instead by
>>> another thread (or hyperthread). I'm not sure what the equivalent is on ARM
>>> processors (if any).
>>>
>>> Certainly commenting it out is one easy way around it; the #ifdef
>>> __X86_64__ seems reasonable; there might even be an ARM equivalent we could
>>> conditionally use instead.
>>>
>>> Ash
>>>
>>>
>>>
>>> On 26 July 2013 20:29, Josh Blum wrote:
>>>
On 07/26/2013 07:57 AM, Manoj Gudi wrote:
> We've been successful in building dependencies for gnuradio on armv7
> platform, however while building GRAS, we got this error:
>
This line is probably the culprit.
https://github.com/captaintrash/theron/blob/master/Include/Theron/Detail/Threading/Utils.h#L163
The thread pools can operate on condition variables or spin locks. For
the spin lock implementation, there is a "pause" instruction --
obviously not applicable on arm. I think you can simply comment this out
to get things rolling.
Supposing this is the issue. What is the recommended fix... just a
simple #ifdef __X86_64__ around this line?
-josh
> *Scanning dependencies of target gras
> [ 13%] Building CXX object
> lib/CMakeFiles/gras.dir/__/Theron/Theron/Receiver.cpp.o
> [ 13%] Generating GrExtras_Ops.pyc
> [ 13%] Generating GrExtras_Ops.pyo
> make[2]: warning: Clock skew detected. Your build may be incomplete.
> [ 13%] Built target pygen_python_grextras_da046
> [ 13%] Swig source
> /tmp/ccONtg2w.s: Assembler messages:
> /tmp/ccONtg2w.s:3234: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:3243: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:3266: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:3275: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:3406: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:3415: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4479: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4488: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4511: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4520: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4540: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4549: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4677: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4686: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4735: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4744: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4816: Error: bad instruction `pause'
> /tmp/ccONtg2w.s:4825: Error: bad instruction `pause'
> make[2]: Warning: File `/usr/include/python2.7/Python.h' has
modification
> time 4.1e+08 s in the future
> [ 13%] Building CXX object
> PMC/python/PMC/CMakeFiles/_PMCBool.dir/PMCBoolPYTHON_wrap.cxx.o
> /home/aakash/gras/build/PMC/python/PMC/PMCBoolPYTHON_wrap.cxx: In
function
> 'void SWIG_InitializeModule(void*)':
> /home/aakash/gras/build/PMC/python/PMC/PMCBoolPYTHON_wrap.cxx:3433:21:
> warning: statement has no effect [-Wunused-value]
> *
>
> In my opinion this is an assembler issue for armV7, but I've got no
leads
> on how to solve this. Will mapping this instruction with an equivalent
> assembly instruction for armV7 work?
>
> Here's /proc/cpuinfo
> *$ cat /proc/cpuinfo
> Processor : ARMv7 Processor rev 2 (v7l)
> BogoMIPS: 1001.88
> Features: swp half thumb fastmult vfp edsp neon vfpv3
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x3
> CPU part: 0xc08
> CPU revision: 2
>
> Hardware: sun5i
> Revision:
> Serial : 000
[Discuss-gnuradio] Using Popen to start a pipe and pass the input
Hello All,
I am trying to use popen to open an application under a block.
This looks something like that:
fp = popen(command, "w"); //doing it in write mode
if(!fp){
#Handle the error
}
..
pclose(fp);
Now the thing is even if I am trying to track using (fp != NULL) it
still keep executing the command over and over. Any ideas on that? May
somebody can guide me through right way to use popen?
Also to pass the c++ output stream, std::cout will work, right?
Thanks
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new to GNUradio: AFSK and codec2 gmsk modem
Hallo Marcus, On 29-07-13 01:44, Marcus D. Leech wrote: - My first step with GNUradio was to learn a bit more about using it; so .. do some test. I wanted to use GNUradio to determine the width of an AFSK signal; so I started looking for a AFSK modulator / demodulator; to come to the conclussion I didn't find one. I looked in the GR source, on CGRAN, using several generic search engines without look. Am I missing something here? I would be surprised there is no AFSK modulator / demodulator in GR as it would mean one cannot do packetradio or APRS with gnuradio. (...) Just found this, it might help: https://github.com/dl1ksv/gr-afsk Hmmm. Looks interesting. A good start. :-) However, it seams I have another problem: it does not build on my system (ubuntu 12.04 LTS). It needs gnuradio-runtime and as I currently run gnuradio 3.6.4.1 + Boost 1.49 build from source, it doesn't have that. I tried to build 3.7.1 -which seams to include gnuradio-runtime in its source- but that fails on a number of tests (qa_fir_filter, qa_freq_xlating_fir_filter, qa_constellation_receiver and qa_codec2_vocoder). Grrr! :-( Also, keep in mind that AFSK is a kind of "double modulation scheme". To demodulate it, first demodulate the FM-voice using a narrowband FM demodulator, then run that into a suitaby-configured FSK demod. AFSK was always a "hack" to allow you to send data over narrowband FM-voice radios without having to do anything to the radio. So, they chose Bell-202 synchronous modem tones, because they'd "fit" in most narrowband FM-voice radios. Well, that is exactly the reason I would like to test it out. :-) We currently do packet/ax.25/aprs at 1200 baud AFSK, which is not that much less then the 1400 bps needed for codec2. Add a little bit frame sync-patterns and -perhaps- some FEC, we might end up with 1600. It would be kind-of-nice to be able to try out DV with standard FM handhelds without any need to have a radio that does 9k6. But, this is for me just as much a practicle test and just a way to getting to know GNUradio. :-) Cheerio! Kr. Bonne - ON1ARF ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRAS build error on armv7
On 07/29/2013 09:08 AM, Manoj Gudi wrote:
> There is no equivalent instruction of pause in ARM that hints the following
> loop is a spin-lock loop; However I just mapped pause into NOP and its not
> throwing an error (yet) :D
Wny not only insert the asm for x86 and no code for all other archs.
This patch will break on PPC and other non x86 archs.
Philip
>
> Here's the diff:
>
> diff --git a/Include/Theron/Detail/Threading/Utils.h
> b/Include/Theron/Detail/Threading/Utils.h
> index 8c6baf2..76947c7 100644
> --- a/Include/Theron/Detail/Threading/Utils.h
> +++ b/Include/Theron/Detail/Threading/Utils.h
> @@ -168,8 +168,12 @@ THERON_FORCEINLINE void Utils::YieldToHyperthread()
> YieldProcessor();
>
> #elif THERON_GCC
> + #ifdef __arm__
> + __asm__ __volatile__ ("NOP");
> + #else
> + __asm__ __volatile__("pause");
> + #endif
>
> -__asm__ __volatile__ ("pause");
>
> #endif
>
>
>
> Can anybody comment on performance degradation?
>
>
> On Sun, Jul 28, 2013 at 8:37 PM, Ashton Mason wrote:
>
>> Thanks Manoj!
>>
>>
>>
>> On 27 July 2013 05:16, Manoj Gudi wrote:
>>
>>> Yes I'll work on it and send you a patch with conditional preprocessors.
>>>
>>>
>>> On Sat, Jul 27, 2013 at 3:06 AM, Ashton Mason wrote:
>>>
Hi guys
Yes that line is no doubt the culprit; The 'pause' is intended to help
prevent a spinning thread from burning a core that could be used instead by
another thread (or hyperthread). I'm not sure what the equivalent is on ARM
processors (if any).
Certainly commenting it out is one easy way around it; the #ifdef
__X86_64__ seems reasonable; there might even be an ARM equivalent we could
conditionally use instead.
Ash
On 26 July 2013 20:29, Josh Blum wrote:
>
>
> On 07/26/2013 07:57 AM, Manoj Gudi wrote:
>> We've been successful in building dependencies for gnuradio on armv7
>> platform, however while building GRAS, we got this error:
>>
>
> This line is probably the culprit.
>
> https://github.com/captaintrash/theron/blob/master/Include/Theron/Detail/Threading/Utils.h#L163
>
> The thread pools can operate on condition variables or spin locks. For
> the spin lock implementation, there is a "pause" instruction --
> obviously not applicable on arm. I think you can simply comment this out
> to get things rolling.
>
> Supposing this is the issue. What is the recommended fix... just a
> simple #ifdef __X86_64__ around this line?
>
> -josh
>
>> *Scanning dependencies of target gras
>> [ 13%] Building CXX object
>> lib/CMakeFiles/gras.dir/__/Theron/Theron/Receiver.cpp.o
>> [ 13%] Generating GrExtras_Ops.pyc
>> [ 13%] Generating GrExtras_Ops.pyo
>> make[2]: warning: Clock skew detected. Your build may be incomplete.
>> [ 13%] Built target pygen_python_grextras_da046
>> [ 13%] Swig source
>> /tmp/ccONtg2w.s: Assembler messages:
>> /tmp/ccONtg2w.s:3234: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:3243: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:3266: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:3275: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:3406: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:3415: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4479: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4488: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4511: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4520: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4540: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4549: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4677: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4686: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4735: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4744: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4816: Error: bad instruction `pause'
>> /tmp/ccONtg2w.s:4825: Error: bad instruction `pause'
>> make[2]: Warning: File `/usr/include/python2.7/Python.h' has
> modification
>> time 4.1e+08 s in the future
>> [ 13%] Building CXX object
>> PMC/python/PMC/CMakeFiles/_PMCBool.dir/PMCBoolPYTHON_wrap.cxx.o
>> /home/aakash/gras/build/PMC/python/PMC/PMCBoolPYTHON_wrap.cxx: In
> function
>> 'void SWIG_InitializeModule(void*)':
>> /home/aakash/gras/build/PMC/python/PMC/PMCBoolPYTHON_wrap.cxx:3433:21:
>> warning: statement has no effect [-Wunused-value]
>> *
>>
>> In my opinion this is an assembler issue for armV7, but I've got no
> leads
>> on how to solve this. Will mapping this instruction with an equivalent
>> assembly instruction for armV7 work?
>>
>> Here's /proc/cpuinfo
>> *$ cat /proc/cpuinfo
>> Processor : ARMv7 Processor rev 2 (v7l)
>> BogoMIPS: 1001.88
>> Features
Re: [Discuss-gnuradio] GRAS build error on armv7
That sounds good.
From: manojgudi
Date: Mon, 29 Jul 2013 17:00:35 +0530
Subject: [PATCH] fixed ASM
---
Include/Theron/Detail/Threading/Utils.h |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Include/Theron/Detail/Threading/Utils.h
b/Include/Theron/Detail/Threading/Utils.h
index 8c6baf2..e2811f1 100644
--- a/Include/Theron/Detail/Threading/Utils.h
+++ b/Include/Theron/Detail/Threading/Utils.h
@@ -168,8 +168,11 @@ THERON_FORCEINLINE void Utils::YieldToHyperthread()
YieldProcessor();
#elif THERON_GCC
-
-__asm__ __volatile__ ("pause");
+#ifdef __arm__
+__asm__ __volatile__ ("NOP");
+#elif __X86_64__
+ __asm__ __volatile__("pause");
+#endif
#endif
--
1.7.9.5
On Mon, Jul 29, 2013 at 4:31 PM, Ashton Mason wrote:
> Or call out code for specific architectures, including ARM and x86, but
> default to nothing.
>
>
>
> On 29 July 2013 11:56, Philip Balister wrote:
>
>> On 07/29/2013 09:08 AM, Manoj Gudi wrote:
>> > There is no equivalent instruction of pause in ARM that hints the
>> following
>> > loop is a spin-lock loop; However I just mapped pause into NOP and its
>> not
>> > throwing an error (yet) :D
>>
>> Wny not only insert the asm for x86 and no code for all other archs.
>> This patch will break on PPC and other non x86 archs.
>>
>> Philip
>>
>> >
>> > Here's the diff:
>> >
>> > diff --git a/Include/Theron/Detail/Threading/Utils.h
>> > b/Include/Theron/Detail/Threading/Utils.h
>> > index 8c6baf2..76947c7 100644
>> > --- a/Include/Theron/Detail/Threading/Utils.h
>> > +++ b/Include/Theron/Detail/Threading/Utils.h
>> > @@ -168,8 +168,12 @@ THERON_FORCEINLINE void Utils::YieldToHyperthread()
>> > YieldProcessor();
>> >
>> > #elif THERON_GCC
>> > + #ifdef __arm__
>> > + __asm__ __volatile__ ("NOP");
>> > + #else
>> > + __asm__ __volatile__("pause");
>> > + #endif
>> >
>> > -__asm__ __volatile__ ("pause");
>> >
>> > #endif
>> >
>> >
>> >
>> > Can anybody comment on performance degradation?
>> >
>> >
>> > On Sun, Jul 28, 2013 at 8:37 PM, Ashton Mason
>> wrote:
>> >
>> >> Thanks Manoj!
>> >>
>> >>
>> >>
>> >> On 27 July 2013 05:16, Manoj Gudi wrote:
>> >>
>> >>> Yes I'll work on it and send you a patch with conditional
>> preprocessors.
>> >>>
>> >>>
>> >>> On Sat, Jul 27, 2013 at 3:06 AM, Ashton Mason > >wrote:
>> >>>
>> Hi guys
>>
>> Yes that line is no doubt the culprit; The 'pause' is intended to
>> help
>> prevent a spinning thread from burning a core that could be used
>> instead by
>> another thread (or hyperthread). I'm not sure what the equivalent is
>> on ARM
>> processors (if any).
>>
>> Certainly commenting it out is one easy way around it; the #ifdef
>> __X86_64__ seems reasonable; there might even be an ARM equivalent
>> we could
>> conditionally use instead.
>>
>> Ash
>>
>>
>>
>> On 26 July 2013 20:29, Josh Blum wrote:
>>
>> >
>> >
>> > On 07/26/2013 07:57 AM, Manoj Gudi wrote:
>> >> We've been successful in building dependencies for gnuradio on
>> armv7
>> >> platform, however while building GRAS, we got this error:
>> >>
>> >
>> > This line is probably the culprit.
>> >
>> >
>> https://github.com/captaintrash/theron/blob/master/Include/Theron/Detail/Threading/Utils.h#L163
>> >
>> > The thread pools can operate on condition variables or spin locks.
>> For
>> > the spin lock implementation, there is a "pause" instruction --
>> > obviously not applicable on arm. I think you can simply comment
>> this out
>> > to get things rolling.
>> >
>> > Supposing this is the issue. What is the recommended fix... just a
>> > simple #ifdef __X86_64__ around this line?
>> >
>> > -josh
>> >
>> >> *Scanning dependencies of target gras
>> >> [ 13%] Building CXX object
>> >> lib/CMakeFiles/gras.dir/__/Theron/Theron/Receiver.cpp.o
>> >> [ 13%] Generating GrExtras_Ops.pyc
>> >> [ 13%] Generating GrExtras_Ops.pyo
>> >> make[2]: warning: Clock skew detected. Your build may be
>> incomplete.
>> >> [ 13%] Built target pygen_python_grextras_da046
>> >> [ 13%] Swig source
>> >> /tmp/ccONtg2w.s: Assembler messages:
>> >> /tmp/ccONtg2w.s:3234: Error: bad instruction `pause'
>> >> /tmp/ccONtg2w.s:3243: Error: bad instruction `pause'
>> >> /tmp/ccONtg2w.s:3266: Error: bad instruction `pause'
>> >> /tmp/ccONtg2w.s:3275: Error: bad instruction `pause'
>> >> /tmp/ccONtg2w.s:3406: Error: bad instruction `pause'
>> >> /tmp/ccONtg2w.s:3415: Error: bad instruction `pause'
>> >> /tmp/ccONtg2w.s:4479: Error: bad instruction `pause'
>> >> /tmp/ccONtg2w.s:4488: Error: bad instruction `pause'
>> >> /tmp/ccONtg2w.s:4511: Error: bad instruction `pause'
>> >> /tmp/ccONtg2w.s:4520: Error: bad instruction `pause'
>> >> /tmp/ccONtg2w.s:4540: Error: bad instruction `pause'
>> >>>
[Discuss-gnuradio] Fwd: Can open BTS run on RasPi?
Hi, I just watched a video on this link: http://www.youtube.com/watch?v=GCcKgrzbix4#at=42 They say they have ported OpenBTS and GR to RasPi and they could make phone calls between 2 mobile phones. Is that even possible? Is RasPi strong enough for handling that kind of data? I am very curious to hear your comments on this, BR, Farhad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Can open BTS run on RasPi?
HI Andrew, Thanks, I will ask the question on OpenBTS, I thought that OpenBTS was a layer on top of the GR, thanks for correcting me. BR, Farhad On Mon, Jul 29, 2013 at 2:24 PM, Andrew Back wrote: > Hi Farhad, > > On 29 July 2013 13:04, Farhad Abdolian > wrote: > > Hi, > > I just watched a video on this link: > > http://www.youtube.com/watch?v=GCcKgrzbix4#at=42 > > > > They say they have ported OpenBTS and GR to RasPi and they could make > phone > > calls between 2 mobile phones. > > > > Is that even possible? > > I don't see why they would lie. > > > Is RasPi strong enough for handling that kind of data? > > It would seem that it is possible to make something work, but as far > as I'm aware it's not practical/useful, unless perhaps there were > OpenCL support for RasPi and you could rewrite parts of OpenBTS to > make use of the GPU. > > In any case, the host is just a small part of the hardware costs and > it would be better to run OpenBTS on something more capable. > > > I am very curious to hear your comments on this, > > You are aware that OpenBTS and GNU Radio are different codebases? I'd > suggest posting questions such as this to the OpenBTS discuss list: > > http://sourceforge.net/p/openbts/mailman/ > > Cheers, > > Andrew > > -- > Andrew Back > http://carrierdetect.com > -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Can open BTS run on RasPi?
Hi Farhad, On 29 July 2013 13:04, Farhad Abdolian wrote: > Hi, > I just watched a video on this link: > http://www.youtube.com/watch?v=GCcKgrzbix4#at=42 > > They say they have ported OpenBTS and GR to RasPi and they could make phone > calls between 2 mobile phones. > > Is that even possible? I don't see why they would lie. > Is RasPi strong enough for handling that kind of data? It would seem that it is possible to make something work, but as far as I'm aware it's not practical/useful, unless perhaps there were OpenCL support for RasPi and you could rewrite parts of OpenBTS to make use of the GPU. In any case, the host is just a small part of the hardware costs and it would be better to run OpenBTS on something more capable. > I am very curious to hear your comments on this, You are aware that OpenBTS and GNU Radio are different codebases? I'd suggest posting questions such as this to the OpenBTS discuss list: http://sourceforge.net/p/openbts/mailman/ Cheers, Andrew -- Andrew Back http://carrierdetect.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] where does gnuradio-companion stores the last opened flowchart ?
I notice that gnuradio-companion always opens the last used flowchart. Can anyone tell me where this information is stored? I am using several (3.6 and 3.7) GR builds in parallel and they all try to open the same flowchart when starting gnuradio-companion. I already looked (and deleted for a test) in ~/.gnuradio ~/.config/GNU Radio and ~/.grc_gnuradio but I could not find any gnuradio-companion "history" stored there. Thanks to anyone who sheds some light on this. Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Dynamic number of "message" ports using nports
I'm using GnuRadio 3.6.5.1 and I wanted to create a block similar to stream-to-streams for messages. In the XML I used a variable and nports so I could specify the number of ports in the flowgraph. However, I've found that this does not work. Whenever I change the variable value to something greater than 1, the variable ID turns red and the number of ports displayed does not change. Simply changing the port type to something other than "message" works correctly. Does anyone have an idea how to fix this? -- View this message in context: http://gnuradio.4.n7.nabble.com/Dynamic-number-of-message-ports-using-nports-tp42766.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] Reading complex numbers from file dump.
Hi, I have created a file dump with samples from USRP output. Samples are in gr_complex format. Now I want to read data from the file to compute FFT. How can I read complex numbers in python from this binary file? -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reading complex numbers from file dump.
On Mon, Jul 29, 2013 at 9:38 AM, Manu T S wrote: > Hi, > > I have created a file dump with samples from USRP output. Samples are in > gr_complex format. Now I want to read data from the file to compute FFT. How > can I read complex numbers in python from this binary file? > > -- > Manu T S See here: http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-gr_file_sink There are also a handful of plotting tools in gr-qtgui/apps that read from files using the scipy.fromfile function mentioned in the above FAQ. You can use these for references. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] where does gnuradio-companion stores the last opened flowchart ?
On Mon, Jul 29, 2013 at 8:34 AM, M Dammer wrote: > I notice that gnuradio-companion always opens the last used flowchart. > Can anyone tell me where this information is stored? I am using several > (3.6 and 3.7) GR builds in parallel and they all try to open the same > flowchart when starting gnuradio-companion. > I already looked (and deleted for a test) in ~/.gnuradio ~/.config/GNU > Radio and ~/.grc_gnuradio but I could not find any gnuradio-companion > "history" stored there. > Thanks to anyone who sheds some light on this. Mark Look at the ~/.grc file. It's just a file, not a directory. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new to GNUradio: AFSK and codec2 gmsk modem
On Mon, Jul 29, 2013 at 5:48 AM, Kristoff Bonne wrote: > Hallo Marcus, > > > > > On 29-07-13 01:44, Marcus D. Leech wrote: >> >> >>> - My first step with GNUradio was to learn a bit more about using it; >>> so .. do some test. >>> I wanted to use GNUradio to determine the width of an AFSK signal; so >>> I started looking for a AFSK modulator / demodulator; to come to the >>> conclussion I didn't find one. >>> I looked in the GR source, on CGRAN, using several generic search >>> engines without look. >>> Am I missing something here? I would be surprised there is no AFSK >>> modulator / demodulator in GR as it would mean one cannot do >>> packetradio or APRS with gnuradio. > > (...) > > > >> Just found this, it might help: >> https://github.com/dl1ksv/gr-afsk > > Hmmm. Looks interesting. A good start. :-) > > > However, it seams I have another problem: it does not build on my system > (ubuntu 12.04 LTS). > It needs gnuradio-runtime and as I currently run gnuradio 3.6.4.1 + Boost > 1.49 build from source, it doesn't have that. > > I tried to build 3.7.1 -which seams to include gnuradio-runtime in its > source- but that fails on a number of tests (qa_fir_filter, > qa_freq_xlating_fir_filter, qa_constellation_receiver and > qa_codec2_vocoder). > > Grrr! :-( Those QA failures are probable a Volk issue. Try running volk_profile after you run 'make install'. If a given kernel fails for an architecture, it will be disabled. Once volk_profile completes (it can take a while), try rerunning 'make test'. If it still fails, run 'ctest -V -R volk' and send us the output. What's your processor? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reading complex numbers from file dump.
On Mon, Jul 29, 2013 at 9:38 AM, Manu T S wrote: > Hi, > > I have created a file dump with samples from USRP output. Samples are in > gr_complex format. Now I want to read data from the file to compute FFT. How > can I read complex numbers in python from this binary file? > > -- > Manu T S > There are examples of this in gr-utils/python/utils . One of the scripts even plots the fft for you. -Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using Popen to start a pipe and pass the input
On Mon, Jul 29, 2013 at 4:02 AM, Shashank Gaur wrote:
> Hello All,
>
> I am trying to use popen to open an application under a block.
>
> This looks something like that:
>
> fp = popen(command, "w"); //doing it in write mode
>
> if(!fp){
> #Handle the error
> }
>
> ..
>
> pclose(fp);
>
> Now the thing is even if I am trying to track using (fp != NULL) it
> still keep executing the command over and over. Any ideas on that? May
> somebody can guide me through right way to use popen?
>
> Also to pass the c++ output stream, std::cout will work, right?
>
> Thanks
Hi Shashank,
I know you are working on GNU Radio for the GSoC, but this question
isn't related to GNU Radio. You'll be better off asking another forum
like Stack Overflow.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS: First impressions and optional dependencies
On Sun, Jul 28, 2013 at 6:40 PM, Alexandru Csete wrote: > On Fri, Jul 26, 2013 at 4:27 PM, Tom Rondeau wrote: >> On Thu, Jul 25, 2013 at 7:28 AM, Alexandru Csete wrote: >>> Greetings, >>> >>> Yesterday, I started playing with pybombs and fixed a few recipes >>> related to gr-osmosdr. During this process I made gr-osmosdr depend on >>> uhd, rtl-sdr, osmo-sdr, hackrf and gr-iqbal. I did this to ensure that >>> all supported input devices are made available to users. It should be >>> noted that all these packages are optional and gr-osmosdr would work >>> just fine with gnuradio as the only dependency still supporting >>> funcube dongles and I/Q file sources. >> >> Alex, >> >> Thanks for the report and all of the patches you submitted to PyBOMBS. >> It's a new project and will definitely need wide-spread testing and >> help to get working well on various systems and for various needs. >> >>> Later I will be adding a recipe for the gr-fcdproplus OOT source block >>> and add that as a gr-osmosdr dependency as well. This works well for >>> now since all these driver libraries are recent and well maintained. >>> However, as time goes this driver list will grow and the risk of >>> something breaking will increase. This made me think whether there may >>> be a need for a weaker dependency specification, something like the >>> "recommends" section in deb packages or the "variant" in macports? >> >> The 'recommends' is a very interesting idea. I'm not sure I like >> forcing the installation of all of the base drivers for gr-osmosdr, >> but if we have a menu-driven section if the dependencies are >> recommended and allow the user to select which, if any, to also >> install, that'd be great. >> >> Would you open a feature issue on the PyBOMBS Redmine page suggesting this? > > Done. Thanks! >>> As an alternate solution here & now, we could just remove all optional >>> dependencies from the gr-osmosdr recipe and instruct users to install >>> their preferred driver libraries prior to installing gr-osmosdr. Or >>> create meta-recipes that would provide the most common combinations. I >>> don't know what would be the best solution. >> >> I'm not sure, either. Until we figure out a concept like the >> recommendations, my preference is to not include them as dependencies, >> but I could be persuaded out of that thought. I'm guessing Philip >> would argue for a meta-layer :) > > Maybe as compromise we can remove all optional dependencies except > rtl-sdr and uhd. That would provide a good default for 95% of the > users today and only require rtl-sdr as extra package since the > gnuradio recipe already depends on uhd. > > Alex I can see that, especially since we have uhd as a dep for gnuradio, too. Also, rtl-sdr is lightweight and only depends on libusb, so it's a pretty safe one to install. And yeah, I agree, that takes care of most people's needs right now. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS: First impressions and optional dependencies
On 07/29/2013 11:10 AM, Tom Rondeau wrote: On Sun, Jul 28, 2013 at 6:40 PM, Alexandru Csete wrote: On Fri, Jul 26, 2013 at 4:27 PM, Tom Rondeau wrote: On Thu, Jul 25, 2013 at 7:28 AM, Alexandru Csete wrote: Greetings, Yesterday, I started playing with pybombs and fixed a few recipes related to gr-osmosdr. During this process I made gr-osmosdr depend on uhd, rtl-sdr, osmo-sdr, hackrf and gr-iqbal. I did this to ensure that all supported input devices are made available to users. It should be noted that all these packages are optional and gr-osmosdr would work just fine with gnuradio as the only dependency still supporting funcube dongles and I/Q file sources. Alex, Thanks for the report and all of the patches you submitted to PyBOMBS. It's a new project and will definitely need wide-spread testing and help to get working well on various systems and for various needs. Later I will be adding a recipe for the gr-fcdproplus OOT source block and add that as a gr-osmosdr dependency as well. This works well for now since all these driver libraries are recent and well maintained. However, as time goes this driver list will grow and the risk of something breaking will increase. This made me think whether there may be a need for a weaker dependency specification, something like the "recommends" section in deb packages or the "variant" in macports? The 'recommends' is a very interesting idea. I'm not sure I like forcing the installation of all of the base drivers for gr-osmosdr, but if we have a menu-driven section if the dependencies are recommended and allow the user to select which, if any, to also install, that'd be great. Would you open a feature issue on the PyBOMBS Redmine page suggesting this? Done. Thanks! As an alternate solution here& now, we could just remove all optional dependencies from the gr-osmosdr recipe and instruct users to install their preferred driver libraries prior to installing gr-osmosdr. Or create meta-recipes that would provide the most common combinations. I don't know what would be the best solution. I'm not sure, either. Until we figure out a concept like the recommendations, my preference is to not include them as dependencies, but I could be persuaded out of that thought. I'm guessing Philip would argue for a meta-layer :) Maybe as compromise we can remove all optional dependencies except rtl-sdr and uhd. That would provide a good default for 95% of the users today and only require rtl-sdr as extra package since the gnuradio recipe already depends on uhd. Alex I can see that, especially since we have uhd as a dep for gnuradio, too. Also, rtl-sdr is lightweight and only depends on libusb, so it's a pretty safe one to install. And yeah, I agree, that takes care of most people's needs right now. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio rtl-sdr is just the device-driver library for RTL dongles. You need gr-osmosdr as well. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS: First impressions and optional dependencies
On Mon, Jul 29, 2013 at 11:16 AM, Marcus D. Leech wrote: > On 07/29/2013 11:10 AM, Tom Rondeau wrote: >> >> On Sun, Jul 28, 2013 at 6:40 PM, Alexandru Csete wrote: >>> >>> On Fri, Jul 26, 2013 at 4:27 PM, Tom Rondeau wrote: On Thu, Jul 25, 2013 at 7:28 AM, Alexandru Csete wrote: > > Greetings, > > Yesterday, I started playing with pybombs and fixed a few recipes > related to gr-osmosdr. During this process I made gr-osmosdr depend on > uhd, rtl-sdr, osmo-sdr, hackrf and gr-iqbal. I did this to ensure that > all supported input devices are made available to users. It should be > noted that all these packages are optional and gr-osmosdr would work > just fine with gnuradio as the only dependency still supporting > funcube dongles and I/Q file sources. Alex, Thanks for the report and all of the patches you submitted to PyBOMBS. It's a new project and will definitely need wide-spread testing and help to get working well on various systems and for various needs. > Later I will be adding a recipe for the gr-fcdproplus OOT source block > and add that as a gr-osmosdr dependency as well. This works well for > now since all these driver libraries are recent and well maintained. > However, as time goes this driver list will grow and the risk of > something breaking will increase. This made me think whether there may > be a need for a weaker dependency specification, something like the > "recommends" section in deb packages or the "variant" in macports? The 'recommends' is a very interesting idea. I'm not sure I like forcing the installation of all of the base drivers for gr-osmosdr, but if we have a menu-driven section if the dependencies are recommended and allow the user to select which, if any, to also install, that'd be great. Would you open a feature issue on the PyBOMBS Redmine page suggesting this? >>> >>> Done. >> >> Thanks! >> > As an alternate solution here& now, we could just remove all optional > > dependencies from the gr-osmosdr recipe and instruct users to install > their preferred driver libraries prior to installing gr-osmosdr. Or > create meta-recipes that would provide the most common combinations. I > don't know what would be the best solution. I'm not sure, either. Until we figure out a concept like the recommendations, my preference is to not include them as dependencies, but I could be persuaded out of that thought. I'm guessing Philip would argue for a meta-layer :) >>> >>> Maybe as compromise we can remove all optional dependencies except >>> rtl-sdr and uhd. That would provide a good default for 95% of the >>> users today and only require rtl-sdr as extra package since the >>> gnuradio recipe already depends on uhd. >>> >>> Alex >> >> I can see that, especially since we have uhd as a dep for gnuradio, >> too. Also, rtl-sdr is lightweight and only depends on libusb, so it's >> a pretty safe one to install. And yeah, I agree, that takes care of >> most people's needs right now. >> >> Tom >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > rtl-sdr is just the device-driver library for RTL dongles. You need > gr-osmosdr as well. The debate is whether or not to include rtl-sdr and uhd as dependencies to gr-osmosdr. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS: First impressions and optional dependencies
On 07/29/2013 11:26 AM, Tom Rondeau wrote: The debate is whether or not to include rtl-sdr and uhd as dependencies to gr-osmosdr. Tom I'll just, um, just go crawl back into my cave, and perhaps increase the caffeine dose -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] question about symbol synchronization for BPSK demodulation
On Sat, Jul 27, 2013 at 10:06 AM, adream wrote: > Hi guys, > I'm learning BPSK demodulation recently. > I have learned how to do the carrier synchronization in the file of > digital_costas_loop_cc.c. > so my question is which classes do the symbol synchronization in the gnu > radio. > thank you very much. There is the polyphase clock sync block (pfb_clock_sync_ccf). Look at generic_mod_demod in gr-digital/python/digital for how to use it. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX GUI Scope frozen and error-msg gr_vmcircbuf_default_factory: Invalid argument
On Sat, Jul 27, 2013 at 9:35 AM, Kees de Groot wrote: > Tom, > > that was a good first shot: > > I created ~/.gnuradio/config.conf with the lines: > > [wxgui] > style = nongl > > > I even tried > > [wxgui] > style = nogl > > not any difference > > Then I renamed C:\Python27\Lib\site-packages\PyOpenGL-3.1.0a1-py2.7.egg-info > to > C:\Python27\Lib\site-packages\PyOpenGL-3.1.0a1-py2.7.egg-info_nope > > and renamed C:\Python27\Lib\site-packages\OpenGL > to > C:\Python27\Lib\site-packages\OpenGL_nope > > and that helped a lot. > I got a moving display on the scope finally. > > In my command window now I get the following message: > > <<< Welcome to GNU Radio Companion 3.6.4.1 >>> > > Loading: "C:\Users\lonneke\gnuradio\first.grc" Done > > > Showing: "C:\Users\lonneke\gnuradio\first.grc" > > Loading: "C:\Users\lonneke\gnuradio\sin_src.grc" Done > > > Loading: "C:\Users\lonneke\gnuradio\noisy.grc" Done > > > Generating: "C:\Users\lonneke\gnuradio\top_block.py" > > Generating: "C:\Users\lonneke\gnuradio\top_block.py" > > Executing: "C:\Users\lonneke\gnuradio\top_block.py" > > ↑ý > ☻x´ > ☻\lonneke\AppData\Roaming\.gnuradio\prefs\gr_vmcircbuf_default_factoryC:\Program > Files (x86)\gnuradio\lib\site-packages\gnuradio\grc\gui\Dialogs.py:36: > GtkWarning: gtk_text_bu > > ffer_emit_insert: assertion `g_utf8_validate (text, len, NULL)' failed > self.insert = lambda line: text_buffer.insert(text_buffer.get_end_iter(), > line) > : Invalid argument Just to be clear, you have GRC executing flowgraphs and the display is working fine? Is there any other indication of something going wrong than that assertion you're seeing on the command line? > FYI the files I used in an endless combination to intalle gnuradio on > Windows 7 prof on a 64 bit VAIO laptop are: > > Microsoft Windows [versie 6.1.7601] > Copyright (c) 2009 Microsoft Corporation. Alle rechten voorbehouden. > > 27-07-2013 14:30 . > 27-07-2013 14:30 .. > 26-07-2013 00:05 449.539 Cheetah-2.4.4.win32-py2.7.exe > 16-07-2013 23:48 cheetahtemplate-cheetah-v2.4 > 16-07-2013 23:46 272.418 > cheetahtemplate-cheetah-v2.4.0-0-g7b1c2ad.zip > 15-07-2013 16:32 1.300.888 FuzeZipSetup-r158-w-bc.exe > 15-07-2013 17:0671.527.469 gnuradio_3.6.4.1_Win32.exe > 15-07-2013 16:50 1.522.840 lxml-3.2.1.win32-py2.7.exe > 15-07-2013 16:32 5.746.517 > numpy-1.6.2-win32-superpack-python2.7.exe > 15-07-2013 16:35 3.139.105 numpy-1.7.0.zip > 15-07-2013 15:59 819.200 pygtk-2.24.0.win32-py2.6.msi > 15-07-2013 16:2633.239.562 pygtk-all-in-one-2.24.2.win32-py2.7.msi > 15-07-2013 16:56 1.161.617 PyOpenGL-3.0.2.win32.exe > 27-07-2013 14:25 1.394.783 PyOpenGL-3.1.0a1.win32-py2.7.exe > 15-07-2013 16:3928.551.998 PyQt-Py2.7-x86-gpl-4.9.6-1.exe > 15-07-2013 16:45 968.776 PyQt4.Qwt5-5.2.1.win32-py27.exe > 15-07-2013 00:1615.867.904 python-2.7.3.msi > 25-07-2013 23:3554.703.148 > scipy-0.12.0-win32-superpack-python2.7.exe > 15-07-2013 16:41 227.956 setuptools-0.6c11.win32-py2.7.exe > 15-07-2013 16:09 4.216.840 vcredist_x86.exe > 26-07-2013 00:2211.811.043 wxPython-2.8.12.1.win32-py2.7.exe > 26-07-2013 00:20 203.234 wxPython-common-2.8.12.1.win32-py2.7.exe > 25-07-2013 17:4411.259.849 wxPython2.8-win32-ansi-2.8.12.1-py27.exe > 15-07-2013 16:4311.398.572 > wxPython2.8-win32-unicode-2.8.12.1-py27.exe > 16-07-2013 23:3212.288 _namemapper.pyd2.5 > 22 bestand(en) 259.795.546 bytes > 3 map(pen) 255.690.354.688 bytes beschikbaar Any chance you could help us update our build guide for windows? http://gnuradio.org/redmine/projects/gnuradio/wiki/WindowsInstall Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help: QAM Constellation and PolyPhase Clock
I have simple 16QAM Modulator block and am plotting the constellation with and without the a polyphase clock block . The constellation directly out of the modulator is not 16 "points" or even blobs but "random" looking points. I put it into a QAM Demod block and it demodulates it correctly. The constellation plot of the polyphase clock block shows 16 distinct "points" but when demodulated is quite noisy. Can anyone explain: 1) Why is the output of the QAM Modulator block not show as 16 points? 2) Why would the "corrected" QAM Modulation not give better demodulation output? I have attached the ConstellationQuestion.grc file. Thanks...Tom ContstellationQuestion.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help: QAM Constellation and PolyPhase Clock
On Mon, Jul 29, 2013 at 12:14 PM, tom sutherland wrote: > I have simple 16QAM Modulator block and am plotting the constellation with > and without the a polyphase clock block . The constellation directly out of > the modulator is not 16 "points" or even blobs but "random" looking points. > I put it into a QAM Demod block and it demodulates it correctly. The > constellation plot of the polyphase clock block shows 16 distinct "points" > but when demodulated is quite noisy. > Can anyone explain: > 1) Why is the output of the QAM Modulator block not show as 16 points? > 2) Why would the "corrected" QAM Modulation not give better demodulation > output? > > I have attached the ConstellationQuestion.grc file. > Thanks...Tom It's what's called ISI, or inter-symbol interference. The modulator applies a pulse shaping filter to the transmitted signal, which in this case is a root raised cosine filter. That has properties that actually "smear" the symbols in time and make them overlap in this way. That's expected and what it's supposed to do. Also, you have now increased the sampling rate to 4 samples / symbol, so you'll get points in between the actual symbol points now. The clock recovery block in this case uses another root raised cosine filter. The convolution of an RRC with an RRC is a raised cosine filter, which is a Nyquist filter, and so you've removed the ISI you've introduced in the first RRC stage. This also finds the correct symbol points and outputs 1 sample per symbol. The PFB still has a little bit of noise added due to the quantization of the possible phases. If you increase nfilts, you'll see this quantization noise go down. But the noise using 32 filters is about the same quantization noise you get for 16 bits of precision, so that limits your situation there. Besides, you're going to quickly become dominated by thermal noise. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] pybombs building 3.6.5.1 - swapping and out of virtual memory
Not sure if this is a Pybombs or Gnuradio build issue: When building version 3.6.5.1 via pybombs the system starts swapping after about 70% of the build have completed and even sometimes bails out with "out of virtual memory". I can complete the build by restarting pybombs install - sometimes several times. I am building on XUbuntu 12.04 64bit - both machines have 4Gb RAM. I notice that "top" shows several cc1plus processes running in parallel each consuming over 1Gb of memory. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pybombs building 3.6.5.1 - swapping and out of virtual memory
On Mon, Jul 29, 2013 at 12:40 PM, M Dammer wrote: > Not sure if this is a Pybombs or Gnuradio build issue: When building > version 3.6.5.1 via pybombs the system starts swapping after about 70% > of the build have completed and even sometimes bails out with "out of > virtual memory". I can complete the build by restarting pybombs install > - sometimes several times. > I am building on XUbuntu 12.04 64bit - both machines have 4Gb RAM. > I notice that "top" shows several cc1plus processes running in parallel > each consuming over 1Gb of memory. That's a GNU Radio issue, not PyBOMBS. The 3.6.5 series is particularly bad about memory usage since there's a lot of duplicated blocks. Best advice for you is to edit templates/cmake.lwt in PyBOMBS and change it from 'make -j4' to 'make -j3' (or -j2 to be even more safe, but -j3 on my 4 GB machine tends to be ok). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pybombs building 3.6.5.1 - swapping and out of virtual memory
By default pybombs runs make with the "-j4" option, allowing it to compile
things in parallel. This typically helps the compile go quicker. I
certainly wouldnt expect the gnuradio compile to have issues like this, but
you could edit the gnuradio recipe to force it not to use the "-j4" option
by adding:
make {
make
}
This basically overwrites the template pybombs uses for the make
stage, which uses the "-j4" by default. It will result in a longer
compile time, and again I wouldnt expect a machine with 4GB of RAM to
have any problems, even with that option, but its something to try.
Tim
On Mon, Jul 29, 2013 at 12:40 PM, M Dammer wrote:
> Not sure if this is a Pybombs or Gnuradio build issue: When building
> version 3.6.5.1 via pybombs the system starts swapping after about 70%
> of the build have completed and even sometimes bails out with "out of
> virtual memory". I can complete the build by restarting pybombs install
> - sometimes several times.
> I am building on XUbuntu 12.04 64bit - both machines have 4Gb RAM.
> I notice that "top" shows several cc1plus processes running in parallel
> each consuming over 1Gb of memory.
>
>
>
> ___
> 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] pybombs building 3.6.5.1 - swapping and out of virtual memory
On 07/29/2013 12:40 PM, M Dammer wrote: Not sure if this is a Pybombs or Gnuradio build issue: When building version 3.6.5.1 via pybombs the system starts swapping after about 70% of the build have completed and even sometimes bails out with "out of virtual memory". I can complete the build by restarting pybombs install - sometimes several times. I am building on XUbuntu 12.04 64bit - both machines have 4Gb RAM. I notice that "top" shows several cc1plus processes running in parallel each consuming over 1Gb of memory. Try adding more swap space. GCC goes all memory-hungry when it's compiling some of the SWIG output in Gnu Radio. And if pybombs is running parallel builds that will add more pressure on VM. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pybombs building 3.6.5.1 - swapping and out of virtual memory
Thanks for all the quick replies. I will go for changing cmake.lwt as I rather have a longer compile time than insane disk activity. On 29/07/13 17:45, Tom Rondeau wrote: > On Mon, Jul 29, 2013 at 12:40 PM, M Dammer wrote: >> Not sure if this is a Pybombs or Gnuradio build issue: When building >> version 3.6.5.1 via pybombs the system starts swapping after about 70% >> of the build have completed and even sometimes bails out with "out of >> virtual memory". I can complete the build by restarting pybombs install >> - sometimes several times. >> I am building on XUbuntu 12.04 64bit - both machines have 4Gb RAM. >> I notice that "top" shows several cc1plus processes running in parallel >> each consuming over 1Gb of memory. > That's a GNU Radio issue, not PyBOMBS. The 3.6.5 series is > particularly bad about memory usage since there's a lot of duplicated > blocks. > > Best advice for you is to edit templates/cmake.lwt in PyBOMBS and > change it from 'make -j4' to 'make -j3' (or -j2 to be even more safe, > but -j3 on my 4 GB machine tends to be ok). > > Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Portable battery for USRPs
Hi! I have to do a few outdoor experiments with USRPs. Hence I'm looking for portable batteries that can be used for this purpose. After searching a bit, the best option that seems to me is to use 12V heavy duty lantern battery followed by a 12V to 110V DC to AC inverter, which can then be used for the USRP adapter. The combined assembly is still a bit heavy for me. Is there any other better (lighter) option ? Are there any batteries specifically designed to be used with USRPs ? Thanks in advance. regards, Aseem -- Aseem Wadhwa Graduate Student Electrical & Computer Engineering University of California Santa Barbara ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: File Transfer using GRC with File Source:Help
-- Forwarded message -- From: vaibhav rayanade Date: Tue, Jul 16, 2013 at 7:28 PM Subject: File Transfer using GRC with File Source:Help To: discuss-gnuradio@gnu.org Hi everyone, 1. I am trying to transfer a file with use of File Source and File sink. I am stuck at the different types of files that can be transferred. I can send and receive a *.png file correctly but other files such as *.pptx etc.Can please anyone tell me what all types of files i.e. *.txt, *.png, *.pdf etc are supported by GRC. How can I save the file with File sink with automatically generated file name?? 2. Also I am working on QPSK modulation for the File transfer. Attached is the GRC file. Please what is wrong in the same. Thank you Vaibhav Rayanade Filetfr.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Portable battery for USRPs
As indicated on the silk screening of the front panel of the USRP(s) they are powered by 6V DC @ 3A (Center pin is positive, outer negative). It's fairly easy to find battery solutions that meet this criteria directly without using the AC adapter. I have built light weight Li-Ion solutions for USRPs also, you need to take a little more care with these, there nominal voltages tend to be significantly higher than 6V and the details of what USRP/daughter board is being used can be important. Stick with a lantern style battery or gel cell if you want to keep it simple and safe. On Jul 29, 2013, at 10:46 AM, aseem wadhwa wrote: > Hi! > > I have to do a few outdoor experiments with USRPs. Hence I'm looking for > portable batteries that can be used for this purpose. After searching a bit, > the best option that seems to me is to use 12V heavy duty lantern battery > followed by a 12V to 110V DC to AC inverter, which can then be used for the > USRP adapter. The combined assembly is still a bit heavy for me. Is there any > other better (lighter) option ? Are there any batteries specifically designed > to be used with USRPs ? > > Thanks in advance. > > regards, > Aseem > > -- > Aseem Wadhwa > Graduate Student > Electrical & Computer Engineering > University of California Santa Barbara > ___ > 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] Portable battery for USRPs
On 07/29/2013 02:16 PM, Ian Buckley wrote: As indicated on the silk screening of the front panel of the USRP(s) they are powered by 6V DC @ 3A (Center pin is positive, outer negative). It's fairly easy to find battery solutions that meet this criteria directly without using the AC adapter. I have built light weight Li-Ion solutions for USRPs also, you need to take a little more care with these, there nominal voltages tend to be significantly higher than 6V and the details of what USRP/daughter board is being used can be important. Stick with a lantern style battery or gel cell if you want to keep it simple and safe. On Jul 29, 2013, at 10:46 AM, aseem wadhwa wrote: A very quick search turned up this: http://www.powerstream.com/PST-MP3500-I.htm Switchable output levels. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Acceptable sampling rate and LO frequency for USRP LFRX
Hi, I have been using GRC and N210 to test my data acquisition scheme. My previous scheme worked well with probably standard sampling rate (10Msps) and LO at DC. When I switched to a non-standard sampling rate (1.2 Msps) and non-standard LO (1.105 MHz), all hell seems to break loose. One message appears to be helpful, says: "Hardware does not support requested sampling rate, request 1.200.. Msps, actual 1.2048. Msps. I suspect my requested LO of 1.105 MHz also may not be met, but there is no message saying that. My question is: how do my find out the LFRX supported sampling rate and LO frequency? Thanks, LD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Acceptable sampling rate and LO frequency for USRP LFRX
On 07/29/2013 02:47 PM, LD Zhang wrote: Hi, I have been using GRC and N210 to test my data acquisition scheme. My previous scheme worked well with probably standard sampling rate (10Msps) and LO at DC. When I switched to a non-standard sampling rate (1.2 Msps) and non-standard LO (1.105 MHz), all hell seems to break loose. One message appears to be helpful, says: "Hardware does not support requested sampling rate, request 1.200.. Msps, actual 1.2048... Msps. I suspect my requested LO of 1.105 MHz also may not be met, but there is no message saying that. My question is: how do my find out the LFRX supported sampling rate and LO frequency? Thanks, LD The daughtercards don't know anything about sample rate. The available sample rates are determined by the motherboard hardware. In the case of the N210, the selected sample rate must be a proper integer fraction of the fixed ADC sample rate, which is 100Msps. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Acceptable sampling rate and LO frequency for USRP LFRX
Thanks. Does the LO frequency also have to integer fraction of 100 MHz? From: discuss-gnuradio-bounces+ldz10565=gmail@gnu.org [mailto:discuss-gnuradio-bounces+ldz10565=gmail@gnu.org] On Behalf Of Marcus D. Leech Sent: Monday, July 29, 2013 11:52 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Acceptable sampling rate and LO frequency for USRP LFRX On 07/29/2013 02:47 PM, LD Zhang wrote: Hi, I have been using GRC and N210 to test my data acquisition scheme. My previous scheme worked well with probably standard sampling rate (10Msps) and LO at DC. When I switched to a non-standard sampling rate (1.2 Msps) and non-standard LO (1.105 MHz), all hell seems to break loose. One message appears to be helpful, says: "Hardware does not support requested sampling rate, request 1.200.. Msps, actual 1.2048. Msps. I suspect my requested LO of 1.105 MHz also may not be met, but there is no message saying that. My question is: how do my find out the LFRX supported sampling rate and LO frequency? Thanks, LD The daughtercards don't know anything about sample rate. The available sample rates are determined by the motherboard hardware. In the case of the N210, the selected sample rate must be a proper integer fraction of the fixed ADC sample rate, which is 100Msps. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QT GUI FFT and Waterfall plots not working for me on 3.7
Hi all, For whatever reason QT FFT and Waterfall plots are not displaying for me. All the controls are present and I can change scale, FFT size, color intensity (for waterfall), etc. but the display area is just a white brick. Time domain display seems to work just fine. I see this behavior both with gr-qtgui/apps/uhd_display.py and with a simple GRC flowgraph with UHD -> QT sink. System info: Ubuntu 13.04 x86_64 GNU Radio v3.7.0-82-g179a2d78 UHD v3.5.3-20-gbcdf7c3 Compiler: g++-4.6 --sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using Popen to start a pipe and pass the input
Apologies, I asked on Stack Overflow but posted here as well.
Thanks
On Mon, Jul 29, 2013 at 5:08 PM, Tom Rondeau wrote:
> On Mon, Jul 29, 2013 at 4:02 AM, Shashank Gaur wrote:
>> Hello All,
>>
>> I am trying to use popen to open an application under a block.
>>
>> This looks something like that:
>>
>> fp = popen(command, "w"); //doing it in write mode
>>
>> if(!fp){
>> #Handle the error
>> }
>>
>> ..
>>
>> pclose(fp);
>>
>> Now the thing is even if I am trying to track using (fp != NULL) it
>> still keep executing the command over and over. Any ideas on that? May
>> somebody can guide me through right way to use popen?
>>
>> Also to pass the c++ output stream, std::cout will work, right?
>>
>> Thanks
>
>
> Hi Shashank,
>
> I know you are working on GNU Radio for the GSoC, but this question
> isn't related to GNU Radio. You'll be better off asking another forum
> like Stack Overflow.
>
> Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new to GNUradio: AFSK and codec2 gmsk modem
Tom, (inline comments) On 29-07-13 17:01, Tom Rondeau wrote: On Mon, Jul 29, 2013 at 5:48 AM, Kristoff Bonne wrote: Just found this, it might help: https://github.com/dl1ksv/gr-afsk Hmmm. Looks interesting. A good start. :-) However, it seams I have another problem: it does not build on my system (ubuntu 12.04 LTS). It needs gnuradio-runtime and as I currently run gnuradio 3.6.4.1 + Boost 1.49 build from source, it doesn't have that. I tried to build 3.7.1 -which seams to include gnuradio-runtime in its source- but that fails on a number of tests (qa_fir_filter, qa_freq_xlating_fir_filter, qa_constellation_receiver and qa_codec2_vocoder). Grrr! :-( Those QA failures are probable a Volk issue. Try running volk_profile after you run 'make install'. If a given kernel fails for an architecture, it will be disabled. Once volk_profile completes (it can take a while), try rerunning 'make test'. Good news and bad news. First test: to run volk_profile without doing the "make install" (I did not want to install something where the "make tests" indicated is wasn't 100 % OK). Same result as before. "make test" still gives 4 errors. 2nd test: ran "sudo make install" anyway, then volk_profile and then "make test": Good news and bad news. 3 tests are now OK, only the codec2 vocoder still fails. --- cut here --- cut here --- cut here --- cut here --- cut here --- The following tests FAILED: 168 - qa_codec2_vocoder (Failed) Errors while running CTest --- cut here --- cut here --- cut here --- cut here --- cut here --- If it still fails, run 'ctest -V -R volk' and send us the output. Is now OK: --- cut here --- cut here --- cut here --- cut here --- cut here --- 1: *** No errors detected 1/1 Test #1: qa_volk_test_all . Passed0.92 sec The following tests passed: qa_volk_test_all 100% tests passed, 0 tests failed out of 1 --- cut here --- cut here --- cut here --- cut here --- cut here --- What is strange is that I do get an error when I do this test on the codec2 vocoder block: --- cut here --- cut here --- cut here --- cut here --- cut here --- 168: Test command: /bin/sh "/home/kristoff/ham/gnuradio/gnuradio-3.7.0/build/gr-vocoder/python/vocoder/qa_codec2_vocoder_test.sh" 168: Test timeout computed to be: 9.99988e+06 168: F 168: == 168: FAIL: test001_module_load (__main__.test_codec2_vocoder) 168: -- 168: Traceback (most recent call last): 168: File "/home/kristoff/ham/gnuradio/gnuradio-3.7.0/gr-vocoder/python/vocoder/qa_codec2_vocoder.py", line 54, in test001_module_load 168: self.assertEqual(expected_data, actual_result) 168: AssertionError: Tuples differ: (0, 0, 0, 3, 2, 0, 1, 5, 6, 7,... != (0, 0, 0, 3, 2, 0, 1, 5, 6, 7,... 168: 168: First differing element 112: 168: 24 168: 25 --- cut here --- cut here --- cut here --- cut here --- cut here --- Am I correct to assume that the errors means there is a difference between what it actually gets back from the module based on a test-pattern and what is expects. Is this related to the volt-libraries that produce a different result on my particular test. But I must say that there does is quite a difference between the test in gnuradio 3.6.4.1. and 3.7.0 All the stuff about "data" and "expected data" are simply not present in the test-script in 3.6.4.1. Perhaps the thing here is that the script for 3.6.4.1. simply does not do this "compair with what we expect" test and it might be that this codec2 library is just as wrong on 3.6.4.1 as in 3.7.0 Both versions I have are build with boost 1.49; as described in README.building-boost I can try with newer versions of boost; but I must say that when using Boost 1.54, GNUradio doesn't even compile on my box. What is the recommended version of boost to be used with gnuradio 3.7.0 ? What's your processor? The machine is a dell laptop. The CPU is a quad-core "Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz" (which is a bit strange as the wikipedia says the 520m is supposed to be dual-core). Tom Cheerio! Kr. Bonne ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRAS build error on armv7
On 07/29/2013 07:31 AM, Manoj Gudi wrote:
> That sounds good.
I second that. Just ifdef the pause for the fix.
For a little extra information here. The thread pools in Theron can have
different yield strategies. GRAS happens to use by default the condition
variable strategy. So the code in question actually has zero impact at
runtime unless a spin lock yield is requested.
Beyond just compiling, in the near future, we will get to test questions
like. Which strategy works better on arm? And that yield code in
particular, what in particular would be most optimal for arm.
Some relevant links.
http://docs.theron-library.com/5.01/structTheron_1_1Framework_1_1Parameters.html
https://github.com/guruofquality/gras/wiki/Threading
-josh
>
> From: manojgudi
> Date: Mon, 29 Jul 2013 17:00:35 +0530
> Subject: [PATCH] fixed ASM
>
> ---
> Include/Theron/Detail/Threading/Utils.h |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Include/Theron/Detail/Threading/Utils.h
> b/Include/Theron/Detail/Threading/Utils.h
> index 8c6baf2..e2811f1 100644
> --- a/Include/Theron/Detail/Threading/Utils.h
> +++ b/Include/Theron/Detail/Threading/Utils.h
> @@ -168,8 +168,11 @@ THERON_FORCEINLINE void Utils::YieldToHyperthread()
> YieldProcessor();
>
> #elif THERON_GCC
> -
> -__asm__ __volatile__ ("pause");
> +#ifdef __arm__
> +__asm__ __volatile__ ("NOP");
> +#elif __X86_64__
> + __asm__ __volatile__("pause");
> +#endif
>
> #endif
>
>
>
> ___
> 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] Gnuradio3.7 make error
Hi, I'm using Ubuntu 12.04 and libboost1.46. I got the following errors when I make the project. [ 85%] Building CXX object gr-uhd/examples/c++/CMakeFiles/tags_demo.dir/tags_demo.cc.o Linking CXX executable tags_demo /usr/bin/ld: warning: libboost_date_time.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_filesystem.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_program_options.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_regex.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_system.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_thread.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_unit_test_framework.so.1.40.0, needed by /usr/local/lib/libuhd.so, not found (try using -rpath or -rpath-link) /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::dir_itr_increment(void*&, void*&, std::basic_string, std::allocator >&, boost::filesystem::file_status&, boost::filesystem::file_status&)' /usr/local/lib/libuhd.so: undefined reference to `boost::thread_resource_error::thread_resource_error()' /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::dir_itr_close(void*&, void*&)' /usr/local/lib/libuhd.so: undefined reference to `boost::lock_error::lock_error()' /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::dir_itr_first(void*&, void*&, std::basic_string, std::allocator > const&, std::basic_string, std::allocator >&, boost::filesystem::file_status&, boost::filesystem::file_status&)' /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::get_current_path_api(std::basic_stringstd::char_traits, std::allocator >&)' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::get_mem_block()' /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::not_found_error()' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::get_default_error_string(boost::regex_constants::error_type)' /usr/local/lib/libuhd.so: undefined reference to `boost::system::get_generic_category()' /usr/local/lib/libuhd.so: undefined reference to `boost::system::get_system_category()' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::put_mem_block(void*)' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::raise_runtime_error(std::runtime_error const&)' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::cpp_regex_traits_implementation::transform_primary(char const*, char const*) const' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::perl_matcherstd::allocator >, boost::regex_traits > >::construct_init(boost::basic_regexboost::cpp_regex_traits > > const&, boost::regex_constants::_match_flags)' /usr/local/lib/libuhd.so: undefined reference to `boost::filesystem::detail::status_api(std::basic_stringstd::char_traits, std::allocator > const&, boost::system::error_code&)' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::cpp_regex_traits_implementation::transform(char const*, char const*) const' /usr/local/lib/libuhd.so: undefined reference to `boost::match_resultsconst*> > >::maybe_assign(boost::match_resultsstd::allocator > > const&)' /usr/local/lib/libuhd.so: undefined reference to `boost::re_detail::verify_options(unsigned int, boost::regex_constants::_match_flags)' /usr/local/lib/libuhd.so: undefined reference to `boost::basic_regexboost::cpp_regex_traits > >::do_assign(char const*, char const*, unsigned int)' collect2: ld returned 1 exit status make[2]: *** [gr-uhd/examples/c++/tags_demo] Error 1 make[1]: *** [gr-uhd/examples/c++/CMakeFiles/tags_demo.dir/all] Error 2 make: *** [all] Error 2 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio3.7 make error
On Mon, Jul 29, 2013 at 10:44 PM, Harry Zhang wrote: > Hi, > I'm using Ubuntu 12.04 and libboost1.46. I got the following errors when > I make the project. > libboost1.46 is known to cause problems with GNU Radio. Ubuntu 12.04 should have libboost1.48 available in the repos. Here's some more info: http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00267.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio3.7 make error
Dear Nathan, I have tried the method in the URL but it does not work. The error remains. 2013/7/30 10:58, Nathan West wrote: On Mon, Jul 29, 2013 at 10:44 PM, Harry Zhang wrote: Hi, I'm using Ubuntu 12.04 and libboost1.46. I got the following errors when I make the project. libboost1.46 is known to cause problems with GNU Radio. Ubuntu 12.04 should have libboost1.48 available in the repos. Here's some more info: http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00267.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio3.7 make error
On Mon, Jul 29, 2013 at 11:55 PM, Gong Zhang wrote: > Dear Nathan, > I have tried the method in the URL but it does not work. The error > remains. > > 2013/7/30 10:58, Nathan West wrote: >> >> On Mon, Jul 29, 2013 at 10:44 PM, Harry Zhang wrote: >>> >>> Hi, >>> I'm using Ubuntu 12.04 and libboost1.46. I got the following errors >>> when >>> I make the project. >>> >> libboost1.46 is known to cause problems with GNU Radio. Ubuntu 12.04 >> should have libboost1.48 available in the repos. Here's some more >> info: >> http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00267.html >> > What do you mean you tried the method in the URL? The cmake flag? The point of sending that link is the version of boost you have is known to cause problems with GNU Radio and unless you have a very good reason for using it you should use another version. If you're having trouble installing GNU Radio for the first time you might give pybombs a shot. It's pretty easy to get an installation going for the first time, especially if you're having a problem with dependencies like boost. Here's info on pybombs: http://gnuradio.org/redmine/projects/pybombs/wiki Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Low cost SDR hardware
Hello everyone, A professor in my university wants to revive lab course on communication. He wants to introduce some experiments involving SDR. For that we need about 100 pieces of hardware( both receiver and transmitter). Buying 100 USRP is not a viable solution for us. We can go for RTL SDR but it has only transmitter. Does anyone know of a good solution for low cost hardware, (transmitter + receiver or just transmitter) preferably GNU Radio compatible, that we could opt for? -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How can I get a high sampling rate in USRP on GNURadio
Hi all I want to transmit samples as fast as I can. However, my maximum sampling rate is only 5MSps because of some congestion in my CPU, and I want to get the rate at least 10MSps. I use Ettus USRP N210, and processor of my desktop is Inter Core i5-3570, and memory is 16GB RAM, and ethernet card is Realtek RTL-8169. Can somebody tell me how to get high sample rate? -Juhwan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
