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 ?
Thanks,
Yusuf
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 ?
Thanks,
Yusuf
From: Discuss-gnuradio <discuss-gnuradio-bounces+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
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:
> ? ? ? ?
> <CALNke=J=5-V5e6FSpR+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:
> >? ? ? ? ?<
> > CAMc++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:
> ? ? ? ?
> <CAJahsjWMGnZJShTFH8-n+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:
>> ? ? ? ?
>> <CALNke=J=5-V5e6FSpR+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:
>> >? ? ? ? ?<
>> > CAMc++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:
>> ? ? ? ?
>> <CAJahsjWMGnZJShTFH8-n+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
************************************************
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:
> ? ? ? ?
> <CALNke=J=5-V5e6FSpR+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:
> >? ? ? ? ?<
> > CAMc++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:
> ? ? ? ?
> <CAJahsjWMGnZJShTFH8-n+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:
>> ? ? ? ?
>> <CALNke=J=5-V5e6FSpR+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:
>> >? ? ? ? ?<
>> > CAMc++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:
>> ? ? ? ?
>> <CAJahsjWMGnZJShTFH8-n+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
************************************************