Re: Discuss-gnuradio Digest, Vol 259, Issue 8

[Moses Browne Mwakyanjala]

Hi Marcus,

The external 10MHz did the trick. I have another related question which I
think we can address here without opening a new ticket. The USRP B210 has a
1PPS port. However, I was not able to poll the status of the time source,
"pps_locked". When I searched for a list of all onboard sensors, the only
visible sensor was "ref_locked". Am I missing something? How can I use and
poll the status of 1PPS?

Regards, Moses


On Wed, May 15, 2024 at 6:04 PM  wrote:

> Send Discuss-gnuradio mailing list submissions to
> discuss-gnuradio@gnu.org
>
> 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
> discuss-gnuradio-requ...@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
>1. USRP B210 Frequency Offset (Moses Browne Mwakyanjala)
>2. Re: USRP B210 Frequency Offset (Marcus D. Leech)
>
>
> ----------
>
> Message: 1
> Date: Wed, 15 May 2024 11:52:27 +0200
> From: Moses Browne Mwakyanjala 
> To: GNURadio Discussion List 
> Subject: USRP B210 Frequency Offset
> Message-ID:
> <
> cabysgdmphq54warsy--5-7renj3pfrahtowuce_rss8ypq-...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I've encountered a consistent frequency offset of around 2ppm with my new
> B210. Operating at a sample rate of 4 MSPS with the "internal" clock, all
> calibrations were performed using a sine wave from an Agilent signal
> generator.
>
> Though seemingly minor, the 800Hz offset at UHF poses challenges in
> receiving low-rate data from orbiting satellites. Is there an automated
> method to approximate and mitigate this offset? Currently, I manually
> adjust the frequency by subtracting the offset in ppm. However, I'm curious
> if there are more sophisticated solutions available, excluding reliance on
> GPS or a 10MHz reference.
>
> Best regards,
> Moses
>
> [image: image.png]
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240515/3082954d/attachment.htm
> >
> -- next part --
> A non-text attachment was scrubbed...
> Name: image.png
> Type: image/png
> Size: 33653 bytes
> Desc: not available
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240515/3082954d/attachment.png
> >
>
> --
>
> Message: 2
> Date: Wed, 15 May 2024 09:10:13 -0400
> From: "Marcus D. Leech" 
> To: discuss-gnuradio@gnu.org
> Subject: Re: USRP B210 Frequency Offset
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 15/05/2024 05:52, Moses Browne Mwakyanjala wrote:
> > I've encountered a consistent frequency offset of around 2ppm with my
> > new B210. Operating at a sample rate of 4 MSPS with the "internal"
> > clock, all calibrations were performed using a sine wave from an
> > Agilent signal generator.
> >
> > Though seemingly minor, the 800Hz offset at UHF poses challenges in
> > receiving low-rate data from orbiting satellites. Is there an
> > automated method to approximate and mitigate this offset? Currently, I
> > manually adjust the frequency by subtracting the offset in ppm.
> > However, I'm curious if there are more sophisticated solutions
> > available, excluding reliance on GPS or a 10MHz reference.
> >
> > Best regards,
> > Moses
> The on-board clock on a B210 is good to about 2.5PPM.  So, it's working
> as you would expect.
>
> There's nothing built in to the UHD API for this, because normally, if
> you care about clock accuracy beyond what the internal clock
>can supply, you use an external, better, clock.   GPSDOs are not very
> expensive these days, and you can pick up used
>10MHz OCXO units fairly cheaply as well...
>
>
> >
> > image.png
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240515/db078ea5/attachment.htm
> >
> -- next part --
> A non-text attachment was scrubbed...
> Name: image.png
> Type: image/png
> Size: 33653 bytes
> Desc: not available
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240515/db078ea5/attachment.png
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> --
>
> End of Discuss-gnuradio Digest, Vol 259, Issue 8
> 
>

USRP B210 Frequency Offset

[Moses Browne Mwakyanjala]

I've encountered a consistent frequency offset of around 2ppm with my new
B210. Operating at a sample rate of 4 MSPS with the "internal" clock, all
calibrations were performed using a sine wave from an Agilent signal
generator.

Though seemingly minor, the 800Hz offset at UHF poses challenges in
receiving low-rate data from orbiting satellites. Is there an automated
method to approximate and mitigate this offset? Currently, I manually
adjust the frequency by subtracting the offset in ppm. However, I'm curious
if there are more sophisticated solutions available, excluding reliance on
GPS or a 10MHz reference.

Best regards,
Moses

[image: image.png]

HDLC block producing false packets

[Moses Browne Mwakyanjala]

Hi everyone,
I was using the HDLC block to receive AX25 packets of satellite signals. I
noticed that the block can sometimes produce packets that are gibberish.
This sounds very unlikely considering the CRC check in the block. Has
anyone experienced this problem?

Regards,
Moses.

Changing USRP subdevice on the fly

[Moses Browne Mwakyanjala]

Hi everyone,
I wrote a simple program for a usrp b210. I would like to change the RX
antenna on the fly. That is, antenna 0 should be RX2 on Subdevice A:A and
antenna 1 RX2 on Subdevice A:B as shown in the piece of code below. The
problem I face is that I can't change the subdevice on the fly. The
usrp->set_rx_subdev_spec(sRxSubDev)
call doesn't seem to have any effect if it is called more than once. How
should I proceed?

std::string sRxSubDev;
switch(m_Settings.m_nTMAntenna)
{
case 0:// Using antenna 1
sRxSubDev = std::string("A:A");
break;
case 1:// Using antenna 2
sRxSubDev = std::string("A:B");
break;
}
usrp->set_rx_subdev_spec(sRxSubDev);
usrp->set_rx_antenna("RX2");

Thanks in advance,

Moses.

Efficient floating-point decoder for BPSK/QPSK manchester code

[Moses Browne Mwakyanjala]

Hi everyone,
I've been struggling to decode manchester signals. I have tried to use some
ad-hoc methods for BPSK that work well. However, there were some if-else
branches that tax the CPU greatly, especially at high symbol rates. The
input is 2 SPS, output 1 SPS. And they didn't seem to work for QPSK.

