| Hello everyone, I’m an electrical engineering master-degree student from Münster, Germany. We have some Ettus devices round here at FH Münster, that were only used with GNU Radio until now, but for a bigger project I now try to use the UHD C++ API for the first time to build a custom (and hopefully fast) C++ application. For this application I need four RF Input streams, coming from four USRP N120. To achieve this, I bundle them into one multi_usrp object. I pasted the relevant lines of code including some comments to a gist to keep this email as short as possible - please take a look here: https://gist.github.com/JanosGit/5273a550867ef1d966741b6e93cacd55 The application is developed on Mac OS X at the moment but with cross-platform compatibility in mind - probably it will be ported to Linux sooner or later. Now, the way I currently set everything up no samples ever get received, the call to rxStream->recv blocks for about a minute before an error message is printed to the command line: UHD
Error: The receive packet handler failed to time-align packets. 67936 received packets were processed by the handler. However, a timestamp match could not
be determined. This also happens if I try to use only three or two channels, however, when I put just one channel into the streamArgs.channel vector, continuos receiving will work. But even if no error is thrown in the one-channel-setup, valid data will only be received if I pass channel 0 to the streamArgs.channels vector. For test purposes, I connected an oscillator to all four receivers, if I receive channel 0, a sine wave appears, but if I put any other channel index first into the channel vector, there is something looking like a dc-block-capacitor from the analogue front-end charging. I plotted (real samples only) both scenarios to make this clear: |
UHD Error.pdf
Description: Adobe PDF document
I tried connecting the oscillator to every possible port of all four devices, but I only get this charging curve from all receivers except for device 0. I also get a similar curve from device 0 if I disconnect the oscillator and just leave the RF port open, so it seems to me as if this is the usual response from an open rf port. Now if I swap the IP-Adresses passed to multi_usrp::make, so that a different hardware device will become channel 0, it stays the same - I’m able to receive valid data from channel 0, no matter which hardware device is channel 0 and all other channels will provide me the same curve. This makes me sure that it’s no hardware error, I got all four hardware devices delivering valid samples as long as their IP address is the first one passed to multi_usrp::make. I’m not sure if both errors I described are related or if there are two completely different reasons for them. Anyway, I’d be glad if you would check the pasted code snippet for errors. And just for your information, I won’t have access to the USRPs for the next 2 weeks, but it would be great if I came back in 2 weeks to continue working with some fresh ideas and hopefully a solution. Best regards Janos |
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
