Re: [Discuss-gnuradio] [USRP-users] C++ --> GRC(Socket PDU ---> QT Frequency GUI)

[Jack White]

For the moment it's just a UHF satellite telemetry downlink (attached) with GMSK. The initial behaviour was that after maybe a minute, I would suddenly get a load of dropped packets (D in the log) - maybe a hundred or so - then 'normal service' would resume. But this process repeated for about an hour and then communication would stop, the processor load for python would drop to 0% and the gui plots would remain static in their last configuration. However, it's not that the programme has frozen, because I can still rescale all the plots - it's communication with the X310 that's stopped.

Following the guidance of someone's post somewhere, I used netstat to monitor the kernel receive buffer errors (RcvbufErrors), which spiked over the running of the flowgraph. The poster said that this indicated the packets are being dropped in the kernel, not on the network card used for interfacing with the X310. So I installed a low-latency kernel. This has almost entirely got rid of the dropped packets, but the freeze now happens after maybe five minutes. GNU Radio doesn't log an error. I can ping the X310, but uhd_find_devices and uhd_usrp_probe don't find it, though maybe that's because there's still and open connection to it.

Cheers,

Jack

On Thu, Aug 3, 2017 at 10:19 AM, Marcus Müller <address@hidden> wrote:

Ah! You've set the data type of the QT GUI sink to "complex message"; I wasn't aware that this feature had made it to the master branch :)

The point of moving to C++ was that the flowgraph I really want to use is just causing me huge problems - most notably that there are periods of a few seconds every now and again when the USRP drops a load of packets and then, after a while, the flow just freezes up. I find it difficult to follow how GNU Radio really works and I thought it would be a better bet to be directly in control of my samples all the way.

Hm, yeah, I know it's not trivial, but I'm pretty sure this isn't the way to go. What kind of flow graph was giving you so much trouble?

Best regards,

Marcus

On 08/03/2017 11:15 AM, Jack White wrote:

Hi Marcus,

Thanks for the response. I attach the flowgraph I am using for this test, and for which I got the "unknown data type of samples" error.

I wasn't aware that the metadata was included in the PDUs, so that makes more sense now.

The point of moving to C++ was that the flowgraph I really want to use is just causing me huge problems - most notably that there are periods of a few seconds every now and again when the USRP drops a load of packets and then, after a while, the flow just freezes up. I find it difficult to follow how GNU Radio really works and I thought it would be a better bet to be directly in control of my samples all the way.

Jack

On Wed, Aug 2, 2017 at 10:45 PM, Marcus Müller via USRP-users <address@hidden> wrote:

Hi Jack,

PDUs are not just samples one after the other – they contain metadata. I can't really imagine what your flow graph looks like, so I'd be grateful for a screenshot (File->Screen Capture).

Anyway, there'd be no obvious reason your UDP detour would make things faster – maybe the intermediate socket buffering might help, but you'd probably get the same result by extending a UHD USRP Source's Output Buffer Size.

So, I'm not sure where we should take this – from a gut feeling, we should maybe move on to the discuss-gnuradio mailing list and discuss what part in your GNU Radio application isn't performing well enough – as I'm currently assuming your approach wasn't born through an in-depth analysis, but might more be of a trial&error iteration?

Best regards,

Marcus

On 02.08.2017 13:10, Jack White via USRP-users wrote:

Hi,

I've been having some difficulty getting reliable data flow from my USRP X310 with a GRC flowgraph, so I'm trying out writing my system in C++ with the UHD driver API. My first step has been to retrieve samples from the X310, forward them to a UDP port and then pick them up with a GRC Socket PDU component and then plot them. The C++ programme, so far, follows Ettus's example rx_samples_to_udp almost exactly and uses the std::complex<float> data type.

When the data enters the running flowgraph from the UDP transport, I get this error:

thread[thread-per-block[1]: <block freq_sink_c (1)>]: freq_sink_c: unknown data type of samples; must be complex.

Can anyone offer insight into why this should occur?

Many thanks,

--

Jack White
address@hidden
07875 813 745

_______________________________________________
USRP-users mailing list
address@hidden
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

_______________________________________________ USRP-users mailing list address@hidden http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

--

Jack White address@hidden 07875 813 745

--

Jack White
address@hidden
07875 813 745

IODDemo01.grc.png
Description: PNG image