Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

PoE-uitbreiding voor Raspberry Pi levert soms te weinig stroom aan randapparaten

Eben Upton, oprichter van de Raspberry Pi Foundation, geeft toe dat de recent verschenen Power over Ethernet-uitbreiding voor de RaspBerry Pi Model 3+ in sommige gevallen te weinig stroom levert aan usb-poorten. Kopers kunnen het bordje inruilen.

Upton zegt tegen The Register dat er minder dan 200mA wordt geleverd, waardoor problemen kunnen ontstaan met verschillende randapparaten zoals externe harde schijven. In een nieuwe productiereeks worden de problemen verholpen, maar de reeds geproduceerde PoE-uitbreidingen die problemen vertonen, worden alleen voorzien van een mededeling die kopers informeert.

Het probleem wordt veroorzaakt door de manier waarop de laagfrequente spanningsregelaar op de PoE-uitbreiding de usb-poorten van stroom voorziet. De stroomregelaar op sommige RPi 3+-bordjes kan hier niet goed mee overweg en denkt dat er kortsluiting optreedt, waardoor de stroom beperkt wordt.

Getroffen kopers kunnen ervoor kiezen hun product terug te sturen of zelf een reparatiepoging te ondernemen, daarvoor moeten de usb reservoir caps van het Raspberry Pi-bord zelf verwijderd worden. Dat heeft dan wel weer tot gevolg dat het bordje waarschijnlijk uitvalt bij het verwisselen van usb-apparatuur.

Volgens Upton is het gebrek niet aan het licht gekomen tijdens tests, omdat er bij de productie van de RPi 3+ twee merken van current limiting switches zijn gebruikt. Bij één merk treden de problemen op bij gebruik van de PoE-uitbreiding, bij het andere merk niet. De organisatie heeft maar met één uitvoering van het bordje tests uitgevoerd met usb-apparatuur die veel stroom vereist.

Upton zegt dan ook dat er in de toekomst meer test uitgevoerd zullen worden om soortgelijke incidenten te voorkomen. De PoE-Hat kwam onlangs beschikbaar en maakt het mogelijk om een Raspberry Pi Model 3+ via ethernet van stroom te voorzien met behulp van een geschikte switch, router of injector.

Door Sander van Voorst

Nieuwsredacteur

12-09-2018 • 13:13

60 Linkedin Google+

Reacties (60)

Wijzig sortering
De regulator op de HAT werkt kennelijk op een te lage frequentie waardoor er teveel stroom gaat lopen. Waarna de beveiliging van de usb ingrijpt. Hogere frequentie moet het oplossen, dan worden er in zekere zin 'kleinere brokjes energie verpompt' :
Because the regulator operates at a fairly low frequency, each time it switches it moves quite a large chunk of energy into the three USB reservoir caps via the current limiting switch: this large instantaneous current is fooling the switch into thinking that a genuine over-current event is occurring."
https://www.theregister.c...spberry_pi_poe_hat_issue/
Blijkt dus toch dat je met elke versie die je maakt moet testen. De stroomvoorziening van de RPi blijft toch een lastig punt. Met micro usb was er weer een probleem met slechte usb kabels.

[Reactie gewijzigd door Mr_gadget op 12 september 2018 13:22]

Waarschijnlijk (niet uit het artikel op te maken) zijn de specificaties van de usb power chip hetzelfde en zou dit, onder de meeste omstandigheden, geen problemen moeten geven. Alle tests runnen op alle versies van de PCB+Componenten is ondoenlijk. Het verbaast mij dan ook niet dat ze dat niet doen.

Dit is blijkbaar een corner case, welke naar boven komt in de eerste productie run, en daarna netjes word opgelost door een return actie te regelen. Goed dat ze deze nu meenemen in de volgende testruns, maar geen reden om het hele protocol omver te gooien en alles exhaustive te gaan testen en dan de prijs van het product omhoog te gooien door de gemaakte kosten.
Alle tests runnen op alle versies van de PCB+Componenten is ondoenlijk.
Natuurlijk wel. Alleen: je moet wel een strategie hebben om een combinatorische explosie van componenten te voorkomen. Als je voor onderdeel 1 leveanciers A en B hebt, en voor onderdeel 2 leveranciers X en Y, dan moet je alleen AX en BY bordjes maken, niet ook nog eens AY en BX.

En inderdaad, je moet van zowel AX als BY bordjes testen of ze aan de hele USB spec voldoen. Dat je ze allebei als "Raspberry Pi Model 3" verkoopt is marketing. In werkelijkheid zijn het twee vergelijkbare maar niet identieke producten, dus die moet je ook als zodanig testen.
Natuurlijk wel. Alleen: je moet wel een strategie hebben om een combinatorische explosie van componenten te voorkomen. Als je voor onderdeel 1 leveanciers A en B hebt, en voor onderdeel 2 leveranciers X en Y, dan moet je alleen AX en BY bordjes maken, niet ook nog eens AY en BX.
Als je interactiefouten wilt voorkomen moet je dit dus wel doen. Als een van de twee componenten afwijkende specs heeft kan dit op allebij de configuraties doorwerken, en om uit te vogelen welke dat is moet je ze alle 4 testen, wat exhaustive is en ondoenelijk voor relatief kleine bedrijven zoals de Foundation.

Ik ben het met je eens dat je de boel wil standaardiseren, maar dat is niet altijd mogelijk door leveringsproblemen of gebruik van chips die niet langer leverbaar zijn (eol) en waarbij de vervanging net iets anders opereert dan het origineel (niet ongebruikelijk).
Je snapt het duidelijk niet. Je kunt niet alle 4 de varianten produceren omdat je ze simpelweg niet eens produceert. Wat niet bestaat kun je ook niet testen.

Sowieso is het werken met twee leveranciers voor hetzelfde onderdeel iets wat je niet doet als klein bedrijfje. Ik ken het uit eigen ervaring - het wordt typisch relevant bij productieaantallen van meer dan een miljoen PCB"s. Dan krijg je het verschijnsel dat leveranciers moeite hebben met de volumes.

Je punt over vervangingen bij EOL is een stuk simpeler. Typisch krijg je daarvoor een last order date. Dan denk je na over je laatste batch met de oude onderdelen (AX), en ga je een nieuw ontwerp maken waarbij je potentieel ook andere onderdelen een update geeft (BY). Je hebt nog steeds maar twee ontwerpen, en bovendien produceer je er maar 1 tegelijk (afgezien van één batch test devices). Totdat je voorraad A en X componenten op is produceer je AX bordjes. Daarna sluit je de productielijn, vul je de machines met componenten B&Y, zet er een nieuw silk mask op met revisie N+1, en ga je BY bordjes maken.
Er is voor zover ik kan zien niet echt een return actie. je kunt de bordjes nu inleveren, maar er is nog geen nieuwe revisie verkrijgbaar volgens mij.
Laat dus idd zien dat je ieder component afzonderlijk moet testen en er niet vanuit moet gaat dat alles hetzelfde is.

Gelukkig hebben ze de testprocedure gewijzigd. Zou wel benieuwd zijn of ze de leverancier van current limiting switch die dus niet goed werkt aansprakelijk gesteld hebben voor de schade. Lijkt er dus op dat die niet goed werkt.
Laat dus idd zien dat je ieder component afzonderlijk moet testen en er niet vanuit moet gaat dat alles hetzelfde is.
Nee, dit laat juist zien dat je componenten niet afzonderlijk moet testen, want de fout treedt op bij de combinatie van een specifieke current limiting switch, de PoE-hat, en een veel verbruikend USB-apparaat.

Verder is het leuk dat ze de testprocedure wijzigen voor dit specifieke probleem, maar het aantal mogelijke combinaties van componenten die samen moeten werken is veel te groot om allemaal te testen, dus de volgende keer kan er zo weer wat doorheen glippen. Dat is geen fout van de testers.
Het komt door een specifiek component, waarbij die van producent A wel goed werkt en die van producent B niet. Ga je dus een bordje bouwen dan zul je dus beide situaties goed moeten testen. Zolang je het specifieke component van 1 leverancier afneemt hoef je dus alleen maar die te testen.
Dit is dus wel degelijk een fout van de tester, ze hadden beide bordjes moeten testen.
Als B zelf al duidelijk niet aan zijn specificatie voldoet, en dit hoort gevonden worden als B in isolatie wordt getest, dan wel.

Wat ik hieruit opmaak, is dat B normaal gesproken goed functioneert, alleen niet in combinatie met andere hardware. De stelling 'komt door een specifiek component' is dus te simplistisch. Dat vindt je dus niet met het testen van een component in isolatie, maar van het hele systeem met extenties. Het aantal mogelijk situaties wat je met extensies kan maken gaat al snel over de googleplex heen. Je test niet 'een bordje', je test één specifieke configuratie.

[Reactie gewijzigd door bwerg op 12 september 2018 14:46]

maar je test dus het bordje met deze configuratie.
Nou, nee, die ene configuratie die fout gaat test je dus niet. Je kan niet van tevoren bedenken in welke configuratie de fout zit (anders hoef je niet meer te testen), dus je zoekt een aantal representatieve combinaties. Daar zat een configuratie met beide varianten bij, alleen niet allebei in combinatie met een USB-apparaat dat veel verbruikt. En dus is die configuratie niet getest.

Je kan bij een waar-is-Waldo-zoekplaatje ook wel zeggen 'maar je wijst dus linksonder' omdat Waldo daar blijkt te zitten, maar dat is makkelijk praten achteraf.

[Reactie gewijzigd door bwerg op 12 september 2018 17:25]

Het probleem is dat moderne componenten voor 99% aan de specificaties voldoen. Genoeg om door snelel tests heen te komen, niet genoeg om blindelings toegepast te worden. En je weet vooraf nooit welke 1% precies het probleem is. Dat is zo'n beetje het gevolg van 20 jaar cost-cutting op de Chinese manier.
Als iedereen 200 euro voor een RPI bordje wil betalen en nog een jaartje wacht, kunnen deze problemen wel voorkomen worden... en misschien ook wel niet. Op een gegeven moment heb je naar je beste weten alles getest dat getest moet worden en breng je het component op de markt. Soms komt het dan voor dat je iets niet heb getest, bijvoorbeeld omdat een ander component (van de concurrent) net iets anders werkt dan normaal en die combinatie zorgt dan net voor problemen...

Ik ben van mening dat hardware en ICs (chips) in het bijzonder al heel erg uitgebreid worden getest. Als alle software net zo getest zou worden als hardware zouden voordat het ge-released wordt er veel minder bugs bestaan en we veel minder updates moeten uitvoeren.
Voldoet de switch niet aan de specificaties, of heeft men het verkeerde type switch besteld? Ik haal dat niet uit het artikel van theregister.co.uk.
Het is niet helemaal hetzelfde, maar ik heb een Pi hier in de patchkast al ongeveer anderhalf jaar POE, met een goedkope en simpele poe splitter. Voor een euro of 5 uit China. Ik begrijp dat het dan niet een mooie alles-in-één oplossing is, maar toch. Geen ventilator en het werkt ook gewoon.
Een passieve splitter (waarbij je dus de ongebruikte paren van de ethernetkabel gebruikt voor de stroomvoorziening) zal bij jou vast wel "gewoon werken", maar is bepaald geen universele/ideale oplossing om onder andere de volgende redenen:
* Werkt niet met gigabit-ethernet (dus niet met de Pi 3), want daarbij zijn alle aderparen in de kabel in gebruik.
* De maximumstroom per paar in ethernetkabels/connectors is gespecificeerd op 0.6A; als jouw splitter beide de bij 10/100 mbit ongebruikte paren gebruikt komt dat neer op 1.2 A, waar je al gauw overheen komt.
* De spanningsval over de kabel is niet te verwaarlozen, afhankelijk van de lengte kan het zijn dat de Pi niet de benodigde minimum voedingsspanning ontvangt.
* Je Pi is niet galvanisch geïsoleerd van de ethernetkabel, wat een veiligheidsrisico kan opleveren.

Apparatuur volgens de PoE-standaard, zoals dit PoE-uitbreidingsboardje, ondervangt al deze zaken.

[Reactie gewijzigd door Brousant op 12 september 2018 14:48]

Belangrijker nog: een PoE switch levert alleen stroom als een actieve component erom vraagt. Daardoor kun je veilig alle soorten apparaten aan een PoE switch aansluiten, ook niet-PoE apparatuur.

Die passieve splitter vraagt geen stroom, dus die moet je gebruiken in combinatie met een passieve splitter aan de andere kant van de kabel. Daar moet je dan een losse voeding aan hangen. En inderdaad, als je daar 5V gebruikt zit je zo aan de 1.2A - PoE is daarom ook 48V.
Er wordt nergens gesproken over passieve splitters. Enkel goedkoop en simpel.
Er bestond al een PoE splitter foor RasPi, die volledig IEEE 802.3af compatible was.
Maar dan heb je wel een ethernet passttrough kabel hangen:
https://uk.pi-supply.com/...ethernet-for-raspberry-pi

En de china afgeleide daarvan ziet er dan zo uit:
https://www.amazon.com/UC...t-Raspberry/dp/B01MDLUSE7
Aliexpress staat er ook vol van.

[Reactie gewijzigd door IceTeaGX op 12 september 2018 15:33]

Volgens zijn linkje krijg je voor 8 euro een active. Dat is wat mij betreft redelijk rond de 5 euro.
Correct. Wij hebben het Chinese origineel gekocht, en die waren inderdaad 5 euro. Niet zo gek; alle componenten zijn standaard.
Ach, met wat knutselwerk krijg je dat wel in een passend kastje, al ligt er hier ook één in een zgn sigarenkistje met draden ;)
Poe hé. Ik wist nog niet wat het was, maar het klinkt handig. Werkt het nou alleen met kabel of ook met WiFi?

[Reactie gewijzigd door BlueKingNL op 12 september 2018 13:45]

Poe hé. Ik wist nog niet wat het was, maar het klinkt handig. Werkt het nou alleen met kabel of ook met WiFi?
Als jij het voor elkaar krijgt om het QI signaal te verzenden met de WiFi ...

Maar POE is Power over Ethernet ... een eigen standaard in de 802.3xx specificaties
https://nl.wikipedia.org/wiki/Power_over_Ethernet
Werkt ook met wifi, maar je kunt in dat geval beter niet tussen je AP en de RPi doorlopen. De plasmastraal is schadelijk. :+
Dat kun je oplossen door er een flux capacitor er tussen te zetten.
Knappe Raspberry Pi die een plasmastraal maakt!
Nee, het is geen draadloze stroom.....
Niet netjes, bij de (dure!!) scherm uitbreiding zijn ze ook flink de fout in gegaan helaas.

De eerste versies zoals ik heb konden geen backlight dimming door (ook alweer) een foutje in de stroomvoorziening. Hier mocht je hem niet eens inruilen want ze vonden dat ze dit nooit beloofd hadden. Terwijl dit toch een standaard functie is die je zou mogen verwachten. Dus zit ik met een 79 euro kostend display dat continu op max. helderheid staat en die is veel te hoog voor de meeste gevallen :/

In elk geval bieden ze hier een omruiling optie, dat is al een stuk beter.
De meeste custom schermpjes voor de Pi doen niet aan backlight dimming (kunnen ze gewoonweg niet) tenzij je dat zelf er in prutst of via externe componenten (potmeter bijvoorbeeld). Dus om die reden te claimen dat het scherm van de Pi Foundation dat wel moet doen vind ik een beetje raar.

Dit is redelijk netjes opgelost omdat het de werking van de Pi beinvloed (wat niet de bedoeling is). Jouw probleem beinvloed de werking van de Pi niet, en valt dus ook niet onder enige vorm van garantie.

Het retourneren en omzetten/terugbetalen van verkochte artikelen is gruwelijk duur voor een relatief kleine organisatie, dus ik snap dat ze die van het scherm zo hebben gelaten.
Nou, in het geval van die backlight was het probleem dat het er wel degelijk in zat, maar ze hadden een fout gemaakt met de PWM controller hiervan die veel te harde pieken veroorzaakte en de pi liet crashen. Eigenlijk eenzelfde soort probleem als met de PoE dus. Ze hebben dat in de volgende revisie opgelost. Ze missen duidelijk wat expertise op powermanagement gebied.

Overigens was wel degelijk beloofd dat het zou werken op het raspberry forum. Het zat er in de software ook in, maar is uiteindelijk uitgeschakeld, en na pas heel veel vragen en doorzeuren is er een antwoord gekomen waarom. Maar uiteindelijk werd dit doodgezwegen als je er over begon, er werd ook niet meegeholpen aan het oplossen hiervan (bijvoorbeeld het aanpassen van de missende condensator). Ik vond het persoonlijk een bijzonder slechte manier om hiermee om te gaan.

Dit is bovendien geen 'custom' schermpje, het is een officieel accessoire dat een veel uitgebreidere support heeft dan die andere third party schermpjes.
Overigens was wel degelijk beloofd dat het zou werken op het raspberry forum.
Als dat zo is, dan heb je gelijk (mijn fout), en is het vrij dom van hen (officieel forum, indien door personen van de Foundation). Ik kan mij echter niet herinneren dat het in de originele specs stond vandaar dat ik het raar vond dat het te verwachten was.
Nou, in het geval van die backlight was het probleem dat het er wel degelijk in zat, maar ze hadden een fout gemaakt met de PWM controller hiervan die veel te harde pieken veroorzaakte en de pi liet crashen.
Verbaast mij niets, de Pi is nogal underpowered als je meer dan de USB aansluitingen wilt gebruiken. Een beetje flinke buffercap wil dit inderdaad wel oplossen en die brownouts die optreden voorkomen, maar een externe powersupply zal beter helpen indien mogelijk.
De organisatie heeft maar met één uitvoering van het bordje tests uitgevoerd met usb-apparatuur die veel stroom vereist.
Dat is wel erg dom, gelukkig lossen ze het erg netjes op en 'leren' ze van die fout.

[Reactie gewijzigd door watercoolertje op 12 september 2018 13:17]

Niet erg dom. Het probleem treed op in specifieke combinaties van hardware, je kunt nooit alle combinaties testen en daarom bepaal je welke tests het belangrijkst zijn. Als je varianten A, B en C wil testen met extra hardware-modules X, Y en Z, dan maak je een inschatting welke combinaties extra risico lopen, en die combinaties test je specifiek. Denk je dat er weinig risico is, dan test je dat niet: als de componenten afzonderlijk werken, zal de combinatie ook wel werken.
Het gaat om specifiek onderdeel niet perse een combinatie (is ook niet uigesloten in het artikel).

Er zit ook niet zo extreem veel op het boordje en de oplage is ook niet extreme waardoor schaarste van 1 levernacier niet heel waarschijnlijk is voor elk onderdeel.

Het klinkt mij of er 2 versies zijn van het bordje en dan zou elke versie gewoon goed getest moeten zijn.
Het klinkt mij of er 2 versies zijn van het bordje en dan zou elke versie gewoon goed getest moeten zijn.
Of er goed getest is kun je hier moeilijk uit opmaken. Testen bewijst geen correctheid, ook goed testen niet, dus er kunnen altijd bugs niet gevonden worden. Achteraf redeneren en zeggen dat iets in testen gevonden had moeten worden, is gemakkelijker gezegd dan gedaan.

[Reactie gewijzigd door bwerg op 12 september 2018 14:37]

Ze zeggen zelf dat ze het niet getest hebben (en wel bij de ander) dus duidelijker bestaat niet :+

[Reactie gewijzigd door watercoolertje op 12 september 2018 15:21]

It was, Upton observed, "dumb luck" that heavy load testing was done with one brand of switch while lighter testing occurred with the other. Thus the PoE HAT passed product validation.
Ze geven toe dat ze 'het' niet getest hebben, inderdaad, maar 'het' is dus de combinatie van load-testing, het PoE-component, en de specifieke variant van het bord.

Dus
  • Load testing is uitgevoerd op het PoE-component
  • variant A en variant B zijn getest op het PoE-component
  • load testing is uitgevoerd op variant A en B (niet expliciet genoemd, maar dit mag ik toch hopen)
Ze volgen dus wel zo'n beetje de best practices in het testen, voor zover van toepassing op hardware-testing. Alleen de gehele combinatie van de drie parameters is niet volledig getest.

Duidelijker bestaat niet, als je testen simplificeert tot het binaire oordeel 'product wel getest' en 'product niet getest', wat totaal onrealistisch is. Wat mij betreft is het juist duidelijk dat je dit soort fouten niet altijd kan ontdekken met testen. Voor de volledigheid even de wikipedia-uitleg:
The most common bugs in a program are generally triggered by either a single input parameter or an interaction between pairs of parameters. Bugs involving interactions between three or more parameters are both progressively less common and also progressively more expensive to find---such testing has as its limit the testing of all possible inputs. Thus, a combinatorial technique for picking test cases like all-pairs testing is a useful cost-benefit compromise that enables a significant reduction in the number of test cases without drastically compromising functional coverage.

[Reactie gewijzigd door bwerg op 12 september 2018 16:08]

In dit geval kiest men er voor om componenten van 2 verschillende leveranciers te gebruiken, dus dan is het wel van belang dat je de betreffende componenten controleert of die identiek presteren.. Dat is ook redelijk normaal bij productie van electronica.
Verschillende componenten presteren praktisch nooit helemaal identiek. Dat hoeft ook niet, als beide componenten gewoon aan hun specificaties voldoen. Of dat zo is, maak ik uit dit nieuwsbericht niet op, en zonder dat te weten kun je moeilijk zeggen of er dus een fout is gemaakt in het testen.
[...]
gelukkig lossen ze het erg netjes op
Daar ben ik het niet mee eens, wie betaald de verzendkosten naar de webshop hier in NL á ¤7?
Dan heb ik het niet eens over de buitenlandse webshops, waar de verzendkosten nog hoger liggen.
En wie betaald de webshop terug met het versturen van de nieuwe (en eventueel de oude naar de leverancier om een nieuwe te krijgen)
De verkoper. Die heeft je immers een ondeugdelijke product verkocht. Daar kan je nu prima de koop ontbinden. En zal je geen cent armer van worden. Je bent alleen wat tijd kwijt.
Dat is wettelijk zo, maar de praktijk is toch vaak anders hier bij NL webshops, dan heb ik het nog niet eens over Europese of buiten Europese webshops.
De meeste webshops houden zich daar prima aan hoor. Maar ik kan begrijpen als je het bij een student als winkel haalt het iets lastiger kan worden. Des te meer reden om ze te dagvaarden. Zeker bij zit soort zaken is het zo klaar als een klontje. En ik weet niet of zij de verzendkosten vergoeden. Genoeg bedrijven doen dit namelijk wel. Of ruilen hem om voor versie die de problemen niet heeft
Dat is omdat de meeste kopers niet weten dat dit zo'n klein bedrag is dat ze geen advocaat nodig hebben. Gewoon een eis indienen bij je lokale kantonrechter, grote kans dat de webwinkel niet naar jouw zaak toe komt. Dan heb je een veroordeling bij verstek, en wordt je hele eis toegewezen.
In eerste instantie wilde ik de PoE-hat bestellen maar gered door me eigen twijfel (vindt hem nogal prijzig).

We erg netjes inderdaad dat je hem mag terug sturen. Heb nu een 2015 en 2017 RPi3 hier liggen, blijven erg leuke devices om mee te spelen.
Maar adviseren om die elcos er dan maar af te braaien?! Is vervangen door beter gespecificeerde elcos dan niet raadzamer. (antwoord: ja!)

Er is genoeg meuk aan elcos in omloop die voornamelijk in N-korea en dat soort landen worden gemaakt.
Kost ook bijna niks dus dat maakt ze aantrekkelijk, heh.

edit: hoezo off-topic?

[Reactie gewijzigd door ToolBee op 12 september 2018 14:56]

Dat adviseren ze niet maar geven ze als mogelijke oplossing. Het advies is je bordje ruilen.
Wellicht handig waar je een bord met problemen aan herkennen (merk/type van de caps).
Of gewoon serienummers van de gewraakte bordjes online zetten? ;)
Het artikel vermeldt wel dat er dus een reeks pi's is waar dit probleem niet optreedt, omdat er een ander type current limiter gebruik is? Of althans: bij dat type is er getest met hogere stroom zonder problemen. Is het dan niet handig om te vermelden hoe je kan zien welk type current limiter jouw pi heeft, en dus vatbaar is of niet? Als je toevallig net de goede pi hebt is er niks aan de hand. Het excuseert niks, maar voor de consument misschien wel handig om te weten.
Ah, ik had hier inderdaad last van :-(

Ik had al een third party PoE hat, en die werkte prima. vervangen omdat deze kleiner zijn en de Pi weer in een normale behuizing past. Maar inderdaad allemaal errors over "USB over-current protection"
Ik wacht eigenlijk op een snellere pi met een snellere cpu maar ook gpu zodat je met Recalbox ook zwaardere N64/Dreamcast en arcade games kunt spelen. De helft doet het niet of slecht. Iemand een alternatief voor een Raspberry pi waar Recalbox ook op werkt zonder teveel gedoe. (Geen retropi dus, die vind ik niets)

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True