[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 13:39:00 -0800 |
|
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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