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 < usrp-users@lists.ettus.com> 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 > white.n.j...@googlemail.com > 07875 813 745 > > > _______________________________________________ > USRP-users mailing > listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > -- Jack White white.n.j...@googlemail.com 07875 813 745
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
