Re: [Discuss-gnuradio] Recurring memory leak problems with iterative decoding [ GNU Radio 3.7.11.1]

[Moses Browne Mwakyanjala]

Hello Ben,
In order to test the current hypothesis, I upgraded my system from Ubuntu
16.04 to 18.04 and GNU Radio from 3.7.11 to 3.7.13.5.
Still, the leak persists. Surprisingly, Michael didn't experience the issue
on his MacOS, running the exact code I'm running at the moment.
I'm not sure what could cause the issue in Ubuntu.

Regards,
Moses.

On Wed, May 15, 2019 at 7:46 AM Ben Hilburn  wrote:

> Sounds good, Moses! Keep us posted.
>
> Cheers,
> Ben
>
> On Sat, May 11, 2019 at 9:16 PM Moses Browne Mwakyanjala <
> mbkit...@gmail.com> wrote:
>
>> Hello Ben,
>> I did try to comment out the decode_u8 vector, without any luck.
>> Interestingly, Michael was able to run the program successfully on his
>> platform, which turned out to be much newer than the one I'm using (3.7.11).
>> I'm in the process of installing a new release of GNU Radio and test the
>> hypothesis. Unfortunately, the installation of the latest GNU Radio
>> releases is surprisingly painful and lengthy.
>> I will let you know what happens after I have tested the program on the
>> new installation.
>>
>> Regards,
>> Moses.
>>
>> On Thu, May 9, 2019 at 10:02 PM Ben Hilburn 
>> wrote:
>>
>>> Hey Moses -
>>>
>>> I don't have an immediate answer for you, but it seems likely the issue
>>> is with `decoded_u8`. Before spending time trying to debug why this might
>>> be happening when the code is used in GNU Radio versus not, it would be
>>> good to figure out where exactly the leak is occurring.
>>>
>>> You should be able to test the `decoded_u8` hypothesis by commenting out
>>> the existing malloc & free, and just using some hard-coded dummy vector or
>>> something similar. Your application obviously won't work, but what you care
>>> about is how that affects the memory leak.
>>>
>>> Separately, is there a reason you are dynamically allocating that
>>> vector? You are freeing the memory within the same scope, anyway. I guess
>>> I'm not sure how much data that realistically is, so perhaps that's why
>>> you're putting it on the heap?
>>>
>>> Cheers,
>>> Ben
>>>
>>> On Wed, May 8, 2019 at 1:33 PM Moses Browne Mwakyanjala <
>>> mbkit...@gmail.com> wrote:
>>>
 Hello Ben,
 Yes. There are no memory leaks when the block is disabled.

 Regards,
 Moses.

 On Wed, May 8, 2019 at 5:50 PM Ben Hilburn 
 wrote:

> Hi Moses -
>
> And just to confirm, if you remove your LDPC block from that flowgraph
> or replace it with a passthrough, you don't see the leak?
>
> Cheers,
> Ben
>
> On Tue, May 7, 2019 at 7:24 PM Moses Browne Mwakyanjala <
> mbkit...@gmail.com> wrote:
>
>> Hello Ben,
>> Thanks.
>> For LDPC, the executable can be found at
>>
>> *gr-ccsds/examples/LDPC/ldpc_2/build-ldpc_decoder-Desktop-Debug/ldpc_decoder.*
>> The C++ executable for Turbo code can be found at
>> *gr-ccsds/lib/fec/turbo/deepspace-turbo/bin/deepspace_turbo*
>>
>> I'm not very familiar with Valgrind so I monitored the memory usage
>> by looking at system monitor on my Ubuntu laptop. The memory usage is
>> almost constant, at around 17.1 Mbs for the ldpc_decoder executable. On 
>> GNU
>> Radio, the memory usage jumps by huge steps (100Mb) in a matter of 
>> seconds
>> until all the memory (the ram is around 8 gigs) is fully consumed.
>>
>> Thanks for links to the memory buffer blog post. I will have a look.
>> Regards,
>> Moses.
>>
>> On Tue, May 7, 2019 at 10:13 PM Ben Hilburn 
>> wrote:
>>
>>> Hey Moses -
>>>
>>> This is really cool work! Thanks so much for sharing it. Michael's
>>> suggestion of pushing it was a good one. I haven't looked at the code 
>>> yet,
>>> but:
>>>
>>> The code was able to run smoothly in a C++ application but
 experienced memory leaks in GNU Radio.

