Funke, Raspberry, Handy, LEDs und Servos zusammen schalten

[BernhardB]

Hallo zusammen, ich habe ja schon hier: 

 geschrieben dass ich dabei bin, ne Funke und ein Handy und einen Raspberry zu verbinden. Da das doch etwas aufwändiger ist, habe ich beschlossen, das Ganze in nen Extra-Thread zu stopfen, damit man es leichter finden kann und auch alles bei der Diskussion besser zusammen ist. Was habe ich vor:

• Eine realistische Beleuchtung mittels LEDs, die auch in der Helligkeit schwanken können.
• Diese soll über eine Handy-App parametrisierbar sein (Schwankungslänge des Lichts usw)
• Die Funke (Frsky) soll das Licht zumindest an- und ausschalten können - SBus auslesen erforderlich
• In einem späteren Zeitpunkt möchte ich damit auch die Segel kontrollieren: Welches ist überhaupt gesetzt? Wie stehen sie zueinander? Prinzipiell möchte ich die Möglichkeit schon jetzt in der Programmierung drinnen haben.

Soweit das Wünschdirwas. Motor- und Ruderansteuerung bleiben da außen vor und werden direkt an den Reciever gehängt - ich möchte kein unsteuerbares Schiff haben wenn der Code aussteigt. Apropos Code: Den jeweiligen Code-Stand könnt Ihr bei https://github.com/BernhardBrem/SteeringMaria als OpenSource haben, Ihr werdet aber damit wahrscheinlich nicht glücklich werden, da ich da gerade reinstecke was mir nützt und soweit dokumentiere, dass ich es selber kapiere....

Derzeit funktioniert schon das Ansteuern der Lampen ganz gut. Dazu habe ich auf einen Raspberry Pi Zero mit Standard RasPi OS einen PYthon-Daemon geschrieben, der eine REST-API bietet und ein 16-Kanal-Servoboard ansteuert ( https://www.berrybase.de/16-kanal-servo-driver-uhat-i2c-fuer-raspberry-pi ). Schaut man in die Beschreibung des Boards und seines Drivers wird schnell klar, dass der PWM-Treiberbaustein _eingentlich_ zum Ansteuern von LEDs gedacht ist 😁Also können die LEDs gleich direkt mit einem Widerstand dazwischen an die Ausgangspins gesteckt werden.

Woran ich derzeit noch arbeite ist der Anschluss des Empfängers an den Raspberry: Der erste Empfänger, mit dem ich es getestet habe, war der da: https://www.frsky-rc.com/product/archer-m/  Der hat als winzigen Lötpunkt einen invertierten SPORT Ausgang (nicht zu verwechseln mit SBUS), den man per Einstellung zum invertierten FPORT- Ausgang umschalten kann. FPORT ist der Nachfolger von SPORT und SBUS und kommt mit einer einzigen Leitung aus. Offensichtlich habe ich aber mit dem Lötkolben etwas zu viel auf dieser Winzlings-Platine rumgelötet wodurch sie ihren Geist aufgab. Deswegen werde ich jetzt die Strategie verwenden, nichts mehr an den Empfängern rumzulöten sondern alles mit Steckverbindern hinzukriegen.... ich möchte nicht mehr Hardware schlachten als unbedingt nötig.

Der nächste Schritt  der jetzt kommt wird das Zusammenlöten eines SBUS-Inverters, den ich benötige um das invertierte SBUS-Signal zurück zu in serial zu konvertieren... Ich werde berichten.

 

 

[BernhardB]

Weiter gehts:

Ich habe ja schon berichtet, dass ich den ersten Sender mittels Anlöten eines Drahtes an den invertierten SPort (Achtung: Nicht SBus) geschrottet habe. Hier vielleicht mal ne kurze Begriffsklärung:

• SBus: Invertierter Bus von Frsky und Futaba der die Werte aller Kanäle als invertiertes serielles Signal rausschreibt
• SPort: Eingang von Daten in den Empfänger. Hier werden z.B. die Sensor-Daten der Remote-Sensoren eingespeist. Auch invertiert.
• FPort: Kombination aus SBus ind SPort, das mit nur einem Kabel auskommt. Ebenfalls invertiert. Zwischen SPort und FPort kann man softwareseitig umschalten.
• Invertierter SPort / Fport: Nicht invertiertes Signal, sollte direkt an einen serial-port eines weiteren Geräts anschließbar sein.

Da ich nun mal Grob-Motoriker bin, habe ich es aufgeben an diesen Mini-Empfängern rumzulöten. Dann muss ich halt das SBus-Signal mit einem Inverter zu was für anständige Hardware lesbaren konvertiert werden. Der Schaltplan ist der da:

Die Funktion ist recht einfach: In gesperrtem Zustand des Transistors liegt an dem Kollektor die volle Betriebsspannung an, die dann an den Eingang der seriellen Schnittstelle (RX) geht. Legt man eine Spannung an "S-Bus in" so schaltet der Transistor durch und der Eingang der seriellen Schnittstelle wird nach GND gezogen. Beachten muss ich allerdings, das Ding nicht wie in dem Plan angegeben mit 5V anzusteuern, sondern mit 3,3 Volt, sonst grille ich den UArt des Raspberry. Also im Netz die Komponenten bestellt (Versandkosten natürlich wieder deutlich mehr als Wert der eigentlichen Lieferung - warum muss man eigentlich das, was in nen wattierten Umschlag passen würde, in ner riesen Schachtel verschicken? Nur so nebenbei...) und nen Inverter zusammen gelötet.

 

 

 

 

 

[wilopaan]

Warum einen HW-Inverter? Ich benutze immer die Invertierung der Ports des µC.

Der HW-Inverter müsste für S.Port/F.Port dann auch bidirektional sein, was Deiner nicht ist. 

 

[BernhardB]

Für SBus langt auf jeden Fall eine Richtung. Für FPort, solange man nichts an Signale reinschickt, meiner Meinung nach eigemtlich auch. Ich habe nicht gefunden dass man nen UArt von nem Raspberry PI softwaretechnisch invertieren könnte... Wenn Du da genaueres an Doku hast: Gerne her damit 😁

[wilopaan]

vor 8 Stunden schrieb BernhardB:

Für SBus langt auf jeden Fall eine Richtung. Für FPort, solange man nichts an Signale reinschickt, meiner Meinung nach eigemtlich auch.

Wenn man schon F.Port verwendet, so bin ich natürlich davon ausgegangen, das man das auch bidirektional nutzt. Nur dann kann man das Command-Interface von S.Port/F.Port benutzen.

 

vor 8 Stunden schrieb BernhardB:

UArt von nem Raspberry PI softwaretechnisch invertieren könnte

Da das fast jeder µC heute kann (von STM32 bis AVR-xx) bin ich davon ausgegangen, Das ein R-Pi das auch kann. Aber ich bin hauptsächlich auf STM unterwegs, deswegen kann ich Dir dabei wenig helfen. Aber ein Blick ins DB sollte ja Klarheit bringen.