|
From: | Jack White |
Subject: | Re: [Discuss-gnuradio] [USRP-users] C++ --> GRC(Socket PDU ---> QT Frequency GUI) |
Date: | Thu, 3 Aug 2017 11:06:39 +0100 |
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:
JackThe 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.I wasn't aware that the metadata was included in the PDUs, so that makes more sense now.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.
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:
Can anyone offer insight into why this should occur?When the data enters the running flowgraph from the UDP transport, I get this error: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.
thread[thread-per-block[1]: <block freq_sink_c (1)>]: freq_sink_c: unknown data type of samples; must be complex.
Many thanks,
--
_______________________________________________ USRP-users mailing list address@hidden http://lists.ettus.com/mailman /listinfo/usrp-users_lists.ett us.com _________________ USRP-users mailing list address@hidden http://lists.ettus.com/mailman /listinfo/usrp-users_lists.ett us.com Jack White address@hidden 07875 813 745
IODDemo01.grc.png
Description: PNG image
[Prev in Thread] | Current Thread | [Next in Thread] |