Thanks for that suggestion Rob, I have tested this now, I now address both devices, I have changed subdev spec to "A:0 B:0" for both motherboards (lines 35, 36). Then I tried several values for stream_args.channels:
I tried with stream_args.channels = (0,2). Here I expect signal on A outputs on both X310s. But I get the following two cases: * The A and B outputs on the first X310 are enabled (TX LED), with signal visible on output, first channel mapped to A output and second channel mapped to B output. * The A and B outputs on the second X310 are enabled (TX LED), with _no signal_ on output. Channel mapping can't be determined because there is no signal. I tried with stream_args.channels = (1,3). Here I expect signal on B outputs on both X310s. But I get the following two cases: * The A and B outputs on the first X310 are enabled (TX LED), with signal visible on output, first channel is mapped to B output and second channel mapped to A output. (Notice reversal of first and second channel) * The A and B outputs on the second X310 are enabled (TX LED), with _no signal_ on output. Channel mapping can't be determined because there is no signal. I tried with stream_args.channels = (2,3). Here I ecpect signal on A and B outputs on the second X310. But I get the following two cases: * The B outputs on both X310 are enabled (TX LED), with signal only visible on the first X310. First channel mapped to B output on first X310. * The A outputs on both X310 are enabled (TX LED), with signal only visible on the first X310. Second channel is mapped to A output on first X310. There is some randomness as to which case happens, I have tested approx 10 runs of each. It looks like what occurs is some shuffling around of the channels, so that the logical channel number (the indexes in the buffer array passed to send()) does not match up with the subdev specification. Since some incorrect outputs get enabled, but with no signal, maybe that helps in understanding where in UHD this could occur. In all these cases, I don't receive the error message I mentioned in my first mail, but the changing channel mapping is just as bad for what I'm trying to do. Regards Andreas ________________________________ CONFIDENTIALITY This e-mail and any attachment contain KONGSBERG information which may be proprietary, confidential or subject to export regulations, and is only meant for the intended recipient(s). Any disclosure, copying, distribution or use is prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in error, please delete it immediately from your system and notify the sender properly. _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