I have tried to use the matched-filter approach (treating the manchester
pulse as 1,1,-1,-1), with 4 SPS input, and 1 SPS output. The PFB taps are
thus the convolution of manchester taps (1,1,-1,-1) and SRRC. This approach
didn't work well. Upon further examination, I discovered that the symbol
synchronizer failed to lock.

I was wondering if there were alternative algorithms that could work for
both BPSK and QPSK.


Thanks in advance,

Moses.

Senior consultant for SDR development

[Moses Browne Mwakyanjala]

Hi everyone,
We are looking for an experienced SDR developer. See the specifics below:

https://careers.abi.se/jobs/1642250-senior-consultant-satellite-and-spacetech-industry

Regards

Moses.

USRP/SDR developer consultation

[Moses Browne Mwakyanjala]

Hi everyone,
Im looking for an SDR developer to optimize a receiver. Please let me know
if you are interested.

Regards,

Moses.

Rate matching between host and SDR

[Moses Browne Mwakyanjala]

Hi everyone,
I'm experimenting with a C++ standalone USRP transmitter using the function
shown below. The data is generated by another function called Modulate()
which "posts" the modulated IQ samples to this function. The transmitter
works very well for burst transmissions (individual packets). I was
wondering how to do transmission in a continuous way. I mean, the
Modulate() function depends on the CPU clock while the actual transmission
is dictated by the rate of the USRP. I did try to send blocks of samples
(10,000) continuously and the USRP was reporting underruns. How do I make
sure my functions run at the same rate as the USRP?

voidUSRPDriver::TransmitIQ(std::vector > fcpxIQ){
//assert(1 ==0);
if(m_bDeviceUp){
if(DEBUG)
std::cout << "USRPDriver::" << __func__ << "Transmitting
IQ Frame Size = " << fcpxIQ.size() << std::endl;
// setup metadata for the first packet
uhd::tx_metadata_t md;
md.start_of_burst = false;
md.end_of_burst   = false;
md.has_time_spec  = false;
md.time_spec  = uhd::time_spec_t(1.5);
// the first call to send() will block this many seconds before sending:
double timeout =  10.0; // timeout (delay before transmit + padding)
tx_stream->send([0], fcpxIQ.size(), md, timeout);
fcpxIQ.clear();
}
}


Regards,


Moses.

Efficiency of PFB symbol sync filtering

[Moses Browne Mwakyanjala]

Hi everyone,
I've been thinking about the PFB and its operations (match-filtering and
interpolation in one go). From the source code of the PFB block Lines 390
and 427
,
the match/diff filter output are
out[i + d_out_idx] = d_filters[d_filtnum].filter([count + d_out_idx]);
gr_complex diff = d_diff_filters[d_filtnum].filter([count]);

That is, the filtering operations produce a single symbol. Given that
filters work on a block of samples, I was wondering how many samples are
actually filtered in the case above.  What becomes of the other output
samples from the filter? Are they just discarded? Correct me if I'm wrong
but shouldn't it be more efficient not to discard the extra samples
produced by the filters? That way, we could "fix" the filter index (
d_filtnum) for a block of the filter output vector? The transient filter
index characteristics will then become a staircase as shown by my
simulation results below.

[image: image.png]
[image: image.png]

Regards,

Moses.

MPSK SVR SNR, Signal and Noise estimation

[Moses Browne Mwakyanjala]

Hi everyone,
It seems like all estimators in MPSK_SNR_EST class, except for the SVR one
(shown below), have signal, noise, and SNR estimations.  How does one get
the signal and noise components from the SVR estimate?

Regards,

Moses.

mpsk_snr_est_svr::mpsk_snr_est_svr(double alpha) : mpsk_snr_est(alpha)

{

d_y1 = 0;

d_y2 = 0;

}


int mpsk_snr_est_svr::update(int noutput_items, const gr_complex* input)

{

for (int i = 0; i < noutput_items; i++) {

double x = abs(input[i + 1]);

double x1 = abs(input[i]);

double y1 = (x * x) * (x1 * x1);

d_y1 = d_alpha * y1 + d_beta * d_y1;


double y2 = x * x * x * x;

d_y2 = d_alpha * y2 + d_beta * d_y2;

}

return noutput_items;

}


double mpsk_snr_est_svr::snr()

{

double x = d_y1 / (d_y2 - d_y1);

return 10.0 * log10(x - 1 + sqrt(x * (x - 1)));

}


Moses Browne Mwakyanjala


Founder - CEO

*Remos Space Systems AB*

m: +46 (0)70 278 2174

a: Aurorum 1C,  977 75 Luleå, Sweden

w: www.remosspace.com e: mbkit...@gmail.com

[image: image.png]

Recommendation for PCI-based SDR frontends

[Moses Browne Mwakyanjala]

Hi everyone,
I'm looking for stable and affordable SDRs that can be connected and
slotted into the computer through the standard  PCI bus. So far I have only
found XTRX. I was wondering if there were other tested solutions out there.

Regards,

Moses.

Commercial C++ libraries for CCSDS Reed-Solomon, Viterbi, LDPC and Turbo

[Moses Browne Mwakyanjala]

Hi everyone,
Could you recommend commercial C++ libraries for CCSDS Reed-Solomon,
Viterbi, LDPC, and Turbo? Preferably, I'm looking for those libraries that
have already been optimized with SIMD (or Intel IPP).

Regards,

Moses.

Suggestion for an SDR computer

[Moses Browne Mwakyanjala]

Hi everyone,
I will be acquiring a frontend that could receive up to 2 Gsps. The
frontend has an FPGA that could host user-defined VHDL signal processing
RTL. It can also stream data directly to the CPU or GPU. I understand that
using the FPGA or the GPU could be quite efficient. BUT, I want the signal
processing functions done in the CPU whereby the waveform is processed in
GNU Radio (or other C++ implementations). I'm currently looking for a
computer that could handle this sample rate. What kind of specs do you
think I could look for (RAM, CPU frequency, cache size etc).? What specific
products would you recommend?

Regards,
Moses.

Information from UHF/VHF satellite ground station operators

[Moses Browne Mwakyanjala]

Hi everybody,
I'm looking for some input from satellite ground station operators. Could
you help me by filling the short questionnaire below:
Link:  https://forms.gle/7EpcUmvdr1Xcvk1o6

Regards,
Moses.

Re: Measuring transmission power from USRP B210

[Moses Browne Mwakyanjala]

Hi,
The flowgraph contains a sinusoidal source and a USRP sink. You may notice
that the sample rate is quite high. It is part of the requirements.
Regards,
Moses.
[image: image.png]

On Mon, Nov 9, 2020 at 6:19 PM  wrote:

> Send Discuss-gnuradio mailing list submissions to
> discuss-gnuradio@gnu.org
>
> 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
> discuss-gnuradio-requ...@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
>1. Re: Measuring transmission power from USRP B210 (Marcus D. Leech)
>
>
> --
>
> Message: 1
> Date: Mon, 09 Nov 2020 12:01:24 -0500
> From: "Marcus D. Leech" 
> To: discuss-gnuradio@gnu.org
> Subject: Re: Measuring transmission power from USRP B210
> Message-ID: <5fa975e4.9020...@gmail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 11/09/2020 11:39 AM, Moses Browne Mwakyanjala wrote:
> > Hello everyone,
> > I'm in the process of testing a GNU Radio transmitter. The transmitter
> > will be connected to a solid-state power amplifier (SSPA) for
> > near-Earth satellite communications. The SSPA expects an input of 0dm
> > from the USRP TX port.
> >
> > The first step is thus to measure the power from the USRP. To that
> > end, the flowgraph generates a complex sinusoidal signal with a unit
> > magnitude. The UHD:USRP Sink block is set to maximum gain (i.e.
> > normalized gain of 1.0). Unfortunately, the maximum power I can see
> > from the spectrum analyzer is around -6.93 dBm as shown below. To my
> > understanding, the USRP can transmit up to 20 dBm as reported in the
> > "External Connections" section at this Ettus link :
> > https://files.ettus.com/manual/page_usrp_b200.html.
> > Could anyone explain why I can't achieve a 20 dBm (or anything around
> > it) power level?
> > IMG_3475.JPG
> > Thanks in advance,
> > Moses.
> >
> Could we perhaps see a minimal flow-graph that demonstrates the issue?
>
> Generally, setting the baseband magnitude to 1.0 at the same times as
> setting to MAX gain can cause linearity issues.
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20201109/e3b13728/attachment.html
> >
> -- next part --
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/jpeg
> Size: 1112823 bytes
> Desc: not available
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20201109/e3b13728/attachment.jpe
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> --
>
> End of Discuss-gnuradio Digest, Vol 217, Issue 10
> *
>

Re: Discuss-gnuradio Digest, Vol 217, Issue 10

[Moses Browne Mwakyanjala]

Hi,
The flowgraph contains a sinusoidal source and a USRP sink. You may notice
that the sample rate is quite high. It is part of the requirements.
Regards,
Moses.
[image: image.png]

On Mon, Nov 9, 2020 at 6:19 PM  wrote:

> Send Discuss-gnuradio mailing list submissions to
> discuss-gnuradio@gnu.org
>
> 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
> discuss-gnuradio-requ...@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
>1. Re: Measuring transmission power from USRP B210 (Marcus D. Leech)
>
>
> --
>
> Message: 1
> Date: Mon, 09 Nov 2020 12:01:24 -0500
> From: "Marcus D. Leech" 
> To: discuss-gnuradio@gnu.org
> Subject: Re: Measuring transmission power from USRP B210
> Message-ID: <5fa975e4.9020...@gmail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 11/09/2020 11:39 AM, Moses Browne Mwakyanjala wrote:
> > Hello everyone,
> > I'm in the process of testing a GNU Radio transmitter. The transmitter
> > will be connected to a solid-state power amplifier (SSPA) for
> > near-Earth satellite communications. The SSPA expects an input of 0dm
> > from the USRP TX port.
> >
> > The first step is thus to measure the power from the USRP. To that
> > end, the flowgraph generates a complex sinusoidal signal with a unit
> > magnitude. The UHD:USRP Sink block is set to maximum gain (i.e.
> > normalized gain of 1.0). Unfortunately, the maximum power I can see
> > from the spectrum analyzer is around -6.93 dBm as shown below. To my
> > understanding, the USRP can transmit up to 20 dBm as reported in the
> > "External Connections" section at this Ettus link :
> > https://files.ettus.com/manual/page_usrp_b200.html.
> > Could anyone explain why I can't achieve a 20 dBm (or anything around
> > it) power level?
> > IMG_3475.JPG
> > Thanks in advance,
> > Moses.
> >
> Could we perhaps see a minimal flow-graph that demonstrates the issue?
>
> Generally, setting the baseband magnitude to 1.0 at the same times as
> setting to MAX gain can cause linearity issues.
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20201109/e3b13728/attachment.html
> >
> -- next part --
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/jpeg
> Size: 1112823 bytes
> Desc: not available
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20201109/e3b13728/attachment.jpe
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> --
>
> End of Discuss-gnuradio Digest, Vol 217, Issue 10
> *
>

Re: Multithreading in GR blocks

[Moses Browne Mwakyanjala]

Hi Marcus,
I was trying to emulate how the ZMQ block handles multithreading.
Basically, the ZMQ block overrides the stop() function and joins the
threads. This is the same thing I tried to do to stop the receive and
listen threads. Is there any other way of doing this?

bool

TCPServer::stop()

{

m_bFinished = true;

m_ReceiveThread->join();

m_ListenThread->join();

return true;

}

Regards,

Moses.


On Mon, Apr 13, 2020 at 7:11 PM Marcus Müller  wrote:

> Hi Moses,
>
> your code doesn't show how your GNU Radio block's stop() function would
> tell your TCP Server thread that it's time to shut down, so I presume
> that doesn't happen – that would explain why the flow graph can't ever
> shut down!
>
> Best regards,
> Marcus
>
> On 13.04.20 18:54, Moses Browne Mwakyanjala wrote:
> > Hello everyone,
> > I have created a TCP/IP block by adapting the ZMQ message pub block.
> > Both blocks make use of boost multithreading. The TCP/IP block is used
> > by a standalone C++ program. To run the gnuradio topblock, the C++
> > program calls tb->start() function. To stop the topblock, the
> > functions tb->stop() and tb->wait() are called.However, the program
> > "hangs" when tb->stop() is called. This suggests there is something
> > wrong with the way I use boost multithreading.
> > All help is appreciated.
> >
> > Regards,
> > Moses.
>
>

Multithreading in GR blocks

[Moses Browne Mwakyanjala]

Hello everyone,
I have created a TCP/IP block by adapting the ZMQ message pub block. Both
blocks make use of boost multithreading. The TCP/IP block is used by a
standalone C++ program. To run the gnuradio topblock, the C++ program calls
tb->start() function. To stop the topblock, the functions tb->stop() and
tb->wait() are called.However, the program "hangs" when tb->stop() is
called. This suggests there is something wrong with the way I use boost
multithreading.
All help is appreciated.

Regards,
Moses.
/* -*- c++ -*- */
/*
 * Copyright 2013 Free Software Foundation, Inc.
 *
 * This file is part of GNU Radio
 *
 * SPDX-License-Identifier: GPL-3.0-or-later
 *
 */

#ifndef INCLUDED_BLOCKS_TCPSERVER_H
#define INCLUDED_BLOCKS_TCPSERVER_H

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include "src/pcm/LineCode.h"

namespace icd {
namespace net {
class TCPServer;
typedef boost::shared_ptr TCPServer_sptr;
TCPServer_sptr
make_TCPServer(std::string addr,
   int port,
   int MTU = 1);
class TCPServer : public gr::block
{
friend
TCPServer_sptr
make_TCPServer(std::string addr,
   int port,
   int MTU);
private:
boost::thread* m_ListenThread, *m_ReceiveThread;
int m_nPort;
std::string m_pzAddr;
int m_nSockFd, m_nNewSockFd;
struct sockaddr_in m_ServerAddress;
struct sockaddr_in m_ClientAddress;
void Setup();
void ListenLoop();
void ReceiveLoop();
void TransmitLoop(pmt::pmt_t pmt_msg);
bool m_bFinished;
int m_nMTU;
pcm::LineCode m_LineCode;

public:
TCPServer(std::string addr,
  int port,
  int MTU = 1);
~TCPServer();
bool start();
bool stop();
};

} /* namespace blocks */
} /* namespace gr */

#endif /* INCLUDED_BLOCKS_TCPServer_H */
/* -*- c++ -*- */
/*
 * Copyright 2013,2019 Free Software Foundation, Inc.
 *
 * This file is part of GNU Radio
 *
 * SPDX-License-Identifier: GPL-3.0-or-later
 *
 */


#include "TCPServer.h"
#include 

namespace icd {
namespace net {

TCPServer_sptr
make_TCPServer(std::string addr,
   int port,
   int MTU)
{
return gnuradio::get_initial_sptr(
new TCPServer(addr, port, MTU));
}

TCPServer::TCPServer(std::string addr,
 int port,
 int MTU)
: block("TCPServer", gr::io_signature::make(0, 0, 0), gr::io_signature::make(0, 0, 0)),
  m_nPort(port),m_pzAddr(addr),m_nMTU(MTU)
{
Setup();
message_port_register_in(pmt::mp("in"));
message_port_register_out(pmt::mp("out"));

set_msg_handler(
pmt::mp("in"),
boost::bind(::TransmitLoop, this, _1)
);
//std::cout << "TCP SERVER CONSTRUCTED" << std::endl;
}
void
TCPServer::Setup()
{
m_nSockFd=socket(AF_INET,SOCK_STREAM,0);
memset(_ServerAddress,0,sizeof(m_ServerAddress));
m_ServerAddress.sin_family=AF_INET;
m_ServerAddress.sin_addr.s_addr=htonl(INADDR_ANY);
m_ServerAddress.sin_port=htons(m_nPort);
bind(m_nSockFd,(struct sockaddr *)_ServerAddress, sizeof(m_ServerAddress));
int reusePort = 1;
setsockopt(m_nSockFd, SOL_SOCKET, SO_REUSEPORT, , sizeof(reusePort));
listen(m_nSockFd,1);
}

void
TCPServer::ListenLoop()
{
int n = 0;
while(!m_bFinished)
{
socklen_t sosize  = sizeof(m_ClientAddress);
m_nNewSockFd = accept(m_nSockFd,(struct sockaddr*)_ClientAddress,);

// Receving Thread
m_ReceiveThread = new boost::thread(boost::bind(::ReceiveLoop, this));

}
}

void
TCPServer::TransmitLoop(pmt::pmt_t pmt_msg)
{
// Extracting message from pmt
pmt::pmt_t msg = pmt::cdr(pmt_msg);
size_t offset(0);
int msg_len = pmt::length(msg);
unsigned char *msg_char = (unsigned char*)malloc(msg_len);
memcpy(msg_char,pmt::uniform_vector_elements(msg, offset),msg_len);

if(m_nNewSockFd != -1)
{
if( send(m_nNewSockFd , msg_char , msg_len , 0) < 0)
{
//std::cout << "Send failed : " << std::endl;
//return false;
}
}
}

void
TCPServer::ReceiveLoop()
{
int n = 0;
while(!m_bFinished)
{
char msg[m_nMTU];
n=recv(m_nNewSockFd,msg,m_nMTU,0);
if(n==0)
{
close(m_nNewSockFd);
break;
}
m_LineCode.UCharArrayDump(msg,n);
std::cout << "NewSockFd : " << m_nNewSockFd << std::endl;
std::cout << "Value of n : " << n << std::endl;
std::cout << "Port number: " << m_nPort << std::endl;
if (n > 0){
std::cout << "Alias : " << this->alias() << std::endl;
pmt::pmt_t pdu(pmt::cons(pmt::PMT_NIL,pmt::make_blob(msg,n)));
message_port_pub(pmt::mp("out"), pdu);
}
}
}

TCPServer::~TCPServer()
{
stop();
}

bool
TCPServer::start()
{
m_bFinished = false;
m_ListenThread = new boost::thread(boost::bind(::ListenLoop, 

Re: Socket PDU (TCP Server) crashes

[Moses Browne Mwakyanjala]

Hi Marcus,
You are absolutely right. I copy/pasted the "Socket PDU" source files from
the latest GNU Radio and compiled it as a separate OOT.
The error has disappeared. I have also tried to use ZMQ, and it seems to be
quite straightforward. I think I will stick to it.

Regards,
Moses.

On Tue, Mar 24, 2020 at 4:09 PM Marcus Müller  wrote:

> Hi Moses,
>
> if it's a bug in the source code of GNU Radio, you'll have to update
> that piece of GNU Radio, right?
> So, "can't update GNU Radio" isn't a very promising point to start from.
> So, what exactly can you and can you not do to your GNU Radio installation?
>
> Does the same code (or even better, a Minimum Reproducible Example) work
> on a different machine with GNU Radio 3.7.14.0?
>
> Cheers,
> Marcus
>
> On 24.03.20 10:47, Moses Browne Mwakyanjala wrote:
> > Hello everyone,
> > I'm running a GNU Radio program in standalone C++ application. I
> > experience something strange with the Socket PDU block.
> > In a header file, the Socket PDU object is declared as follows:
> >
> > gr::blocks::socket_pdu::sptrm_TCPServer;
> >
> > and in the implementation file, the object is initialized like this:
> >
> >
> m_TCPServer=gr::blocks::socket_pdu::make("TCP_SERVER","127.0.0.1","2001");
> >
> > Tracing the debugger output, the SIGSEGV signal is triggered by the
> reactive_socket_service_base::destroy(...) function. In particular, the
> debugger points to the
> >
> > reactor_.deregistor_descriptor(..) function.
> >
> >
> > All help is warmly welcomed.
> >
> >
> > DISCLAIMER: The program is run on a machine with an old version of GNU
> > Radio (3.7.11.1), which can't be updated (for security reasons).
> >
> >
> > Regards,
> >
> > Moses.
> >
> > voidreactive_socket_service_base::destroy(
> reactive_socket_service_base::base_implementation_type)
> >
> > {
> >
> > if(impl.socket_!=invalid_socket)
> >
> >
> > {
> >
> > BOOST_ASIO_HANDLER_OPERATION(("socket",,"close"));
> >
> > reactor_.deregister_descriptor(impl.socket_,impl.reactor_data_,=>
> > Debugger points to this line
> >
> > (impl.state__ops::possible_dup)==0);
> >
> > boost::system::error_codeignored_ec;
> >
> > socket_ops::close(impl.socket_,impl.state_,true,ignored_ec);
> >
> > }
> >
> > }
> >
> >
> > DEBUGGER OUTPUT
> >
> > ---
> >
> > 1   boost::asio::detail::reactive_socket_service_base::destroy
>
>reactive_socket_service_base.ipp 87   0x764c9baf
> > 2   boost::asio::socket_acceptor_service::destroy
>
> socket_acceptor_service.hpp  137  0x764c9e8a
> > 3
> boost::asio::basic_io_object>::~basic_io_object
>  basic_io_object.hpp
>124  0x764c9e8a
> > 4   boost::asio::basic_socket_acceptor boost::asio::socket_acceptor_service>::~basic_socket_acceptor
>basic_socket_acceptor.hpp55   0x764c9e8a
> > 5
> boost::checked_delete boost::asio::socket_acceptor_service>>
>   checked_delete.hpp   34   0x764c9e8a
> > 6
> boost::detail::sp_counted_impl_p boost::asio::socket_acceptor_service>>::dispose
> sp_counted_impl.hpp  78   0x764c9e8a
> > 7   boost::detail::sp_counted_base::release
>
> sp_counted_base_gcc_x86.hpp  146  0x764c203a
> > 8   boost::detail::sp_counted_base::release
>
> sp_counted_base_gcc_x86.hpp  144  0x764c5cfd
> > 9   boost::detail::shared_count::~shared_count
>
>shared_count.hpp 443  0x764c5cfd
> > 10
>  boost::shared_ptr boost::asio::socket_acceptor_service>>::~shared_ptr
>  shared_ptr.hpp   323  0x764c5cfd
> > 11  gr::blocks::socket_pdu_impl::socket_pdu_impl
>
>socket_pdu_impl.cc   45   0x764c5cfd
> > 12  gr::blocks::socket_pdu::make
>
>socket_pdu_impl.cc   38   0x764c6132
> > 13  StandardTTC::createFlowgraph
>
>standardttc.cpp  1006 0x427807
> > 14  StandardTTC::startDevice
>
>standardttc.cpp  405  0x421510
> > 15  StandardTTC::qt_static_metacall
>
> moc_standardttc.cpp  63   0x49df41
> > 16  QMetaObject::activate(QObject *, QMetaObject const *, int, void * *)
>
>  0x73fc2f80
> > 17  QAbstractButton::toggled(bool)
>
>  0x74b803e2
> > 18  QAbstractButton::setChecked(bool)
>
>   0x748b712d
> > 19  ??
>
>  0x748b6cd3
> > 20  QAbstractButton::mouseReleaseEvent(QMouseEvent *)
>
>   0x748b6e24
> > ... 
>
>
> >
> >
>

Socket PDU (TCP Server) crashes

[Moses Browne Mwakyanjala]

Hello everyone,
I'm running a GNU Radio program in standalone C++ application. I experience
something strange with the Socket PDU block.
In a header file, the Socket PDU object is declared as follows:

gr::blocks::socket_pdu::sptr m_TCPServer;

and in the implementation file, the object is initialized like this:

m_TCPServer = gr::blocks::socket_pdu::make("TCP_SERVER","127.0.0.1","2001");

Tracing the debugger output, the SIGSEGV signal is triggered by the
reactive_socket_service_base::destroy(...) function. In particular,
the debugger points to the

reactor_.deregistor_descriptor(..) function.


All help is warmly welcomed.


DISCLAIMER: The program is run on a machine with an old version of GNU
Radio (3.7.11.1), which can't be updated (for security reasons).


Regards,

Moses.

void reactive_socket_service_base::destroy(
reactive_socket_service_base::base_implementation_type& impl)

{

  if (impl.socket_ != invalid_socket)

  {

BOOST_ASIO_HANDLER_OPERATION(("socket", , "close"));

reactor_.deregister_descriptor(impl.socket_,
impl.reactor_data_,=> Debugger points to this line

(impl.state_ & socket_ops::possible_dup) == 0);

boost::system::error_code ignored_ec;

socket_ops::close(impl.socket_, impl.state_, true, ignored_ec);

  }

}


DEBUGGER OUTPUT

---

1   boost::asio::detail::reactive_socket_service_base::destroy

  reactive_socket_service_base.ipp 87
0x764c9baf
2   boost::asio::socket_acceptor_service::destroy

 socket_acceptor_service.hpp  137
0x764c9e8a
3   
boost::asio::basic_io_object>::~basic_io_object

basic_io_object.hpp  124  0x764c9e8a
4   boost::asio::basic_socket_acceptor>::~basic_socket_acceptor
   basic_socket_acceptor.hpp55
0x764c9e8a
5   
boost::checked_delete>>
  checked_delete.hpp   34   0x764c9e8a
6   
boost::detail::sp_counted_impl_p>>::dispose
sp_counted_impl.hpp  78   0x764c9e8a
7   boost::detail::sp_counted_base::release

  sp_counted_base_gcc_x86.hpp  146
0x764c203a
8   boost::detail::sp_counted_base::release

  sp_counted_base_gcc_x86.hpp  144
0x764c5cfd
9   boost::detail::shared_count::~shared_count

  shared_count.hpp 443
0x764c5cfd
10  boost::shared_ptr>>::~shared_ptr
   shared_ptr.hpp   323  0x764c5cfd
11  gr::blocks::socket_pdu_impl::socket_pdu_impl

  socket_pdu_impl.cc   45
0x764c5cfd
12  gr::blocks::socket_pdu::make

  socket_pdu_impl.cc   38
0x764c6132
13  StandardTTC::createFlowgraph

  standardttc.cpp  1006 0x427807
14  StandardTTC::startDevice

  standardttc.cpp  405  0x421510
15  StandardTTC::qt_static_metacall

  moc_standardttc.cpp  63   0x49df41
16  QMetaObject::activate(QObject *, QMetaObject const *, int, void *
*)

0x73fc2f80
17  QAbstractButton::toggled(bool)


0x74b803e2
18  QAbstractButton::setChecked(bool)


0x748b712d
19  ??


0x748b6cd3
20  QAbstractButton::mouseReleaseEvent(QMouseEvent *)


0x748b6e24
... 

Amazon AWG Ground Stations

[Moses Browne Mwakyanjala]

Hello everyone,
I was wondering if anyone has tried to use GNU Radio with the Amazon ground
stations. What was the experience?

Regards,
Moses.

GNU Radio Viterbi Implementation

[Moses Browne Mwakyanjala]

Hello everyone,
I have a couple of questions on GNU Radio implementation of the Butterfly
macros. I'm somehow familiar with doing butterfly on paper (the trellis)
but could someone explain to me how this macro works? I also don't
understand how the list of butterflies for a specific code (for example the
CCSDS CC(K= 7, R = 1/2) butterflies generated by the program below the
butterfly macro) are generated (in particular, how to derive the partab
lookup).

Regards,

#define BUTTERFLY(i, sym) \

{ \

int m0, m1;   \

  \

/* ACS for 0 branch */\

m0 = state[i].metric + mets[sym];  /* 2*i */  \

m1 = state[i + 32].metric + mets[3 ^ sym]; /* 2*i + 64 */ \

if (m0 > m1) {\

next[2 * i].metric = m0;  \

next[2 * i].path = state[i].path << 1;\

} else {  \

next[2 * i].metric = m1;  \

next[2 * i].path = (state[i + 32].path << 1) | 1; \

} \

/* ACS for 1 branch */\

m0 = state[i].metric + mets[3 ^ sym];  /* 2*i + 1 */  \

m1 = state[i + 32].metric + mets[sym]; /* 2*i + 65 */ \

if (m0 > m1) {\

next[2 * i + 1].metric = m0;  \

next[2 * i + 1].path = state[i].path << 1;\

} else {  \

next[2 * i + 1].metric = m1;  \

next[2 * i + 1].path = (state[i + 32].path << 1) | 1; \

} \

}


*/* Generate the inline BUTTERFLY macro calls for viterbi.c */*

*/* The two generator polynomials for the NASA Standard K=7 code */  *

*#include *

*#define POLYA   0x4f*

*#define POLYB   0x6d  *

*unsigned char Partab[] = {*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

*};*



*int main(int argc, char *argv[])  *

*{  *

* int e,i;*

* int nNonInv = 1;*

* for(i=0;i<32;i++){  *

* if(nNonInv) {*

* e = Partab[2*i & POLYA] << 1;  *

* e |= Partab[2*i & POLYB];  *

* }*

* else {*

* // CCSDS Poly V27POLYB, -V27POLYA*

* e = Partab[2*i & POLYA] << 1;  *

* e |= 1^Partab[2*i & POLYB];  *

* }*

* printf("BUTTERFLY(%d,%d); ",i,e);*

* if (i % 4 ==3) {*

* printf("\n");*

* }  *

* }  *

* return 0;*

*}  *

Re: [Discuss-gnuradio] Compiling QT C++ programs with GNU Radio

[Moses Browne Mwakyanjala]

Hello Nick,
Thanks.
I will have a look.

Regards,
Moses.

On Tue, Oct 8, 2019 at 10:59 PM Nick Foster  wrote:

> Maybe I'm just confused, then. You weren't clear about the problem you're
> experiencing, or what you've tried to resolve it. It sounded in your
> initial email like you just don't know how to build a CMake project (using
> "g++", for instance, is not how that works). Further leading me to think
> this was that you apparently are doing this compilation in-tree, in
> gr-qtgui/examples, which isn't a good place for user projects.
>
> The CMakeLists.txt you attached appears to be designed for in-tree
> compilation. This means your project would always have to be compiled along
> with your own custom branch of Gnuradio, which I'm almost positive is not
> what you actually want to do. The out-of-tree module template includes all
> of the CMake commands necessary to compile and link your own project
> outside the Gnuradio source tree. It should serve as a much better starting
> point for your project than the CMakeLists.txt that you attached, which
> lacks the necessary find_package calls to properly find and link to
> Gnuradio (and any other libraries you might use). You'll want to take a
> look at the toplevel CMakeLists.txt in the out-of-tree template as well as
> the one in lib/, which you'll want to modify to produce an executable
> instead of a library for your project.
>
> You could also look at the CMake files from other standalone Gnuradio
> applications for inspiration, such as gqrx.
>
> Nick
>
> On Tue, Oct 8, 2019 at 12:55 PM Moses Browne Mwakyanjala <
> mbkit...@gmail.com> wrote:
>
>> Hello Nick,
>> As I have mentioned in my previous email, I know how to use CMake as I
>> have already made a lot of OOTs before. Please understand that I'm not
>> trying to build an OOT. In the program, a top_block_sptr object (think
>> of it as a C++ based flowgraph) object is initialized with signal
>> generators and qt graphics. The Qt event loop initializes the flowgraph (an
>> object called 'mywindow'), makes signal/slot connections and runs it. You
>> can also have a look at the CMakeList.txt file I attached. It doesn't look
>> like the traditional OOT makefiles.
>>
>> Regards,
>>
>> Moses.
>>
>>
>> On Tue, Oct 8, 2019 at 9:21 PM Nick Foster  wrote:
>>
>>> Within the "out of tree module" link I sent is basic information on how
>>> to compile an application using CMake.
>>>
>>> https://wiki.gnuradio.org/index.php/OutOfTreeModules#Using_CMake
>>>
>>>
>>> On Tue, Oct 8, 2019 at 12:05 PM Moses Browne Mwakyanjala <
>>> mbkit...@gmail.com> wrote:
>>>
>>>> Hello Nick,
>>>> Thanks for your email.
>>>> I have created the OOTs already. What I'm trying to do it to integrate
>>>> my OOTs in a QT C++ application (something akin to Gqrx).
>>>> You could see what I'm trying to do from the example source code I
>>>> attached.
>>>>
>>>> Regards,
>>>> Moses.
>>>>
>>>> On Tue, Oct 8, 2019 at 8:56 PM Nick Foster 
>>>> wrote:
>>>>
>>>>> I think you should read up on creating out-of-tree GNURadio modules:
>>>>>
>>>>> https://wiki.gnuradio.org/index.php/OutOfTreeModules
>>>>>
>>>>> Nick
>>>>>
>>>>> On Tue, Oct 8, 2019 at 11:44 AM Moses Browne Mwakyanjala <
>>>>> mbkit...@gmail.com> wrote:
>>>>>
>>>>>> Hello all,
>>>>>> I'm trying to implement an easy-to-use QT-based receiver in GNU
>>>>>> Radio. As a starting point, I would like to compile a C++ example
>>>>>> (attached) under /gnuradio/gr-qtgui/examples/c++ . This example program
>>>>>> generates a noisy sine wave and displays on some qt gui qwidgets. I was
>>>>>> able to compile and run the program a couple of years ago. 
>>>>>> Unfortunately, I
>>>>>> can't remember what I did as the whole process was trial and error. I 
>>>>>> have
>>>>>> tried both "make" and "g++" without any luck. Please don't hesitate to 
>>>>>> ask
>>>>>> for more information.
>>>>>> All help is highly appreciated.
>>>>>> Best regards,
>>>>>> Moses.
>>>>>> ___
>>>>>> 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] Compiling QT C++ programs with GNU Radio

[Moses Browne Mwakyanjala]

Hello Nick,
As I have mentioned in my previous email, I know how to use CMake as I have
already made a lot of OOTs before. Please understand that I'm not trying to
build an OOT. In the program, a top_block_sptr object (think of it as a C++
based flowgraph) object is initialized with signal generators and qt
graphics. The Qt event loop initializes the flowgraph (an object called
'mywindow'), makes signal/slot connections and runs it. You can also have a
look at the CMakeList.txt file I attached. It doesn't look like the
traditional OOT makefiles.

Regards,

Moses.


On Tue, Oct 8, 2019 at 9:21 PM Nick Foster  wrote:

> Within the "out of tree module" link I sent is basic information on how to
> compile an application using CMake.
>
> https://wiki.gnuradio.org/index.php/OutOfTreeModules#Using_CMake
>
>
> On Tue, Oct 8, 2019 at 12:05 PM Moses Browne Mwakyanjala <
> mbkit...@gmail.com> wrote:
>
>> Hello Nick,
>> Thanks for your email.
>> I have created the OOTs already. What I'm trying to do it to integrate my
>> OOTs in a QT C++ application (something akin to Gqrx).
>> You could see what I'm trying to do from the example source code I
>> attached.
>>
>> Regards,
>> Moses.
>>
>> On Tue, Oct 8, 2019 at 8:56 PM Nick Foster  wrote:
>>
>>> I think you should read up on creating out-of-tree GNURadio modules:
>>>
>>> https://wiki.gnuradio.org/index.php/OutOfTreeModules
>>>
>>> Nick
>>>
>>> On Tue, Oct 8, 2019 at 11:44 AM Moses Browne Mwakyanjala <
>>> mbkit...@gmail.com> wrote:
>>>
>>>> Hello all,
>>>> I'm trying to implement an easy-to-use QT-based receiver in GNU Radio.
>>>> As a starting point, I would like to compile a C++ example (attached) under
>>>> /gnuradio/gr-qtgui/examples/c++ . This example program generates a noisy
>>>> sine wave and displays on some qt gui qwidgets. I was able to compile and
>>>> run the program a couple of years ago. Unfortunately, I can't remember what
>>>> I did as the whole process was trial and error. I have tried both "make"
>>>> and "g++" without any luck. Please don't hesitate to ask for
>>>> more information.
>>>> All help is highly appreciated.
>>>> Best regards,
>>>> Moses.
>>>> ___
>>>> 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] Compiling QT C++ programs with GNU Radio

[Moses Browne Mwakyanjala]

Hello Nick,
Thanks for your email.
I have created the OOTs already. What I'm trying to do it to integrate my
OOTs in a QT C++ application (something akin to Gqrx).
You could see what I'm trying to do from the example source code I
attached.

Regards,
Moses.

On Tue, Oct 8, 2019 at 8:56 PM Nick Foster  wrote:

> I think you should read up on creating out-of-tree GNURadio modules:
>
> https://wiki.gnuradio.org/index.php/OutOfTreeModules
>
> Nick
>
> On Tue, Oct 8, 2019 at 11:44 AM Moses Browne Mwakyanjala <
> mbkit...@gmail.com> wrote:
>
>> Hello all,
>> I'm trying to implement an easy-to-use QT-based receiver in GNU Radio. As
>> a starting point, I would like to compile a C++ example (attached) under
>> /gnuradio/gr-qtgui/examples/c++ . This example program generates a noisy
>> sine wave and displays on some qt gui qwidgets. I was able to compile and
>> run the program a couple of years ago. Unfortunately, I can't remember what
>> I did as the whole process was trial and error. I have tried both "make"
>> and "g++" without any luck. Please don't hesitate to ask for
>> more information.
>> All help is highly appreciated.
>> Best regards,
>> Moses.
>> ___
>> 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] Compiling QT C++ programs with GNU Radio

[Moses Browne Mwakyanjala]

Hello all,
I'm trying to implement an easy-to-use QT-based receiver in GNU Radio. As a
starting point, I would like to compile a C++ example (attached) under
/gnuradio/gr-qtgui/examples/c++ . This example program generates a noisy
sine wave and displays on some qt gui qwidgets. I was able to compile and
run the program a couple of years ago. Unfortunately, I can't remember what
I did as the whole process was trial and error. I have tried both "make"
and "g++" without any luck. Please don't hesitate to ask for
more information.
All help is highly appreciated.
Best regards,
Moses.
# Copyright 2016 Free Software Foundation, Inc.
#
# This file is part of GNU Radio
#
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.

include_directories(
  ${GR_QTGUI_INCLUDE_DIRS}
  ${GR_ANALOG_INCLUDE_DIRS}
  ${GR_FILTER_INCLUDE_DIRS}
  ${GR_BLOCKS_INCLUDE_DIRS}
  ${GR_FFT_INCLUDE_DIRS}
  ${GNURADIO_RUNTIME_INCLUDE_DIRS}
  ${QT_INCLUDE_DIRS}
  ${Boost_INCLUDE_DIRS}
)

list(APPEND QTGUI_LIBRARIES
  gnuradio-qtgui
  gnuradio-analog
  gnuradio-filter
  gnuradio-blocks
  gnuradio-fft
  gnuradio-runtime
)

QT4_WRAP_CPP(qtgui_moc_sources display_qt.h)
add_executable(display_qt display_qt.cc ${qtgui_moc_sources})
target_link_libraries(display_qt ${QTGUI_LIBRARIES})

INSTALL(TARGETS
  display_qt
  DESTINATION ${GR_PKG_QTGUI_EXAMPLES_DIR}
  COMPONENT "qtgui_examples"
)
/*
 * Copyright 2016 Free Software Foundation, Inc.
 *
 * This file is part of GNU Radio
 *
 * GNU Radio is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3, or (at your option)
 * any later version.
 *
 * GNU Radio is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with GNU Radio; see the file COPYING.  If not, write to
 * the Free Software Foundation, Inc., 51 Franklin Street,
 * Boston, MA 02110-1301, USA.
 */

#include "display_qt.h"

mywindow::mywindow()
  : QWidget()
{
  // We'll use a horizontal layout of two QTabWidgets
  layout = new QHBoxLayout();

  // Create the tab widgets
  tab0 = new QTabWidget();
  tab1 = new QTabWidget();

  // Add the tab widgets to the layou
  layout->addWidget(tab0);
  layout->addWidget(tab1);

  // Set the layout as the main widget's layou
  setLayout(layout);

  // Simple resizing of the app
  resize(2000,800);

  // sample rate
  int rate = 48000;

  // Create the GNU Radio top block
  tb = make_top_block("display_qt");

  // Source will be sine wave in noise
  src0 = analog::sig_source_f::make(rate, analog::GR_SIN_WAVE, 1500, 1);
  src1 = analog::noise_source_f::make(analog::GR_GAUSSIAN, 0.1);

  // Combine signal and noise; add throttle
  src = blocks::add_ff::make();
  thr = blocks::throttle::make(sizeof(float), rate);

  // Create the QTGUI sinks
  // Time, Freq, Waterfall, and Histogram sinks
  tsnk = qtgui::time_sink_f::make(1024, rate, "", 1);
  fsnk = qtgui::freq_sink_f::make(1024, fft::window::WIN_HANN,
  0, rate, "", 1);
  wsnk = qtgui::waterfall_sink_f::make(1024, fft::window::WIN_HANN,
   0, rate, "", 1);
  hsnk = qtgui::histogram_sink_f::make(1024, 100, -2, 2, "", 1);

  // Turn off the legend on these plots
  tsnk->disable_legend();
  fsnk->disable_legend();
  hsnk->disable_legend();

  // Connect the graph
  tb->connect(src0, 0, src, 0);
  tb->connect(src1, 0, src, 1);
  tb->connect(src, 0, thr, 0);
  tb->connect(thr, 0, tsnk, 0);
  tb->connect(thr, 0, fsnk, 0);
  tb->connect(thr, 0, wsnk, 0);
  tb->connect(thr, 0, hsnk, 0);

  // Get the raw QWidget objects from the GNU Radio blocks
  qtgui_time_sink_win = tsnk->qwidget();
  qtgui_freq_sink_win = fsnk->qwidget();
  qtgui_waterfall_sink_win = wsnk->qwidget();
  qtgui_histogram_sink_win = hsnk->qwidget();

  // Plug the widgets into the tabs
  tab0->addTab(qtgui_time_sink_win, "Time");
  tab0->addTab(qtgui_histogram_sink_win, "Hist");
  tab1->addTab(qtgui_freq_sink_win, "Freq");
  tab1->addTab(qtgui_waterfall_sink_win, "Waterfall");
}

mywindow::~mywindow()
{
}

void
mywindow::start()
{
  

[Discuss-gnuradio] Possible solution to USRP Packet Dropping

[Moses Browne Mwakyanjala]

Hello everyone,
I'm experiencing packet dropping when I operate the USRP X310 (1GBe, 1472
bytes buffer) at high sample rates (around 20 MSamples/Second). This
severely limits the nominal bit rate I was hoping for. Over a year ago, I
stumbled upon a presentation [1] where the presenter was able to go around
the problem by creating a block he called buffer. Basically, this block
converts high rate complex IQ samples into 2-byte char and store them
somewhere in RAM. The data is then released at a low-enough rate such that
subsequent blocks cause no overflows. Sadly, the code is not public and I
was thinking of writing a similar block myself. I'm looking for ideas on
how to efficiently reproduce his results. All suggestions are highly
welcomed.

Regards,
Moses.
[image: image.png]

[1] https://youtu.be/sDz9Ove0Dgc?t=581
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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 t

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

[Moses Browne Mwakyanjala]

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/listinfo/discuss-gnuradio