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

[Marcus Müller]

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