[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:32:38 -0500 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
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 ?
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
>