Ein neuer Controller

[MasterOfGizmo]

Hab mich mal durch das libroboint-Massaker gewühlt und die Änderungen in bb258fc übernommen.

Wie bist Du denn auf

Code: Alles auswählen

area->AV = 3.1267*AV-51.068;

gekommen? Bei mir liefert 0.03*AV wirklich exakte Werte in Volt. Allerdings habe ich nur 6-11 Volt getestet.

[Defiant]

Ist bei meiner Robo IO Extension der Wert in mV. Gemessen mit zwei Spannungen (~9V und ~6V) und durch polyfit() berechnet. Die etwas über 9V meines ft-Netzteils haben z.B. einen Wert von 332.

Edit: Hmm, mit 3*AV kommt man allerdings auch ganz gut hin, die jetzige Formel ist vermutlich einfach auf die Toleranzen meiner Version angepasst, und mein Messmittel war jetzt auch nicht kalibriert.

[Markus Burkhardt]

Hallo zusammen,

darf ich vorschlagen, dass wir diese Diskussion in die Kategorie "Robo Pro / Computing / Software" verschieben?

Viele Grüße
Markus

[sven]

Hallo!

@markus:
Gute Idee, das hatte ich mir auch schon überlegt.

Habe diesen Thread dann mal direkt verschoben.

Gruß
Sven

[MasterOfGizmo]

Ist bei meiner Robo IO Extension der Wert in mV. Gemessen mit zwei Spannungen (~9V und ~6V) und durch polyfit() berechnet. Die etwas über 9V meines ft-Netzteils haben z.B. einen Wert von 332.

Bei mir liefert das bei 9V aus stabilisiertem Netzteil genau 300, manchmal auch 301. Deine Rechnung liefert aber dann Centivolt, nicht Millivolt ...

[Defiant]

Richtig. Allerdings hab ich da eh mist gebaut, da laut der Knobloch-Lib AV anscheinend den Rohwert des ADC (0..1023) enthält. Die Umrechnung in der lib ist damit also Geschichte.

[richard.kunze]

Hallo MoG,

hast Du den ROBO LT direkt am TXT getestet oder nur am PC?

Ich bekommen meinen nämlich am TXT nicht zum Laufen - ich kriege da nur die folgenden Fehlermeldungen:

Code: Alles auswählen

[   44.978293] musb-hdrc musb-hdrc.2.auto: VBUS_ERROR in a_wait_bcon (91, <VBusValid), retry #1, port1 00000104
[   45.062732] musb-hdrc musb-hdrc.2.auto: VBUS_ERROR in a_wait_vrise (91, <VBusValid), retry #2, port1 00000104
[   47.737294] musb-hdrc musb-hdrc.2.auto: VBUS_ERROR in a_wait_vrise (91, <VBusValid), retry #3, port1 00000104
[   50.466552] musb-hdrc musb-hdrc.2.auto: VBUS_ERROR in a_wait_vrise (90, <VBusValid), retry #3, port1 0008010c

Danach ist dann der Host-USB blockiert und macht bis zum nächsten Reboot gar nichts mehr.

Laut Google bedeutet die Fehlermeldung wohl, dass die Versorgungspannung für das angeschlossene Gerät nicht rechtzeitig bereitsteht und der Bus dann aus Sicherheitsgründen abgeschaltet wird. Warum das beim ROBO LT passiert und z.B. bei der Kamera nicht weiß ich noch nicht.

Edit: Mit einem USB-Hub (mit eigener Stromversorgung) zwischendrin läuft der ROBO LT auch am TXT. Sollte aber eigentlich trotzdem auch direkt gehen...

Edit2: Mit einem USB-Hub ohne eigene Stromversorgung geht es auch. Sogar mit einem Motor (im Leerlauf), und ohne die zusätzliche Stromversorgung am LT anzuschliessen. Liegt also wohl nicht daran, dass der LT mehr Strom zieht als USB erlaubt oder der TXT liefern kann, sondern scheint eher ein (Timing-?)Problem beim Einschalten des LT zu sein...

[MasterOfGizmo]

Laeuft bei mir direkt am TXT. Stromversorgung des RoboLT vom Versorgungsausgang des TXT.

[richard.kunze]

Laeuft bei mir direkt am TXT. Stromversorgung des RoboLT vom Versorgungsausgang des TXT.

Seltsam.

Bei mir gibt ein direkter Anschluss an den TXT immer einen Fehler. Mit einem Hub ohne eigene Stromversorgung dazwischen klappt es oft (aber nicht immer), ich kann aber zuverlässig einen Fehler provozieren wenn ich den LT ab- und wieder anstecke. Den ganzen Hub ab- und wieder anhängen klappt meistens, aber nicht immer. Wenn der Hub zusätzlich von extern mit Strom versorgt wird läuft alles stabil.

Wenn der LT einmal erfolgreich läuft, dann läuft er auch in allen Fällen stabil.

Stromversorgung für den TXT ist bei mir normalerweise ein Steckernetzteil 9V/500mA (nicht von Fischertechnik), aber mit dem FT-Akku habe ich exakt dasselbe Verhalten. Mit dem Setup TXT<->Hub(unpowered)<->LT und zusätzlich 9V vom Versorgungsausgang des TXT an den LT meldet die Test-App eine Versorgungspannung von 9.27V und mein (einfaches) Multimeter zeigt 9.1V. Ohne die 9V-Versorgung meldet die App eine Spannung von 2.22V.

[MasterOfGizmo]

Ohne die 9V-Versorgung meldet die App eine Spannung von 2.22V.

Ohne die 9V-Versorung tut der LT, den ich hier habe gar nichts. Welche Firmware-Version meldet der bei dir denn?

Am Ende hat einer von uns beiden kein Seriengerät ... das wäre ja wenig hilfreich ...

Edit: So, hab' gerade nochmal getestet. TXT gestartet an einfachem 9V-Netzteil. Dann LT erst via FT-Kabel am TXT unten rechts mit Spannung versorgt, dann USB-Kabel eingestellt. LT-Demo gestartet: Geht. Dann TXT ausgeschaltet, wieder eingeschaltet. LT geht immernoch.

Ich sehe Deine Probleme definitiv nicht. Nun wäre ja interessant, welcher Teil den Unterschied ausmacht. Vielleicht unterscheiden sich ja auch unsere TXTs. Meiner wurde vor ziemlich genau einem Jahr gekauft. Das Netzteil ist ein stabilisiertes 1.5A Universalnetzteil aus dem Saturn in der Stadt, das auf 9V gestellt ist, dann auch recht genau 9V liefert. Direkt darüber versorgt und an den PC angeschlossen zeigt der LT auch genau 9V an. Mit dem gleichen Netzteil aber über den TXT versorgt zeigt er nur 8.21V an. Ich nehme an, dass da irgendwelche TXT-Internen Strombegrenzungen, Spannungsregler, ... Schuld sind ...

[richard.kunze]

Ohne die 9V-Versorung tut der LT, den ich hier habe gar nichts.

Meiner funktioniert definitiv auch wenn er nur per USB mit Strom versorgt wird.

Der liefert sogar ohne zusätzliche Stromversorgung an den Motorausgängen ca. 7.5V ohne Motor und immerhin noch 6.9V, wenn er einen leer drehenden XM-Motor versorgt. Mit zusätzlicher Stromversorgung habe ich an den Motorausgängen 8.9V ohne und 8.2V mit Motor.

Wenn ich die zusätzliche Stromversorgung abziehe während der Motorausgang eingeschaltet ist, dann sinkt die Spannung ohne Motor innerhalb von ca. 10 Sekunden von 8.9V auf 7.5V ab.

Scheint so, als könnte mein LT die Versorgungsspannung für Modelle auch aus den 5V am USB erzeugen.

Welche Firmware-Version meldet der bei dir denn?

Die Test-App sagt Firmware V3.0.8.0, Serial 1. Wobei die Seriennummer laut Aufkleber an der Seite eigentlich 00318037 sein sollte.

Edit: So, hab' gerade nochmal getestet. TXT gestartet an einfachem 9V-Netzteil. Dann LT erst via FT-Kabel am TXT unten rechts mit Spannung versorgt, dann USB-Kabel eingestellt. LT-Demo gestartet: Geht. Dann TXT ausgeschaltet, wieder eingeschaltet. LT geht immernoch.

Gleiches Szenario bei mir: Nope. Geht definitiv nicht.

Wann geht bei Dir denn die grüne LED am LT an: Wenn Du die 9V einsteckst oder wenn Du USB anschließt? Bei mir: Wenn ich USB anschließe.

Ich sehe Deine Probleme definitiv nicht. Nun wäre ja interessant, welcher Teil den Unterschied ausmacht.

So wie es aussieht haben wir wohl tatsächlich unterschiedliche LTs.

Vielleicht unterscheiden sich ja auch unsere TXTs. Meiner wurde vor ziemlich genau einem Jahr gekauft.

Meinen habe ich erst im Januar gekauft, aber die ursprünglich aufgespielte Firmware war von Anfang/Mitte letzten Jahres (Für die genau Version müsste ich in den Dump vom Root-Filesystem schauen, aber der zugehörige Kernel wurde am 29. März 2015 übersetzt).

Das Netzteil ist ein stabilisiertes 1.5A Universalnetzteil aus dem Saturn in der Stadt, das auf 9V gestellt ist, dann auch recht genau 9V liefert.

Meins ist eine Wandwarze aus der Bastelkiste, ebenfalls einstellbar, aber es liefert nur maximal 500mA. Die Spannung scheint da nicht so gut geregelt zu sein wie bei Deinem Netzteil, ich hab auf der "9V"-Einstellung im Leerlauf 11.8V anliegen :-/

Direkt darüber versorgt und an den PC angeschlossen zeigt der LT auch genau 9V an. Mit dem gleichen Netzteil aber über den TXT versorgt zeigt er nur 8.21V an.

Ist hier genau so - direkt am Netzteil zeigt der LT die Spannung des Netzteils an, am TXT nur 8.2V.

Edit: Auf meinem LT steht - anders als auf dem Foto aus der Datenbank - auch explizit "ROBO LT Controller USB powered" drauf. Wie sieht das denn bei Dir aus?

[MasterOfGizmo]

Die Test-App sagt Firmware V3.0.8.0, Serial 1. Wobei die Seriennummer laut Aufkleber an der Seite eigentlich 00318037 sein sollte.

Meine Firmware ist 3.0.5.0. Die Serienummer ist laut Kommentar in libroboint immer 1 bis man sie per speziellem Kommando aktiviert und dann die richtige Seriennummer kommt. Der Auflkeber bei mir sagt 00301654.

Wann geht bei Dir denn die grüne LED am LT an: Wenn Du die 9V einsteckst oder wenn Du USB anschließt? Bei mir: Wenn ich USB anschließe.

Erst wenn externe 9V anliegen geht die LED an.

Edit: Auf meinem LT steht ... auch explizit "ROBO LT Controller USB powered"

Nö, meiner sieht aus wie der aus der Datenbank. Nix mit USB-Powered.

Sieht so aus, als hätte ich das ältere Modell, das sich noch nicht über USB versorgen konnte. Aber genau das scheint der Teil zu sein, mit dem der TXT bei Dir Probleme hat.

Na super ... hab' ich also einen Treiber für ein Gerät geschrieben, das gar nicht mehr verkauft wird?

Edit: Du könntest versuchen, ein USB-Kabel zu nehmen, bei dem die 5V-Leitung gekappt ist. Oder eines, wo ein fetter Elko an 5V stützt. Sieht mir so aus, als würde der "neue" LT auch dann an den 5V nuckeln, wenn er eigentlich eine separate Versorgung hat. USB macht da recht enge Vorgaben, was den erlaubten Stromverbrauch vor der Enumerierung bzw. vor vollständiger Konfiguration angeht. Klingt als würde sich der neue LT da nicht an die Spec halten. Speziell vor der Enumerierung darf man praktisch keinen Strom ziehen.

Na da wünschen wir uns doch umso mehr einen kleinen self-powered-USB-Hub von FT.

Aber ist schon cool, dass sie ihre eigenen Produkte anscheinend nicht gegeneinander testen. Mutig

[richard.kunze]

Edit: Auf meinem LT steht ... auch explizit "ROBO LT Controller USB powered"

Nö, meiner sieht aus wie der aus der Datenbank. Nix mit USB-Powered.

OK, das dürfte es dann erklären.

Sieht so aus, als hätte ich das ältere Modell, das sich noch nicht über USB versorgen konnte. Aber genau das scheint der Teil zu sein, mit dem der TXT bei Dir Probleme hat.

Scheint so. Aber so wie es aussieht auch "nur" beim Start - wenn ich den LT (per Umweg über den powered USB Hub) einmal am Laufen habe, dann kann ich die zusätzliche Stromversorgung am Hub auch abziehen und es läuft trotzdem alles weiter - inklusive Stromversorgung für einen Motor über den USB-Anschluss am TXT. Und an einem normalen USB-Port am PC läuft der LT ja auch problemlos.

Mit etwas Glück braucht der LT also nur bei der Initialisierung etwas länger bis die USB-Spannung stabil wird, und der TXT ist da etwas zu pingelig. Dann könnte man das wohl per Software lösen.

Und im schlimmsten Fall - wenn der LT tatsächlich mehr Saft braucht als der TXT liefern kann - bleibt immer noch der Weg über einen zwischengeschalteten USB-Hub mit zusätzlicher Stromversorgung.

Ich schau mal, ob ich Informationen darüber finde welche Leistung der Host-USB am TXT zur Verfügung stellen kann, und was der LT tasächlich haben will (Der LT selbst - via "lsusb -v" - ist da wenig hilfreich. Der behauptet, er wäre "bus powered" und will maximal 0mA. Das kann so nicht stimmen :-/) Aber vermutlich erst nachdem die v0.9 draußen ist - ich hab hier eigentlich noch ein paar Aufräumarbeiten, Doku und etwas Netzwerkkram auf dem Zettel, und langsam wirds auch mal Zeit für ein Release.

Alternativ kann ich Dir auch meinen LT schicken, wenn Du vorher Zeit hast Dir das mal anzuschauen.

Na super ... hab' ich also einen Treiber für ein Gerät geschrieben, das gar nicht mehr verkauft wird?

Der Treiber scheint ansonsten ja auch mit meinem LT prima zu laufen.

[richard.kunze]

Edit: Du könntest versuchen, ein USB-Kabel zu nehmen, bei dem die 5V-Leitung gekappt ist. Oder eines, wo ein fetter Elko an 5V stützt.

Ich hab den Verdacht, dass genau so ein fetter Elko im LT selbst Schuld an dem Debakel ist, indem der dafür sorgt dass sich die Spannung am USB nach dem Einstecken nicht schnell genug stabilisiert (weil erstmal der Elko geladen werden muss).

Sieht mir so aus, als würde der "neue" LT auch dann an den 5V nuckeln, wenn er eigentlich eine separate Versorgung hat. USB macht da recht enge Vorgaben, was den erlaubten Stromverbrauch vor der Enumerierung bzw. vor vollständiger Konfiguration angeht. Klingt als würde sich der neue LT da nicht an die Spec halten. Speziell vor der Enumerierung darf man praktisch keinen Strom ziehen.

Naja, zwischen dem was in der USB-Spec steht und was tatsächlich gibt es oft deutliche Unterschiede. Streng nach Spec dürfte auch ca. die Hälfte aller verkauften USB-Festplatten nicht funktionieren

[MasterOfGizmo]

Ich hab den Verdacht, dass genau so ein fetter Elko im LT selbst Schuld an dem Debakel ist, indem der dafür sorgt dass sich die Spannung am USB nach dem Einstecken nicht schnell genug stabilisiert (weil erstmal der Elko geladen werden muss).

Ok, Elko mit Vorwiderstand

Streng nach Spec dürfte auch ca. die Hälfte aller verkauften USB-Festplatten nicht funktionieren

Tun sie ja auch oft genug nicht. Bei den Festplatten zählt immerhin die Ausrede, dass sie einfach nicht drumrum kommen, dass die verbauten Platten jenseits der 500mA ziehen. Aber bei einem RoboLT, der extern versorgt ist, gibt es einfach keinen Grund, Strom vom USB zu ziehen. Das wäre dann eine völlig sinnlose Verletzung der Spec und das wäre recht bitter.

Der behauptet auch dann, self-powered zu sein, wenn er nicht extern versorgt ist? Das ist ja schonmal unschön. Und nein, danke, Deinen LT brauche ich nicht. Selbst wenn da mit ein paar Modifikationen was zu machen wäre ist es ja eher sinnlos, wenn das der Otto-Normal-User nicht nutzen kann. Aber es bleibt ja der WeDo-Hub. Der behauptet immerhin, bus powererd mit 100mA zu sein. 500mW bei dem Motor? Hmmm ... verlogene Welt

[MasterOfGizmo]

Es gibt im Linux-Kernel noch ein paar Möglichkeiten, die Sache zu tunen. Man kann da ein paar Timeouts und Retries erhöhen. Sobald ich einen aktuellen LT habe mache ich das mal.

[MasterOfGizmo]

Code: Alles auswählen

[   44.978293] musb-hdrc musb-hdrc.2.auto: VBUS_ERROR in a_wait_bcon (91, <VBusValid), retry #1, port1 00000104
[   45.062732] musb-hdrc musb-hdrc.2.auto: VBUS_ERROR in a_wait_vrise (91, <VBusValid), retry #2, port1 00000104
[   47.737294] musb-hdrc musb-hdrc.2.auto: VBUS_ERROR in a_wait_vrise (91, <VBusValid), retry #3, port1 00000104
[   50.466552] musb-hdrc musb-hdrc.2.auto: VBUS_ERROR in a_wait_vrise (90, <VBusValid), retry #3, port1 0008010c

Was ich jetzt erst sehe ist, dass das über 5 Sekunden so geht. Wenn sich da irgendwo ein Elko auflädt sollte das ja nach 5 Sekunden langsam mal passiert sein. Interessant wären auch Traces von dem "geht manchmal"-Fall mit dem bus-powered-Hub dazwischen. Wenn das so ein knappes Ding ist, dann sieht man da ja ggf. wie er es doch noch gerade aus den Retries raus schafft.

Edit: Der USB-Spec nach und z.B. laut USB FAQ http://www.usb.org/developers/usbfaq#pow2 sollte ein USB-Gerät auf VBUS max. 10uF Kapazität haben, um in 100ms nach VBUS-on auf mindestens 4.4V zu kommen. Das versucht der Kernel wohl viermal im Abstand von 1.5 Sekunden. Da ist mit mehrfachen Retries dann auch nicht viel zu machen, wenn der Elko zwischendurch wieder vollständig entladen wird. Die 100mS sind wie ich das bisher sehe in der Hardware des MUSB verankert. Dann wiederum ist da im Kernel nicht viel zu retten. Dann könnte ein USB-Kabel mit einem niederohmigen Widerstand in der VBUS-Leitung ggf. was nützen.

Edit^2: Im TXT selbst befindet sich an VBUS schonmal eine 4.7uF-Kapazität ...

[richard.kunze]

Der behauptet auch dann, self-powered zu sein, wenn er nicht extern versorgt ist?

Nee, der behauptet bus-powered zu sein (stimmt soweit) und trotzdem 0mA Strom zu brauchen (und das glaub ich ihm irgendwie nicht )

Interessant wären auch Traces von dem "geht manchmal"-Fall mit dem bus-powered-Hub dazwischen. Wenn das so ein knappes Ding ist, dann sieht man da ja ggf. wie er es doch noch gerade aus den Retries raus schafft.

Erster Versuch, komplett ohne Probleme:

Code: Alles auswählen

[   10.943135] usb 1-1: new high-speed USB device number 2 using musb-hdrc
[   11.070246] usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
[   11.070292] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   11.070311] usb 1-1: Product: USB2.0 Hub
[   11.553078] usb 1-1.1: new high-speed USB device number 3 using musb-hdrc
[   11.643431] usb 1-1.1: New USB device found, idVendor=05e3, idProduct=0608
[   11.643477] usb 1-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   11.643498] usb 1-1.1: Product: USB2.0 Hub
[   11.763087] usb 1-1.4: new full-speed USB device number 4 using musb-hdrc
[   11.856756] usb 1-1.4: New USB device found, idVendor=146a, idProduct=000a
[   11.856801] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   11.856821] usb 1-1.4: Product: fischertechnik Robo LT-Controller (Knobloch GmbH)
[   11.856839] usb 1-1.4: Manufacturer: Knobloch-GmbH
[   11.856856] usb 1-1.4: SerialNumber: 00000001

(der zwischengeschaltete Hub hat 8 Ports und besteht intern aus 2 4-Port-Hubs, deshalb tauchen da zwei Hub-Einträge auf).

2. und 3. Versuch, einmal Timeout (Logs sind bis auf Timestamps identisch):

Code: Alles auswählen

[  127.105582] usb 1-1: USB disconnect, device number 2
[  127.105635] usb 1-1.1: USB disconnect, device number 3
[  127.205290] usb 1-1.4: USB disconnect, device number 4
[  129.582839] musb-hdrc musb-hdrc.2.auto: VBUS_ERROR in a_wait_bcon (91, <VBusValid), retry #1, port1 00000104
[  130.057918] usb 1-1: new high-speed USB device number 5 using musb-hdrc
[  130.184736] usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
[  130.184774] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[  130.184794] usb 1-1: Product: USB2.0 Hub
[  130.502913] usb 1-1.1: new high-speed USB device number 6 using musb-hdrc
[  130.589824] usb 1-1.1: New USB device found, idVendor=05e3, idProduct=0608
[  130.589863] usb 1-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[  130.589882] usb 1-1.1: Product: USB2.0 Hub
[  130.687923] usb 1-1.4: new full-speed USB device number 7 using musb-hdrc
[  130.777464] usb 1-1.4: New USB device found, idVendor=146a, idProduct=000a
[  130.777505] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  130.777525] usb 1-1.4: Product: fischertechnik Robo LT-Controller (Knobloch GmbH)
[  130.777542] usb 1-1.4: Manufacturer: Knobloch-GmbH
[  130.777560] usb 1-1.4: SerialNumber: 00000001

4. Versuch, 2 Timeouts:

Code: Alles auswählen

[  542.116063] usb 1-1: USB disconnect, device number 8
[  542.116114] usb 1-1.1: USB disconnect, device number 9
[  542.161664] usb 1-1.4: USB disconnect, device number 10
[  544.217685] musb-hdrc musb-hdrc.2.auto: VBUS_ERROR in a_wait_bcon (91, <VBusValid), retry #1, port1 00000104
[  544.284890] musb-hdrc musb-hdrc.2.auto: VBUS_ERROR in a_wait_vrise (91, <VBusValid), retry #2, port1 00000104
[  545.358552] usb 1-1: new high-speed USB device number 11 using musb-hdrc
[  545.485395] usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
[  545.485435] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[  545.485454] usb 1-1: Product: USB2.0 Hub
[  545.778503] usb 1-1.1: new high-speed USB device number 12 using musb-hdrc
[  545.865388] usb 1-1.1: New USB device found, idVendor=05e3, idProduct=0608
[  545.865425] usb 1-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[  545.865445] usb 1-1.1: Product: USB2.0 Hub
[  545.968501] usb 1-1.4: new full-speed USB device number 13 using musb-hdrc
[  546.058435] usb 1-1.4: New USB device found, idVendor=146a, idProduct=000a
[  546.058477] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  546.058497] usb 1-1.4: Product: fischertechnik Robo LT-Controller (Knobloch GmbH)
[  546.058515] usb 1-1.4: Manufacturer: Knobloch-GmbH
[  546.058532] usb 1-1.4: SerialNumber: 00000001

[MasterOfGizmo]

Ok, das spricht ja dafuer, dass sich da was tricksen lässt. Ggf begrenzt der Hub durch seinen eigenen Innenwiderstand den Ladestrom etwas. Mit dem entsprechenden LT wuerde ich dann bei Gelegenheit mal den Startverlauf von vbus aufzeichen. Ich nehme stark an, dass man da sieht was passiert.

Dass es generell möglich ist, den LT am TXT ohne Fremdeinspeisung zu betreiben zeigt das ja schonmal.

[MasterOfGizmo]

Update: Ich habe vorhin einen neuen Bus-Powered RoboLT in die Finger bekommen. Zufällig habe ich hier ein recht langes USB-Kabel verwendet. Und damit funktioniert der LT am TXT, sogar komplett Bus-Powered, also versorgt vom TXT. Mit meinen kurzen Kabel geht es nicht und ich habe das von Richard beschriebene Phänomen. Was auch immer der Unterschied zwischen den Kabeln ist, es beweist, dass das Problem irgendwas extrem knappes ist, was schon bei einem geringfügig anderen Kabel nicht mehr fatal ist.

Ein 2-Ohm-Widerstand in die VBUS-Leitung eingeschleift behebt das Problem auch beim kurzen Kabel:


Der Wert ist recht eng. Bei 1 Ohm tritt der Fehler weiterhin manchmal auf, bei 10 Ohm bricht die Versorgungsspannung am RoboLT zu stark ein, wenn man z.B. eine Lampe einschaltet, dass der RoboLT offensichtlich abstürzt. Steckt man zusätzlich den RoboLT mit seinen Versorungsspannungseingängen an die 9V-Aufgänge des TXT (aus denen übrigens nur 8.5V kommen wenn man den TXT mit 9V versorgt), dann liefert der RoboLT an seinen Ausgängen mehr Strom und bricht weniger ein. Mit einer kleinen Induktivität statt des 2-Ohm-Winderstandes geht es ggf. besser, aber ich hatte gerade keine zur Hand.

Fazit: Geht auch mit dem neuen LT, man muss nur so ein Kabel irgendwo her bekommen ...