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