>>>
>>> I'm curious how confident you are in this? It might be worthwhile to 
>>> run the pure-C++ version through Valgrind just to double-check, if you 
>>> haven't already.
>>>
>>> I also have one question regarding buffering in GNU Radio. Since
 iterative decoding with a large number of iterations and large block 
 sizes
 takes time to complete, the input pmt data that is not consumed 
 immediately
 will have to be stored somewhere. Is that the case? Could that be the
 reason for the memory leak?

>>>
>>> Things do get stored until buffers and full, and then backpressure
>>> builds up through the flowgraph. This shouldn't cause memory leaks.
>>>
>>> For a more thorough explanation of this, check out this excellent
>>> blog post from Marcus Mueller!
>>>
>>> https://www.gnuradio.org/blog/2017-01-05-buffers/
>>>
>>> Cheers,
>>> Ben
>>>
>>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman

Re: [Discuss-gnuradio] Recurring memory leak problems with iterative decoding [ GNU Radio 3.7.11.1]

[Michael Dickens]

My suggestion at this point is to take the -exact- "work" code from a block 
that seems to be causing this memory issue and move it into a test program as a 
subroutine. Then, from "main" create a replicated set of calls to this "work" 
and see what happens. The goal here is to remove the GR part of the coding, 
reducing the code-at-issue to its minimum to show the issue -- or, not show the 
issue in which case we know it's GR, somehow. - MLD

On Wed, May 15, 2019, at 8:57 AM, Moses Browne Mwakyanjala wrote:
> Hello Ben,
> In order to test the current hypothesis, I upgraded my system from Ubuntu 
> 16.04 to 18.04 and GNU Radio from 3.7.11 to 3.7.13.5.
> Still, the leak persists. Surprisingly, Michael didn't experience the issue 
> on his MacOS, running the exact code I'm running at the moment. 
> I'm not sure what could cause the issue in Ubuntu. 
> 
> Regards,
> Moses. 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD:USRP source FE options: recent experience and 2 questions

[Achilleas Anastasopoulos]

Hi all,

I have recently run an old experiment that used to work fine:

One UHD:USRP Tx is sending a constant tone at 1GHz
One UHD:USRP Rx is receiving at 1GHz and displays in X-Y mode.

Observations:
1) When the 2 USRPs have default (internal) clock I see a circle (due to
frequency instability).
2) When they have external clock (eg either from octoclock, or one feeds
the other in a master/slave configuration) I see a nice dot (off center)
that is pretty stable thus showing that the Tx/Rx are time/frequency
synchronized.

When I run this experiment recently
(with GNURADIO 3.7.13.5 and UHD 3.14.0.0)
 I got observation 1) but NOT 2).
In fact any time I connected an external clock and did 2) the Rx didn't
seem to receive anything.

After several hours of agony (thinking I have burnt the REF IN port) I
realized what the culprit was:
The switch in the UHD:USRP source block in the FE Correction tab was
"Enable DC offset correction: True"

Once I turned off the DC offset correction everything worked as before.
In retrospect I realize that this is the intended behavior, since the USRP
is receiving a DC signal and tries to eliminate it.
Clearly one way to avoid this is to receive at 1GHz+df and then correct for
df in software.
I am writing this note in case someone else comes up with a similar
situation and wonders what is going on...

Another issue I saw is that no matter what the switch is for the IQ
imbalance correction (True/False) I always get a warning when I run the
program:

[WARNING] [MULTI_USRP] Setting IQ imbalance compensation is not possible on
this device.

Q1) Is this a bug or a feature?

Finally one last question (probably off topic since it is USRP related):

Q2) Is it OK to connect the REF OUT of one USRP to the REF IN of another?
The REF OUT says 3.3V and the REF IN says +15dBm MAX.
I used to do that all the time without burning anything but now I am
skeptical...

thanks
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD:USRP source FE options: recent experience and 2 questions

[Marcus D. Leech]

