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 <mailto: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
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
