Re: [Discuss-gnuradio] Messaging Passing on a Budget
Packaging the json string as a vector of u8 integers worked like a charm,
thank you for the suggestion!
Python code:
https://gist.github.com/regulatre/38e7162d6f470ad0dbd77b171a69dc79
C++ block code:
https://gist.github.com/regulatre/f264fb4751ca3bd8d6b98abf9792e95d
Memory consumption by the python flowgraph is no longer showing signs of
memory leakage (at least in the 4 hours it's been running :)
On Fri, Mar 1, 2019 at 1:50 PM Müller, Marcus (CEL) wrote:
> Hi Brad,
>
> so, yes, your observation is correct: PMT symbols are/were meant to be
> used as "identifiers", not as "data carriers"; the motivation behind
> the hash table you find in pmt.cc is that there's only one instance of
> any given PMT symbol, and thus, a simple address comparison suffices to
> tell whether two PMT symbols are the same.
>
> You'll notice that on x86 (and presumably modern ARM) string comparison
> is pretty fast, and that you'd need to do *a lot* comparisons to offset
> the cost of hashing a symbol once. Anyway, yes, that table grows
> unboundedly.
>
> Since your string isn't actually a "symbol", I'd recommend simply
> encoding it safely (that's probably already the case), and putting it
> in a uniform PMT vector of 8bit integers (u8vector).
>
> On a different note, there's actually "unintended" (as in: I don't
> intend GNU Radio to have an unbounded hash map, but it's at least what
> was originally intended) memory leaks with PMTs and tag_t on the
> Python/C++ boundary, and there's quite some broken concepts within PMT.
>
> Long or medium term, we'll be replacing PMT with something that is
> actually a common serialization format for usage in external software
> (i.e. not for usage within the same flow graph), and ideally with the
> unserialized universal container that comes with such a format. Stay
> tuned. However, not happening in 3.8 or anything before.
>
> Best regards,
> Marcus
>
> On Thu, 2019-02-28 at 14:48 -0500, Brad Hein wrote:
> >
> > In my gnuradio test application I’m attempting to pass a JSON formatted
> string from my C++ custom block, to my python flow graph containing the
> block.
> >
> > The String message are being received by my python flow graph, but
> there’s a memory leak. Over time, my flowgraph RSS (memory footprint) grows
> at about 32k/s up until the application runs out of memory.
> >
> > The leak didn’t start until after I retrofitted my flowgraph and custom
> block with polymorphic type (PMT) based message passing. I’m passing a 200
> or so byte JSON string (as a symbol) from C++ block to python flow graph
> about 60 times per second.
> >
> > Sleuthing through the pmt.cc code [1] I see the String (symbol) objects
> are stored in a hash. I suspect what is happening is that since all of my
> JSON strings are unique, they’re getting added to the hash and causing the
> hash to grow unbounded over time.
> >
> > From what I can tell by reading the wiki [2], the approach I’m using is
> the best way to get a string from my custom block and into my python
> flowgraph.
> >
> > [1]
> https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/pmt/pmt.cc
> > [2] https://www.gnuradio.org/doc/doxygen/page_pmt.html
> >
> >
> > Sample c++ block code snippet from my work function:
> >
> > // Calculate metrics. Occasionally (60/second) we'll get back a JSON
> formatted string of metrics.
> > crossingData = calculateWaveCrossingMetrics(lastSampleValue,in[i]);
> >
> > if (crossingData.length() > 0) {
> > pmt::pmt_t messageString;
> > messageString = pmt::string_to_symbol(crossingData.c_str());
> > message_port_pub(polymorphicMessageDestination, messageString);
> >
> >
> > Questions:
> >
> > 1. Is this the best way to get a string from my C++ block into my
> python application?
> > 2. Is there a way to pass my messages that doesn’t result in memory
> growing unbounded?
> >
> >
> > Thank you
> > Brad
> >
> > ___
> > 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] Two instances of the same custom block walk into a bar
t;, >> but that needs to be balanced with keeping the "support envelope" >> for this forum manageable. >> >> It is the case that being really successful with a framework like Gnu >> Radio requires non-trivial facility in a number of different disciplines, >> and >> there really is no substitute for developing that facility. I'm fairly >> sure that other specialized programming frameworks go through the same >> thing, and I wonder how they cope as a community... >> >> >> >> On Thu, May 9, 2019, 22:05 Marcus D. Leech >> wrote: >> >>> On 05/09/2019 02:54 PM, Albin Stigö wrote: >>> >>> Every instance of a block is an instance of the c++ class but like Nick >>> says all your variables are static and not member variables. Those need to >>> be declared in the header. Your two block instances are referring to the >>> same variables and that's why things get messed up. >>> >>> "A tour of C++" by Bjarne Stroustrup is a good refresher on C++. >>> >>> --Albin >>> >>> I'm going to suggest, ever-so-gently, that discuss-gnuradio, and Gnu >>> Radio in general aren't the places for learning C++. There are forums >>> already for that. >>> >>> I'm saying this only because in the 15 years () I've been involved >>> with Gnu Radio, I see an alarming number of cases where the >>> intrepid Gnu Radio developer actually doesn't have much in the way of >>> programming experience in the underlying languages used, >>> and arrives here, nearly-certain that their problem is GR related, >>> rather than an improper use of the underlying programming language. >>> >>> My guess is that other specialized-framework environments have the same >>> issue. Fortunately, most people here are helpful regardless. >>> But it shouldn't be a growing *expectation*, IMHO. >>> >>> >>> >>> On Thu, May 9, 2019, 20:46 Nick Foster wrote: >>> >>>> It looks like you've declared a bunch of static variables within your >>>> block's namespace. Those variables (including pointers!) will be shared >>>> with every instance of your block. This is Bad News. Those variables should >>>> probably all be declared in the header as class member variables. >>>> >>>> On Thu, May 9, 2019 at 11:43 AM Brad Hein wrote: >>>> >>>>> I'm running into a strange issue with a new flow graph [1] I'm working >>>>> on that uses a custom C++ block [2] that I built. The block takes input >>>>> samples, performs some DSP, and outputs modified samples at the same >>>>> sample >>>>> rate. >>>>> >>>>> When the flowgraph has a single instance of my custom block enabled, >>>>> it works fine. But when I enable a second instance of the block in a >>>>> separate second usage, (think stereo sound, one per sink channel) it acts >>>>> very unexpectedly - output samples are wildly inaccurate and distorted. >>>>> >>>>> My perception is that the two instances of the same block seem to be >>>>> sharing some part of their memory namespace and as they modify/store >>>>> variables they are doing so in some sort of shared namespace or memory >>>>> segment. >>>>> >>>>> Is it possible for two blocks to corrupt each other's memory? I can't >>>>> think of any other explanation for the two streams working fine >>>>> individually, but when both are enabled at the same time the output is >>>>> garbled. I've tried all sorts of things like tying them to the same source >>>>> block, removing the upsampling/downsampling, adding a delay to one, etc. >>>>> with no luck. >>>>> >>>>> >>>>> [1] "Flowgraph with two parallel streams both using the custom block >>>>> pq_rails": >>>>> https://github.com/regulatre/gr-powerquality/blob/master/examples/streamer.grc >>>>> >>>>> [2] "pq_rails (Custom block) source code": >>>>> https://github.com/regulatre/gr-powerquality/blob/master/lib/pq_rails_impl.cc >>>>> >>>>> ___ >>>>> 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 >>> 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 >> > ___ > 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] Tuning in VLF with a sound card
Great suggestion thank you! This also gives me new topics to read up on as I am still a VLF amateur. [Sent from mobile device] On Wed, May 15, 2019, 1:20 PM John Coppens On Thu, 2 May 2019 16:22:24 -0400 > Brad Hein wrote: > > > I took a Raspberry Pi and attached a 48KHz USB sound card, with a big > > magnetic loop antenna fed into the mic. > > Just a suggestion: If you have a loop antenna, which is a symmetrical > antenna, > and couple it to an asymmetrical input (MIC), you will make the antenna > more sensitive to static noise. I'd suggest you use either a transformer > or > an 'instrumentation amplifier' with an operational amplifier to convert > the signal from the antenna to asymmetrical signal. > > A transformer would be easiest to install at the base of the antenna (no > need for a supply). The op-amp amplifier would cover a larger bandwidth. > (it would also offer some protection for your computer). > > John > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Two instances of the same custom block walk into a bar
Thank you Nick and Albin. It's all much clearer now... I will refactor the code and give it another go. And I have put the book on my wish list, Albin :) On Thu, May 9, 2019 at 2:54 PM Albin Stigö wrote: > Every instance of a block is an instance of the c++ class but like Nick > says all your variables are static and not member variables. Those need to > be declared in the header. Your two block instances are referring to the > same variables and that's why things get messed up. > > "A tour of C++" by Bjarne Stroustrup is a good refresher on C++. > > --Albin > > On Thu, May 9, 2019, 20:46 Nick Foster wrote: > >> It looks like you've declared a bunch of static variables within your >> block's namespace. Those variables (including pointers!) will be shared >> with every instance of your block. This is Bad News. Those variables should >> probably all be declared in the header as class member variables. >> >> On Thu, May 9, 2019 at 11:43 AM Brad Hein wrote: >> >>> I'm running into a strange issue with a new flow graph [1] I'm working >>> on that uses a custom C++ block [2] that I built. The block takes input >>> samples, performs some DSP, and outputs modified samples at the same sample >>> rate. >>> >>> When the flowgraph has a single instance of my custom block enabled, it >>> works fine. But when I enable a second instance of the block in a separate >>> second usage, (think stereo sound, one per sink channel) it acts very >>> unexpectedly - output samples are wildly inaccurate and distorted. >>> >>> My perception is that the two instances of the same block seem to be >>> sharing some part of their memory namespace and as they modify/store >>> variables they are doing so in some sort of shared namespace or memory >>> segment. >>> >>> Is it possible for two blocks to corrupt each other's memory? I can't >>> think of any other explanation for the two streams working fine >>> individually, but when both are enabled at the same time the output is >>> garbled. I've tried all sorts of things like tying them to the same source >>> block, removing the upsampling/downsampling, adding a delay to one, etc. >>> with no luck. >>> >>> >>> [1] "Flowgraph with two parallel streams both using the custom block >>> pq_rails": >>> https://github.com/regulatre/gr-powerquality/blob/master/examples/streamer.grc >>> >>> [2] "pq_rails (Custom block) source code": >>> https://github.com/regulatre/gr-powerquality/blob/master/lib/pq_rails_impl.cc >>> >>> ___ >>> 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] Two instances of the same custom block walk into a bar
I'm running into a strange issue with a new flow graph [1] I'm working on that uses a custom C++ block [2] that I built. The block takes input samples, performs some DSP, and outputs modified samples at the same sample rate. When the flowgraph has a single instance of my custom block enabled, it works fine. But when I enable a second instance of the block in a separate second usage, (think stereo sound, one per sink channel) it acts very unexpectedly - output samples are wildly inaccurate and distorted. My perception is that the two instances of the same block seem to be sharing some part of their memory namespace and as they modify/store variables they are doing so in some sort of shared namespace or memory segment. Is it possible for two blocks to corrupt each other's memory? I can't think of any other explanation for the two streams working fine individually, but when both are enabled at the same time the output is garbled. I've tried all sorts of things like tying them to the same source block, removing the upsampling/downsampling, adding a delay to one, etc. with no luck. [1] "Flowgraph with two parallel streams both using the custom block pq_rails": https://github.com/regulatre/gr-powerquality/blob/master/examples/streamer.grc [2] "pq_rails (Custom block) source code": https://github.com/regulatre/gr-powerquality/blob/master/lib/pq_rails_impl.cc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tuning in VLF with a sound card
As an avid fan of Raspberry Pi, often putting them to use for DSP applications, I just want to say thank you for your hard work keeping gnuradio working and optimized on the platform! I've seen some great FET preamp circuits available on the internet, a few of which I've tried out. I'll dust one off and see if I can make it work in this application. On Wed, May 8, 2019 at 4:15 AM Albin Stigö wrote: > Hi Brad, > > Just some random ideas... What you are trying to do is very doable. Ive > seen a lot of people do it for VLF reception... Usually along with some > kind of FET amplifier before the mic... > > The frequency xlating FIR filter doesn't have great performance on the > rbpi at the moment. > The frequency xlating FFT filter would be better in your case. > > I'm working on a patch that will make these blocks 14 times faster on > raspberry pi so that will also improve things... > > > > --Albin > > > > On Wed, May 8, 2019, 06:06 Brad Hein wrote: > >> >> >> >> On Tue, May 7, 2019 at 4:19 PM Marcus D. Leech >> wrote: >> >>> On 05/07/2019 04:05 PM, Ben Hilburn wrote: >>> >>> Hey Brad - just checking in! This is an interesting experiment, and I >>> would love to hear how it went! >>> >>> Big thanks to Kevin and JMF for providing very helpful guidance, here, >>> too =) >>> >>> Cheers, >>> Ben >>> >>> I should perhaps have entered this discussion earlier, and pointed out >>> one of my early applications using a sound-card for VLF work: >>> >>> https://github.com/patchvonbraun/SIDSuite >>> >>> It's OLD now--I don't think it was ever converted to GR 3.7 >>> >>> One of the problems with mag-loop antenna is that they're very high Q, >>> and thus have very small fractional bandwidths, which means that >>> they're wildly inefficient at all but the resonant frequency. I made >>> up for that using a Behringer microphone pre-amp using the balanced input. >>> That meant I could use a fairly "random" multi-turn mag-loop and not >>> worry about efficiency very much. >>> >>> >> Thanks Marcus - I'll see if I can get it to compile again. In the >> meantime I have put together an AM receiver flowgraph using recommendations >> from this thread, along with what I remembered from the gnuradio tutorials >> and Mike Osman's video tutorials. >> >> https://github.com/regulatre/vlfCoilEperiment >> >> Given a 5-minute recording, which I included in the repo, I quickly found >> that QRM interference will be a hurdle and as you pointed out Marcus, my >> coil (an old VGA degaussing coil) seems to be resonant at undesirable >> frequencies. In its current installation it's getting overwhelmed by a >> steady interference source that sounds like ripples coming from a 60Hz >> half-wave rectifier. There are some gaps in the noise, and as I tuned >> around within the baseband using my flowgraph (in the repo above), I was >> able to tune to various parts of the baseband, but in all cases I had too >> much interference noise. >> >> I have a Focusrite Si2 I could use instead, which would have more gain >> potential and a very low noise floor, but first I think I'll need to find a >> way to get away from the noise sources. >> >> >> >> >> >> ___ >> 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] Tuning in VLF with a sound card
On Tue, May 7, 2019 at 4:19 PM Marcus D. Leech wrote: > On 05/07/2019 04:05 PM, Ben Hilburn wrote: > > Hey Brad - just checking in! This is an interesting experiment, and I > would love to hear how it went! > > Big thanks to Kevin and JMF for providing very helpful guidance, here, too > =) > > Cheers, > Ben > > I should perhaps have entered this discussion earlier, and pointed out one > of my early applications using a sound-card for VLF work: > > https://github.com/patchvonbraun/SIDSuite > > It's OLD now--I don't think it was ever converted to GR 3.7 > > One of the problems with mag-loop antenna is that they're very high Q, and > thus have very small fractional bandwidths, which means that > they're wildly inefficient at all but the resonant frequency. I made up > for that using a Behringer microphone pre-amp using the balanced input. > That meant I could use a fairly "random" multi-turn mag-loop and not > worry about efficiency very much. > > Thanks Marcus - I'll see if I can get it to compile again. In the meantime I have put together an AM receiver flowgraph using recommendations from this thread, along with what I remembered from the gnuradio tutorials and Mike Osman's video tutorials. https://github.com/regulatre/vlfCoilEperiment Given a 5-minute recording, which I included in the repo, I quickly found that QRM interference will be a hurdle and as you pointed out Marcus, my coil (an old VGA degaussing coil) seems to be resonant at undesirable frequencies. In its current installation it's getting overwhelmed by a steady interference source that sounds like ripples coming from a 60Hz half-wave rectifier. There are some gaps in the noise, and as I tuned around within the baseband using my flowgraph (in the repo above), I was able to tune to various parts of the baseband, but in all cases I had too much interference noise. I have a Focusrite Si2 I could use instead, which would have more gain potential and a very low noise floor, but first I think I'll need to find a way to get away from the noise sources. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tuning in VLF with a sound card
Yes I am very eager and hankful for the suggestions. Trying to make time to build out the flow graph and give it a go. Hopefully tonight! [Sent from mobile device] On Tue, May 7, 2019, 4:06 PM Ben Hilburn Hey Brad - just checking in! This is an interesting experiment, and I > would love to hear how it went! > > Big thanks to Kevin and JMF for providing very helpful guidance, here, too > =) > > Cheers, > Ben > > On Thu, May 2, 2019 at 7:12 PM Kevin Reid wrote: > >> On Thu, May 2, 2019 at 1:22 PM Brad Hein wrote: >> >>> I took a Raspberry Pi and attached a 48KHz USB sound card, with a big >>> magnetic loop antenna fed into the mic. A little cheesy? yes! But I'd like >>> to try and see if I can receive VLF. It's in a remote location with little >>> to no interference so I'm thinking my chances should be good. The challenge >>> I'm facing is that I need to write the SDR logic to "tune" throughout the >>> 0-24KHz tuning range. >>> >>> My question is, being that a sound card source presents samples in float >>> and not the usual complex data type, can I still apply the same SDR logic >>> that we use for SSB/FM/AM demodulation such as those presented in the >>> Gnuradio tutorials (eg. >>> http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial3.pdf) >>> and if not, how do I go about translating the float input into something I >>> can use to feed existing AM/FM/SSB demodulator flowgraphs? >>> >> >> The first thing you need to do is a "float to complex" operation (which >> will leave the imaginary/Q part zero). If you were to plot the spectrum of >> the resulting you would see that it is symmetric around 0 Hz, containing an >> extra copy of all the signals you're receiving, but that is no worse than a >> more typical received spectrum where the other half contains unrelated >> signals. >> >> After that, the approach is exactly the same as any other receiver >> flowgraph that supports receiving at an offset from the hardware >> center/zero frequency. You can use either the "Frequency Xlating FIR >> Filter" block (which combines a frequency shift and a low pass filter) or >> the "Rotator" block (which performs a frequency shift and would usually be >> followed by a separate filter), and the frequency shift of that block >> should be under user control for "tuning". Then you have a baseband signal >> that you can demodulate. >> ___ >> 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] Tuning in VLF with a sound card
I took a Raspberry Pi and attached a 48KHz USB sound card, with a big magnetic loop antenna fed into the mic. A little cheesy? yes! But I'd like to try and see if I can receive VLF. It's in a remote location with little to no interference so I'm thinking my chances should be good. The challenge I'm facing is that I need to write the SDR logic to "tune" throughout the 0-24KHz tuning range. My question is, being that a sound card source presents samples in float and not the usual complex data type, can I still apply the same SDR logic that we use for SSB/FM/AM demodulation such as those presented in the Gnuradio tutorials (eg. http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial3.pdf) and if not, how do I go about translating the float input into something I can use to feed existing AM/FM/SSB demodulator flowgraphs? I run many other flowgraphs on Raspberry Pi's remotely so the networking and remote aspect of the project will be easy for me. I really just need some initial guidance knowing which direction to go in terms of tuning. Thanks! Brad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Messaging Passing on a Budget
Thanks for the clever insights, Marcus. I'll consider the PMT vector
approach you mentioned, while at the same time knowing PMT is likely to
undergo changes in the future as you mentioned, I'll also look into using
TCP/IP to pass the needed information, perhaps ZeroMQ or a UDP socket even.
On Fri, Mar 1, 2019 at 1:50 PM Müller, Marcus (CEL) wrote:
> Hi Brad,
>
> so, yes, your observation is correct: PMT symbols are/were meant to be
> used as "identifiers", not as "data carriers"; the motivation behind
> the hash table you find in pmt.cc is that there's only one instance of
> any given PMT symbol, and thus, a simple address comparison suffices to
> tell whether two PMT symbols are the same.
>
> You'll notice that on x86 (and presumably modern ARM) string comparison
> is pretty fast, and that you'd need to do *a lot* comparisons to offset
> the cost of hashing a symbol once. Anyway, yes, that table grows
> unboundedly.
>
> Since your string isn't actually a "symbol", I'd recommend simply
> encoding it safely (that's probably already the case), and putting it
> in a uniform PMT vector of 8bit integers (u8vector).
>
> On a different note, there's actually "unintended" (as in: I don't
> intend GNU Radio to have an unbounded hash map, but it's at least what
> was originally intended) memory leaks with PMTs and tag_t on the
> Python/C++ boundary, and there's quite some broken concepts within PMT.
>
> Long or medium term, we'll be replacing PMT with something that is
> actually a common serialization format for usage in external software
> (i.e. not for usage within the same flow graph), and ideally with the
> unserialized universal container that comes with such a format. Stay
> tuned. However, not happening in 3.8 or anything before.
>
> Best regards,
> Marcus
>
> On Thu, 2019-02-28 at 14:48 -0500, Brad Hein wrote:
> >
> > In my gnuradio test application I’m attempting to pass a JSON formatted
> string from my C++ custom block, to my python flow graph containing the
> block.
> >
> > The String message are being received by my python flow graph, but
> there’s a memory leak. Over time, my flowgraph RSS (memory footprint) grows
> at about 32k/s up until the application runs out of memory.
> >
> > The leak didn’t start until after I retrofitted my flowgraph and custom
> block with polymorphic type (PMT) based message passing. I’m passing a 200
> or so byte JSON string (as a symbol) from C++ block to python flow graph
> about 60 times per second.
> >
> > Sleuthing through the pmt.cc code [1] I see the String (symbol) objects
> are stored in a hash. I suspect what is happening is that since all of my
> JSON strings are unique, they’re getting added to the hash and causing the
> hash to grow unbounded over time.
> >
> > From what I can tell by reading the wiki [2], the approach I’m using is
> the best way to get a string from my custom block and into my python
> flowgraph.
> >
> > [1]
> https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/pmt/pmt.cc
> > [2] https://www.gnuradio.org/doc/doxygen/page_pmt.html
> >
> >
> > Sample c++ block code snippet from my work function:
> >
> > // Calculate metrics. Occasionally (60/second) we'll get back a JSON
> formatted string of metrics.
> > crossingData = calculateWaveCrossingMetrics(lastSampleValue,in[i]);
> >
> > if (crossingData.length() > 0) {
> > pmt::pmt_t messageString;
> > messageString = pmt::string_to_symbol(crossingData.c_str());
> > message_port_pub(polymorphicMessageDestination, messageString);
> >
> >
> > Questions:
> >
> > 1. Is this the best way to get a string from my C++ block into my
> python application?
> > 2. Is there a way to pass my messages that doesn’t result in memory
> growing unbounded?
> >
> >
> > Thank you
> > Brad
> >
> > ___
> > 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] Messaging Passing on a Budget
In my gnuradio test application I’m attempting to pass a JSON formatted
string from my C++ custom block, to my python flow graph containing the
block.
The String message are being received by my python flow graph, but there’s
a memory leak. Over time, my flowgraph RSS (memory footprint) grows at
about 32k/s up until the application runs out of memory.
The leak didn’t start until after I retrofitted my flowgraph and custom
block with polymorphic type (PMT) based message passing. I’m passing a 200
or so byte JSON string (as a symbol) from C++ block to python flow graph
about 60 times per second.
Sleuthing through the pmt.cc code [1] I see the String (symbol) objects are
stored in a hash. I suspect what is happening is that since all of my JSON
strings are unique, they’re getting added to the hash and causing the hash
to grow unbounded over time.
>From what I can tell by reading the wiki [2], the approach I’m using is the
best way to get a string from my custom block and into my python flowgraph.
[1]
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/pmt/pmt.cc
[2] https://www.gnuradio.org/doc/doxygen/page_pmt.html
Sample c++ block code snippet from my work function:
// Calculate metrics. Occasionally (60/second) we'll get back a JSON
formatted string of metrics.
crossingData = calculateWaveCrossingMetrics(lastSampleValue,in[i]);
if (crossingData.length() > 0) {
pmt::pmt_t messageString;
messageString = pmt::string_to_symbol(crossingData.c_str());
message_port_pub(polymorphicMessageDestination, messageString);
Questions:
1. Is this the best way to get a string from my C++ block into my
python application?
2. Is there a way to pass my messages that doesn’t result in memory
growing unbounded?
Thank you
Brad
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sound card output issue
I see a lot of inputs to the sound card sink in the flowgraph.. could the signal be getting mixed with itself among the many inputs to the card and causing new frequency components as it gets mixed? Can you try sending the flow graph signal to just one sink input at a time (perhaps using a constant source on the others if needed) to try and rule out this possibility? Also this looks like a good card for vlf, hows the noise floor? [Sent from mobile device] On Thu, Jul 19, 2018, 4:49 AM Jean-Michel FRIEDT < jean-michel.fri...@femto-st.fr> wrote: > I have a funny problem with the output of a sound card fed from a signal > source. > The hardware setup is a Scarlett 18i8 sound card sampled at 192 kHz (for > VLF >signal analysis) with the signal generated from the front output number > 1 >(channel number 3 in the GNURadio audio sink). > The sound card is controlled from ALSA. >gr::log :INFO: audio source - Audio sink arch: alsa > The minimalistic flowgraph to reproduce the problem is at >jmfriedt.org/untitled_grc.png > When first launched with an output frequency set to 90 kHz, the sound card > output looks like jmfriedt.org/snd1.png, ie with some spectral component > around 6 kHz whose origin I am unable to identify. If, using the slider, I > change the frequency and set it back to its original value of 90 kHz, I get > the fine output of jmfriedt.org/snd2.png which looks as good as I can > expect from an output frequency so close to the Nyquist frequency. > > Since I want to automate data acquisition over a long duration (ie launch > the python script, collect a few seconds of data, kill the script and > launch > it again a few minutes later, and repeat for a few months or years) the > option > of manually setting the frequency is not acceptable. I cannot think of a > way > to start debugging the problem, whether on ALSA source or the signal > generator > side. Both seem reasonable > > Any hint at which block could be the cause of the issue (there's only > two of them left in the minimalistic GRC graph !). I've read both source > codes and cannot see the difference between the initialization and the > callback function when changing the frequency. > > Thanks, JM > > -- > JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, > 25000 Besancon, France > > > This message was sent using IMP, the Internet Messaging Program. > > > ___ > 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] Custom block not showing up in gnuradio-companion blocks list (but ok in Linux)
Thanks John, Following your suggestion I was able to see that the XML was indeed being installed to /usr/local/ by default. I just needed to change the install prefix with a cmake option (below) and re-install. (I also did a `sudo make uninstall` first). $ sudo make uninstall $ cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/local ../ $ sudo make install Then restarted gnuradio-companion, and there was my block! On Sat, Jun 2, 2018 at 9:32 AM, John Medrano wrote: > You need to check directory " /opt/local/share/gnuradio/grc/blocks" to > see if your xml file is present. > > If it is not, then look at output from "sudo make install" to see if file > is being installed or updated. > > From what it looks like, given that it works in on previous and other > platforms. I suspect file is not being installed. If that is the case, then > you need to look at output from cmake to see if it give any clues as to > why. > > On Sat, Jun 2, 2018 at 12:17 AM, Chris Kuethe > wrote: > >> I think you may be missing the .xml file. >> >> Clearly you've got the python that implements the actual signal >> processing, eg. https://github.com/ckuethe/gr-nmea/blob/master/python/ >> nmea_gpsd.py >> Now you need to show gnuradio-companion how to use it, eg. >> https://github.com/ckuethe/gr-nmea/blob/master/grc/gps_nmea_gpsd.xml >> >> On Sun, May 27, 2018 at 6:16 AM Brad Hein wrote: >> >>> >>> For some reason my custom block won't show up in gnuradio on my mac (but >>> works fine on my Linux servers). I've tried various things over the past >>> few weeks. Not making much progress so posting here to get some >>> suggestions. >>> >>> OS: OSX/Mac High Sierra. >>> gnuradio is installed with Macports, Version 3.7.11. >>> >>> $ which gnuradio-companion >>> /opt/local/bin/gnuradio-companion >>> >>> $ port installed|grep -i gnuradio >>> gnuradio @3.7.11_7+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+ >>> swig+uhd+wavelet+zeromq >>> gnuradio >>> @3.7.11_7+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+wxgui+zeromq >>> (active) >>> >>> My custom block installs elsewhere and even on my previous mac, but not >>> on this new one. Something must be different. >>> >>> $ mkdir build-mac >>> $ cmake ../ >>> $ make >>> [ 8%] Built target gnuradio-powerquality >>> [ 21%] Built target test-powerquality >>> [ 30%] Built target _powerquality_swig_doc_tag >>> [ 39%] Built target powerquality_swig_swig_doc >>> [ 47%] Built target _powerquality_swig_swig_tag >>> [ 69%] Built target powerquality_swig_swig_2d0df >>> [ 78%] Built target pygen_swig_8ae51 >>> [ 86%] Built target _powerquality_swig >>> [ 95%] Built target pygen_python_5cd9b >>> [ 95%] Built target pygen_apps_9a6dd >>> [100%] Built target doxygen_target >>> >>> $ sudo make install >>> [ 8%] Built target gnuradio-powerquality >>> [ 21%] Built target test-powerquality >>> [ 30%] Built target _powerquality_swig_doc_tag >>> [ 39%] Built target powerquality_swig_swig_doc >>> [ 47%] Built target _powerquality_swig_swig_tag >>> [ 69%] Built target powerquality_swig_swig_2d0df >>> [ 78%] Built target pygen_swig_8ae51 >>> [ 86%] Built target _powerquality_swig >>> [ 95%] Built target pygen_python_5cd9b >>> [ 95%] Built target pygen_apps_9a6dd >>> [100%] Built target doxygen_target >>> Install the project... >>> -- Install configuration: "Release" >>> -- Up-to-date: /usr/local/lib/cmake/powerqual >>> ity/powerqualityConfig.cmake >>> -- Up-to-date: /usr/local/include/powerquality/api.h >>> -- Up-to-date: /usr/local/include/powerquality/getfreqcpp.h >>> -- Up-to-date: /usr/local/lib/libgnuradio-powerquality.1.0.0git.dylib >>> -- Up-to-date: /usr/local/lib/libgnuradio-powerquality.dylib >>> -- Up-to-date: /usr/local/lib/python2.7/site- >>> packages/powerquality/_powerquality_swig.so >>> -- Up-to-date: /usr/local/lib/python2.7/site- >>> packages/powerquality/powerquality_swig.py >>> -- Up-to-date: /usr/local/lib/python2.7/site- >>> packages/powerquality/powerquality_swig.pyc >>> -- Up-to-date: /usr/local/lib/python2.7/site- >>> packages/powerquality/powerquality_swig.pyo >>> ...snip... >>> >>> (Start up gnuradio-companion) >>> >>> <<< Welcome to GNU Radio Companion 3.7.11 >>> >>> Block p
[Discuss-gnuradio] Custom block not showing up in gnuradio-companion blocks list (but ok in Linux)
For some reason my custom block won't show up in gnuradio on my mac (but works fine on my Linux servers). I've tried various things over the past few weeks. Not making much progress so posting here to get some suggestions. OS: OSX/Mac High Sierra. gnuradio is installed with Macports, Version 3.7.11. $ which gnuradio-companion /opt/local/bin/gnuradio-companion $ port installed|grep -i gnuradio gnuradio @3.7.11_7+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+zeromq gnuradio @3.7.11_7+docs+grc+jack+log4cpp+logging+portaudio+qtgui+sdl+swig+uhd+wavelet+wxgui+zeromq (active) My custom block installs elsewhere and even on my previous mac, but not on this new one. Something must be different. $ mkdir build-mac $ cmake ../ $ make [ 8%] Built target gnuradio-powerquality [ 21%] Built target test-powerquality [ 30%] Built target _powerquality_swig_doc_tag [ 39%] Built target powerquality_swig_swig_doc [ 47%] Built target _powerquality_swig_swig_tag [ 69%] Built target powerquality_swig_swig_2d0df [ 78%] Built target pygen_swig_8ae51 [ 86%] Built target _powerquality_swig [ 95%] Built target pygen_python_5cd9b [ 95%] Built target pygen_apps_9a6dd [100%] Built target doxygen_target $ sudo make install [ 8%] Built target gnuradio-powerquality [ 21%] Built target test-powerquality [ 30%] Built target _powerquality_swig_doc_tag [ 39%] Built target powerquality_swig_swig_doc [ 47%] Built target _powerquality_swig_swig_tag [ 69%] Built target powerquality_swig_swig_2d0df [ 78%] Built target pygen_swig_8ae51 [ 86%] Built target _powerquality_swig [ 95%] Built target pygen_python_5cd9b [ 95%] Built target pygen_apps_9a6dd [100%] Built target doxygen_target Install the project... -- Install configuration: "Release" -- Up-to-date: /usr/local/lib/cmake/powerquality/powerqualityConfig.cmake -- Up-to-date: /usr/local/include/powerquality/api.h -- Up-to-date: /usr/local/include/powerquality/getfreqcpp.h -- Up-to-date: /usr/local/lib/libgnuradio-powerquality.1.0.0git.dylib -- Up-to-date: /usr/local/lib/libgnuradio-powerquality.dylib -- Up-to-date: /usr/local/lib/python2.7/site-packages/powerquality/_powerquality_swig.so -- Up-to-date: /usr/local/lib/python2.7/site-packages/powerquality/powerquality_swig.py -- Up-to-date: /usr/local/lib/python2.7/site-packages/powerquality/powerquality_swig.pyc -- Up-to-date: /usr/local/lib/python2.7/site-packages/powerquality/powerquality_swig.pyo ...snip... (Start up gnuradio-companion) <<< Welcome to GNU Radio Companion 3.7.11 >>> Block paths: /usr/local/lib/python2.7/site-packages /opt/local/share/gnuradio/grc/blocks gnuradio-companion even lists the precise location where my custom block was installed, as one of the block paths. $ ls -ltrh /usr/local/lib/python2.7/site-packages/powerquality/ total 600 -rw-r--r-- 1 root admin 1.1K Aug 21 2017 __init__.py -rw-r--r-- 1 root admin18K Apr 10 12:37 powerquality_swig.py -rw-r--r-- 1 root admin27K Apr 10 12:37 powerquality_swig.pyo -rw-r--r-- 1 root admin27K Apr 10 12:37 powerquality_swig.pyc -rwxr-xr-x 1 root admin 210K Apr 10 12:37 _powerquality_swig.so -rw-r--r-- 1 root admin 369B Apr 10 12:37 __init__.pyo -rw-r--r-- 1 root admin 369B Apr 10 12:37 __init__.pyc But the block (block name getfreqcpp) is not showing up in the list... At the commandline I can import the block in Python. $ python Python 2.7.10 (default, Oct 6 2017, 22:29:07) [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import powerquality >>> from powerquality import getfreqcpp >>> getfreqcpp >>> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gnuradio + ZeroMQ = win!
Just a follow up to some of the issues I reported recently with the Socket PDU blocks.. Switching to ZeroMQ (ZMQ) based source and sink blocks for flowgraph-to-flowgraph communications has eliminated all of the issues I was encountering. Thanks to those who suggested trying zmq. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting gnuradio to compile with zeromq
You're a genius!! [root@sdr ~]# find / -name zmq.hpp [root@sdr ~]# yum provides "*/zmq.hpp" cppzmq-devel-4.1.4-5.el7.x86_64 : Development files for cppzmq Repo: epel Matched from: Filename: /usr/include/zmq.hpp *# yum install cppzmq-devel* [root@sdr ~]# rpm -ql cppzmq-devel /usr/include/zmq.hpp /usr/share/licenses/cppzmq-devel-4.1.4 /usr/share/licenses/cppzmq-devel-4.1.4/LICENSE cmake... -- ## -- # Gnuradio disabled components -- ## -- * sphinx -- * gr-comedi -- * gr-video-sdl On Wed, May 9, 2018 at 12:33 PM, Müller, Marcus (CEL) <muel...@kit.edu> wrote: > Hi Brad, > > changing the pythonpath shouldn't change the path in which CMake looks > for include files and libraries, at all. > > Can you check whether your /usr/include has some zmq.hpp ? > Debian just throws that C++ wrapper for C zeromq into the zeromq-devel > package (without any documentation which version they use ... g), > but other distros don't, and you might need to manually add that header > to your system's include path. It's a single, isolated header file, so > you can just download it from github and add it. > > Best regards, > Marcus > > On Wed, 2018-05-09 at 12:00 -0400, Brad Hein wrote: > > > > I'm unable to get the gnuradio cmake process to recognize that I have > zeromq installed. Every time I run cmake it ends up with gr-zeromq > disabled. I tried installing zeromq and zeromq-devel version 4 (yum install > zeromq zeromq-dev) but that didn't help. I also tried uninstalling the > default version 4 and installing the zeromq and zeromq-dev version 3 > packages, still cmake wouldn't detect zeromq. > > > > OS: CentOS 7.4 with all updates. X86_64 VM. > > > > gnuradio: latest code, master branch. current comit: > > * 82d0a6b -(4 weeks ago) gr-newmod: Pylint fixes in python scripts . > Swapnil Negi (HEAD, origin/master, origin/HEAD, master) > > > > > > One thing I noticed is that gnuradio defaults my install prefix to > /usr/local (/usr/local/lib64 for example) which leads to me having to set > my pythonpath manually... maybe nothing... but I wonder if the cmake > process is looking under /usr/local/lib64 for the zeromq libraries instead > of /usr/lib64? not sure. > > > > I've done some googling but I'm coming up empty handed in terms of > getting gnuradio to compile with zeromq. > > > > I'm on the gnuradio master branch. > > > > -- Configuring gr-zeromq support... > > -- Dependency Boost_FOUND = 1 > > -- Dependency ENABLE_GNURADIO_RUNTIME = ON > > -- Dependency ZEROMQ_FOUND = FALSE > > CMake Error at cmake/Modules/GrComponent.cmake:75 (message): > > user force-enabled gr-zeromq but configuration checked failed > > Call Stack (most recent call first): > > gr-zeromq/CMakeLists.txt:32 (GR_REGISTER_COMPONENT) > > > > -- Configuring incomplete, errors occurred! > > See also "/home/brad/gr/gnuradio/build/CMakeFiles/CMakeOutput.log". > > See also "/home/brad/gr/gnuradio/build/CMakeFiles/CMakeError.log". > > > > > > Looking through the cmake error log file mentioned above there are > strangely no references to zeromq. > > > > > > > > > > ___ > > 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] Raspberry Pi 3 / Error: selected processor does not support ARM mode
Thanks Marcus, I spent an hour reading all about BSP last night and it looks quite fascinating. The learning curve looks step, so blog tutorials definitely make sense. With that said, that doesn't do anything for me and my Raspberry Pi 3 that's facing compile errors :) On Wed, May 9, 2018 at 12:53 PM, Müller, Marcus (CEL) <muel...@kit.edu> wrote: > Hi Brad, > > to jump in and clarify what Phil probably could've said in a lot fewer > words, but for didn't ;) : > > Philip is an OpenEmbedded Guru of ancient fame. Basically, OpenEmbedded > is a system to build your own linux distros, by defining what > compilers, libraries, and tools to include in the base image. > It's what whoever built the Linux system in your car entertainment box, > your industrial control or USRP E310 might have been using to get Linux > and their software running on the boxes they're selling. > > The idea is that you build yourself a full system image and tooling, > including an SDK that you can use to cross-compile software for the > target system (in your case, the pi), on your workstation. > > A BSP is a board support package, and contains what is necessary to > know how build a correctly working kernel and base system. The meta- > raspberrypi thing is essentially the base system, atop of which you can > add packages (such as GNU Radio) to be compiled exactly for your > hardware. > > Best regards, > Marcus > > On Tue, 2018-05-08 at 23:58 -0400, Brad Hein wrote: > > I don't follow... but I look forward to reading your blog post when it > is available. > > > > On Tue, May 8, 2018 at 6:37 PM, Philip Balister <phi...@balister.org> > wrote: > > > On 05/08/2018 04:13 PM, Brad Hein wrote: > > > > Hi Philip, > > > > > > > > How do I go a out trying an alternative as you suggest? > > > > > > I have a note to do a blog post on building an aarch64 image with > > > OpenEmbedded, but paying work is interfering. It is fairly straight > > > forward the meta-raspberrypi bsp is very good. > > > > > > Philip > > > > > > > > > > > Thanks! > > > > > > > > [Sent from mobile device] > > > > > > > > On Tue, May 8, 2018, 6:07 PM Philip Balister <phi...@balister.org> > wrote: > > > > > > > >> I'm not that familiar wit Raspian, but my impression is that it is > > > >> binary compatible with the original Pi, which has no neon support. > The > > > >> volk code didn't handle this gracefully until recently. > > > >> > > > >> That said, The Pi 3 does support neon and better. For the Pi-3, I'd > use > > > >> something built to take advantage of the better processor. > > > >> > > > >> Philip > > > >> > > > >> > > > >> On 05/08/2018 11:08 AM, Brad Hein wrote: > > > >>> On a new Raspberry Pi 3, running Raspbian, all apt-get package > updates > > > >>> loaded, I'm encountering an error compiling gnuradio (branch: > master). I > > > >>> made one modification from the default source code, and that is the > > > >> neonasm > > > >>> patch to fix a different compile error with a missing instruction > on the > > > >>> Pi. > > > >>> > > > >>> Has anybody encountered the ARM mode error mentioned below or know > what I > > > >>> can do to push past it? > > > >>> > > > >>> > > > >>> $ git diff HEAD~1 > > > >>> diff --git > > > >>> a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s > > > >>> b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s > > > >>> index e4002b8..37dcd75 100644 > > > >>> --- a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_ > opts.s > > > >>> +++ b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_ > opts.s > > > >>> @@ -43,7 +43,12 @@ volk_32f_x2_dot_prod_32f_a_neonasm_opts: > > > >>> vadd.f32 s15, s15, s13 > > > >>> vadd.f32 s15, s15, s14 > > > >>> bls.done @ if vector is multiple of 16 then > finish > > > >>> - sbfx r11, r1, #2, #1 @ check alignment > > > >>> +@ BH > > > >>> > > > >> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/ > msg00234.html > > > >>> +@ sbfx r1
[Discuss-gnuradio] Getting gnuradio to compile with zeromq
I'm unable to get the gnuradio cmake process to recognize that I have zeromq installed. Every time I run cmake it ends up with gr-zeromq disabled. I tried installing zeromq and zeromq-devel version 4 (yum install zeromq zeromq-dev) but that didn't help. I also tried uninstalling the default version 4 and installing the zeromq and zeromq-dev version 3 packages, still cmake wouldn't detect zeromq. OS: CentOS 7.4 with all updates. X86_64 VM. gnuradio: latest code, master branch. current comit: * 82d0a6b -(4 weeks ago) gr-newmod: Pylint fixes in python scripts . Swapnil Negi (HEAD, origin/master, origin/HEAD, master) One thing I noticed is that gnuradio defaults my install prefix to /usr/local (/usr/local/lib64 for example) which leads to me having to set my pythonpath manually... maybe nothing... but I wonder if the cmake process is looking under /usr/local/lib64 for the zeromq libraries instead of /usr/lib64? not sure. I've done some googling but I'm coming up empty handed in terms of getting gnuradio to compile with zeromq. I'm on the gnuradio master branch. -- Configuring gr-zeromq support... -- Dependency Boost_FOUND = 1 -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ZEROMQ_FOUND = FALSE CMake Error at cmake/Modules/GrComponent.cmake:75 (message): user force-enabled gr-zeromq but configuration checked failed Call Stack (most recent call first): gr-zeromq/CMakeLists.txt:32 (GR_REGISTER_COMPONENT) -- Configuring incomplete, errors occurred! See also "/home/brad/gr/gnuradio/build/CMakeFiles/CMakeOutput.log". See also "/home/brad/gr/gnuradio/build/CMakeFiles/CMakeError.log". Looking through the cmake error log file mentioned above there are strangely no references to zeromq. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Raspberry Pi 3 / Error: selected processor does not support ARM mode
I don't follow... but I look forward to reading your blog post when it is available. On Tue, May 8, 2018 at 6:37 PM, Philip Balister <phi...@balister.org> wrote: > On 05/08/2018 04:13 PM, Brad Hein wrote: > > Hi Philip, > > > > How do I go a out trying an alternative as you suggest? > > I have a note to do a blog post on building an aarch64 image with > OpenEmbedded, but paying work is interfering. It is fairly straight > forward the meta-raspberrypi bsp is very good. > > Philip > > > > > Thanks! > > > > [Sent from mobile device] > > > > On Tue, May 8, 2018, 6:07 PM Philip Balister <phi...@balister.org> > wrote: > > > >> I'm not that familiar wit Raspian, but my impression is that it is > >> binary compatible with the original Pi, which has no neon support. The > >> volk code didn't handle this gracefully until recently. > >> > >> That said, The Pi 3 does support neon and better. For the Pi-3, I'd use > >> something built to take advantage of the better processor. > >> > >> Philip > >> > >> > >> On 05/08/2018 11:08 AM, Brad Hein wrote: > >>> On a new Raspberry Pi 3, running Raspbian, all apt-get package updates > >>> loaded, I'm encountering an error compiling gnuradio (branch: master). > I > >>> made one modification from the default source code, and that is the > >> neonasm > >>> patch to fix a different compile error with a missing instruction on > the > >>> Pi. > >>> > >>> Has anybody encountered the ARM mode error mentioned below or know > what I > >>> can do to push past it? > >>> > >>> > >>> $ git diff HEAD~1 > >>> diff --git > >>> a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s > >>> b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s > >>> index e4002b8..37dcd75 100644 > >>> --- a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s > >>> +++ b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s > >>> @@ -43,7 +43,12 @@ volk_32f_x2_dot_prod_32f_a_neonasm_opts: > >>> vadd.f32 s15, s15, s13 > >>> vadd.f32 s15, s15, s14 > >>> bls.done @ if vector is multiple of 16 then finish > >>> - sbfx r11, r1, #2, #1 @ check alignment > >>> +@ BH > >>> > >> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/ > msg00234.html > >>> +@ sbfx r11, r1, #2, #1 @ check alignment > >>> + mov r11,#0 > >>> + tst r1,#4 > >>> + movner11,#15 > >>> +# BH END OF PATCH > >>> rsbr9, r8, r3 > >>> andr11, r11, #3 > >>> movr6, r1 > >>> > >>> > >>> > >>> $ cat /etc/debian_version > >>> 8.0 > >>> > >>> > >>> $ uname -a > >>> Linux redwave 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l > >>> GNU/Linux > >>> > >>> $ gnuradio branch: master (82d0a6b) > >>> * 82d0a6b -(4 weeks ago) gr-newmod: Pylint fixes in python scripts . > >>> Swapnil Negi (HEAD, origin/master, origin/HEAD, master) > >>> > >>> > >>> > >>> Error output follows: > >>> > >>> [ 0%] Building C object > >>> volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o > >>> In file included from > >>> /home/pi/gr/gnuradio/build/volk/lib/volk_machine_neon_ > hardfp_orc.c:130:0: > >>> /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_ > multiply_32fc.h: > >> In > >>> function ‘volk_32fc_s32fc_multiply_32fc_neon’: > >>> > >> /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_ > multiply_32fc.h:282:16: > >>> warning: unused variable ‘cPtr’ [-Wunused-variable] > >>> lv_32fc_t* cPtr = cVector; > >>> ^ > >>> /tmp/ccWuy8Qj.s: Assembler messages: > >>> /tmp/ccWuy8Qj.s:7707: Error: selected processor does not support ARM > mode > >>> `rbit r4,r4' > >>> /tmp/ccWuy8Qj.s:7718: Error: selected processor does not support ARM > mode > >>> `rbit r4,r4' > >>> /tmp/ccWuy8Qj.s:7725: Error: selected processor does not support ARM > mode > >>> `rbit r4,r4' > >>> /tmp/ccWuy8Qj.s:7732:
[Discuss-gnuradio] I miss the TCP server and client blocks!
Trying to get the socket PDU blocks to send and receive a stream of data is proving to be a significant challenge. I miss the simplicity and reliability of the TCP server and client blocks - they always "just worked" for me. I don't understand why they were deprecated only to leave us with these buggy and difficult to use socket PDU blocks. Sorry for the rant, I'm just running into one problem after another trying to get two flowgraphs to communicate using the socket PDU blocks (issue IDs 1770,1769,1763,1762). These new ZeroMQ blocks look cool. Are they a good alternative? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Raspberry Pi 3 / Error: selected processor does not support ARM mode
Hi Philip, How do I go a out trying an alternative as you suggest? Thanks! [Sent from mobile device] On Tue, May 8, 2018, 6:07 PM Philip Balister <phi...@balister.org> wrote: > I'm not that familiar wit Raspian, but my impression is that it is > binary compatible with the original Pi, which has no neon support. The > volk code didn't handle this gracefully until recently. > > That said, The Pi 3 does support neon and better. For the Pi-3, I'd use > something built to take advantage of the better processor. > > Philip > > > On 05/08/2018 11:08 AM, Brad Hein wrote: > > On a new Raspberry Pi 3, running Raspbian, all apt-get package updates > > loaded, I'm encountering an error compiling gnuradio (branch: master). I > > made one modification from the default source code, and that is the > neonasm > > patch to fix a different compile error with a missing instruction on the > > Pi. > > > > Has anybody encountered the ARM mode error mentioned below or know what I > > can do to push past it? > > > > > > $ git diff HEAD~1 > > diff --git > > a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s > > b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s > > index e4002b8..37dcd75 100644 > > --- a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s > > +++ b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s > > @@ -43,7 +43,12 @@ volk_32f_x2_dot_prod_32f_a_neonasm_opts: > > vadd.f32 s15, s15, s13 > > vadd.f32 s15, s15, s14 > > bls.done @ if vector is multiple of 16 then finish > > - sbfx r11, r1, #2, #1 @ check alignment > > +@ BH > > > https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00234.html > > +@ sbfx r11, r1, #2, #1 @ check alignment > > + mov r11,#0 > > + tst r1,#4 > > + movner11,#15 > > +# BH END OF PATCH > > rsbr9, r8, r3 > > andr11, r11, #3 > > movr6, r1 > > > > > > > > $ cat /etc/debian_version > > 8.0 > > > > > > $ uname -a > > Linux redwave 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l > > GNU/Linux > > > > $ gnuradio branch: master (82d0a6b) > > * 82d0a6b -(4 weeks ago) gr-newmod: Pylint fixes in python scripts . > > Swapnil Negi (HEAD, origin/master, origin/HEAD, master) > > > > > > > > Error output follows: > > > > [ 0%] Building C object > > volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o > > In file included from > > /home/pi/gr/gnuradio/build/volk/lib/volk_machine_neon_hardfp_orc.c:130:0: > > /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_multiply_32fc.h: > In > > function ‘volk_32fc_s32fc_multiply_32fc_neon’: > > > /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_multiply_32fc.h:282:16: > > warning: unused variable ‘cPtr’ [-Wunused-variable] > > lv_32fc_t* cPtr = cVector; > > ^ > > /tmp/ccWuy8Qj.s: Assembler messages: > > /tmp/ccWuy8Qj.s:7707: Error: selected processor does not support ARM mode > > `rbit r4,r4' > > /tmp/ccWuy8Qj.s:7718: Error: selected processor does not support ARM mode > > `rbit r4,r4' > > /tmp/ccWuy8Qj.s:7725: Error: selected processor does not support ARM mode > > `rbit r4,r4' > > /tmp/ccWuy8Qj.s:7732: Error: selected processor does not support ARM mode > > `rbit r4,r4' > > /tmp/ccWuy8Qj.s:7740: Error: selected processor does not support ARM mode > > `rbit r4,r4' > > /tmp/ccWuy8Qj.s:7747: Error: selected processor does not support ARM mode > > `rbit r4,r4' > > /tmp/ccWuy8Qj.s:7754: Error: selected processor does not support ARM mode > > `rbit r4,r4' > > /tmp/ccWuy8Qj.s:7761: Error: selected processor does not support ARM mode > > `rbit r4,r4' > > /tmp/ccWuy8Qj.s:7789: Error: selected processor does not support ARM mode > > `rbit ip,ip' > > volk/lib/CMakeFiles/volk_obj.dir/build.make:2572: recipe for target > > 'volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o' > failed > > make[2]: *** > > [volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o] > Error 1 > > CMakeFiles/Makefile2:178: recipe for target > > 'volk/lib/CMakeFiles/volk_obj.dir/all' failed > > make[1]: *** [volk/lib/CMakeFiles/volk_obj.dir/all] Error 2 > > Makefile:160: recipe for target 'all' failed > > make: *** [all] Error 2 > > > > > > > > ___ > > 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] Raspberry Pi 3 / Error: selected processor does not support ARM mode
On a new Raspberry Pi 3, running Raspbian, all apt-get package updates loaded, I'm encountering an error compiling gnuradio (branch: master). I made one modification from the default source code, and that is the neonasm patch to fix a different compile error with a missing instruction on the Pi. Has anybody encountered the ARM mode error mentioned below or know what I can do to push past it? $ git diff HEAD~1 diff --git a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s index e4002b8..37dcd75 100644 --- a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s +++ b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s @@ -43,7 +43,12 @@ volk_32f_x2_dot_prod_32f_a_neonasm_opts: vadd.f32 s15, s15, s13 vadd.f32 s15, s15, s14 bls.done @ if vector is multiple of 16 then finish - sbfx r11, r1, #2, #1 @ check alignment +@ BH https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00234.html +@ sbfx r11, r1, #2, #1 @ check alignment + mov r11,#0 + tst r1,#4 + movner11,#15 +# BH END OF PATCH rsbr9, r8, r3 andr11, r11, #3 movr6, r1 $ cat /etc/debian_version 8.0 $ uname -a Linux redwave 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux $ gnuradio branch: master (82d0a6b) * 82d0a6b -(4 weeks ago) gr-newmod: Pylint fixes in python scripts . Swapnil Negi (HEAD, origin/master, origin/HEAD, master) Error output follows: [ 0%] Building C object volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o In file included from /home/pi/gr/gnuradio/build/volk/lib/volk_machine_neon_hardfp_orc.c:130:0: /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_multiply_32fc.h: In function ‘volk_32fc_s32fc_multiply_32fc_neon’: /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_multiply_32fc.h:282:16: warning: unused variable ‘cPtr’ [-Wunused-variable] lv_32fc_t* cPtr = cVector; ^ /tmp/ccWuy8Qj.s: Assembler messages: /tmp/ccWuy8Qj.s:7707: Error: selected processor does not support ARM mode `rbit r4,r4' /tmp/ccWuy8Qj.s:7718: Error: selected processor does not support ARM mode `rbit r4,r4' /tmp/ccWuy8Qj.s:7725: Error: selected processor does not support ARM mode `rbit r4,r4' /tmp/ccWuy8Qj.s:7732: Error: selected processor does not support ARM mode `rbit r4,r4' /tmp/ccWuy8Qj.s:7740: Error: selected processor does not support ARM mode `rbit r4,r4' /tmp/ccWuy8Qj.s:7747: Error: selected processor does not support ARM mode `rbit r4,r4' /tmp/ccWuy8Qj.s:7754: Error: selected processor does not support ARM mode `rbit r4,r4' /tmp/ccWuy8Qj.s:7761: Error: selected processor does not support ARM mode `rbit r4,r4' /tmp/ccWuy8Qj.s:7789: Error: selected processor does not support ARM mode `rbit ip,ip' volk/lib/CMakeFiles/volk_obj.dir/build.make:2572: recipe for target 'volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o' failed make[2]: *** [volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o] Error 1 CMakeFiles/Makefile2:178: recipe for target 'volk/lib/CMakeFiles/volk_obj.dir/all' failed make[1]: *** [volk/lib/CMakeFiles/volk_obj.dir/all] Error 2 Makefile:160: recipe for target 'all' failed make: *** [all] Error 2 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] vector sink "malloc(): memory corruption" / object was probably modified after being freed
I'll do my best, but it might take me quite some time to get gdb set up with the symbols you mentioned. C++/debugging doesn't come naturally for me. What it smells like to me is memory is being freed but then written to. Then when the system goes to allocate memory it says hey that memory isn't so free because it's still being written to (freed memory checksum mismatch).. And it isn't until the crime has been discovered at the time of m'allocation that an exception is thrown. Correct me if I'm wrong but the real problem (leak?) would be some to many instructions prior to the malloc exception triggered at the time of discovery? The lead suspect in the case seems to be the vector sink. I know using vector sink blocks is shunned and I feel very naughty for doing so but it is making it possible for me to do significant research without having to deep dive into C++. I'll try and think of some clever test cases to put the vector sink through its paces to trigger the error in a different context., On Mon, Apr 30, 2018 at 1:28 PM, Müller, Marcus (CEL) <muel...@kit.edu> wrote: > Ah, by the way, the function names where that error occurs are mangled > C++ names; I'll try to show what is what (using `c++filt` to demangle > the names) > > > /lib64/libc.so.6(+0x7dd4d)[0x7fa14f448d4d] > > /lib64/libc.so.6(__libc_malloc+0x4c)[0x7fa14f44afbc] > OK, that's malloc; are we certain that this has anything to do with > `free`? > > /lib64/libstdc++.so.6(_Znwm+0x1d)[0x7fa145c0e0cd] > "operator new(unsigned long)" > so, we're reserving space. Which calls malloc. Makes sense > > /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/ > _blocks_swig1.so(_ZNSt6vectorIfSaIfEEaSERKS1_+0xd4)[0x7fa13df58e64] > "std::vector<float, std::allocator > >::operator=(std::vector<float, std::allocator > const&)" > > Assignment operator on a std::vector! > > > /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/ > _blocks_swig1.so(+0x12c8a0)[0x7fa13deea8a0] > > So, we are indeed in gr-blocks; but since this is the first frame > called from libpython that isn't libpython, it's likely just SWIG > wrapper code, not our own code (which doesn't imply our code isn't the > one that's buggy here). In other words: This might be the place where > SWIG or you *assign* something to something preallocated. Strange! > > The rest is just python internals: > > /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6df0)[0x7fa150195af0] > > /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd] > > /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd] > > /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7fa150197e3d] > > /lib64/libpython2.7.so.1.0(+0x7088d)[0x7fa15012188d] > > /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3] > > /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x17fd)[0x7fa1501904fd] > > /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd] > > /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd] > > /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7fa150197e3d] > > /lib64/libpython2.7.so.1.0(+0x70798)[0x7fa150121798] > > /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3] > > /lib64/libpython2.7.so.1.0(+0x5a8d5)[0x7fa15010b8d5] > > /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3] > > /lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+ > 0x47)[0x7fa15018e6f7] > > /lib64/libpython2.7.so.1.0(+0x1155c2)[0x7fa1501c65c2] > > /lib64/libpthread.so.0(+0x7dc5)[0x7fa14fe9cdc5] > > /lib64/libc.so.6(clone+0x6d)[0x7fa14f4c276d] > > If this problem persists, I'd be very interested in you running the > flowgraph in GDB, e.g. > > gdb --args python2 /path/to/your/fg.py > ... > (gdb)run > ... > crash > ... > (gdb)backtrace > > The backtrace would be even more useful if your GDB knows the python > debug symbols, and maybe even has the scripting in place to interleave > Python state with the back trace (since we then would even see which > Python line was being executed, as well as the state of the python > interpreter). > > Best regards, > Marcus > > On Mon, 2018-04-30 at 17:16 +, Müller, Marcus (CEL) wrote: > > Hi Brad, > > > > Sorry that I missed your mail for so long! > > So, I'm pretty certain I've fixed a potential race condition when > > accessing the data vector in vector sink lately: > > > > https://github.com/gnuradio/gnuradio/pull/1445 > > > > But that should be included in the 3.7.11.1 release you're using... hm. > > > > We should probably be looking into what happens in reset(), right? > > > > Best regards, > > Marcus > > &g
Re: [Discuss-gnuradio] nan error from wavfile sink coupled with delayed input data
In an effort to simplify this a bit, I created two flow graphs. One as the server (dial tone frequencies sent to socket PDU) and a client (unpack the socket data and send it to wav file sink). I was able to recreate the issue with these simplified blocks when their TCP/IP path traverses the internet. In order to post images and a better description I posted the issue on SO: https://stackoverflow.com/questions/50119704/wavfile-sink-value-nan-can-not-be-represented-in-the-target-integer-type On Mon, Apr 30, 2018 at 1:33 PM, Müller, Marcus (CEL) <muel...@kit.edu> wrote: > Huh, no, barring great undiscovered bugs, the delay involved shouldn't > have anything to do with the data, and the error pretty certainly has > something to do with invalid input data. > Are you sure the data is always the same? > > Best regards, > Marcus > > On Thu, 2018-04-12 at 11:03 -0400, Brad Hein wrote: > > > > error: > > thread[thread-per-block[22]: ]: Error in > function boost::math::round(f): Value nan can not be represented in the > target integer type. > > > > I have a flow graph that's connecting to a remote host on a TCP port > using the socket PDU. The flow graph is relatively simple and outputs a > derivative of the stream that it gets to a wav file sink. > > > > [data source (48khz floating point data stream using socket PDU)] ---> > TCP/internet ---> [destination flowgraph] ---> wavfile sink (stdout). > > > > When I run the flow graph against the source locally (<5ms ping time) it > works fine. But when I run the flow graph against a remote host that's 20ms > away I get the above error 99% of the time. > > > > I have a hunch that what's happening is that the flow graph initializes > and starts to try and send data to the wavfile sink BEFORE the socket PDU > starts receiving data from the remote host. If this is the case, I would > like to adapt the flowgraph to better handle the arbitrary delay of data > coming into the flow graph. > > > > I'm looking for suggestions for what sort of block or blocks I can add > to help the flow graph better handle the delayed start of data coming into > the flowgraph from the socket pdu block. > > > > Thanks! > > > > > > ___ > > 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] vector sink "malloc(): memory corruption" / object was probably modified after being freed
The Vector Sink is coming in very handy for some experimentation I'm doing. I'm analyzing the output of an FFT block which terminates into a float vector sink. every few seconds from a thread which then calls reset() to clear the contents in preparation for another read. This seems problematic as the program crashes quite frequently after seconds to minutes of operation. Based on my layman's perspective it seems to be a memory leak in the vector block. I tried many things over the last couple of days. Nothing seems to mitigate it. For example self.lock and self.unlock to lock the flowgraph before reading from the vector (results in flowgraph never starting back up, seems to be a whole different issue)... I tried using python copy.deepcopy to make a copy of the vector contents before using it but that didn't help eiehter. When the exception occurs, it seems to happen right after resetting the vector sink. My flowgraph doesn't run standalone and requires a number of other applications to function but I'll work on getting it up to github for review if that helps Gnuradio 3.7.11.1 on a CentOS VM (Linux 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux) BTW when the exception occurs on OSX the error is: Python(86100,0x7eab9000) malloc: *** error for object 0x7f94bf9042b8: incorrect checksum for freed object - object was probably modified after being freed. Stack Trace samples from Linux (they are all quite similar to eachother with only slight differences in the addresses): *** Error in `python': malloc(): memory corruption: 0x7fa0cc019ba0 *** === Backtrace: = /lib64/libc.so.6(+0x7dd4d)[0x7fa14f448d4d] /lib64/libc.so.6(__libc_malloc+0x4c)[0x7fa14f44afbc] /lib64/libstdc++.so.6(_Znwm+0x1d)[0x7fa145c0e0cd] /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(_ZNSt6vectorIfSaIfEEaSERKS1_+0xd4)[0x7fa13df58e64] /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(+0x12c8a0)[0x7fa13deea8a0] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6df0)[0x7fa150195af0] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd] /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7fa150197e3d] /lib64/libpython2.7.so.1.0(+0x7088d)[0x7fa15012188d] /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x17fd)[0x7fa1501904fd] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd] /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7fa150197e3d] /lib64/libpython2.7.so.1.0(+0x70798)[0x7fa150121798] /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3] /lib64/libpython2.7.so.1.0(+0x5a8d5)[0x7fa15010b8d5] /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3] /lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7fa15018e6f7] /lib64/libpython2.7.so.1.0(+0x1155c2)[0x7fa1501c65c2] /lib64/libpthread.so.0(+0x7dc5)[0x7fa14fe9cdc5] /lib64/libc.so.6(clone+0x6d)[0x7fa14f4c276d] === Memory map: 0040-00401000 r-xp fd:00 242126 /usr/bin/python2.7 0060-00601000 r--p fd:00 242126 /usr/bin/python2.7 -- *** Error in `python': malloc(): memory corruption: 0x7f03ac00f640 *** === Backtrace: = /lib64/libc.so.6(+0x7dd4d)[0x7f04382b6d4d] /lib64/libc.so.6(__libc_malloc+0x4c)[0x7f04382b8fbc] /lib64/libstdc++.so.6(_Znwm+0x1d)[0x7f042ea7c0cd] /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(_ZNSt6vectorIfSaIfEEaSERKS1_+0xd4)[0x7f0426dc6e64] /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(+0x12c8a0)[0x7f0426d588a0] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6df0)[0x7f0439003af0] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7f04390034bd] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7f04390034bd] /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7f0439005e3d] /lib64/libpython2.7.so.1.0(+0x7088d)[0x7f0438f8f88d] /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f0438f6a8e3] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x17fd)[0x7f0438ffe4fd] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7f04390034bd] /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7f04390034bd] /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7f0439005e3d] /lib64/libpython2.7.so.1.0(+0x70798)[0x7f0438f8f798] /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f0438f6a8e3] /lib64/libpython2.7.so.1.0(+0x5a8d5)[0x7f0438f798d5] /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f0438f6a8e3] /lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7f0438ffc6f7] /lib64/libpython2.7.so.1.0(+0x1155c2)[0x7f04390345c2] /lib64/libpthread.so.0(+0x7dc5)[0x7f0438d0adc5] /lib64/libc.so.6(clone+0x6d)[0x7f043833076d] === Memory map: 0040-00401000 r-xp fd:00 242126
[Discuss-gnuradio] nan error from wavfile sink coupled with delayed input data
error: thread[thread-per-block[22]: ]: Error in function boost::math::round(f): Value nan can not be represented in the target integer type. I have a flow graph that's connecting to a remote host on a TCP port using the socket PDU. The flow graph is relatively simple and outputs a derivative of the stream that it gets to a wav file sink. [data source (48khz floating point data stream using socket PDU)] ---> TCP/internet ---> [destination flowgraph] ---> wavfile sink (stdout). When I run the flow graph against the source locally (<5ms ping time) it works fine. But when I run the flow graph against a remote host that's 20ms away I get the above error 99% of the time. I have a hunch that what's happening is that the flow graph initializes and starts to try and send data to the wavfile sink BEFORE the socket PDU starts receiving data from the remote host. If this is the case, I would like to adapt the flowgraph to better handle the arbitrary delay of data coming into the flow graph. I'm looking for suggestions for what sort of block or blocks I can add to help the flow graph better handle the delayed start of data coming into the flowgraph from the socket pdu block. Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Floating point FFT usage - suppress half of it?
A few final clarifying questions, inline below: On Sun, Mar 18, 2018 at 8:35 PM, Maximilian Stiefel < stiefel.maximil...@online.de> wrote: > Hi Brad, > > > Taking a step back, maybe the mirroring is a product of the method I'm > > using to interpret the output of the FFT. > > I really do not think so, because, as explained below and in the previous > mail, the phenomenon, we witness here, results from the physics behind > signal theory. > > As I understand your code, you are calculating the Energy Spectrum Density > (ESD), because you take the square of the magnitude of the FFT. The ESD > gives you the energy distribution of the signal over the spectrum. > > https://en.wikipedia.org/wiki/Spectral_density#Definition > > It is legitimate to design audio signal analysis like that, from my point > of view. To interpret your results one can say, that the ESD (let's call it > Psi(w)) has the following properties: > > Psi(w) = Psi(-w) (even) > Psi(w) >= 0 > > This properties also accord to what I explained in my previous mail. A > "natural real signal" such as the output from your wave file consists out > of an odd and even part i.e. > > s(t) = se(t) + so(t). > > We said, that the even part corresponds to an even real part in the > frequency domain and the odd part corresponds to an odd imaginary part in > the frequency domain. However, by taking the square of the FFT's magnitude > (this is what I saw in your code) you will make the whole spectrum even and > real e.g. > > ( j*sin(x) )^2 = -sin^2(x) > ^ ^ > odd and imaginary even and real > > Thus, your output corresponds to the underlying physics. > > > If we listen to a dial tone recording for example, we can clearly tell > > that two and only two tones are present. Is FFT able to tell us the same > > thing (exactly two spikes, at expected frequencies) if given floating > > point samples rather than complex? (Tried this using wx gui FFT plot > > and I don't see mirroring, does the WX GUI FFT suppress the mirroring?) > > Yes, the DFT/FFT/"Fourier transform of the signal" is exactly what you > need. Bin [-512 to -1] are the negative frequencies (which you do not seem > to be interested in) and bin [0 to 511] are the positive frequencies you > want evaluate. > > The sharpness of the frequency peaks you are expecting has something to do > with the window you are using. I saw you used a Blackman-Harris window. Try > playing around a bit with this setscrew if you are not happy with your > results. > Thank you for the suggestion! > > Two further comments: > > 1) If your application is about loudness as perceived by humans you have > to introduce a model for the ear as we do not hear linearly. > This is a good point that I will keep in mind, although my application of this work is not intended for comparison with perceived amplitude, it may be useful to process it that way so I will look into it. > > 2) It is impressive how you visualize your ESD on console, but why are you > not using the mighty QT GUI Time Sink or a python plotting library like > matplotlib to plot your result? (Played around with it recently > https://gist.github.com/m3x1m0m/1d524d560ff2f3e0702ca6c5d73bcff1) > > Thank you for the kind suggestion - I haven't explored the QT UI much but I tried the time sink and found it useful. I went with ascii art initially so that I could gain an intimate familiarity with the vector sink and its behavior. I have to confess I am struggling with the math descriptions provided. If I may, I would like to ask a few questions simplified into terms that I I think I can understand the responses to: - Is it true then that if I have a 100-bin FFT, that each of the "left 50" equals the negative of its corresponding right-side bin? - Is there any use for "negative frequencies" if my goal is to simply measure the ESD for each of the frequency bins? - If I want to get 48 usable frequency bands, each corresponding to a 0-1k, 1k-2k, 2k-3k, etc do I actually need a 96 bin FFT due to the mirroring? - Do the negative frequencies correspond to a phase difference compared to the positive frequencies - in other words if I have two 2600Hz signals that are out of phase by 180 degrees, would this be reflected in the negative vs positive bin associated with 2600Hz? Thanks! Brad > Regards, > > Max > > ___ > 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] Floating point FFT usage - suppress half of it?
to get around the negative frequencies to be calculated. Indeed, it is an interesting question, though. Regards, Max On 2018-03-18 15:17, Müller, Marcus (CEL) wrote: > Hi Brad, > > Put another way, is it safe to >> discard the left side of the output as it appears to consist only of >> aliases of the true data? >> > > Well, it does not contain information that's not in the other side > (it's not really an alias, though, but the conjugate mirror of the > other side). > > best way to recover the useful information from the FFT >> > > What's the thing you want to achieve? Because "useful" and "best" are > meaningless without knowing what you want to do! :) > > Regarding the numerical inefficiency of computing both sides of > something symmetric: The FFTW, the library used to actually compute > these DFTs, does come with an effort-reduced FFT for real-valued input > data, which will also only output one side of the spectrum. > The savings in CPU cycles are usually relatively modest (because the > non-hermitian FFT is already very optimized, and leaving out the > results stage doesn't simply go and half the effort) – the main > advantage would, in practice, probably be reduced memory bandwidth. > > But: audio sample rates on modern CPUs with FFTs of benign length might > not really be what you should worry about computationally, I'd guess. > What is the computational bottleneck you need to widen? > > Best regards, > Marcus > > On Sun, 2018-03-18 at 09:29 -0400, Brad Hein wrote: > >> >> Frequency domain output of the FFT block seems to be mirrored when >> using floating point data type. I recall that when using complex >> numbers this mirroring doesn't occur. The input I'm working with is >> 48khz sound from a wav file. I understand this mirroring is a >> characteristic of the Fourier transform, but what I'm wondering is >> what is the best way to recover the useful information from the FFT >> >> I tried marshaling the data into complex data before feeding it into >> the FFT but I couldn't get a reliable process. >> >> If discarding half of the FFT output is the way to go then what about >> the wasted CPU in calculating that half of the frequency domain - is >> there a better way to recover the useful frequency domain >> information? >> >> Thanks! >> >> ___ >> 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
[Discuss-gnuradio] Floating point FFT usage - suppress half of it?
Frequency domain output of the FFT block seems to be mirrored when using floating point data type. I recall that when using complex numbers this mirroring doesn't occur. The input I'm working with is 48khz sound from a wav file. I understand this mirroring is a characteristic of the Fourier transform, but what I'm wondering is what is the best way to recover the useful information from the FFT when using floating point numbers. Put another way, is it safe to discard the left side of the output as it appears to consist only of aliases of the true data? Are there any better ways to do this? I tried marshaling the data into complex data before feeding it into the FFT but I couldn't get a reliable process. If discarding half of the FFT output is the way to go then what about the wasted CPU in calculating that half of the frequency domain - is there a better way to recover the useful frequency domain information? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help accessing fft bins in python script
This sounds interesting - do you have any sample code? Can anybody explain the concept of size of an fft (Arg 1 of fft . fft_vcc ) comes into play if the output of that FFT generates as many samples as it receives? - Original Message - From: John Malsbury jmalsbury.perso...@gmail.com To: Brad Hein k1...@comcast.net Cc: Martin Braun martin.br...@ettus.com, discuss-gnuradio@gnu.org Sent: Friday, October 17, 2014 1:50:31 AM Subject: Re: [Discuss-gnuradio] help accessing fft bins in python script Sometimes when I want to grab samples and perform some periodic operation like CNR estimation, or fine-frequency estimation I sometimes use a vector_sink, and then two function probe blocks - one to read the data and one to reset it (yes I call the reset function from the function probe). This seems to work wonderfully for certain corner cases where a vector sink doesn't work well. And I mostly use this technique when I want to prototyping something quickly before writing a block. But am I asking for trouble with memory allocation issues??? Also, I was thinking, it would be good to have the option, either a block parameter or an overloaded function) to reset the vector_sink, each time .data() is called... I can code this up unless anyone thinks this functionality would lead to regressions. But I agree the vector sink block is much more convenient for FFTs... -John On Thu, Oct 16, 2014 at 5:37 PM, Brad Hein k1...@comcast.net wrote: Is there any way to access the fft bins from python without writing a custom block? From: Martin Braun martin.br...@ettus.com To: discuss-gnuradio@gnu.org Sent: Thursday, October 16, 2014 2:02:03 PM Subject: Re: [Discuss-gnuradio] help accessing fft bins in python script A very simple way would just be to write your block downstream of the FFT in Python. You can then operate on the vectors in the work function. M On 10/16/2014 07:44 PM, mle...@ripnet.com wrote: The vector sink is for debugging only. Don't use it in production code, because there's no convenient way to vacuum it out, so it grows without bound. When I've had this problem, I use a vector-probe block, and have a function probe running at a couple of Hz, and then leverage the dependency-tree evaluator to have my own function called with the result of the function probe. There are other ways, that's the one I personally find most convenient. But there are message queues and sundry other methods as well. On 2014-10-16 13:36, Brad Hein wrote: Using qa_fft.py for inspiration[1], I'm trying to feed a raw capture file into an fft of size 32 and then review the 32 fft bins at an instantaneous point in time[2]. I must be doing something wrong however because when I review the vector sink's data() method, it returns a rather large array (compared to the 32-element array I am expecting). data() seems to return an array with the same number of elements as samples fed into the fft. I just want an array of the 32 fft bins so I can calculate the relative power in the given band. Any help/pointers appreciated! Thanks [1] http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-fft/python/fft/qa_fft.py [2] https://github.com/regulatre/grfun/blob/9dbbf676d2fea013787720273af0b419699c75a4/hello-fft/decodeDump162.py [Brad Hein] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help accessing fft bins in python script
Is there any way to access the fft bins from python without writing a custom block? - Original Message - From: Martin Braun martin.br...@ettus.com To: discuss-gnuradio@gnu.org Sent: Thursday, October 16, 2014 2:02:03 PM Subject: Re: [Discuss-gnuradio] help accessing fft bins in python script A very simple way would just be to write your block downstream of the FFT in Python. You can then operate on the vectors in the work function. M On 10/16/2014 07:44 PM, mle...@ripnet.com wrote: The vector sink is for debugging only. Don't use it in production code, because there's no convenient way to vacuum it out, so it grows without bound. When I've had this problem, I use a vector-probe block, and have a function probe running at a couple of Hz, and then leverage the dependency-tree evaluator to have my own function called with the result of the function probe. There are other ways, that's the one I personally find most convenient. But there are message queues and sundry other methods as well. On 2014-10-16 13:36, Brad Hein wrote: Using qa_fft.py for inspiration[1], I'm trying to feed a raw capture file into an fft of size 32 and then review the 32 fft bins at an instantaneous point in time[2]. I must be doing something wrong however because when I review the vector sink's data() method, it returns a rather large array (compared to the 32-element array I am expecting). data() seems to return an array with the same number of elements as samples fed into the fft. I just want an array of the 32 fft bins so I can calculate the relative power in the given band. Any help/pointers appreciated! Thanks [1] http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-fft/python/fft/qa_fft.py [2] https://github.com/regulatre/grfun/blob/9dbbf676d2fea013787720273af0b419699c75a4/hello-fft/decodeDump162.py [Brad Hein] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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
[Discuss-gnuradio] Installing the latest gnuradio and gnuradio-companion (grc) in Fedora 14
Hello all - I wanted to share my notes for installing gnuradio in Fedora 14. There were a few snags at first but with help from the friendly folks on discuss-gnuradio, I was able to push through and compile gnuradio and gnuradio-companion in Fedora 14! Note that Installing gnuradio/grc with yum didn't work for me so I had to compile from source. At a future date there may be some updated binaries added to the Fedora repository, but until then, we can install it by compiling the source! Getting latest GNURadio from GIT and building it on Fedora 14! == * Uninstall any existing gnuradio and grc rpm packages using yum. * Obtain the source code to gnuradio via git. # git clone git://gnuradio.org/gnuradio * A Link to the build instructions. http://gnuradio.org/redmine/wiki/1/BuildGuide http://gnuradio.org/redmine/repositories/entry/gnuradio/README * Per the instructions, for a required package foo, we will install foo and foo-devel * The following single YUM command sets up the environment necessary to build gnuradio! # yum install SDL* PyQt4 PyQt4-devel alsa-lib-devel gcc gpp gcc-c++ autoconf automake libtool pkgconfig fftw fftw-devel python numpy boost boost-* cppunit cppunit-devel swig sdcc sdcc-libc-sources guile guile-devel guile-* gsl gsl-devel pygsl pygsl-devel wxPython wxPython-devel xmlto python-cheetah python-turbocheetah python-lxml doxygen pygtk2 qwt-devel * Now go into the gnuradio direcotry and run ./bootstrap to build the configure script. * Now run configure # ./configure --enable-grc --enable-gr-qtgui --enable-gr-audio-alsa * Then run # make check install Troubleshooting - Problem: Python path set incorrectly and prevents gnuradio-companion (grc) from starting. $ echo $PYTHONPATH /usr/lib/python2.7/site-packages/mpich2 Solution: -- Change the python path before running gnuradio-companion. -- $ export PYTHONPATH=/usr/local/lib/python2.7/site-packages -- A more permanent fix can be applied by adding the export command to a new file in /etc/profiles.d, or ~/.bash_profile. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ICOM 706 MKIIG as input to GNURadio
On Sat, Jan 1, 2011 at 9:12 AM, ikjtel ikj12...@yahoo.com wrote: Anybody else had any success in tapping the IQ in a receiver and feeding that into GNURadio? Yes - haven't gotten into the 9-10 MHz range IF's, but I have built converters for 455 KHz IF's - overall they work quite well although there are some slight compromises in the overall system; for example I've found that the AGC action in the host receiver may interfere somewhat with some types of signals although it's not usually a severe problem. After building several I/Q converters it was discovered that (for our application) it wasn't necessary to perform quadrature sampling in hardware - that is, it was sufficient simply to downconvert the signal to the center of the soundcard range and sample that conventionally using a single soundcard input channel. The signal is then converted to the complex format entirely in software (setting the real components to the input values and stuffing zeros into the imaginary (Q) components). This has the advantages of simplifying the hardware and of freeing up one of the two soundcard input channels. It would no doubt be straightforward to extend these ideas to the 9-10 MHz IF's. One thing though is that there's perhaps 50-60 dB more signal available to work with after the 455 KHz IF amp chain has done its work. So if you tap into the 9-10 MHz IF you may be looking at building up a relatively significant amount of RF gain yourself... Here are links to a couple of my pages containing schematic and other diagrams, and application notes: http://www.lightlink.com/mhp/lsm/ http://www.lightlink.com/mhp/iq/ Good luck Max Max, Marcus, thank you very much! A lot of this is over my head right now but I'm reading up and hope to put to work some or all of your suggestions. I especially like the prospect of having a cheap but effective USB SDR. Although if I had a USB SDR I probably wouldn't even need to perform surgery on my HF allmode rig. Also, a little more reading revealed that my rig has a third IF that operates at 455Khz and is utilized in FM and WFM modes, which may be just what I need, and what you were describing, Max. BH ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ICOM 706 MKIIG as input to GNURadio
I'm looking for a way to tap into the unmodulated signal in my ICOM 706 MKIIG (I don't have a SDR BUT I do have a sound card, and lots of ham equipment :) ). Referring to the product service manual[1], I have found the product detector signal before it reaches the AF stages. Also it appears (hoping I'm wrong) that the second IF runs at about 9Mhz. So does that mean that I need to down-convert the signal from 9Mhz, to something the soundcard can handle? Or is there a better place to tap the IQ signal coming from the VDO...? Anybody else had any success in tapping the IQ in a receiver and feeding that into GNURadio? 73 K1GTO BH References [1] http://www.rigpix.com/icom/ic706mkiig.htm ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] output 0 is not connected internally
On Thu, Dec 30, 2010 at 10:26 AM, Tom Rondeau trondeau1...@gmail.comwrote: On Wed, Dec 29, 2010 at 10:57 PM, Brad Hein linuxb...@gmail.com wrote: I'm endeavouring to get gnuradio+grc working in Fedora 14 on my i386 computers. I've tried two now, and I'm plagued with the same problems - they just won't execute. I suspect there's a problem which went undetected, maybe a python file version mismatch or some other inconsistency. I'm trying hard to isolate the source of the problem. I also wrote a very basic grc which consisted of a sound source and attached it to different sinks (audio sync / waterfall sink / scope sink) - each producing the same error shown below, when executed. I'm trying different things, but any input would be greatly appreciated =) Looking at your version information below, you're running a very old version of the GNU Radio Companion (grc 0.70). You'll need to update it, which I think will solve your problem. I actually don't know if we have a newer package of GRC out there, so you might have to compile/install it yourself (Josh, let me know if I'm wrong about this). Thank you for pointing that out! I went ahead and obtained gnuradio 3.3.0 (sourcecode) and I'm setting up my faster Fedora PC to compile it. If this works, I suppose I should share the procedure with Fedora so they can make the necessary changes to the F14 repo so that others can have a working configuration without the need for compiling. BH Tom The error shown when executed === Executing: /usr/share/grc/examples/audio/phone_tones.grc.xml Verbose: Traceback (most recent call last): File /usr/share/grc/src/ExecFlowGraphGUI.py, line 231, in OnInit self.SetTopWindow(FlowGraphFrame(self.flow_graph_file_path))#first argument is the flow graph File /usr/share/grc/src/ExecFlowGraphGUI.py, line 165, in __init__ self._start() #start the flow graph File /usr/share/grc/src/ExecFlowGraph.py, line 54, in _start self.start() File /usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py, line 97, in start self._tb.start() File /usr/lib/python2.7/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py, line 1455, in start return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self) RuntimeError: In hierarchical block scope throttle, output 0 is not connected internally Done RPM Package list on Fedora14 notebook PC (basically identical to the other F14 PC) === [r...@fedora14laptop ~]# rpm -qa |egrep -i gnuradio|grc|python|sort abrt-addon-python-1.1.14-1.fc14.i686 at-spi-python-1.32.0-2.fc14.i686 audit-libs-python-2.0.4-4.fc14.i686 cracklib-python-2.8.16-4.fc14.i686 dbus-python-0.83.0-7.fc14.i686 farsight2-python-0.0.21-2.fc14.i686 gnome-python2-2.28.1-3.fc14.i686 gnome-python2-applet-2.32.0-1.fc14.i686 gnome-python2-bonobo-2.28.1-3.fc14.i686 gnome-python2-canvas-2.28.1-3.fc14.i686 gnome-python2-desktop-2.32.0-1.fc14.i686 gnome-python2-extras-2.25.3-25.fc14.1.i686 gnome-python2-gconf-2.28.1-3.fc14.i686 gnome-python2-gnome-2.28.1-3.fc14.i686 gnome-python2-gnomekeyring-2.32.0-1.fc14.i686 gnome-python2-gnomevfs-2.28.1-3.fc14.i686 gnome-python2-gtkhtml2-2.25.3-25.fc14.1.i686 gnome-python2-libegg-2.25.3-25.fc14.1.i686 gnome-python2-libwnck-2.32.0-1.fc14.i686 gnuradio-3.2.2-7.fc14.i686 grc-0.70-6.fc12.noarch gstreamer-python-0.10.19-1.fc14.i686 libproxy-python-0.4.4-7.fc14.noarch libselinux-python-2.0.96-6.fc14.1.i686 libsemanage-python-2.0.45-5.fc14.i686 libuser-python-0.56.18-2.fc14.i686 libxml2-python-2.7.7-2.fc14.i686 newt-python-0.52.12-1.fc14.i686 notify-python-0.1.1-15.fc14.i686 policycoreutils-python-2.0.83-33.2.fc14.i686 python-2.7-8.fc14.1.i686 python-beaker-1.5.3-5.fc14.noarch python-BeautifulSoup-3.0.8.1-2.fc14.noarch python-boto-1.9b-3.fc14.noarch python-bugzilla-0.6.1-3.fc14.noarch python-crypto-2.3-2.fc14.1.i686 python-cryptsetup-0.0.10-3.fc14.i686 python-decorator-3.2.0-3.fc14.noarch python-deltarpm-3.6-0.2.20100708git.fc14.i686 python-devel-2.7-8.fc14.1.i686 python-ethtool-0.5-1.fc14.i686 python-feedparser-4.1-12.fc14.noarch python-GnuPGInterface-0.3.2-7.fc14.noarch python-httplib2-0.6.0-3.fc14.noarch python-iniparse-0.4-2.fc14.noarch python-iwlib-0.1-3.fc14.i686 python-libs-2.7-8.fc14.1.i686 python-mako-0.3.4-2.fc14.noarch python-markupsafe-0.9.2-4.fc14.i686 python-meh-0.10-2.fc14.noarch python-nose-0.11.3-5.fc14.noarch python-nss-0.9-9.fc14.i686 python-paste-1.7.4-7.fc14.noarch python-pyblock-0.52-1.fc14.i686 python-pycurl-7.19.0-7.fc14.i686 python-setuptools-0.6.14-3.fc14.noarch python-simplejson-2.1.1-4.fc14.i686 python-slip-0.2.13-1.fc14.noarch python-slip-dbus-0.2.13-1.fc14.noarch python-telepathy-0.15.18-1.fc14.noarch python-tempita-0.4-5.fc14.noarch python
Re: [Discuss-gnuradio] output 0 is not connected internally
On Thu, Dec 30, 2010 at 11:12 AM, Brad Hein linuxb...@gmail.com wrote: On Thu, Dec 30, 2010 at 10:26 AM, Tom Rondeau trondeau1...@gmail.comwrote: On Wed, Dec 29, 2010 at 10:57 PM, Brad Hein linuxb...@gmail.com wrote: I'm endeavouring to get gnuradio+grc working in Fedora 14 on my i386 computers. I've tried two now, and I'm plagued with the same problems - they just won't execute. I suspect there's a problem which went undetected, maybe a python file version mismatch or some other inconsistency. I'm trying hard to isolate the source of the problem. I also wrote a very basic grc which consisted of a sound source and attached it to different sinks (audio sync / waterfall sink / scope sink) - each producing the same error shown below, when executed. I'm trying different things, but any input would be greatly appreciated =) Looking at your version information below, you're running a very old version of the GNU Radio Companion (grc 0.70). You'll need to update it, which I think will solve your problem. I actually don't know if we have a newer package of GRC out there, so you might have to compile/install it yourself (Josh, let me know if I'm wrong about this). Thank you for pointing that out! I went ahead and obtained gnuradio 3.3.0 (sourcecode) and I'm setting up my faster Fedora PC to compile it. If this works, I suppose I should share the procedure with Fedora so they can make the necessary changes to the F14 repo so that others can have a working configuration without the need for compiling. Unfortunately the compile failed - I ran into compile errors with things in the usrp2 and gr-usrp2 directories, so I removed them from the Makefile and the compile eventually went through... But make install didn't seem to install any new grc binaries. I made sure to run configure with --with-grc, so I don't think it's being skipped. Is anybody else out there working on getting gnuradio working in Fedora14 who would like to join forces? My next step is to install Ubuntu (not to use, but as a reference), which is what I saw a user in a youtube video using to demonstrate a touch tones app. I'll try and transplant grc to Fedora, or at least compare the two configurations to hopefully expose a difference in the python files so I can get it working. Tom The error shown when executed === Executing: /usr/share/grc/examples/audio/phone_tones.grc.xml Verbose: Traceback (most recent call last): File /usr/share/grc/src/ExecFlowGraphGUI.py, line 231, in OnInit self.SetTopWindow(FlowGraphFrame(self.flow_graph_file_path))#first argument is the flow graph File /usr/share/grc/src/ExecFlowGraphGUI.py, line 165, in __init__ self._start() #start the flow graph File /usr/share/grc/src/ExecFlowGraph.py, line 54, in _start self.start() File /usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py, line 97, in start self._tb.start() File /usr/lib/python2.7/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py, line 1455, in start return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self) RuntimeError: In hierarchical block scope throttle, output 0 is not connected internally Done RPM Package list on Fedora14 notebook PC (basically identical to the other F14 PC) === [r...@fedora14laptop ~]# rpm -qa |egrep -i gnuradio|grc|python|sort abrt-addon-python-1.1.14-1.fc14.i686 at-spi-python-1.32.0-2.fc14.i686 audit-libs-python-2.0.4-4.fc14.i686 cracklib-python-2.8.16-4.fc14.i686 dbus-python-0.83.0-7.fc14.i686 farsight2-python-0.0.21-2.fc14.i686 gnome-python2-2.28.1-3.fc14.i686 gnome-python2-applet-2.32.0-1.fc14.i686 gnome-python2-bonobo-2.28.1-3.fc14.i686 gnome-python2-canvas-2.28.1-3.fc14.i686 gnome-python2-desktop-2.32.0-1.fc14.i686 gnome-python2-extras-2.25.3-25.fc14.1.i686 gnome-python2-gconf-2.28.1-3.fc14.i686 gnome-python2-gnome-2.28.1-3.fc14.i686 gnome-python2-gnomekeyring-2.32.0-1.fc14.i686 gnome-python2-gnomevfs-2.28.1-3.fc14.i686 gnome-python2-gtkhtml2-2.25.3-25.fc14.1.i686 gnome-python2-libegg-2.25.3-25.fc14.1.i686 gnome-python2-libwnck-2.32.0-1.fc14.i686 gnuradio-3.2.2-7.fc14.i686 grc-0.70-6.fc12.noarch gstreamer-python-0.10.19-1.fc14.i686 libproxy-python-0.4.4-7.fc14.noarch libselinux-python-2.0.96-6.fc14.1.i686 libsemanage-python-2.0.45-5.fc14.i686 libuser-python-0.56.18-2.fc14.i686 libxml2-python-2.7.7-2.fc14.i686 newt-python-0.52.12-1.fc14.i686 notify-python-0.1.1-15.fc14.i686 policycoreutils-python-2.0.83-33.2.fc14.i686 python-2.7-8.fc14.1.i686 python-beaker-1.5.3-5.fc14.noarch python-BeautifulSoup-3.0.8.1-2.fc14.noarch python-boto-1.9b-3.fc14.noarch python-bugzilla-0.6.1-3.fc14.noarch python-crypto-2.3-2.fc14.1.i686 python-cryptsetup-0.0.10-3.fc14.i686 python-decorator-3.2.0-3.fc14.noarch python
Re: [Discuss-gnuradio] output 0 is not connected internally
On Thu, Dec 30, 2010 at 1:26 PM, Tom Rondeau trondeau1...@gmail.com wrote: On Thu, Dec 30, 2010 at 12:48 PM, Marcus D. Leech mle...@ripnet.com wrote: On 12/30/2010 12:39 PM, George S. Williams wrote: On 12/30/2010 12:16 PM, Brad Hein wrote: Unfortunately the compile failed - I ran into compile errors with things in the usrp2 and gr-usrp2 directories, so I removed them from the Makefile and the compile eventually went through... But make install didn't seem to install any new grc binaries. I made sure to run configure with --with-grc, so I don't think it's being skipped. Is anybody else out there working on getting gnuradio working in Fedora14 who would like to join forces? I've been running Gnu Radio on F14 for quite some time. Following the instructions in the build guide, make sure you have the pre-reqs, and you should be good to go. http://gnuradio.org/redmine/wiki/gnuradio/BuildGuide If you go the UHD route (which I recommend), you'll need to set PKG_CONFIG_PATH to point at /usr/local/lib/pkgconfig before doing the configure and make steps for gnu radio. Thank you both for your suggestions, I'll go ahead and carefully follow the instructions on the gnuradio wiki page FedoraInstall under gnuradio from tarball. BH -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org Brad, Follow what Marcus said. I just wanted to chime in and say that you shouldn't ever need to do anything with the Makefiles. If a component fails in configure, make will not try to build it. If you need to, you can explicitly remove a component with ./configure --disable-component-name. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] output 0 is not connected internally
On Thu, Dec 30, 2010 at 2:05 PM, Marcus D. Leech mle...@ripnet.com wrote: On 12/30/2010 01:51 PM, Brad Hein wrote: Thank you both for your suggestions, I'll go ahead and carefully follow the instructions on the gnuradio wiki page FedoraInstall under gnuradio from tarball. BH Do it from the GIT source. It's almost always stable enough to use. Compilation from GIT source was successful. I ran make install, and ran gnuradio-companion, and it's now producing the error shown below, which I am investigating... Marcus - Any chance you could send me the output from an rpm -qa on your box, so I can compare packages? I'm wondering what could be different between your Fedora14 (which as you say, works) , and mine, which has so many problems... [r...@gto ~]# gnuradio-companion Traceback (most recent call last): File /usr/local/bin/gnuradio-companion, line 45, in module %gr.version() AttributeError: 'module' object has no attribute 'version' -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] output 0 is not connected internally
On Thu, Dec 30, 2010 at 4:44 PM, Josh Blum j...@joshknows.com wrote: [r...@gto ~]# gnuradio-companion Traceback (most recent call last): File /usr/local/bin/gnuradio-companion, line 45, in module %gr.version() AttributeError: 'module' object has no attribute 'version' it looks like its importing from an older install of gnuradio that didnt have the gr_constants* stuff. Make sure to clean out old gnuradio installs tarballs, rpms, etc... Aha - you're right! $ echo $PYTHONPATH /usr/lib/python2.7/site-packages/mpich2 So after I set the PYTHONPATH to the one in /usr/local/lib... specified by Marcus, ***gnuradio-companion started up for the first time! *** And you are correct - I did in fact have an old gnuradio RPM hanging around out there (it was a dependency of some other AX.25 stuff I was using so I thought I could get away with overwriting it with the compiled version of gnuradio, but I was wrong.). Here's what I've learned from this experience #1 - It is possible to run gnuradio + grc on Fedora 14 #2 - Install all development packages required to make the build process successful (if unsuccesful then it's due to missing dependency package) #3 - Install gnuradio + grc from git source (as specified on gnuradio wiki page BuildGuide. #4 - Make sure that PYTHONPATH=/usr/local/lib/ python2.7/site-packages. If not, then there is another instance of something (gnuradio?) conflicting with the newly built one. #5 - The gnuradio and grc which currently ship with Fedora 14 are outdated, and seem to be broken/misconfigured (they don't work out of hte box). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] output 0 is not connected internally
I'm endeavouring to get gnuradio+grc working in Fedora 14 on my i386 computers. I've tried two now, and I'm plagued with the same problems - they just won't execute. I suspect there's a problem which went undetected, maybe a python file version mismatch or some other inconsistency. I'm trying hard to isolate the source of the problem. I also wrote a very basic grc which consisted of a sound source and attached it to different sinks (audio sync / waterfall sink / scope sink) - each producing the same error shown below, when executed. I'm trying different things, but any input would be greatly appreciated =) The error shown when executed === Executing: /usr/share/grc/examples/audio/phone_tones.grc.xml Verbose: Traceback (most recent call last): File /usr/share/grc/src/ExecFlowGraphGUI.py, line 231, in OnInit self.SetTopWindow(FlowGraphFrame(self.flow_graph_file_path))#first argument is the flow graph File /usr/share/grc/src/ExecFlowGraphGUI.py, line 165, in __init__ self._start() #start the flow graph File /usr/share/grc/src/ExecFlowGraph.py, line 54, in _start self.start() File /usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py, line 97, in start self._tb.start() File /usr/lib/python2.7/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py, line 1455, in start return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self) RuntimeError: In hierarchical block scope throttle, output 0 is not connected internally Done RPM Package list on Fedora14 notebook PC (basically identical to the other F14 PC) === [r...@fedora14laptop ~]# rpm -qa |egrep -i gnuradio|grc|python|sort abrt-addon-python-1.1.14-1.fc14.i686 at-spi-python-1.32.0-2.fc14.i686 audit-libs-python-2.0.4-4.fc14.i686 cracklib-python-2.8.16-4.fc14.i686 dbus-python-0.83.0-7.fc14.i686 farsight2-python-0.0.21-2.fc14.i686 gnome-python2-2.28.1-3.fc14.i686 gnome-python2-applet-2.32.0-1.fc14.i686 gnome-python2-bonobo-2.28.1-3.fc14.i686 gnome-python2-canvas-2.28.1-3.fc14.i686 gnome-python2-desktop-2.32.0-1.fc14.i686 gnome-python2-extras-2.25.3-25.fc14.1.i686 gnome-python2-gconf-2.28.1-3.fc14.i686 gnome-python2-gnome-2.28.1-3.fc14.i686 gnome-python2-gnomekeyring-2.32.0-1.fc14.i686 gnome-python2-gnomevfs-2.28.1-3.fc14.i686 gnome-python2-gtkhtml2-2.25.3-25.fc14.1.i686 gnome-python2-libegg-2.25.3-25.fc14.1.i686 gnome-python2-libwnck-2.32.0-1.fc14.i686 gnuradio-3.2.2-7.fc14.i686 grc-0.70-6.fc12.noarch gstreamer-python-0.10.19-1.fc14.i686 libproxy-python-0.4.4-7.fc14.noarch libselinux-python-2.0.96-6.fc14.1.i686 libsemanage-python-2.0.45-5.fc14.i686 libuser-python-0.56.18-2.fc14.i686 libxml2-python-2.7.7-2.fc14.i686 newt-python-0.52.12-1.fc14.i686 notify-python-0.1.1-15.fc14.i686 policycoreutils-python-2.0.83-33.2.fc14.i686 python-2.7-8.fc14.1.i686 python-beaker-1.5.3-5.fc14.noarch python-BeautifulSoup-3.0.8.1-2.fc14.noarch python-boto-1.9b-3.fc14.noarch python-bugzilla-0.6.1-3.fc14.noarch python-crypto-2.3-2.fc14.1.i686 python-cryptsetup-0.0.10-3.fc14.i686 python-decorator-3.2.0-3.fc14.noarch python-deltarpm-3.6-0.2.20100708git.fc14.i686 python-devel-2.7-8.fc14.1.i686 python-ethtool-0.5-1.fc14.i686 python-feedparser-4.1-12.fc14.noarch python-GnuPGInterface-0.3.2-7.fc14.noarch python-httplib2-0.6.0-3.fc14.noarch python-iniparse-0.4-2.fc14.noarch python-iwlib-0.1-3.fc14.i686 python-libs-2.7-8.fc14.1.i686 python-mako-0.3.4-2.fc14.noarch python-markupsafe-0.9.2-4.fc14.i686 python-meh-0.10-2.fc14.noarch python-nose-0.11.3-5.fc14.noarch python-nss-0.9-9.fc14.i686 python-paste-1.7.4-7.fc14.noarch python-pyblock-0.52-1.fc14.i686 python-pycurl-7.19.0-7.fc14.i686 python-setuptools-0.6.14-3.fc14.noarch python-simplejson-2.1.1-4.fc14.i686 python-slip-0.2.13-1.fc14.noarch python-slip-dbus-0.2.13-1.fc14.noarch python-telepathy-0.15.18-1.fc14.noarch python-tempita-0.4-5.fc14.noarch python-urlgrabber-3.9.1-7.fc14.noarch python-virtkey-0.50-8.fc14.i686 python-xlib-0.15-0.3.rc1.fc14.noarch rpm-python-4.8.1-5.fc14.i686 setools-libs-python-3.3.7-8.fc14.i686 wxPython-2.8.11.0-4.fc14.i686 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