On 05/15/2019 10:46 AM, Achilleas Anastasopoulos wrote:

Hi all,

I have recently run an old experiment that used to work fine:

One UHD:USRP Tx is sending a constant tone at 1GHz
One UHD:USRP Rx is receiving at 1GHz and displays in X-Y mode.

Observations:
1) When the 2 USRPs have default (internal) clock I see a circle (due 
to frequency instability).
2) When they have external clock (eg either from octoclock, or one 
feeds the other in a master/slave configuration) I see a nice dot (off 
center) that is pretty stable thus showing that the Tx/Rx are 
time/frequency synchronized.


When I run this experiment recently
(with GNURADIO 3.7.13.5 and UHD 3.14.0.0)
 I got observation 1) but NOT 2).
In fact any time I connected an external clock and did 2) the Rx 
didn't seem to receive anything.


After several hours of agony (thinking I have burnt the REF IN port) I 
realized what the culprit was:

The switch in the UHD:USRP source block in the FE Correction tab was
"Enable DC offset correction: True"

Once I turned off the DC offset correction everything worked as before.
In retrospect I realize that this is the intended behavior, since the 
USRP is receiving a DC signal and tries to eliminate it.
Clearly one way to avoid this is to receive at 1GHz+df and then 
correct for df in software.
I am writing this note in case someone else comes up with a similar 
situation and wonders what is going on...


Another issue I saw is that no matter what the switch is for the IQ 
imbalance correction (True/False) I always get a warning when I run 
the program:


[WARNING] [MULTI_USRP] Setting IQ imbalance compensation is not 
possible on this device.


Q1) Is this a bug or a feature?

It depends on what kind of device/device configuration.


Finally one last question (probably off topic since it is USRP related):

Q2) Is it OK to connect the REF OUT of one USRP to the REF IN of another?
The REF OUT says 3.3V and the REF IN says +15dBm MAX.
I used to do that all the time without burning anything but now I am 
skeptical...


thanks
Achilleas





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[John Coppens]

On Thu, 2 May 2019 16:22:24 -0400
Brad Hein  wrote:

> I took a Raspberry Pi and attached a 48KHz USB sound card, with a big
> magnetic loop antenna fed into the mic.

Just a suggestion: If you have a loop antenna, which is a symmetrical antenna,
and couple it to an asymmetrical input (MIC), you will make the antenna
more sensitive to static noise. I'd suggest you use either a transformer or 
an 'instrumentation amplifier' with an operational amplifier to convert
the signal from the antenna to asymmetrical signal.

A transformer would be easiest to install at the base of the antenna (no
need for a supply). The op-amp amplifier would cover a larger bandwidth.
(it would also offer some protection for your computer).

John


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[Brad Hein]

Great suggestion thank you! This also gives me new topics to read up on as
I am still a VLF amateur.

[Sent from mobile device]

On Wed, May 15, 2019, 1:20 PM John Coppens  On Thu, 2 May 2019 16:22:24 -0400
> Brad Hein  wrote:
>
> > I took a Raspberry Pi and attached a 48KHz USB sound card, with a big
> > magnetic loop antenna fed into the mic.
>
> Just a suggestion: If you have a loop antenna, which is a symmetrical
> antenna,
> and couple it to an asymmetrical input (MIC), you will make the antenna
> more sensitive to static noise. I'd suggest you use either a transformer
> or
> an 'instrumentation amplifier' with an operational amplifier to convert
> the signal from the antenna to asymmetrical signal.
>
> A transformer would be easiest to install at the base of the antenna (no
> need for a supply). The op-amp amplifier would cover a larger bandwidth.
> (it would also offer some protection for your computer).
>
> John
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[Marcus D. Leech]

On 05/15/2019 03:23 PM, Brad Hein wrote:
Great suggestion thank you! This also gives me new topics to read up 
on as I am still a VLF amateur.


[Sent from mobile device]
I used a Berhringer "mini-MIC" microphone amplifier, which has a 
balanced, XLR, input, and has bandwidth out to
  about 90kHz.  Worked a champ.  Not as cheap as a DIY 
op-amp+transformer approach, but more convenient,

  to be sure.




On Wed, May 15, 2019, 1:20 PM John Coppens  wrote:


On Thu, 2 May 2019 16:22:24 -0400
Brad Hein mailto:linuxb...@gmail.com>> wrote:

> I took a Raspberry Pi and attached a 48KHz USB sound card, with
a big
> magnetic loop antenna fed into the mic.

Just a suggestion: If you have a loop antenna, which is a
symmetrical antenna,
and couple it to an asymmetrical input (MIC), you will make the
antenna
more sensitive to static noise. I'd suggest you use either a
transformer or
an 'instrumentation amplifier' with an operational amplifier to
convert
the signal from the antenna to asymmetrical signal.

A transformer would be easiest to install at the base of the
antenna (no
need for a supply). The op-amp amplifier would cover a larger
bandwidth.
(it would also offer some protection for your computer).

John



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[Glen I Langston]

Hi Marcus,

That’s great.  What could you hear/detect with the 90 kHz bandwidth?

Glen

> On May 15, 2019, at 5:28 PM, Marcus D. Leech  wrote:
> 
> On 05/15/2019 03:23 PM, Brad Hein wrote:
>> Great suggestion thank you! This also gives me new topics to read up on as I 
>> am still a VLF amateur. 
>> 
>> [Sent from mobile device]
> I used a Berhringer "mini-MIC" microphone amplifier, which has a balanced, 
> XLR, input, and has bandwidth out to
>   about 90kHz.  Worked a champ.  Not as cheap as a DIY op-amp+transformer 
> approach, but more convenient,
>   to be sure.
> 
> 
>> 
>> On Wed, May 15, 2019, 1:20 PM John Coppens > On Thu, 2 May 2019 16:22:24 -0400
>> Brad Hein  wrote:
>> 
>> > I took a Raspberry Pi and attached a 48KHz USB sound card, with a big
>> > magnetic loop antenna fed into the mic.
>> 
>> Just a suggestion: If you have a loop antenna, which is a symmetrical 
>> antenna,
>> and couple it to an asymmetrical input (MIC), you will make the antenna
>> more sensitive to static noise. I'd suggest you use either a transformer or 
>> an 'instrumentation amplifier' with an operational amplifier to convert
>> the signal from the antenna to asymmetrical signal.
>> 
>> A transformer would be easiest to install at the base of the antenna (no
>> need for a supply). The op-amp amplifier would cover a larger bandwidth.
>> (it would also offer some protection for your computer).
>> 
>> John
>> 
>> 
>> 
>> ___
>> Discuss-gnuradio mailing list
>> 
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[Marcus D. Leech]

On 05/15/2019 05:45 PM, Glen I Langston wrote:

Hi Marcus,

That’s great.  What could you hear/detect with the 90 kHz bandwidth?

Glen

I used it strictly for SIDs in the VLF band up to 40kHz or so...

I had a loop antenna, about 1.2m diameter, and about 10 windings of 
#20ga wire.  No tuning capacitor.




On May 15, 2019, at 5:28 PM, Marcus D. Leech  wrote:

On 05/15/2019 03:23 PM, Brad Hein wrote:

Great suggestion thank you! This also gives me new topics to read up on as I am 
still a VLF amateur.

[Sent from mobile device]

I used a Berhringer "mini-MIC" microphone amplifier, which has a balanced, XLR, 
input, and has bandwidth out to
   about 90kHz.  Worked a champ.  Not as cheap as a DIY op-amp+transformer 
approach, but more convenient,
   to be sure.



On Wed, May 15, 2019, 1:20 PM John Coppens  wrote:


I took a Raspberry Pi and attached a 48KHz USB sound card, with a big
magnetic loop antenna fed into the mic.

Just a suggestion: If you have a loop antenna, which is a symmetrical antenna,
and couple it to an asymmetrical input (MIC), you will make the antenna
more sensitive to static noise. I'd suggest you use either a transformer or
an 'instrumentation amplifier' with an operational amplifier to convert
the signal from the antenna to asymmetrical signal.

A transformer would be easiest to install at the base of the antenna (no
need for a supply). The op-amp amplifier would cover a larger bandwidth.
(it would also offer some protection for your computer).

John



___
Discuss-gnuradio mailing list

Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio