Azért tippelek a tápra, mert ha labilis az USB kommunikáció, a host eldobja a device-t, annak lehet az az oka, hogy a device újraindul, a host driver-e meg timeout-ol. Ugyanakkor ne csak az RPI táplálására gyanakodj. Ahogy írtam, pusztán abból is lehet baj, hogy hosszú az USB kábel. Hiába nem terheled túl a csatlakozót, s a host oldalán hiába van meg az 5 V, ha a vezetéken esik akkora feszültség, hogy a device tegyük fel, olykor 4.5 V-ról táplálkozik. Konklúzió: használj igen rövid USB kábelt legalább a próba idejére, valamint amit javasoltak, használj "Y" kábelt. Ezen felül semmiképp se toldd, ne hosszabbítsd az USB kábelt!
Viszont az RPI táplálásánál is lehet gond a hosszú kábel. Normális mérnök éppen ezért soha nem csinál olyat, hogy a már stabilizált feszültséget viszi messzebbre, mert a feszültségesés, a vezeték ellenállása és öninduktivitása miatt nem lesz már stabil a feszültség, hanem a terheléstől függően változni fog.
Úgy szokás ezt, hogy a stabilizálatlan feszültséget visszük vezetéken, majd helyben, a felhasználás helyén lévő nyákon stabilizáljuk a feszültséget az alkalmazás számára, így ott biztosítható az igen alacsony generátor impedancia, s ezzel a terheléstől független stabil tápfeszültség.
Az USB a fenti szempontokat nem veszi figyelembe, mondhatjuk bátran, hogy egy hibás konstrukció. Ugyanakkor tegyük hozzá, az USB esetén kifejezetten alacsony áramigényű eszközök táplálása volt a cél. Ez egy egér, egy billentyűzet esetén teljesül is. Sajnos megjelentek olyan perifériák, amelyek nem valók USB-re, de helytelen módon rá lettek erőltetve. Az USB-s külső HDD kifejezetten ilyen agyrém, de a GSM modem hasonlóképpen. Ezeknek külső tápot kellene adni, de hát mennyivel kevesebb a drót, mosolygósabb a felhasználó, még ha műszakilag inkorrekt is a megoldás.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE