I have generally had to use external power with Odroids for B2xx.
Sent from my iPhone > On Feb 17, 2018, at 8:02 AM, Marcus Müller via USRP-users > <usrp-users@lists.ettus.com> wrote: > > 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 _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
