|
| From: | Luis Roca |
| Subject: | Re: [Discuss-gnuradio] help: optimizing a fm broadcast flowchart. Getting multiple stations in a rtlsdr (Derek Kozel) (Michael Dickens) |
| Date: | Fri, 7 Dec 2018 15:33:26 -0400 |
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) (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>
To: address@hidden
Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
flowchart. Getting multiple stations in a rtlsdr (Derek Kozel)
Message-ID:
<CALNke=J=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> wrote:
> 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. 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>
> To: address@hidden
> Subject: [Discuss-gnuradio] help: optimizing a fm broadcast flowchart.
> Getting multiple stations in a rtlsdr
> Message-ID:
> <CALNke=
> 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>
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
> flowchart. Getting multiple stations in a rtlsdr
> Message-ID: <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
> > 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>
> To: Marcus M?ller <address@hidden>,
> "address@hidden" <address@hidden>
> Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
> commands to USRP with gnuradio
> Message-ID: <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; 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>
> To: GNURadio Discussion List <address@hidden>
> Subject: [Discuss-gnuradio] Lock/unlock?
> Message-ID:
> <
> 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
> 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>
To: Luis Roca <address@hidden>, address@hidden
Subject: Re: [Discuss-gnuradio] help: optimizing a fm broadcast
flowchart. Getting multiple stations in a rtlsdr (Derek Kozel)
Message-ID:
<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>
To: "address@hidden" <address@hidden>,
"address@hidden" <address@hidden>,
"address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
commands to USRP with gnuradio
Message-ID: <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; 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
> 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>
To: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
commands to USRP with gnuradio
Message-ID: <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; 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
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> _______________________________________________
> Discuss-gnuradio mailing list
> 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>
To: address@hidden
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
commands to USRP with gnuradio
Message-ID:
<CAJahsjWMGnZJShTFH8-n+hdz_0fqa5Zk4=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> 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; 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
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 6
Date: Fri, 7 Dec 2018 12:13:24 +0000
From: M?ller, Marcus (CEL) <address@hidden>
To: "address@hidden" <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] [USRP-users] Segmentation fault
commands to USRP with gnuradio
Message-ID: <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> 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; 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
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 7
Date: Fri, 7 Dec 2018 16:21:53 +0000
From: Guilherme Theis <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Receiving NOAA signals and passing to BB
Message-ID:
<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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
End of Discuss-gnuradio Digest, Vol 194, Issue 6
************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |