Bitte um Hilfe für RaspberryPi per Kabel am Notebook

[oberallgeier]

Das CuteCom läuft gut und ich kann über WLAN+RasPi+USB-UART meine Platinen steuern. Läuft bestens. Dumm, dass es das HT (ASCII 09) nicht dekodieren kann. Weiß jemand ob es dazu einen Schalter gibt - ich habe den nicht gefunden.

Beispielhafte Anzeige vom CuteCom in den unteren vier Zeilen. Im Terminal von br@y steht kein \0x09, da wird wirklich ein Tabulator geschaltet. Sieht halt im CuteCom jetzt etwas ungewöhnlich aus - gewöhnungsbedürftig. Und ich würde das gerne ändern.

\0x09Kmd: d,Mnvkk,W,Z0,(Tn)
\0x09KOMM MOST erkannt
\0x09Regeltest sspeed = 30
\0x09IZdiff0/1 = 84/82\0x09KOMM MOST erkannt

Danke im Voraus für die Hilfe.

[oberallgeier]

Für mich unerklärlich ist eine gestörte WLAN-Verbindung zum RasPi bei "gemeinsamer" Stromversorgung.

Aufbau:
Master-Slave-Verbund mit RNControl/M1284-20MHz als Master.
Drei Slaves aktiv, einer davon MotorControl mit RN-VN2_DualMotor/m328/20MHz.
Zwei Motoren - im Test gelegentlich lastlos laufend, dann nur ca. 0,2A/13,2V.
RasPi mit EDIMAX-WLAN-Stick und FTDI-UART - Verbindung zum Master 115,2kBd.

Spannungsversorgung:
Gesamtbedarf des Aufbaus ca. 1A, etwas mehr bei langsam laufenden Motoren.
A) 13,2V-Block, laut Datenblatt "Maximum Continuous Discharge 50A" für >Alles<
B) 13,2V-Block wie vor für alles ausser RasPi, 9,9V-Block max-50A für RasPi
Die Versorgung des RasPI geht über 78S05 hinter einer 2A-Diode. Die Spannung wurde kontrolliert (ohne Oszilloskop), sie ist ruhig und stabil bei ca. 5,05^±0,1 V.
C) Ähnlich wie A) und B) aber teils Netzteile und teils Akkublocks/Netzteile gemischt.

Problem:
Bei getrennter Versorgung des RasPi ist WLAN/remote desktop einwandfrei aktiv, es können UART-Telegramme vom PC über remote desktop vom RasPi an den Master gesendet werden, die werden per TWI z.B. an die MotoControl weitergeleitet. Alles nach Plan, egal ob Motoren laufen oder nicht. GND ist verbunden.
Bei gemeinsamer Versorgung von Raspi und Rest-Aufbau ist der Wlanempfang vorzugsweise gestört, gelegentliches Aufflackern der WLAN-Anzeige am EDIMAX-Stick. WLAN/remote desktop ist sehr selten aktivierbar, stürzt meist gleich ab. GND ist hier erst recht verbunden *ggg*.

Knapp ausgedrückt: bei gemeinsamer Versorgung der Platinen UND des RasPi ist WLAN-Empfang gestört, bei getrennter Versorgung ist alles ok.

Frage:
Was ist als Ursache für den gestörten WLAN-Empfang denkbar? Spannungseinbrüche können es schlecht sein, die Kabel sind für mehrere Ampere gut.

Danke für eure Hilfe.

[Sebas]

Kann es sein dass du die Versorgungsspannung doch irgendwie zum "schwingen" bringst? Hängt sonst was am USB vom Raspberry? Wo speist du die 5v für den Raspberry ein, am MicroUsb oder über die GPIO?
Joa das war erstmal alles was mir einfällt...

[oberallgeier]

Kann es sein dass du die Versorgungsspannung doch irgendwie zum "schwingen" bringst? ...

Genau das fürchte ich, obwohl ich einen völlig gesonderten Spannungsregleraufbau (78S05, Kondensatoren) benutze. Ich werde das prüfen.

... Hängt sonst was am USB vom Raspberry? ...

Es sind beide Anschlüsse belegt: EDIMAX-WLAN-Stick und FTDI-UART für Verbindung zum Master 115,2kBd. Und WENN der RasPi-Hub zwei Anschlüsse hat, so sollten die ja beide nutzbar sein.

... Wo speist du die 5v für den Raspberry ein, am MicroUsb oder über die GPIO? ...

Am MicroUSB.

Derzeit vermute ich, dass ich eben als Simpellösung, ohne weitere Fehlersuche, einen zweiten 9,9V/2,5Ah-Block nur für den RasPi besorge. Wollte eigentlich nur einen für die gesamte Controllerbestückung verwenden. Aber das ist kein Problem. Besser drei Blöcke mit Funktion als zwei mit Störung.

[HeXPloreR]

Vielleicht eine Störung von den Motoren ausgehend. Sind die Motoren ausreichend entstört? Oder vielleicht zu nahm am WLAN-Stick?

Hast Du denn schon den Gesamtverbarauch auch mit dem RasPi gemessen? - der alleine benötigt ja schon ca. 700mA + WLAN. Vielleicht bist Du bei dem 78S05 mit max 2A schon raus.

[oberallgeier]

Danke Sebas, danke HeXPloreR für eure Ratschläge.

Vielleicht eine Störung von den Motoren ausgehend ... entstört? ... zu nah am WLAN ...

Die Motoren sind nicht entstört aber durch ein Metall-U (Motorträger) in Richtung RasPi abgeschirmt. Egal - das WLAN ist gestört d.h. es läuft nicht, auch wenn die Motoren still stehen, d.h. PWM auf 0 und beide Steuerpins gleiches Niveau. WENN die Versorgung des RasPi durch den separaten Block oder das separate Netzteil erfolgt -- jeweils mit rund 9,9V und Netzteil auf 3A limitiert -- dann läuft WLAN auch wenn die Motoren laufen und der RasPi zieht vom Netzteil (Netzteildisplay) rund 0,5 A. Das Netzteil-Amperemeter (bei meinen beiden Netzteilen) hatte ich vor ein paar Wochen mit dem DMM überprüft und für gut befunden.

... Gesamtverbrauch auch mit dem RasPi gemessen? ...

Ja, das sind die oben genannten ca 0,5A - RasPi inclusive FTDI-UART und EDIMAX - bei funktionierendem WLAN. Bei gemeinsamer Versorgung - die drei controllerbestückten Platinen UND das RasPi an einem Energiestrang, d.h. fehlerträchtige Konfiguration - liegt der Verbrauch um die 1A, etwa die Summe der Teilverbräuche bei Netzteilbetrieb an zwei getrennten Netzteilen.

Bin grad auf einem Kongress bis Fr, werde die Motorentstörung aber am Wochenende prüfen - oder besser die Motoren ganz abklemmen. Irgendwie stört mich ein entdeckter Fehler ohne bekannte Ursache.

[oberallgeier]

Da dachte ich zum 6000er (Beitrag) Jubiläum könnte ich ne Antwort auf eine zwar einfache, aber auf den ersten Blick relativ einfache Frage finden. Warum eben der Raspi nicht mit anderen Controllern an einer gemeinsamen Versorgung zusammen arbeiten will, kann, tut. Na ja, er arbeitet, aber WLAN tuts nicht.

Egal ob mit oder ohne angeschlossene Motoren, es geht nicht. Stromaufnahme des Raspi-Zweiges gemessen - die ist sozusagen beliebig hoch - anfangs, wenn WLAN kurz aufflackert, bis knapp ein halbes Ampere. So viel wie eben der normale Verbrauch ist. Aber das Wlan stellt den Betrieb nach kurzen Wechselgefunke mit dem Router wieder ein und damit sinkt auch der Stromverbrauch. Ne separate Versorgung des Raspi bringts dann wieder.

Die Untersuchung auf Masseschleifen brachte auch nichts, eine masselose UART-Verbindung Raspi-Master ergab nur sinnloses Zeugs am Raspi-Terminal, sofern WLAN lief.

Fazit: Separate Versorgung des Raspi wird gestellt. Meine Frage ist nicht beantwortet aber eine technische Lösung ist realisiert. Eher unbefriedigend.