Hi Roman, sorry for the delay in getting back to you:
Regarding the power consumption: I don't have the Odroid XU4 PCB layout files, but assuming that you need to crank out let's say 1.6 A in sum through the USB3 connectors, don't forget that connector resistances, fuse/power monitoring shunts and also underdimensioned power traces might easily drop a couple hundred mV; so, I'd recommend measuring the voltage on the boards themselves; close to the USB connector on the B205i you'll find a relatively large capacitor, C114. Probe that with an oscilloscope (use the screw holes as ground contact), and check for stable voltage; a couple hundred mV below 5V will not hurt extremely much, but you really don't want things to see sudden breakdowns or averages below ca 4.8V. Maybe the `kitchen_sink` utility that we ship with UHD source in uhd/tools/kitchen_sink will tell you more about what's happening. Hope any of this helps, Marcus On Thu, 2018-01-11 at 08:13 +0000, Román Rodríguez Pérez via USRP-users wrote: > Good morning, > > We are trying to control two USRP B205i simultaneously on the same > device (an ODROID XU4 running Ubuntu 16.04 minimal). > > Our goal is to launch two instances of our software on system power > up (without the need of the user logging in into the OS), each one of > them running a different USRP front-end selected by its unique > serial. So we have configured them as 3 cron tasks: > > @reboot uhd_find_devices > /home/user/log/uhd.log 2>&1 > @reboot /usr/bin/screen –dmSL first_usrp /home/user/myapp –s > settings1.ini > @reboot /usr/bin/screen –dmSL second_usrp /home/user/myapp –s > settings2.ini > > The first line will store in a log file the result of calling > uhd_find_devices, just to check that both front-ends are being > detected. > > The other lines will run myapp instances with different settings > using screen command. > > This system design was tested using a laptop (instead of the ODROID, > using Ubuntu 16.04 desktop edition) and worked successfully. > Nevertheless, when working over the ODROID, if I check screen log > files, my first_usrp session starts correctly and continues working > continuously. On the other hand, my second_usrp session throws an > error and myapp terminates: > > UHD Error: > The receive packet handler caught an exception. > RuntimeError: usb rx6 transfer status: LIBUSB_TRANSFER_ERROR > terminate called after throwing an instance of 'std::runtime_error' > what(): Receiver error: ERROR_CODE_BAD_PACKET > > Please note that this does not mean that second_usrp session is the > one which fails always. In other occasions the one which fails is the > first one. It just seems that it is not possible to handle both USRPs > at the same time. Also, while typically this error happens for one of > the USRPs just after being initialized in our code, in some cases it > even runs smoothly for both USRPs for a while (less than 10 seconds) > until the error is thrown anyway for one of the front-ends. > > My first though was that this is a power problem, with the ODROID not > being able to supply enough amperage to the USRPs. Although I > couldn’t find the information about USRP 205-I power consumption, > this doesn’t seem to be the problem since I tested using a power > supply up to 20A and consumption did never go north of 3-3.2A and the > problem appeared again. > > I also considered CPU usage to be a problem, but after setting > exclusive cores to each instance the problem persisted and CPU usage > stayed around 30% of 1 core capacity. > > Libusb version was also considered, but version 1.0.20-2 which comes > with Ubuntu 16.04 seems quite up to date to be a problem (and is also > the same version deployed in the laptop). > > I also checked dmesg output for errors, but everything seems fine. > > We are also considering if the problem might be related to slower > operations over the hard disk (since ODROID works on a microSD card), > ODROID USB bandwidth capacity might being shared between both USB 3.0 > ports (and therefore not enough to handle both USRPs at the same > time), or even if this is an Ubuntu minimal problem. All of these > seem pretty far shoots, and I have run out of ideas. > > Any additional information on the causes of ERROR_CODE_BAD_PACKET on > rx6? Any hint about how to solve this problem? > > Best regards > > > Román Rodríguez Pérez > Project Manager / GNSS Software Engineer GMV > Isaac Newton, 11 > P.T.M. Tres Cantos > E-28760 Madrid > Tel. +34 91 807 21 00 > Fax +34 91 807 21 99 > www.gmv.com > > > > > P Please consider the environment before printing this e-mail. > This message including any attachments may contain confidential > information, according to our Information Security Management System, > and intended solely for a specific individual to whom they are > addressed. Any unauthorised copy, disclosure or distribution of this > message is strictly forbidden. If you have received this transmission > in error, please notify the sender immediately and delete it. Thank > you. > Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede > contener información clasificada por su emisor como confidencial en > el marco de su Sistema de Gestión de Seguridad de la Información > siendo para uso exclusivo del destinatario, quedando prohibida su > divulgación copia o distribución a terceros sin la autorización > expresa del remitente. Si Vd. ha recibido este mensaje erróneamente, > se ruega lo notifique al remitente y proceda a su borrado. Gracias > por su colaboración. > Esta mensagem, incluindo qualquer ficheiro anexo, pode conter > informação confidencial, de acordo com nosso Sistema de Gestão de > Segurança da Informação, sendo para uso exclusivo do destinatário e > estando proibida a sua divulgação, cópia ou distribuição a terceiros > sem autorização expressa do remetente da mesma. Se recebeu esta > mensagem por engano, por favor avise de imediato o remetente e > apague-a. Obrigado pela sua colaboração. > _______________________________________________ > 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
