[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Embedded Development with GNU Radio
|
From: |
Philip Balister |
|
Subject: |
Re: [Discuss-gnuradio] Embedded Development with GNU Radio |
|
Date: |
Mon, 10 Dec 2018 15:42:35 -0500 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
On 12/10/2018 03:32 PM, Philip Balister wrote:
> On 12/10/2018 03:16 PM, Mohamed Youseif wrote:
>> Hello,
>> I'm trying to build an embedd linux image using yocto project with gnuradio
>> for my target which is wandboard, so i downloaded the meta-sdr layer ( sumo
>> branch ), then i configure my local configuration to install all needed
>> packages (like gnuradio, uhd, gr-burst, etc.) , then i bitbake
>> core-image-minimal and everythings gone well and get my image and copied it
>> to my sdcard, i see that i have gnuradio and uhd installed but i did not
>> found gr-uhd installed in gnuradio core, so when i try to run any uhd
>> example script it ouput import error for no uhd module. so do i need to do
>> more configuration to have the gr-uhd installed with my image ?
And the other pain point, I am testing gnuradio/next in master and am
still fixing stuff there. And this is going slowly due to paying work,
holiday season and snow.
Philip
>
> I disabled uhd since the recipe is bitrotting in meta-sdr and isn't
> buildable. Wait ...
>
> Hmm, I did get a patch updating it to a buildable version, but it
> doesn't include the fpga image packages update. I applied the patch
> since it improves the situation, but haven't checked against gnuradio.
>
> You could try setting the PACKAGECONFIG for gnuradio in local.conf and
> add uhd back and see if that works. Or do what I do and use an rtlsdr
> dongle :)
>
> I apologize for this sorry state of affairs wrt to uhd support.
>
> Philip
>
>
>> Thanks,
>> Yusuf
>> ________________________________
>> From: Discuss-gnuradio <address@hidden> on behalf of address@hidden
>> <address@hidden>
>> Sent: Monday, December 10, 2018 7:00 PM
>> To: address@hidden
>> Subject: Discuss-gnuradio Digest, Vol 194, Issue 8
>>
>> Send Discuss-gnuradio mailing list submissions to
>> address@hidden
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> or, via email, send a message with subject or body 'help' to
>> address@hidden
>>
>> You can reach the person managing the list at
>> address@hidden
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Discuss-gnuradio digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: help: optimizing a fm broadcast flowchart. Getting
>> multiple stations in a rtlsdr (Derek Kozel) (Michael Dickens)
>> (Cinaed Simson)
>> 2. Re: help: optimizing a fm broadcast flowchart. Getting
>> multiple stations in a rtlsdr (Derek Kozel) (Michael Dickens)
>> (Cinaed Simson)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 9 Dec 2018 13:39:00 -0800
>> From: Cinaed Simson <address@hidden>
>> To: address@hidden
>> Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
>> flowchart. Getting multiple stations in a rtlsdr (Derek Kozel)
>> (Michael Dickens)
>> Message-ID: <address@hidden>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Here's an example of broadcast FM. It's from the first couple of
>> tutorials at
>>
>> https://greatscottgadgets.com/sdr
>>
>> All you need to do is to change the samp rate and the center_freq, and
>> swap out the osmocom Source for the RTL-SDR Source.
>>
>> Since each channel is roughly 200 kHz wide, you probably won't get more
>> then 2 stations at a sampling rate of 2 MHz.
>>
>> I have HackRF One and it runs fine on my i7 at sampling rate of 20 MHz.
>>
>> However, this was the first time I tried on the i7 - and when I drop
>> the sampling rate to 2 MHz, I got the 'Ua's - audio underflows,
>>
>> But it sounded fine. Not sure what is causing the audio underflow.
>>
>> I would guess you should be able to replace the "Signal
>> Source/Multiply/Low Pass Filter" with the "Frequency Xlating FIR Filter"
>> or the "Low Pass Filter/Rational Resampler" with the polyphase filter bank.
>>
>> -- Cinaed
>>
>>
>> On 12/07/2018 11:33 AM, Luis Roca wrote:
>>> Thanks!
>>>
>>> On Fri, Dec 7, 2018 at 1:12 PM <address@hidden
>>> <mailto:address@hidden>> wrote:
>>>
>>> Send Discuss-gnuradio mailing list submissions to
>>> ? ? ? ? address@hidden <mailto:address@hidden>
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> ? ? ? ? https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> or, via email, send a message with subject or body 'help' to
>>> ? ? ? ? address@hidden
>>> <mailto:address@hidden>
>>>
>>> You can reach the person managing the list at
>>> ? ? ? ? address@hidden
>>> <mailto:address@hidden>
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Discuss-gnuradio digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> ? ?1. Re: help: optimizing a fm broadcast flowchart. Getting
>>> ? ? ? multiple stations in a rtlsdr (Derek Kozel) (Luis Roca)
>>> ? ?2. Re: help: optimizing a fm broadcast flowchart. Getting
>>> ? ? ? multiple stations in a rtlsdr (Derek Kozel) (Michael Dickens)
>>> ? ?3. Re: [USRP-users] Segmentation fault commands to USRP with
>>> ? ? ? gnuradio (M?ller)
>>> ? ?4. Re: [USRP-users] Segmentation fault commands to USRP with
>>> ? ? ? gnuradio (M?ller)
>>> ? ?5. Re: [USRP-users] Segmentation fault commands to USRP with
>>> ? ? ? gnuradio (Christoph Mayer)
>>> ? ?6. Re: [USRP-users] Segmentation fault commands to USRP with
>>> ? ? ? gnuradio (M?ller)
>>> ? ?7. Receiving NOAA signals and passing to BB (Guilherme Theis)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Thu, 6 Dec 2018 13:17:01 -0400
>>> From: Luis Roca <address@hidden <mailto:address@hidden>>
>>> To: address@hidden <mailto:address@hidden>
>>> Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
>>> ? ? ? ? flowchart. Getting multiple stations in a rtlsdr (Derek Kozel)
>>> Message-ID:
>>> ? ? ? ?
>>> <address@hidden
>>> <mailto:address@hidden>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Thanks for your response Derek, we are using a FIR filter. I am
>>> including
>>> the flowchart
>>>
>>> On Thu, Dec 6, 2018 at 1:01 PM <address@hidden
>>> <mailto:address@hidden>> wrote:
>>>
>>> > Send Discuss-gnuradio mailing list submissions to
>>> >? ? ? ? address@hidden <mailto:address@hidden>
>>> >
>>> > To subscribe or unsubscribe via the World Wide Web, visit
>>> >? ? ? ? ?https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> > or, via email, send a message with subject or body 'help' to
>>> >? ? ? ? address@hidden
>>> <mailto:address@hidden>
>>> >
>>> > You can reach the person managing the list at
>>> >? ? ? ? address@hidden
>>> <mailto:address@hidden>
>>> >
>>> > When replying, please edit your Subject line so it is more specific
>>> > than "Re: Contents of Discuss-gnuradio digest..."
>>> >
>>> >
>>> > Today's Topics:
>>> >
>>> >? ? 1. help: optimizing a fm broadcast flowchart. Getting multiple
>>> >? ? ? ?stations in a rtlsdr (Luis Roca)
>>> >? ? 2. Re: help: optimizing a fm broadcast flowchart. Getting
>>> >? ? ? ?multiple stations in a rtlsdr (Derek Kozel)
>>> >? ? 3. Re: [USRP-users] Segmentation fault commands to USRP with
>>> >? ? ? ?gnuradio (samuel verdon)
>>> >? ? 4. Lock/unlock? (Albin Stig?)
>>> >
>>> >
>>> > ----------------------------------------------------------------------
>>> >
>>> > Message: 1
>>> > Date: Wed, 5 Dec 2018 20:54:52 -0400
>>> > From: Luis Roca <address@hidden <mailto:address@hidden>>
>>> > To: address@hidden <mailto:address@hidden>
>>> > Subject: [Discuss-gnuradio] help: optimizing a fm broadcast flowchart.
>>> >? ? ? ? ?Getting multiple stations in a rtlsdr
>>> > Message-ID:
>>> >? ? ? ? ?<CALNke=
>>> > address@hidden
>>> <mailto:address@hidden>>
>>> > Content-Type: text/plain; charset="utf-8"
>>> >
>>> > Thanks for this great software. We are tinkering with a setup for
>>> listening
>>> > to radio and storing the streams as wavs.? We have two challenges
>>> that we
>>> > haven't been able to tackle satisfactorily.? Any help would be
>>> appreciated.
>>> >
>>> > 1. What do we need in order to tune into as many stations as an
>>> rtlsdr can
>>> > fit in its bandwidth and create wav files for each one. In our
>>> setup we use
>>> > each sdr for a single station but scaling is a challenge.
>>> >
>>> > 2. How can we optimize our existing flowchart ( included
>>> screenshot) for
>>> > broadcasting wavs from the computer thru a hackRF.? We use this
>>> for testing
>>> > the sdr setup.
>>> >
>>> > Thanks all,
>>> > Luis
>>> > -------------- next part --------------
>>> > An HTML attachment was scrubbed...
>>> > URL: <
>>> >
>>>
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181205/f813c036/attachment.html
>>> > >
>>> >
>>> > ------------------------------
>>> >
>>> > Message: 2
>>> > Date: Thu, 6 Dec 2018 13:50:09 +0000
>>> > From: Derek Kozel <address@hidden
>>> <mailto:address@hidden>>
>>> > To: address@hidden <mailto:address@hidden>
>>> > Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
>>> >? ? ? ? ?flowchart. Getting multiple stations in a rtlsdr
>>> > Message-ID: <address@hidden
>>> <mailto:address@hidden>>
>>> > Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>> >
>>> > Hi Luis,
>>> >
>>> > At least on my end I can't see an attachment. Since FM broadcast
>>> > stations are regularly spaced the polyphase filterbank is a good
>>> choice
>>> > for separating out each of the individual channels. You can then
>>> use the
>>> > same demodulation set of blocks and file sink that you're (presumably)
>>> > using now to handle each channel.
>>> >
>>> > Regards,
>>> > Derek
>>> >
>>> > On 06/12/2018 00:54, Luis Roca wrote:
>>> > > Thanks for this great software. We are tinkering with a setup for
>>> > > listening to radio and storing the streams as wavs.? We have two
>>> > > challenges that we haven't been able to tackle satisfactorily.? Any
>>> > > help would be appreciated.
>>> > >
>>> > > 1. What do we need in order to tune into as many stations as an
>>> rtlsdr
>>> > > can fit in its bandwidth and create wav files for each one. In our
>>> > > setup we use each sdr for a single station but scaling is a
>>> challenge.
>>> > >
>>> > > 2. How can we optimize our existing flowchart ( included screenshot)
>>> > > for broadcasting wavs from the computer thru a hackRF.? We use this
>>> > > for testing the sdr setup.
>>> > >
>>> > > Thanks all,
>>> > > Luis
>>> > >
>>> > > _______________________________________________
>>> > > Discuss-gnuradio mailing list
>>> > > address@hidden <mailto:address@hidden>
>>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> >
>>> > -------------- next part --------------
>>> > An HTML attachment was scrubbed...
>>> > URL: <
>>> >
>>>
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/4b58fd34/attachment.html
>>> > >
>>> >
>>> > ------------------------------
>>> >
>>> > Message: 3
>>> > Date: Thu, 6 Dec 2018 16:48:52 +0100
>>> > From: samuel verdon <address@hidden
>>> <mailto:address@hidden>>
>>> > To: Marcus M?ller <address@hidden
>>> <mailto:address@hidden>>,
>>> >? ? ? ? ?"address@hidden
>>> <mailto:address@hidden>" <address@hidden
>>> <mailto:address@hidden>>
>>> > Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
>>> >? ? ? ? ?commands to USRP with gnuradio
>>> > Message-ID: <address@hidden
>>> <mailto:address@hidden>>
>>> > Content-Type: text/plain; charset="utf-8"
>>> >
>>> > Hi Marcus and Martin,
>>> > Thank you for your help!
>>> > Do you now how I can follow the problem?
>>> > Or if is it already solved, how can I fix it?
>>> >
>>> > Thanks a lot!
>>> >
>>> > Samuel
>>> >
>>> >
>>> > De?: Marcus M?ller
>>> > Envoy? le?:Wednesday, December 5, 2018 13:50
>>> > ??: address@hidden <mailto:address@hidden>;
>>> samuel verdon
>>> > Cc?: Martin Braun
>>> > Objet?:Re: [USRP-users] Segmentation fault commands to USRP with
>>> gnuradio
>>> >
>>> > <ugly expletive>
>>> > this looks like my fault. Not feeling well enough to fix now, but wait
>>> > a day and I'll have something to test.
>>> > On Wed, 2018-12-05 at 12:56 +0100, Marcus M?ller wrote:
>>> > > Hi Samuel,
>>> > >
>>> > > cool! That's really helpful :)
>>> > >
>>> > > I'm now cross-posting this to discuss-gr, because it's a GNU Radio-
>>> > > land
>>> > > issue. The maintainers of gr-uhd are active over there, too, so this
>>> > > seems the smarter place to continue discussion.
>>> > >
>>> > >
>>> > > so, in medias res:
>>> > >
>>> > > On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
>>> > > > #3? 0x00007f7f15906700 in pmt::dict_has_key (dict=..., key=...) at
>>> > > > /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937
>>> > >
>>> > > m?p m???p. Our favorite (only) variadic type library leads to
>>> > > segfaults.
>>> > >
>>> > > I'll look into that and be back in a while.
>>> > >
>>> > > Best regards,
>>> > > Marcus
>>> > >
>>> >
>>> >
>>> > -------------- next part --------------
>>> > An HTML attachment was scrubbed...
>>> > URL: <
>>> >
>>>
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/0116089a/attachment.html
>>> > >
>>> >
>>> > ------------------------------
>>> >
>>> > Message: 4
>>> > Date: Thu, 6 Dec 2018 17:51:39 +0100
>>> > From: Albin Stig? <address@hidden
>>> <mailto:address@hidden>>
>>> > To: GNURadio Discussion List <address@hidden
>>> <mailto:address@hidden>>
>>> > Subject: [Discuss-gnuradio] Lock/unlock?
>>> > Message-ID:
>>> >? ? ? ? ?<
>>> > address@hidden
>>> <mailto:address@hidden>>
>>> > Content-Type: text/plain; charset="utf-8"
>>> >
>>> > Does calling lock/unlock on a top block call the stop method on
>>> connected
>>> > blocks? And does it flush/empty buffers?
>>> >
>>> >
>>> > --Albin
>>> > -------------- next part --------------
>>> > An HTML attachment was scrubbed...
>>> > URL: <
>>> >
>>>
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/4fd8d57e/attachment.html
>>> > >
>>> >
>>> > ------------------------------
>>> >
>>> > Subject: Digest Footer
>>> >
>>> > _______________________________________________
>>> > Discuss-gnuradio mailing list
>>> > address@hidden <mailto:address@hidden>
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> >
>>> >
>>> > ------------------------------
>>> >
>>> > End of Discuss-gnuradio Digest, Vol 194, Issue 5
>>> > ************************************************
>>> >
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>>
>>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/ab22faea/attachment.html>
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: Screen Shot 2018-12-06 at 12.10.23 PM.jpeg
>>> Type: image/jpeg
>>> Size: 241723 bytes
>>> Desc: not available
>>> URL:
>>>
>>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/ab22faea/attachment.jpeg>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Thu, 06 Dec 2018 12:33:56 -0500
>>> From: Michael Dickens <address@hidden
>>> <mailto:address@hidden>>
>>> To: Luis Roca <address@hidden
>>> <mailto:address@hidden>>, address@hidden
>>> <mailto:address@hidden>
>>> Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
>>> ? ? ? ? flowchart. Getting multiple stations in a rtlsdr (Derek Kozel)
>>> Message-ID:
>>> ? ? ? ?
>>> <address@hidden
>>> <mailto:address@hidden>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Unless your host computer's CPU is way underpowered, I'm with Derek
>>> here: use polyphase filterbanks to channelize into 200 kHz bandwidth per
>>> channel, then have a bank of FM demodulators, one per channel. Output to
>>> files, or display, or whatever you need. - MLD
>>> On Thu, Dec 6, 2018, at 12:17 PM, Luis Roca wrote:
>>> > Thanks for your response Derek, we are using a FIR filter. I am
>>> > including the flowchart> Email had 1 attachment:
>>> >? * Screen Shot 2018-12-06 at 12.10.23 PM.jpeg 331k (image/jpeg)
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>>
>>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/46a4e5f9/attachment.html>
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Fri, 7 Dec 2018 10:21:24 +0000
>>> From: M?ller, Marcus (CEL) <address@hidden <mailto:address@hidden>>
>>> To: "address@hidden <mailto:address@hidden>"
>>> <address@hidden <mailto:address@hidden>>,
>>> ? ? ? ? "address@hidden <mailto:address@hidden>"
>>> <address@hidden <mailto:address@hidden>>,
>>> ? ? ? ? "address@hidden
>>> <mailto:address@hidden>"? ? ? <address@hidden
>>> <mailto:address@hidden>>
>>> Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
>>> ? ? ? ? commands to USRP with gnuradio
>>> Message-ID: <address@hidden
>>> <mailto:address@hidden>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hi Samuel,
>>>
>>> so, my guess is that once again, we're running into the C++-specific
>>> static initialization order fiasco (SIOF, yes, it's a term) for the PMT
>>> keys used in the dicts.
>>>
>>> Solution: I've extracted functions to return these keys and statically
>>> initialize them but once, because PMT's pmt_symbol creation is
>>> relatively CPU-intense, and shouldn't be done at run time.
>>>
>>> Somehow, it seems, that can sometimes lead to different notions of the
>>> same symbol.
>>>
>>> Solution: I was going to go in there, and instead of having these
>>> functions that all look like
>>>
>>> const pmt::pmt_t gr::uhd::cmd_time_key()
>>> {
>>> ? static const pmt::pmt_t val
>>> = pmt::mp("time");
>>> ? return val;
>>> }
>>>
>>> just go in there, and give each instance of a usrp_block its own const
>>> fields of the same name, and initialize them in block constructor
>>> initialization list; that's what I did for the rest of GR, and I hope
>>> it works there.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On Thu, 2018-12-06 at 16:48 +0100, samuel verdon wrote:
>>> > Hi Marcus and Martin,
>>> > Thank you for your help!
>>> > Do you now how I can follow the problem?
>>> > Or if is it already solved, how can I fix it?
>>> >?
>>> > Thanks a lot!
>>> >?
>>> > Samuel
>>> >?
>>> >?
>>> > De : Marcus M?ller
>>> > Envoy? le :Wednesday, December 5, 2018 13:50
>>> > ? : address@hidden <mailto:address@hidden>;
>>> samuel verdon
>>> > Cc : Martin Braun
>>> > Objet :Re: [USRP-users] Segmentation fault commands to USRP with
>>> gnuradio
>>> >?
>>> > <ugly expletive>
>>> > this looks like my fault. Not feeling well enough to fix now, but wait
>>> > a day and I'll have something to test.
>>> > On Wed, 2018-12-05 at 12:56 +0100, Marcus M?ller wrote:
>>> > > Hi Samuel,
>>> > >
>>> > > cool! That's really helpful :)
>>> > >
>>> > > I'm now cross-posting this to discuss-gr, because it's a GNU Radio-
>>> > > land
>>> > > issue. The maintainers of gr-uhd are active over there, too, so this
>>> > > seems the smarter place to continue discussion.
>>> > >
>>> > >
>>> > > so, in medias res:
>>> > >
>>> > > On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
>>> > > > #3? 0x00007f7f15906700 in pmt::dict_has_key (dict=..., key=...) at
>>> > > > /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937
>>> > >
>>> > > m?p m???p. Our favorite (only) variadic type library leads to
>>> > > segfaults.
>>> > >
>>> > > I'll look into that and be back in a while.
>>> > >
>>> > > Best regards,
>>> > > Marcus
>>> > >
>>> >?
>>> >?
>>> > _______________________________________________
>>> > Discuss-gnuradio mailing list
>>> > address@hidden <mailto:address@hidden>
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Fri, 7 Dec 2018 10:30:34 +0000
>>> From: M?ller, Marcus (CEL) <address@hidden <mailto:address@hidden>>
>>> To: "address@hidden <mailto:address@hidden>"
>>> <address@hidden <mailto:address@hidden>>
>>> Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
>>> ? ? ? ? commands to USRP with gnuradio
>>> Message-ID: <address@hidden
>>> <mailto:address@hidden>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> By the way, I think the reason this goes wrong is that a) I've managed
>>> to run into the Static Initialization Order Fiasco, destructor edition,
>>> and b) that can't be solved with pmt_t, as pmt_t is actually a typedef
>>> for smart_pointer<actual_type>, and the moment the statically generated
>>> object (the smart pointer) leaves scope of the consuming function the
>>> first time, its destructor is being called.
>>>
>>> So, yay, if that assessment is correct, by putting PMT keys into the
>>> members of class instances, I've only postponed the problem you're
>>> seeing now to the destruction of blocks, and since that typically
>>> doesn't happen until the end of programs, it doesn't "hurt" anyone.
>>>
>>> It's still wrong, and would lead to unpredictable behaviour in case
>>> someone cleans up blocks at runtime. Which they should be able to do.
>>>
>>> Soooo argh. No simple solution here. Anyone a great idea?
>>>
>>> Best regards,
>>> Marcus
>>> On Fri, 2018-12-07 at 10:21 +0000, M?ller, Marcus (CEL) wrote:
>>> > Hi Samuel,
>>> >
>>> > so, my guess is that once again, we're running into the C++-specific
>>> > static initialization order fiasco (SIOF, yes, it's a term) for
>>> the PMT
>>> > keys used in the dicts.
>>> >
>>> > Solution: I've extracted functions to return these keys and statically
>>> > initialize them but once, because PMT's pmt_symbol creation is
>>> > relatively CPU-intense, and shouldn't be done at run time.
>>> >
>>> > Somehow, it seems, that can sometimes lead to different notions of the
>>> > same symbol.
>>> >
>>> > Solution: I was going to go in there, and instead of having these
>>> > functions that all look like
>>> >
>>> > const pmt::pmt_t gr::uhd::cmd_time_key()
>>> > {
>>> >? ?static const pmt::pmt_t val
>>> > = pmt::mp("time");
>>> >? ?return val;
>>> > }
>>> >
>>> > just go in there, and give each instance of a usrp_block its own const
>>> > fields of the same name, and initialize them in block constructor
>>> > initialization list; that's what I did for the rest of GR, and I hope
>>> > it works there.
>>> >
>>> > Best regards,
>>> > Marcus
>>> >
>>> > On Thu, 2018-12-06 at 16:48 +0100, samuel verdon wrote:
>>> > > Hi Marcus and Martin,
>>> > > Thank you for your help!
>>> > > Do you now how I can follow the problem?
>>> > > Or if is it already solved, how can I fix it?
>>> > >?
>>> > > Thanks a lot!
>>> > >?
>>> > > Samuel
>>> > >?
>>> > >?
>>> > > De : Marcus M?ller
>>> > > Envoy? le :Wednesday, December 5, 2018 13:50
>>> > > ? : address@hidden <mailto:address@hidden>;
>>> samuel verdon
>>> > > Cc : Martin Braun
>>> > > Objet :Re: [USRP-users] Segmentation fault commands to USRP with
>>> gnuradio
>>> > >?
>>> > > <ugly expletive>
>>> > > this looks like my fault. Not feeling well enough to fix now,
>>> but wait
>>> > > a day and I'll have something to test.
>>> > > On Wed, 2018-12-05 at 12:56 +0100, Marcus M?ller wrote:
>>> > > > Hi Samuel,
>>> > > >
>>> > > > cool! That's really helpful :)
>>> > > >
>>> > > > I'm now cross-posting this to discuss-gr, because it's a GNU
>>> Radio-
>>> > > > land
>>> > > > issue. The maintainers of gr-uhd are active over there, too,
>>> so this
>>> > > > seems the smarter place to continue discussion.
>>> > > >
>>> > > >
>>> > > > so, in medias res:
>>> > > >
>>> > > > On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
>>> > > > > #3? 0x00007f7f15906700 in pmt::dict_has_key (dict=...,
>>> key=...) at
>>> > > > > /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937
>>> > > >
>>> > > > m?p m???p. Our favorite (only) variadic type library leads to
>>> > > > segfaults.
>>> > > >
>>> > > > I'll look into that and be back in a while.
>>> > > >
>>> > > > Best regards,
>>> > > > Marcus
>>> > > >
>>> > >
>>> > >?
>>> > >?
>>> > > _______________________________________________
>>> > > Discuss-gnuradio mailing list
>>> > > address@hidden <mailto:address@hidden>
>>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> >
>>> > _______________________________________________
>>> > Discuss-gnuradio mailing list
>>> > address@hidden <mailto:address@hidden>
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>> ------------------------------
>>>
>>> Message: 5
>>> Date: Fri, 7 Dec 2018 13:00:53 +0100
>>> From: Christoph Mayer <address@hidden <mailto:address@hidden>>
>>> To: address@hidden <mailto:address@hidden>
>>> Cc: address@hidden <mailto:address@hidden>
>>> Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
>>> ? ? ? ? commands to USRP with gnuradio
>>> Message-ID:
>>> ? ? ? ?
>>> <address@hidden
>>> <mailto:address@hidden>>
>>> Content-Type: text/plain; charset="UTF-8"
>>>
>>> Hi Marcus,
>>>
>>> what is the reason for having
>>> ? typedef boost::intrusive_ptr<pmt_base> pmt_t;
>>> and not using a shared_ptr?
>>>
>>> As far as I understand, if a shared_ptr instead of
>>> boost::intrusive_ptr were used, one could use either the method
>>> described here:
>>>
>>> https://www.boost.org/doc/libs/1_68_0/libs/smart_ptr/doc/html/smart_ptr.html#techniques_static
>>> or use the aliasing constructor of a shared_ptr (probably better).
>>>
>>> Best regards
>>> Christoph
>>>
>>> On Fri, Dec 7, 2018 at 11:32 AM M?ller, Marcus (CEL)
>>> <address@hidden <mailto:address@hidden>> wrote:
>>> >
>>> > By the way, I think the reason this goes wrong is that a) I've managed
>>> > to run into the Static Initialization Order Fiasco, destructor
>>> edition,
>>> > and b) that can't be solved with pmt_t, as pmt_t is actually a typedef
>>> > for smart_pointer<actual_type>, and the moment the statically
>>> generated
>>> > object (the smart pointer) leaves scope of the consuming function the
>>> > first time, its destructor is being called.
>>> >
>>> > So, yay, if that assessment is correct, by putting PMT keys into the
>>> > members of class instances, I've only postponed the problem you're
>>> > seeing now to the destruction of blocks, and since that typically
>>> > doesn't happen until the end of programs, it doesn't "hurt" anyone.
>>> >
>>> > It's still wrong, and would lead to unpredictable behaviour in case
>>> > someone cleans up blocks at runtime. Which they should be able to do.
>>> >
>>> > Soooo argh. No simple solution here. Anyone a great idea?
>>> >
>>> > Best regards,
>>> > Marcus
>>> > On Fri, 2018-12-07 at 10:21 +0000, M?ller, Marcus (CEL) wrote:
>>> > > Hi Samuel,
>>> > >
>>> > > so, my guess is that once again, we're running into the C++-specific
>>> > > static initialization order fiasco (SIOF, yes, it's a term) for
>>> the PMT
>>> > > keys used in the dicts.
>>> > >
>>> > > Solution: I've extracted functions to return these keys and
>>> statically
>>> > > initialize them but once, because PMT's pmt_symbol creation is
>>> > > relatively CPU-intense, and shouldn't be done at run time.
>>> > >
>>> > > Somehow, it seems, that can sometimes lead to different notions
>>> of the
>>> > > same symbol.
>>> > >
>>> > > Solution: I was going to go in there, and instead of having these
>>> > > functions that all look like
>>> > >
>>> > > const pmt::pmt_t gr::uhd::cmd_time_key()
>>> > > {
>>> > >? ?static const pmt::pmt_t val
>>> > > = pmt::mp("time");
>>> > >? ?return val;
>>> > > }
>>> > >
>>> > > just go in there, and give each instance of a usrp_block its own
>>> const
>>> > > fields of the same name, and initialize them in block constructor
>>> > > initialization list; that's what I did for the rest of GR, and I
>>> hope
>>> > > it works there.
>>> > >
>>> > > Best regards,
>>> > > Marcus
>>> > >
>>> > > On Thu, 2018-12-06 at 16:48 +0100, samuel verdon wrote:
>>> > > > Hi Marcus and Martin,
>>> > > > Thank you for your help!
>>> > > > Do you now how I can follow the problem?
>>> > > > Or if is it already solved, how can I fix it?
>>> > > >
>>> > > > Thanks a lot!
>>> > > >
>>> > > > Samuel
>>> > > >
>>> > > >
>>> > > > De : Marcus M?ller
>>> > > > Envoy? le :Wednesday, December 5, 2018 13:50
>>> > > > ? : address@hidden
>>> <mailto:address@hidden>; samuel verdon
>>> > > > Cc : Martin Braun
>>> > > > Objet :Re: [USRP-users] Segmentation fault commands to USRP
>>> with gnuradio
>>> > > >
>>> > > > <ugly expletive>
>>> > > > this looks like my fault. Not feeling well enough to fix now,
>>> but wait
>>> > > > a day and I'll have something to test.
>>> > > > On Wed, 2018-12-05 at 12:56 +0100, Marcus M?ller wrote:
>>> > > > > Hi Samuel,
>>> > > > >
>>> > > > > cool! That's really helpful :)
>>> > > > >
>>> > > > > I'm now cross-posting this to discuss-gr, because it's a GNU
>>> Radio-
>>> > > > > land
>>> > > > > issue. The maintainers of gr-uhd are active over there, too,
>>> so this
>>> > > > > seems the smarter place to continue discussion.
>>> > > > >
>>> > > > >
>>> > > > > so, in medias res:
>>> > > > >
>>> > > > > On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
>>> > > > > > #3? 0x00007f7f15906700 in pmt::dict_has_key (dict=...,
>>> key=...) at
>>> > > > > > /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937
>>> > > > >
>>> > > > > m?p m???p. Our favorite (only) variadic type library leads to
>>> > > > > segfaults.
>>> > > > >
>>> > > > > I'll look into that and be back in a while.
>>> > > > >
>>> > > > > Best regards,
>>> > > > > Marcus
>>> > > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > _______________________________________________
>>> > > > Discuss-gnuradio mailing list
>>> > > > address@hidden <mailto:address@hidden>
>>> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> > >
>>> > > _______________________________________________
>>> > > Discuss-gnuradio mailing list
>>> > > address@hidden <mailto:address@hidden>
>>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> > _______________________________________________
>>> > Discuss-gnuradio mailing list
>>> > address@hidden <mailto:address@hidden>
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 6
>>> Date: Fri, 7 Dec 2018 12:13:24 +0000
>>> From: M?ller, Marcus (CEL) <address@hidden <mailto:address@hidden>>
>>> To: "address@hidden <mailto:address@hidden>" <address@hidden
>>> <mailto:address@hidden>>
>>> Cc: "address@hidden <mailto:address@hidden>"
>>> <address@hidden <mailto:address@hidden>>
>>> Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
>>> ? ? ? ? commands to USRP with gnuradio
>>> Message-ID: <address@hidden
>>> <mailto:address@hidden>>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hi Christoph,
>>>
>>> The ancient lore goes that this was a evaluation-based decision on
>>> account of performance. Technically, intrusive_ptr is nice because the
>>> object lies right next to the refcounter, so your memory controller can
>>> do the linear fetching thing and things should be nice without jumping
>>> through wildly different RAM areas.
>>>
>>> I haven't been able so far to produce a useful performance metric for
>>> PMT operations that reflects this, because real-world PMT usage is
>>> dominated by the efficiency of the involved operations, not by the
>>> smart pointer derefencing. I do, however, really believe this was done
>>> with serious evaluation of performance.
>>>
>>> Anyway, I'd love to change that, but it would be ? pun intended ? an
>>> intrusive API change, and tbh, I'm not sure I want to get all the tests
>>> for that change sorted out before 3.8's release. After 3.8, I'd like to
>>> get rid of PMT altogether.
>>> However, this situation here changes things. Maybe I'll whip up a test
>>> branch this weekend where I just go and make the exact change you
>>> recommend and test whether it works without further ado.
>>>
>>> Thanks! Haven't thought about that, and maybe things are really much
>>> easier than I was afraid they were.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On Fri, 2018-12-07 at 13:00 +0100, Christoph Mayer wrote:
>>> > Hi Marcus,
>>> >
>>> > what is the reason for having
>>> >? ?typedef boost::intrusive_ptr<pmt_base> pmt_t;
>>> > and not using a shared_ptr?
>>> >
>>> > As far as I understand, if a shared_ptr instead of
>>> > boost::intrusive_ptr were used, one could use either the method
>>> > described here:
>>> >
>>>
>>> https://www.boost.org/doc/libs/1_68_0/libs/smart_ptr/doc/html/smart_ptr.html#techniques_static
>>> > or use the aliasing constructor of a shared_ptr (probably better).
>>> >
>>> > Best regards
>>> > Christoph
>>> >
>>> > On Fri, Dec 7, 2018 at 11:32 AM M?ller, Marcus (CEL)
>>> <address@hidden <mailto:address@hidden>> wrote:
>>> > >
>>> > > By the way, I think the reason this goes wrong is that a) I've
>>> managed
>>> > > to run into the Static Initialization Order Fiasco, destructor
>>> edition,
>>> > > and b) that can't be solved with pmt_t, as pmt_t is actually a
>>> typedef
>>> > > for smart_pointer<actual_type>, and the moment the statically
>>> generated
>>> > > object (the smart pointer) leaves scope of the consuming
>>> function the
>>> > > first time, its destructor is being called.
>>> > >
>>> > > So, yay, if that assessment is correct, by putting PMT keys into the
>>> > > members of class instances, I've only postponed the problem you're
>>> > > seeing now to the destruction of blocks, and since that typically
>>> > > doesn't happen until the end of programs, it doesn't "hurt" anyone.
>>> > >
>>> > > It's still wrong, and would lead to unpredictable behaviour in case
>>> > > someone cleans up blocks at runtime. Which they should be able
>>> to do.
>>> > >
>>> > > Soooo argh. No simple solution here. Anyone a great idea?
>>> > >
>>> > > Best regards,
>>> > > Marcus
>>> > > On Fri, 2018-12-07 at 10:21 +0000, M?ller, Marcus (CEL) wrote:
>>> > > > Hi Samuel,
>>> > > >
>>> > > > so, my guess is that once again, we're running into the
>>> C++-specific
>>> > > > static initialization order fiasco (SIOF, yes, it's a term)
>>> for the PMT
>>> > > > keys used in the dicts.
>>> > > >
>>> > > > Solution: I've extracted functions to return these keys and
>>> statically
>>> > > > initialize them but once, because PMT's pmt_symbol creation is
>>> > > > relatively CPU-intense, and shouldn't be done at run time.
>>> > > >
>>> > > > Somehow, it seems, that can sometimes lead to different
>>> notions of the
>>> > > > same symbol.
>>> > > >
>>> > > > Solution: I was going to go in there, and instead of having these
>>> > > > functions that all look like
>>> > > >
>>> > > > const pmt::pmt_t gr::uhd::cmd_time_key()
>>> > > > {
>>> > > >? ?static const pmt::pmt_t val
>>> > > > = pmt::mp("time");
>>> > > >? ?return val;
>>> > > > }
>>> > > >
>>> > > > just go in there, and give each instance of a usrp_block its
>>> own const
>>> > > > fields of the same name, and initialize them in block constructor
>>> > > > initialization list; that's what I did for the rest of GR, and
>>> I hope
>>> > > > it works there.
>>> > > >
>>> > > > Best regards,
>>> > > > Marcus
>>> > > >
>>> > > > On Thu, 2018-12-06 at 16:48 +0100, samuel verdon wrote:
>>> > > > > Hi Marcus and Martin,
>>> > > > > Thank you for your help!
>>> > > > > Do you now how I can follow the problem?
>>> > > > > Or if is it already solved, how can I fix it?
>>> > > > >
>>> > > > > Thanks a lot!
>>> > > > >
>>> > > > > Samuel
>>> > > > >
>>> > > > >
>>> > > > > De : Marcus M?ller
>>> > > > > Envoy? le :Wednesday, December 5, 2018 13:50
>>> > > > > ? : address@hidden
>>> <mailto:address@hidden>; samuel verdon
>>> > > > > Cc : Martin Braun
>>> > > > > Objet :Re: [USRP-users] Segmentation fault commands to USRP
>>> with gnuradio
>>> > > > >
>>> > > > > <ugly expletive>
>>> > > > > this looks like my fault. Not feeling well enough to fix
>>> now, but wait
>>> > > > > a day and I'll have something to test.
>>> > > > > On Wed, 2018-12-05 at 12:56 +0100, Marcus M?ller wrote:
>>> > > > > > Hi Samuel,
>>> > > > > >
>>> > > > > > cool! That's really helpful :)
>>> > > > > >
>>> > > > > > I'm now cross-posting this to discuss-gr, because it's a
>>> GNU Radio-
>>> > > > > > land
>>> > > > > > issue. The maintainers of gr-uhd are active over there,
>>> too, so this
>>> > > > > > seems the smarter place to continue discussion.
>>> > > > > >
>>> > > > > >
>>> > > > > > so, in medias res:
>>> > > > > >
>>> > > > > > On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
>>> > > > > > > #3? 0x00007f7f15906700 in pmt::dict_has_key (dict=...,
>>> key=...) at
>>> > > > > > > /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937
>>> > > > > >
>>> > > > > > m?p m???p. Our favorite (only) variadic type library leads to
>>> > > > > > segfaults.
>>> > > > > >
>>> > > > > > I'll look into that and be back in a while.
>>> > > > > >
>>> > > > > > Best regards,
>>> > > > > > Marcus
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > _______________________________________________
>>> > > > > Discuss-gnuradio mailing list
>>> > > > > address@hidden <mailto:address@hidden>
>>> > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> > > >
>>> > > > _______________________________________________
>>> > > > Discuss-gnuradio mailing list
>>> > > > address@hidden <mailto:address@hidden>
>>> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> > >
>>> > > _______________________________________________
>>> > > Discuss-gnuradio mailing list
>>> > > address@hidden <mailto:address@hidden>
>>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>> ------------------------------
>>>
>>> Message: 7
>>> Date: Fri, 7 Dec 2018 16:21:53 +0000
>>> From: Guilherme Theis <address@hidden
>>> <mailto:address@hidden>>
>>> To: "address@hidden <mailto:address@hidden>"
>>> <address@hidden <mailto:address@hidden>>
>>> Subject: [Discuss-gnuradio] Receiving NOAA signals and passing to BB
>>> Message-ID:
>>> ? ? ? ?
>>> <address@hidden
>>> <mailto:address@hidden>>
>>>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Hello,
>>>
>>> I've been looking up for a way to use an USRP+Gnuradio to simply
>>> receive the HRPT signals and generate an .wav output to be processed
>>> afterwards But all I can find is this processing using a .wav input
>>> in the flow. There is any way to demodulate this split-phase
>>> modulation from NOAA using GRC?
>>>
>>> Best regards,
>>>
>>> Guilherme
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>>
>>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181207/3ab07632/attachment.html>
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden <mailto:address@hidden>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>> ------------------------------
>>>
>>> End of Discuss-gnuradio Digest, Vol 194, Issue 6
>>> ************************************************
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: broadcast_fm.grc
>> Type: text/xml
>> Size: 55778 bytes
>> Desc: not available
>> URL:
>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181209/34173e0e/attachment.xml>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sun, 9 Dec 2018 21:00:59 -0800
>> From: Cinaed Simson <address@hidden>
>> To: address@hidden
>> Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
>> flowchart. Getting multiple stations in a rtlsdr (Derek Kozel)
>> (Michael Dickens)
>> Message-ID: <address@hidden>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Yikes, I was playing quad_rate to see if I could change the behavior of
>> my audio problem - I couldn't - but I forgot to restore to the correct
>> quad_rate.
>>
>> Enclosed is the corrected version.
>>
>> The quad_rate should be set to
>>
>> channel_width*12/5.
>>
>> -- Cinaed
>>
>> On 12/09/2018 01:39 PM, Cinaed Simson wrote:
>>> Here's an example of broadcast FM. It's from the first couple of
>>> tutorials at
>>>
>>> https://greatscottgadgets.com/sdr
>>>
>>> All you need to do is to change the samp rate and the center_freq, and
>>> swap out the osmocom Source for the RTL-SDR Source.
>>>
>>> Since each channel is roughly 200 kHz wide, you probably won't get more
>>> then 2 stations at a sampling rate of 2 MHz.
>>>
>>> I have HackRF One and it runs fine on my i7 at sampling rate of 20 MHz.
>>>
>>> However, this was the first time I tried on the i7 - and when I drop
>>> the sampling rate to 2 MHz, I got the 'Ua's - audio underflows,
>>>
>>> But it sounded fine. Not sure what is causing the audio underflow.
>>>
>>> I would guess you should be able to replace the "Signal
>>> Source/Multiply/Low Pass Filter" with the "Frequency Xlating FIR Filter"
>>> or the "Low Pass Filter/Rational Resampler" with the polyphase filter bank.
>>>
>>> -- Cinaed
>>>
>>>
>>> On 12/07/2018 11:33 AM, Luis Roca wrote:
>>>> Thanks!
>>>>
>>>> On Fri, Dec 7, 2018 at 1:12 PM <address@hidden
>>>> <mailto:address@hidden>> wrote:
>>>>
>>>> Send Discuss-gnuradio mailing list submissions to
>>>> ? ? ? ? address@hidden <mailto:address@hidden>
>>>>
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>> ? ? ? ? https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>> or, via email, send a message with subject or body 'help' to
>>>> ? ? ? ? address@hidden
>>>> <mailto:address@hidden>
>>>>
>>>> You can reach the person managing the list at
>>>> ? ? ? ? address@hidden
>>>> <mailto:address@hidden>
>>>>
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of Discuss-gnuradio digest..."
>>>>
>>>>
>>>> Today's Topics:
>>>>
>>>> ? ?1. Re: help: optimizing a fm broadcast flowchart. Getting
>>>> ? ? ? multiple stations in a rtlsdr (Derek Kozel) (Luis Roca)
>>>> ? ?2. Re: help: optimizing a fm broadcast flowchart. Getting
>>>> ? ? ? multiple stations in a rtlsdr (Derek Kozel) (Michael Dickens)
>>>> ? ?3. Re: [USRP-users] Segmentation fault commands to USRP with
>>>> ? ? ? gnuradio (M?ller)
>>>> ? ?4. Re: [USRP-users] Segmentation fault commands to USRP with
>>>> ? ? ? gnuradio (M?ller)
>>>> ? ?5. Re: [USRP-users] Segmentation fault commands to USRP with
>>>> ? ? ? gnuradio (Christoph Mayer)
>>>> ? ?6. Re: [USRP-users] Segmentation fault commands to USRP with
>>>> ? ? ? gnuradio (M?ller)
>>>> ? ?7. Receiving NOAA signals and passing to BB (Guilherme Theis)
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Thu, 6 Dec 2018 13:17:01 -0400
>>>> From: Luis Roca <address@hidden <mailto:address@hidden>>
>>>> To: address@hidden <mailto:address@hidden>
>>>> Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
>>>> ? ? ? ? flowchart. Getting multiple stations in a rtlsdr (Derek Kozel)
>>>> Message-ID:
>>>> ? ? ? ?
>>>> <address@hidden
>>>> <mailto:address@hidden>>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> Thanks for your response Derek, we are using a FIR filter. I am
>>>> including
>>>> the flowchart
>>>>
>>>> On Thu, Dec 6, 2018 at 1:01 PM <address@hidden
>>>> <mailto:address@hidden>> wrote:
>>>>
>>>> > Send Discuss-gnuradio mailing list submissions to
>>>> >? ? ? ? address@hidden <mailto:address@hidden>
>>>> >
>>>> > To subscribe or unsubscribe via the World Wide Web, visit
>>>> >? ? ? ? ?https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>> > or, via email, send a message with subject or body 'help' to
>>>> >? ? ? ? address@hidden
>>>> <mailto:address@hidden>
>>>> >
>>>> > You can reach the person managing the list at
>>>> >? ? ? ? address@hidden
>>>> <mailto:address@hidden>
>>>> >
>>>> > When replying, please edit your Subject line so it is more specific
>>>> > than "Re: Contents of Discuss-gnuradio digest..."
>>>> >
>>>> >
>>>> > Today's Topics:
>>>> >
>>>> >? ? 1. help: optimizing a fm broadcast flowchart. Getting multiple
>>>> >? ? ? ?stations in a rtlsdr (Luis Roca)
>>>> >? ? 2. Re: help: optimizing a fm broadcast flowchart. Getting
>>>> >? ? ? ?multiple stations in a rtlsdr (Derek Kozel)
>>>> >? ? 3. Re: [USRP-users] Segmentation fault commands to USRP with
>>>> >? ? ? ?gnuradio (samuel verdon)
>>>> >? ? 4. Lock/unlock? (Albin Stig?)
>>>> >
>>>> >
>>>> >
>>>> ----------------------------------------------------------------------
>>>> >
>>>> > Message: 1
>>>> > Date: Wed, 5 Dec 2018 20:54:52 -0400
>>>> > From: Luis Roca <address@hidden <mailto:address@hidden>>
>>>> > To: address@hidden <mailto:address@hidden>
>>>> > Subject: [Discuss-gnuradio] help: optimizing a fm broadcast
>>>> flowchart.
>>>> >? ? ? ? ?Getting multiple stations in a rtlsdr
>>>> > Message-ID:
>>>> >? ? ? ? ?<CALNke=
>>>> > address@hidden
>>>> <mailto:address@hidden>>
>>>> > Content-Type: text/plain; charset="utf-8"
>>>> >
>>>> > Thanks for this great software. We are tinkering with a setup for
>>>> listening
>>>> > to radio and storing the streams as wavs.? We have two challenges
>>>> that we
>>>> > haven't been able to tackle satisfactorily.? Any help would be
>>>> appreciated.
>>>> >
>>>> > 1. What do we need in order to tune into as many stations as an
>>>> rtlsdr can
>>>> > fit in its bandwidth and create wav files for each one. In our
>>>> setup we use
>>>> > each sdr for a single station but scaling is a challenge.
>>>> >
>>>> > 2. How can we optimize our existing flowchart ( included
>>>> screenshot) for
>>>> > broadcasting wavs from the computer thru a hackRF.? We use this
>>>> for testing
>>>> > the sdr setup.
>>>> >
>>>> > Thanks all,
>>>> > Luis
>>>> > -------------- next part --------------
>>>> > An HTML attachment was scrubbed...
>>>> > URL: <
>>>> >
>>>>
>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181205/f813c036/attachment.html
>>>> > >
>>>> >
>>>> > ------------------------------
>>>> >
>>>> > Message: 2
>>>> > Date: Thu, 6 Dec 2018 13:50:09 +0000
>>>> > From: Derek Kozel <address@hidden
>>>> <mailto:address@hidden>>
>>>> > To: address@hidden <mailto:address@hidden>
>>>> > Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
>>>> >? ? ? ? ?flowchart. Getting multiple stations in a rtlsdr
>>>> > Message-ID: <address@hidden
>>>> <mailto:address@hidden>>
>>>> > Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>> >
>>>> > Hi Luis,
>>>> >
>>>> > At least on my end I can't see an attachment. Since FM broadcast
>>>> > stations are regularly spaced the polyphase filterbank is a good
>>>> choice
>>>> > for separating out each of the individual channels. You can then
>>>> use the
>>>> > same demodulation set of blocks and file sink that you're
>>>> (presumably)
>>>> > using now to handle each channel.
>>>> >
>>>> > Regards,
>>>> > Derek
>>>> >
>>>> > On 06/12/2018 00:54, Luis Roca wrote:
>>>> > > Thanks for this great software. We are tinkering with a setup for
>>>> > > listening to radio and storing the streams as wavs.? We have two
>>>> > > challenges that we haven't been able to tackle satisfactorily.? Any
>>>> > > help would be appreciated.
>>>> > >
>>>> > > 1. What do we need in order to tune into as many stations as an
>>>> rtlsdr
>>>> > > can fit in its bandwidth and create wav files for each one. In our
>>>> > > setup we use each sdr for a single station but scaling is a
>>>> challenge.
>>>> > >
>>>> > > 2. How can we optimize our existing flowchart ( included
>>>> screenshot)
>>>> > > for broadcasting wavs from the computer thru a hackRF.? We use this
>>>> > > for testing the sdr setup.
>>>> > >
>>>> > > Thanks all,
>>>> > > Luis
>>>> > >
>>>> > > _______________________________________________
>>>> > > Discuss-gnuradio mailing list
>>>> > > address@hidden <mailto:address@hidden>
>>>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>> >
>>>> > -------------- next part --------------
>>>> > An HTML attachment was scrubbed...
>>>> > URL: <
>>>> >
>>>>
>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/4b58fd34/attachment.html
>>>> > >
>>>> >
>>>> > ------------------------------
>>>> >
>>>> > Message: 3
>>>> > Date: Thu, 6 Dec 2018 16:48:52 +0100
>>>> > From: samuel verdon <address@hidden
>>>> <mailto:address@hidden>>
>>>> > To: Marcus M?ller <address@hidden
>>>> <mailto:address@hidden>>,
>>>> >? ? ? ? ?"address@hidden
>>>> <mailto:address@hidden>" <address@hidden
>>>> <mailto:address@hidden>>
>>>> > Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
>>>> >? ? ? ? ?commands to USRP with gnuradio
>>>> > Message-ID: <address@hidden
>>>> <mailto:address@hidden>>
>>>> > Content-Type: text/plain; charset="utf-8"
>>>> >
>>>> > Hi Marcus and Martin,
>>>> > Thank you for your help!
>>>> > Do you now how I can follow the problem?
>>>> > Or if is it already solved, how can I fix it?
>>>> >
>>>> > Thanks a lot!
>>>> >
>>>> > Samuel
>>>> >
>>>> >
>>>> > De?: Marcus M?ller
>>>> > Envoy? le?:Wednesday, December 5, 2018 13:50
>>>> > ??: address@hidden <mailto:address@hidden>;
>>>> samuel verdon
>>>> > Cc?: Martin Braun
>>>> > Objet?:Re: [USRP-users] Segmentation fault commands to USRP with
>>>> gnuradio
>>>> >
>>>> > <ugly expletive>
>>>> > this looks like my fault. Not feeling well enough to fix now, but
>>>> wait
>>>> > a day and I'll have something to test.
>>>> > On Wed, 2018-12-05 at 12:56 +0100, Marcus M?ller wrote:
>>>> > > Hi Samuel,
>>>> > >
>>>> > > cool! That's really helpful :)
>>>> > >
>>>> > > I'm now cross-posting this to discuss-gr, because it's a GNU Radio-
>>>> > > land
>>>> > > issue. The maintainers of gr-uhd are active over there, too, so
>>>> this
>>>> > > seems the smarter place to continue discussion.
>>>> > >
>>>> > >
>>>> > > so, in medias res:
>>>> > >
>>>> > > On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
>>>> > > > #3? 0x00007f7f15906700 in pmt::dict_has_key (dict=..., key=...)
>>>> at
>>>> > > > /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937
>>>> > >
>>>> > > m?p m???p. Our favorite (only) variadic type library leads to
>>>> > > segfaults.
>>>> > >
>>>> > > I'll look into that and be back in a while.
>>>> > >
>>>> > > Best regards,
>>>> > > Marcus
>>>> > >
>>>> >
>>>> >
>>>> > -------------- next part --------------
>>>> > An HTML attachment was scrubbed...
>>>> > URL: <
>>>> >
>>>>
>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/0116089a/attachment.html
>>>> > >
>>>> >
>>>> > ------------------------------
>>>> >
>>>> > Message: 4
>>>> > Date: Thu, 6 Dec 2018 17:51:39 +0100
>>>> > From: Albin Stig? <address@hidden
>>>> <mailto:address@hidden>>
>>>> > To: GNURadio Discussion List <address@hidden
>>>> <mailto:address@hidden>>
>>>> > Subject: [Discuss-gnuradio] Lock/unlock?
>>>> > Message-ID:
>>>> >? ? ? ? ?<
>>>> > address@hidden
>>>> <mailto:address@hidden>>
>>>> > Content-Type: text/plain; charset="utf-8"
>>>> >
>>>> > Does calling lock/unlock on a top block call the stop method on
>>>> connected
>>>> > blocks? And does it flush/empty buffers?
>>>> >
>>>> >
>>>> > --Albin
>>>> > -------------- next part --------------
>>>> > An HTML attachment was scrubbed...
>>>> > URL: <
>>>> >
>>>>
>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/4fd8d57e/attachment.html
>>>> > >
>>>> >
>>>> > ------------------------------
>>>> >
>>>> > Subject: Digest Footer
>>>> >
>>>> > _______________________________________________
>>>> > Discuss-gnuradio mailing list
>>>> > address@hidden <mailto:address@hidden>
>>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>> >
>>>> >
>>>> > ------------------------------
>>>> >
>>>> > End of Discuss-gnuradio Digest, Vol 194, Issue 5
>>>> > ************************************************
>>>> >
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL:
>>>>
>>>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/ab22faea/attachment.html>
>>>> -------------- next part --------------
>>>> A non-text attachment was scrubbed...
>>>> Name: Screen Shot 2018-12-06 at 12.10.23 PM.jpeg
>>>> Type: image/jpeg
>>>> Size: 241723 bytes
>>>> Desc: not available
>>>> URL:
>>>>
>>>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/ab22faea/attachment.jpeg>
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 2
>>>> Date: Thu, 06 Dec 2018 12:33:56 -0500
>>>> From: Michael Dickens <address@hidden
>>>> <mailto:address@hidden>>
>>>> To: Luis Roca <address@hidden
>>>> <mailto:address@hidden>>, address@hidden
>>>> <mailto:address@hidden>
>>>> Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
>>>> ? ? ? ? flowchart. Getting multiple stations in a rtlsdr (Derek Kozel)
>>>> Message-ID:
>>>> ? ? ? ?
>>>> <address@hidden
>>>> <mailto:address@hidden>>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> Unless your host computer's CPU is way underpowered, I'm with Derek
>>>> here: use polyphase filterbanks to channelize into 200 kHz bandwidth
>>>> per
>>>> channel, then have a bank of FM demodulators, one per channel. Output
>>>> to
>>>> files, or display, or whatever you need. - MLD
>>>> On Thu, Dec 6, 2018, at 12:17 PM, Luis Roca wrote:
>>>> > Thanks for your response Derek, we are using a FIR filter. I am
>>>> > including the flowchart> Email had 1 attachment:
>>>> >? * Screen Shot 2018-12-06 at 12.10.23 PM.jpeg 331k (image/jpeg)
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL:
>>>>
>>>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181206/46a4e5f9/attachment.html>
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 3
>>>> Date: Fri, 7 Dec 2018 10:21:24 +0000
>>>> From: M?ller, Marcus (CEL) <address@hidden <mailto:address@hidden>>
>>>> To: "address@hidden <mailto:address@hidden>"
>>>> <address@hidden <mailto:address@hidden>>,
>>>> ? ? ? ? "address@hidden <mailto:address@hidden>"
>>>> <address@hidden <mailto:address@hidden>>,
>>>> ? ? ? ? "address@hidden
>>>> <mailto:address@hidden>"? ? ? <address@hidden
>>>> <mailto:address@hidden>>
>>>> Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
>>>> ? ? ? ? commands to USRP with gnuradio
>>>> Message-ID: <address@hidden
>>>> <mailto:address@hidden>>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> Hi Samuel,
>>>>
>>>> so, my guess is that once again, we're running into the C++-specific
>>>> static initialization order fiasco (SIOF, yes, it's a term) for the PMT
>>>> keys used in the dicts.
>>>>
>>>> Solution: I've extracted functions to return these keys and statically
>>>> initialize them but once, because PMT's pmt_symbol creation is
>>>> relatively CPU-intense, and shouldn't be done at run time.
>>>>
>>>> Somehow, it seems, that can sometimes lead to different notions of the
>>>> same symbol.
>>>>
>>>> Solution: I was going to go in there, and instead of having these
>>>> functions that all look like
>>>>
>>>> const pmt::pmt_t gr::uhd::cmd_time_key()
>>>> {
>>>> ? static const pmt::pmt_t val
>>>> = pmt::mp("time");
>>>> ? return val;
>>>> }
>>>>
>>>> just go in there, and give each instance of a usrp_block its own const
>>>> fields of the same name, and initialize them in block constructor
>>>> initialization list; that's what I did for the rest of GR, and I hope
>>>> it works there.
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>> On Thu, 2018-12-06 at 16:48 +0100, samuel verdon wrote:
>>>> > Hi Marcus and Martin,
>>>> > Thank you for your help!
>>>> > Do you now how I can follow the problem?
>>>> > Or if is it already solved, how can I fix it?
>>>> >?
>>>> > Thanks a lot!
>>>> >?
>>>> > Samuel
>>>> >?
>>>> >?
>>>> > De : Marcus M?ller
>>>> > Envoy? le :Wednesday, December 5, 2018 13:50
>>>> > ? : address@hidden <mailto:address@hidden>;
>>>> samuel verdon
>>>> > Cc : Martin Braun
>>>> > Objet :Re: [USRP-users] Segmentation fault commands to USRP with
>>>> gnuradio
>>>> >?
>>>> > <ugly expletive>
>>>> > this looks like my fault. Not feeling well enough to fix now, but
>>>> wait
>>>> > a day and I'll have something to test.
>>>> > On Wed, 2018-12-05 at 12:56 +0100, Marcus M?ller wrote:
>>>> > > Hi Samuel,
>>>> > >
>>>> > > cool! That's really helpful :)
>>>> > >
>>>> > > I'm now cross-posting this to discuss-gr, because it's a GNU Radio-
>>>> > > land
>>>> > > issue. The maintainers of gr-uhd are active over there, too, so
>>>> this
>>>> > > seems the smarter place to continue discussion.
>>>> > >
>>>> > >
>>>> > > so, in medias res:
>>>> > >
>>>> > > On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
>>>> > > > #3? 0x00007f7f15906700 in pmt::dict_has_key (dict=..., key=...)
>>>> at
>>>> > > > /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937
>>>> > >
>>>> > > m?p m???p. Our favorite (only) variadic type library leads to
>>>> > > segfaults.
>>>> > >
>>>> > > I'll look into that and be back in a while.
>>>> > >
>>>> > > Best regards,
>>>> > > Marcus
>>>> > >
>>>> >?
>>>> >?
>>>> > _______________________________________________
>>>> > Discuss-gnuradio mailing list
>>>> > address@hidden <mailto:address@hidden>
>>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 4
>>>> Date: Fri, 7 Dec 2018 10:30:34 +0000
>>>> From: M?ller, Marcus (CEL) <address@hidden <mailto:address@hidden>>
>>>> To: "address@hidden <mailto:address@hidden>"
>>>> <address@hidden <mailto:address@hidden>>
>>>> Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
>>>> ? ? ? ? commands to USRP with gnuradio
>>>> Message-ID: <address@hidden
>>>> <mailto:address@hidden>>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> By the way, I think the reason this goes wrong is that a) I've managed
>>>> to run into the Static Initialization Order Fiasco, destructor edition,
>>>> and b) that can't be solved with pmt_t, as pmt_t is actually a typedef
>>>> for smart_pointer<actual_type>, and the moment the statically generated
>>>> object (the smart pointer) leaves scope of the consuming function the
>>>> first time, its destructor is being called.
>>>>
>>>> So, yay, if that assessment is correct, by putting PMT keys into the
>>>> members of class instances, I've only postponed the problem you're
>>>> seeing now to the destruction of blocks, and since that typically
>>>> doesn't happen until the end of programs, it doesn't "hurt" anyone.
>>>>
>>>> It's still wrong, and would lead to unpredictable behaviour in case
>>>> someone cleans up blocks at runtime. Which they should be able to do.
>>>>
>>>> Soooo argh. No simple solution here. Anyone a great idea?
>>>>
>>>> Best regards,
>>>> Marcus
>>>> On Fri, 2018-12-07 at 10:21 +0000, M?ller, Marcus (CEL) wrote:
>>>> > Hi Samuel,
>>>> >
>>>> > so, my guess is that once again, we're running into the C++-specific
>>>> > static initialization order fiasco (SIOF, yes, it's a term) for
>>>> the PMT
>>>> > keys used in the dicts.
>>>> >
>>>> > Solution: I've extracted functions to return these keys and
>>>> statically
>>>> > initialize them but once, because PMT's pmt_symbol creation is
>>>> > relatively CPU-intense, and shouldn't be done at run time.
>>>> >
>>>> > Somehow, it seems, that can sometimes lead to different notions of
>>>> the
>>>> > same symbol.
>>>> >
>>>> > Solution: I was going to go in there, and instead of having these
>>>> > functions that all look like
>>>> >
>>>> > const pmt::pmt_t gr::uhd::cmd_time_key()
>>>> > {
>>>> >? ?static const pmt::pmt_t val
>>>> > = pmt::mp("time");
>>>> >? ?return val;
>>>> > }
>>>> >
>>>> > just go in there, and give each instance of a usrp_block its own
>>>> const
>>>> > fields of the same name, and initialize them in block constructor
>>>> > initialization list; that's what I did for the rest of GR, and I hope
>>>> > it works there.
>>>> >
>>>> > Best regards,
>>>> > Marcus
>>>> >
>>>> > On Thu, 2018-12-06 at 16:48 +0100, samuel verdon wrote:
>>>> > > Hi Marcus and Martin,
>>>> > > Thank you for your help!
>>>> > > Do you now how I can follow the problem?
>>>> > > Or if is it already solved, how can I fix it?
>>>> > >?
>>>> > > Thanks a lot!
>>>> > >?
>>>> > > Samuel
>>>> > >?
>>>> > >?
>>>> > > De : Marcus M?ller
>>>> > > Envoy? le :Wednesday, December 5, 2018 13:50
>>>> > > ? : address@hidden <mailto:address@hidden>;
>>>> samuel verdon
>>>> > > Cc : Martin Braun
>>>> > > Objet :Re: [USRP-users] Segmentation fault commands to USRP with
>>>> gnuradio
>>>> > >?
>>>> > > <ugly expletive>
>>>> > > this looks like my fault. Not feeling well enough to fix now,
>>>> but wait
>>>> > > a day and I'll have something to test.
>>>> > > On Wed, 2018-12-05 at 12:56 +0100, Marcus M?ller wrote:
>>>> > > > Hi Samuel,
>>>> > > >
>>>> > > > cool! That's really helpful :)
>>>> > > >
>>>> > > > I'm now cross-posting this to discuss-gr, because it's a GNU
>>>> Radio-
>>>> > > > land
>>>> > > > issue. The maintainers of gr-uhd are active over there, too,
>>>> so this
>>>> > > > seems the smarter place to continue discussion.
>>>> > > >
>>>> > > >
>>>> > > > so, in medias res:
>>>> > > >
>>>> > > > On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
>>>> > > > > #3? 0x00007f7f15906700 in pmt::dict_has_key (dict=...,
>>>> key=...) at
>>>> > > > > /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937
>>>> > > >
>>>> > > > m?p m???p. Our favorite (only) variadic type library leads to
>>>> > > > segfaults.
>>>> > > >
>>>> > > > I'll look into that and be back in a while.
>>>> > > >
>>>> > > > Best regards,
>>>> > > > Marcus
>>>> > > >
>>>> > >
>>>> > >?
>>>> > >?
>>>> > > _______________________________________________
>>>> > > Discuss-gnuradio mailing list
>>>> > > address@hidden <mailto:address@hidden>
>>>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>> >
>>>> > _______________________________________________
>>>> > Discuss-gnuradio mailing list
>>>> > address@hidden <mailto:address@hidden>
>>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 5
>>>> Date: Fri, 7 Dec 2018 13:00:53 +0100
>>>> From: Christoph Mayer <address@hidden <mailto:address@hidden>>
>>>> To: address@hidden <mailto:address@hidden>
>>>> Cc: address@hidden <mailto:address@hidden>
>>>> Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
>>>> ? ? ? ? commands to USRP with gnuradio
>>>> Message-ID:
>>>> ? ? ? ?
>>>> <address@hidden
>>>> <mailto:address@hidden>>
>>>> Content-Type: text/plain; charset="UTF-8"
>>>>
>>>> Hi Marcus,
>>>>
>>>> what is the reason for having
>>>> ? typedef boost::intrusive_ptr<pmt_base> pmt_t;
>>>> and not using a shared_ptr?
>>>>
>>>> As far as I understand, if a shared_ptr instead of
>>>> boost::intrusive_ptr were used, one could use either the method
>>>> described here:
>>>>
>>>> https://www.boost.org/doc/libs/1_68_0/libs/smart_ptr/doc/html/smart_ptr.html#techniques_static
>>>> or use the aliasing constructor of a shared_ptr (probably better).
>>>>
>>>> Best regards
>>>> Christoph
>>>>
>>>> On Fri, Dec 7, 2018 at 11:32 AM M?ller, Marcus (CEL)
>>>> <address@hidden <mailto:address@hidden>> wrote:
>>>> >
>>>> > By the way, I think the reason this goes wrong is that a) I've
>>>> managed
>>>> > to run into the Static Initialization Order Fiasco, destructor
>>>> edition,
>>>> > and b) that can't be solved with pmt_t, as pmt_t is actually a
>>>> typedef
>>>> > for smart_pointer<actual_type>, and the moment the statically
>>>> generated
>>>> > object (the smart pointer) leaves scope of the consuming function the
>>>> > first time, its destructor is being called.
>>>> >
>>>> > So, yay, if that assessment is correct, by putting PMT keys into the
>>>> > members of class instances, I've only postponed the problem you're
>>>> > seeing now to the destruction of blocks, and since that typically
>>>> > doesn't happen until the end of programs, it doesn't "hurt" anyone.
>>>> >
>>>> > It's still wrong, and would lead to unpredictable behaviour in case
>>>> > someone cleans up blocks at runtime. Which they should be able to do.
>>>> >
>>>> > Soooo argh. No simple solution here. Anyone a great idea?
>>>> >
>>>> > Best regards,
>>>> > Marcus
>>>> > On Fri, 2018-12-07 at 10:21 +0000, M?ller, Marcus (CEL) wrote:
>>>> > > Hi Samuel,
>>>> > >
>>>> > > so, my guess is that once again, we're running into the
>>>> C++-specific
>>>> > > static initialization order fiasco (SIOF, yes, it's a term) for
>>>> the PMT
>>>> > > keys used in the dicts.
>>>> > >
>>>> > > Solution: I've extracted functions to return these keys and
>>>> statically
>>>> > > initialize them but once, because PMT's pmt_symbol creation is
>>>> > > relatively CPU-intense, and shouldn't be done at run time.
>>>> > >
>>>> > > Somehow, it seems, that can sometimes lead to different notions
>>>> of the
>>>> > > same symbol.
>>>> > >
>>>> > > Solution: I was going to go in there, and instead of having these
>>>> > > functions that all look like
>>>> > >
>>>> > > const pmt::pmt_t gr::uhd::cmd_time_key()
>>>> > > {
>>>> > >? ?static const pmt::pmt_t val
>>>> > > = pmt::mp("time");
>>>> > >? ?return val;
>>>> > > }
>>>> > >
>>>> > > just go in there, and give each instance of a usrp_block its own
>>>> const
>>>> > > fields of the same name, and initialize them in block constructor
>>>> > > initialization list; that's what I did for the rest of GR, and I
>>>> hope
>>>> > > it works there.
>>>> > >
>>>> > > Best regards,
>>>> > > Marcus
>>>> > >
>>>> > > On Thu, 2018-12-06 at 16:48 +0100, samuel verdon wrote:
>>>> > > > Hi Marcus and Martin,
>>>> > > > Thank you for your help!
>>>> > > > Do you now how I can follow the problem?
>>>> > > > Or if is it already solved, how can I fix it?
>>>> > > >
>>>> > > > Thanks a lot!
>>>> > > >
>>>> > > > Samuel
>>>> > > >
>>>> > > >
>>>> > > > De : Marcus M?ller
>>>> > > > Envoy? le :Wednesday, December 5, 2018 13:50
>>>> > > > ? : address@hidden
>>>> <mailto:address@hidden>; samuel verdon
>>>> > > > Cc : Martin Braun
>>>> > > > Objet :Re: [USRP-users] Segmentation fault commands to USRP
>>>> with gnuradio
>>>> > > >
>>>> > > > <ugly expletive>
>>>> > > > this looks like my fault. Not feeling well enough to fix now,
>>>> but wait
>>>> > > > a day and I'll have something to test.
>>>> > > > On Wed, 2018-12-05 at 12:56 +0100, Marcus M?ller wrote:
>>>> > > > > Hi Samuel,
>>>> > > > >
>>>> > > > > cool! That's really helpful :)
>>>> > > > >
>>>> > > > > I'm now cross-posting this to discuss-gr, because it's a GNU
>>>> Radio-
>>>> > > > > land
>>>> > > > > issue. The maintainers of gr-uhd are active over there, too,
>>>> so this
>>>> > > > > seems the smarter place to continue discussion.
>>>> > > > >
>>>> > > > >
>>>> > > > > so, in medias res:
>>>> > > > >
>>>> > > > > On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
>>>> > > > > > #3? 0x00007f7f15906700 in pmt::dict_has_key (dict=...,
>>>> key=...) at
>>>> > > > > > /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937
>>>> > > > >
>>>> > > > > m?p m???p. Our favorite (only) variadic type library leads to
>>>> > > > > segfaults.
>>>> > > > >
>>>> > > > > I'll look into that and be back in a while.
>>>> > > > >
>>>> > > > > Best regards,
>>>> > > > > Marcus
>>>> > > > >
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > _______________________________________________
>>>> > > > Discuss-gnuradio mailing list
>>>> > > > address@hidden <mailto:address@hidden>
>>>> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>> > >
>>>> > > _______________________________________________
>>>> > > Discuss-gnuradio mailing list
>>>> > > address@hidden <mailto:address@hidden>
>>>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>> > _______________________________________________
>>>> > Discuss-gnuradio mailing list
>>>> > address@hidden <mailto:address@hidden>
>>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 6
>>>> Date: Fri, 7 Dec 2018 12:13:24 +0000
>>>> From: M?ller, Marcus (CEL) <address@hidden <mailto:address@hidden>>
>>>> To: "address@hidden <mailto:address@hidden>" <address@hidden
>>>> <mailto:address@hidden>>
>>>> Cc: "address@hidden <mailto:address@hidden>"
>>>> <address@hidden <mailto:address@hidden>>
>>>> Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
>>>> ? ? ? ? commands to USRP with gnuradio
>>>> Message-ID: <address@hidden
>>>> <mailto:address@hidden>>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> Hi Christoph,
>>>>
>>>> The ancient lore goes that this was a evaluation-based decision on
>>>> account of performance. Technically, intrusive_ptr is nice because the
>>>> object lies right next to the refcounter, so your memory controller can
>>>> do the linear fetching thing and things should be nice without jumping
>>>> through wildly different RAM areas.
>>>>
>>>> I haven't been able so far to produce a useful performance metric for
>>>> PMT operations that reflects this, because real-world PMT usage is
>>>> dominated by the efficiency of the involved operations, not by the
>>>> smart pointer derefencing. I do, however, really believe this was done
>>>> with serious evaluation of performance.
>>>>
>>>> Anyway, I'd love to change that, but it would be ? pun intended ? an
>>>> intrusive API change, and tbh, I'm not sure I want to get all the tests
>>>> for that change sorted out before 3.8's release. After 3.8, I'd like to
>>>> get rid of PMT altogether.
>>>> However, this situation here changes things. Maybe I'll whip up a test
>>>> branch this weekend where I just go and make the exact change you
>>>> recommend and test whether it works without further ado.
>>>>
>>>> Thanks! Haven't thought about that, and maybe things are really much
>>>> easier than I was afraid they were.
>>>>
>>>> Best regards,
>>>> Marcus
>>>>
>>>>
>>>> On Fri, 2018-12-07 at 13:00 +0100, Christoph Mayer wrote:
>>>> > Hi Marcus,
>>>> >
>>>> > what is the reason for having
>>>> >? ?typedef boost::intrusive_ptr<pmt_base> pmt_t;
>>>> > and not using a shared_ptr?
>>>> >
>>>> > As far as I understand, if a shared_ptr instead of
>>>> > boost::intrusive_ptr were used, one could use either the method
>>>> > described here:
>>>> >
>>>>
>>>> https://www.boost.org/doc/libs/1_68_0/libs/smart_ptr/doc/html/smart_ptr.html#techniques_static
>>>> > or use the aliasing constructor of a shared_ptr (probably better).
>>>> >
>>>> > Best regards
>>>> > Christoph
>>>> >
>>>> > On Fri, Dec 7, 2018 at 11:32 AM M?ller, Marcus (CEL)
>>>> <address@hidden <mailto:address@hidden>> wrote:
>>>> > >
>>>> > > By the way, I think the reason this goes wrong is that a) I've
>>>> managed
>>>> > > to run into the Static Initialization Order Fiasco, destructor
>>>> edition,
>>>> > > and b) that can't be solved with pmt_t, as pmt_t is actually a
>>>> typedef
>>>> > > for smart_pointer<actual_type>, and the moment the statically
>>>> generated
>>>> > > object (the smart pointer) leaves scope of the consuming
>>>> function the
>>>> > > first time, its destructor is being called.
>>>> > >
>>>> > > So, yay, if that assessment is correct, by putting PMT keys into
>>>> the
>>>> > > members of class instances, I've only postponed the problem you're
>>>> > > seeing now to the destruction of blocks, and since that typically
>>>> > > doesn't happen until the end of programs, it doesn't "hurt" anyone.
>>>> > >
>>>> > > It's still wrong, and would lead to unpredictable behaviour in case
>>>> > > someone cleans up blocks at runtime. Which they should be able
>>>> to do.
>>>> > >
>>>> > > Soooo argh. No simple solution here. Anyone a great idea?
>>>> > >
>>>> > > Best regards,
>>>> > > Marcus
>>>> > > On Fri, 2018-12-07 at 10:21 +0000, M?ller, Marcus (CEL) wrote:
>>>> > > > Hi Samuel,
>>>> > > >
>>>> > > > so, my guess is that once again, we're running into the
>>>> C++-specific
>>>> > > > static initialization order fiasco (SIOF, yes, it's a term)
>>>> for the PMT
>>>> > > > keys used in the dicts.
>>>> > > >
>>>> > > > Solution: I've extracted functions to return these keys and
>>>> statically
>>>> > > > initialize them but once, because PMT's pmt_symbol creation is
>>>> > > > relatively CPU-intense, and shouldn't be done at run time.
>>>> > > >
>>>> > > > Somehow, it seems, that can sometimes lead to different
>>>> notions of the
>>>> > > > same symbol.
>>>> > > >
>>>> > > > Solution: I was going to go in there, and instead of having these
>>>> > > > functions that all look like
>>>> > > >
>>>> > > > const pmt::pmt_t gr::uhd::cmd_time_key()
>>>> > > > {
>>>> > > >? ?static const pmt::pmt_t val
>>>> > > > = pmt::mp("time");
>>>> > > >? ?return val;
>>>> > > > }
>>>> > > >
>>>> > > > just go in there, and give each instance of a usrp_block its
>>>> own const
>>>> > > > fields of the same name, and initialize them in block constructor
>>>> > > > initialization list; that's what I did for the rest of GR, and
>>>> I hope
>>>> > > > it works there.
>>>> > > >
>>>> > > > Best regards,
>>>> > > > Marcus
>>>> > > >
>>>> > > > On Thu, 2018-12-06 at 16:48 +0100, samuel verdon wrote:
>>>> > > > > Hi Marcus and Martin,
>>>> > > > > Thank you for your help!
>>>> > > > > Do you now how I can follow the problem?
>>>> > > > > Or if is it already solved, how can I fix it?
>>>> > > > >
>>>> > > > > Thanks a lot!
>>>> > > > >
>>>> > > > > Samuel
>>>> > > > >
>>>> > > > >
>>>> > > > > De : Marcus M?ller
>>>> > > > > Envoy? le :Wednesday, December 5, 2018 13:50
>>>> > > > > ? : address@hidden
>>>> <mailto:address@hidden>; samuel verdon
>>>> > > > > Cc : Martin Braun
>>>> > > > > Objet :Re: [USRP-users] Segmentation fault commands to USRP
>>>> with gnuradio
>>>> > > > >
>>>> > > > > <ugly expletive>
>>>> > > > > this looks like my fault. Not feeling well enough to fix
>>>> now, but wait
>>>> > > > > a day and I'll have something to test.
>>>> > > > > On Wed, 2018-12-05 at 12:56 +0100, Marcus M?ller wrote:
>>>> > > > > > Hi Samuel,
>>>> > > > > >
>>>> > > > > > cool! That's really helpful :)
>>>> > > > > >
>>>> > > > > > I'm now cross-posting this to discuss-gr, because it's a
>>>> GNU Radio-
>>>> > > > > > land
>>>> > > > > > issue. The maintainers of gr-uhd are active over there,
>>>> too, so this
>>>> > > > > > seems the smarter place to continue discussion.
>>>> > > > > >
>>>> > > > > >
>>>> > > > > > so, in medias res:
>>>> > > > > >
>>>> > > > > > On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
>>>> > > > > > > #3? 0x00007f7f15906700 in pmt::dict_has_key (dict=...,
>>>> key=...) at
>>>> > > > > > > /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937
>>>> > > > > >
>>>> > > > > > m?p m???p. Our favorite (only) variadic type library leads to
>>>> > > > > > segfaults.
>>>> > > > > >
>>>> > > > > > I'll look into that and be back in a while.
>>>> > > > > >
>>>> > > > > > Best regards,
>>>> > > > > > Marcus
>>>> > > > > >
>>>> > > > >
>>>> > > > >
>>>> > > > >
>>>> > > > > _______________________________________________
>>>> > > > > Discuss-gnuradio mailing list
>>>> > > > > address@hidden <mailto:address@hidden>
>>>> > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>> > > >
>>>> > > > _______________________________________________
>>>> > > > Discuss-gnuradio mailing list
>>>> > > > address@hidden <mailto:address@hidden>
>>>> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>> > >
>>>> > > _______________________________________________
>>>> > > Discuss-gnuradio mailing list
>>>> > > address@hidden <mailto:address@hidden>
>>>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 7
>>>> Date: Fri, 7 Dec 2018 16:21:53 +0000
>>>> From: Guilherme Theis <address@hidden
>>>> <mailto:address@hidden>>
>>>> To: "address@hidden <mailto:address@hidden>"
>>>> <address@hidden <mailto:address@hidden>>
>>>> Subject: [Discuss-gnuradio] Receiving NOAA signals and passing to BB
>>>> Message-ID:
>>>> ? ? ? ?
>>>> <address@hidden
>>>> <mailto:address@hidden>>
>>>>
>>>> Content-Type: text/plain; charset="iso-8859-1"
>>>>
>>>> Hello,
>>>>
>>>> I've been looking up for a way to use an USRP+Gnuradio to simply
>>>> receive the HRPT signals and generate an .wav output to be processed
>>>> afterwards But all I can find is this processing using a .wav input
>>>> in the flow. There is any way to demodulate this split-phase
>>>> modulation from NOAA using GRC?
>>>>
>>>> Best regards,
>>>>
>>>> Guilherme
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL:
>>>>
>>>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181207/3ab07632/attachment.html>
>>>>
>>>> ------------------------------
>>>>
>>>> Subject: Digest Footer
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> address@hidden <mailto:address@hidden>
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> End of Discuss-gnuradio Digest, Vol 194, Issue 6
>>>> ************************************************
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: broadcast_fm.grc
>> Type: text/xml
>> Size: 55768 bytes
>> Desc: not available
>> URL:
>> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20181209/87da6ccd/attachment.xml>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> ------------------------------
>>
>> End of Discuss-gnuradio Digest, Vol 194, Issue 8
>> ************************************************
>>
>> [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
>> Virus-free.
>> www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>