Hallo an euch Alle....
ich bin ein Anfänger und habe eine Frage (oder mehrere)...
Ich baue ein Ferngesteuertes Gerät, an dem sind viele Sensoren etc dran. Manche sind 3,3 V Andere 5V. Meine Idee war I²c System mit CD74HC4067M (Multiplexer) danach einen MCP2307E SP (ADC) und hinten dran einen TXS0108EPW (Pull up/down). Somit kann ich alles dran hängen was der Markt hergibt. Das ganze noch doppelt und zusätzlich noch 2 PCB9685PM (das hängt mit dem Fahrzeugaufbau zusammen - geht nicht anderst). Die zu steuernden Motoren und Servos lasse ich mal weg - die sind auch nicht das Problem...
Jetzt die Frage....ist I²c richtig ?? oder SPI besser geeignet dafür ??? (Die Fernsteuersignale werden per PPM abgefragt und weitergegeben oder verarbeitet).
Ich bin für alles offen und nehme gerne Vorschläge an ! - bitte nur nicht hauen....
Welches Bussystem ?
Das geht mir etwas zu sehr durcheinander. Du mischst hier analoge mit digitalen Signalen, Busse und Portexpander. Was sich da zu was wie verhält ist daraus nicht ersichtlich. Das könntest du mal etwas systematischer beschreiben, damit man das nachvollziehen kann.
Ganz allgemein ist I2C bei vielen Teilnehmern die bessere Wahl, weil es logisch statt physikalisch addressiert. Es kann trivial mit mosfets Pegel-gewandelt werden. Oder mit geeigneten integrierten Schaltkreisen. Wichtig: die Leitungslänge ist durch die starke Abhängigkeit von der kapazitiven Last beschränkt. Ohne weitere Maßnahmen auf etwa 30cm. Ich habe daher in der Vergangenheit mit P82B715 Treibern gearbeitet. Davon braucht man 2, oder N, wenn man mehrere “Inseln” hat. Ich habe damit problemlos Kabel von mehreren Metern nutzen können. Dabei habe ich auf geschirmte Kabel mit 5 Adern gesetzt (4 hätten es auch getan), um sowohl Spannung als auch I2C zu transportieren.
Ganz allgemein ist I2C bei vielen Teilnehmern die bessere Wahl, weil es logisch statt physikalisch addressiert. Es kann trivial mit mosfets Pegel-gewandelt werden. Oder mit geeigneten integrierten Schaltkreisen. Wichtig: die Leitungslänge ist durch die starke Abhängigkeit von der kapazitiven Last beschränkt. Ohne weitere Maßnahmen auf etwa 30cm. Ich habe daher in der Vergangenheit mit P82B715 Treibern gearbeitet. Davon braucht man 2, oder N, wenn man mehrere “Inseln” hat. Ich habe damit problemlos Kabel von mehreren Metern nutzen können. Dabei habe ich auf geschirmte Kabel mit 5 Adern gesetzt (4 hätten es auch getan), um sowohl Spannung als auch I2C zu transportieren.
ok.... ich fange mal von hinten an...
ich habe einige Sensoren die ich abfragen will, dazu gehören 3x pt 1000 Temeratursensoren (400 Grad) ein pt1000 Drucksensor (16 Bar), 4 MQ Gassensoren, diese laufen alle auf 5V und sind Analog.
Damit ich diese verarbeiten kann muss ich auf 3,3 V (TXS0108EPW). Dann von Analog auf Digital - da ja der Raspi kein Analog kann (z.B. MCP2307E SP).
Und weil ich Bautechnisch nicht mit einem armdicken Kabelbaum durch ein 10mm Loch komme, wird das alles per Bus an den Raspi geleitet.
Die Steuerung des Gerätes geht aus der Fernsteuerung per PPM Signal in den Raspi und dann auch über Bus und die PCB9685PM an die Servos.
ich hoffe jetzt ist es klarer...
Die Sensoren und Servos haben längere Zuleitungen ca. 1m (die Sensordatenverzerrung durch Kabel wird vernachlässigt), Die Chips sitzen unmittelbar nebeneinander (vielleicht mach ich auch ein PCB mit allen drauf). Der Abstand Zwischen PI und der "Insel" sind max. 1m.
ich habe einige Sensoren die ich abfragen will, dazu gehören 3x pt 1000 Temeratursensoren (400 Grad) ein pt1000 Drucksensor (16 Bar), 4 MQ Gassensoren, diese laufen alle auf 5V und sind Analog.
Damit ich diese verarbeiten kann muss ich auf 3,3 V (TXS0108EPW). Dann von Analog auf Digital - da ja der Raspi kein Analog kann (z.B. MCP2307E SP).
Und weil ich Bautechnisch nicht mit einem armdicken Kabelbaum durch ein 10mm Loch komme, wird das alles per Bus an den Raspi geleitet.
Die Steuerung des Gerätes geht aus der Fernsteuerung per PPM Signal in den Raspi und dann auch über Bus und die PCB9685PM an die Servos.
ich hoffe jetzt ist es klarer...
Die Sensoren und Servos haben längere Zuleitungen ca. 1m (die Sensordatenverzerrung durch Kabel wird vernachlässigt), Die Chips sitzen unmittelbar nebeneinander (vielleicht mach ich auch ein PCB mit allen drauf). Der Abstand Zwischen PI und der "Insel" sind max. 1m.
Die analogen Sensoren solltest du nicht Pegelwandeln. Das ist ein nicht-linearer Vorgang, womit die resultierenden Werte für die Katz sind, weil verzerrt. Stattdessen müssen die dann eben in 5V per ADC abgetastet werden. Wenn du da I2C-Varianten wählst, kannst du dann zb gleich mit dem Treiber-Chip den ich genannt habe zwei Fliegen mit einer Klappe schlagen: Erhöhung der Reichweite & Pegelwandlung. Weil ein Teil in 5V, die Strecke auch in 5V, und dann hinter dem Pi-Seitigen Ende due benötigten 3V3.
Das PPM Signal mit dem PI Erfassen zu wollen, kannst du dir abschminken. Sowohl die zeitliche Auflösung als auch Latenz und Jitter durch das OS machen dir da einen Strich durch die Rechnung. Bestenfalls kannst du da SBUS nehmen. Das musst du invertieren, und dann in den UART füttern, das sollte robust funktionieren. Aber Latenz und Jitter bleiben obendrauf, und einen PI würde ich ohne Not nicht in meine Steuerkette einschleusen. Man kann mit PREEMPT_RT arbeiten, und dann auf wenige ms Latenz und höhere jitterfestigkeit kommen. Aber das ist fortgeschritten, und Python hat da nichts verloren. Ich würde sowas mit einem microcontroller machen.
Außer, es ist ziemlich egal, wenn die Verarbeitung zu lange dauert. Die PPM Wandlung (wenn SBUS keine Option ist) musst du aber immer noch mit einem uC machen.
Das PPM Signal mit dem PI Erfassen zu wollen, kannst du dir abschminken. Sowohl die zeitliche Auflösung als auch Latenz und Jitter durch das OS machen dir da einen Strich durch die Rechnung. Bestenfalls kannst du da SBUS nehmen. Das musst du invertieren, und dann in den UART füttern, das sollte robust funktionieren. Aber Latenz und Jitter bleiben obendrauf, und einen PI würde ich ohne Not nicht in meine Steuerkette einschleusen. Man kann mit PREEMPT_RT arbeiten, und dann auf wenige ms Latenz und höhere jitterfestigkeit kommen. Aber das ist fortgeschritten, und Python hat da nichts verloren. Ich würde sowas mit einem microcontroller machen.
Außer, es ist ziemlich egal, wenn die Verarbeitung zu lange dauert. Die PPM Wandlung (wenn SBUS keine Option ist) musst du aber immer noch mit einem uC machen.
Hab die Kanne leer....
Also wäre eine gute Lösung das Sensorgeraffel und die Steuerung über einen Arduino zu machen, und die Daten die ich brauche dann mit I²c zum Raspi ?
somit könnte ich auch die analogen Daten im Arduino auch gleich in Digital umwandeln.
Korrigiere mich bitte wenn ich falsch liege !
Den Raspi wollte ich eigentlich nur wegen der schöneren Grafik im OSD.....Arduinos OSD sieht aus wie ein alter Gameboy...geht gar nicht !!!
Also wäre eine gute Lösung das Sensorgeraffel und die Steuerung über einen Arduino zu machen, und die Daten die ich brauche dann mit I²c zum Raspi ?
somit könnte ich auch die analogen Daten im Arduino auch gleich in Digital umwandeln.
Korrigiere mich bitte wenn ich falsch liege !
Den Raspi wollte ich eigentlich nur wegen der schöneren Grafik im OSD.....Arduinos OSD sieht aus wie ein alter Gameboy...geht gar nicht !!!
I2C wäre eine Möglichkeit. Ich würde bei Verfügbarkeit eher UART nutzen, weil es einfacher zu nutzen ist und von beiden Seiten aus ereignisbasiert initiiert werden kann.
Und wenn es nur um Darstellung geht, ist ggf ein Nextion Display eine Alternative.
Und wenn es nur um Darstellung geht, ist ggf ein Nextion Display eine Alternative.
Das mit dem Display ist nicht so einfach....das Video und OSD signal geht in den Empfänder der das Signal zur Fernsteuerung zurück auch verschlüsselt....einfach rüber zu irgendeinem Display wäre ja auch zu einfach...und die Fernsteuerung hat ein 4k fähiges Touch Sreen Display in 7 " da hat Game Boy Grafik nix verloren...
OK also ein Raspi mit uart an Arduino (keutze nicht die Strahlen....Ghostbusters...lang ists her...) und der macht die Sensoren und wandelt in digital...
so richtig Herr Lehrer ???
...ich Danke dir ohh Meister der Chips....augenzwinker...kommt dein deets von Kopf ???
OK also ein Raspi mit uart an Arduino (keutze nicht die Strahlen....Ghostbusters...lang ists her...) und der macht die Sensoren und wandelt in digital...
so richtig Herr Lehrer ???
...ich Danke dir ohh Meister der Chips....augenzwinker...kommt dein deets von Kopf ???
Wie bekommst du denn das Video in den PI? Und dann das OSD? Ist die damit einhergehende Latenz nicht ein Problem? Bei meinen Koptern interessiert mich der Gameboy weniger, aber die Latenz sehr. Und 4K - wie bekommst du das denn über den Äther?
Das mit der Bitrate verstehe ich nicht.
Das mit der Bitrate verstehe ich nicht.
PI Cam und das OSD vom PI drüber mit den Sensordaten vom Arduino und dann raus in den Empfäner per h.264 oder h.265
Das 4 K ist schon in der Fernsteuerung drin....wie die das machen is mir Wurst...guckst du hier ...https://www.beasttx.com/
Bitrate: je schneller die Taktrate der Chips je schneller kann ich doch Daten senden oder bin ich aufm Holzweg ?
Das 4 K ist schon in der Fernsteuerung drin....wie die das machen is mir Wurst...guckst du hier ...https://www.beasttx.com/
Bitrate: je schneller die Taktrate der Chips je schneller kann ich doch Daten senden oder bin ich aufm Holzweg ?
So simpel ist die Rechnung nicht. Vor allem aber fallen bei dir ein paar hundert Byte pro Sekunde an. Wenn es hochkommt. Da reichen die üblichen Geschwindigkeiten von 115200 aus. Dicke. Ob der DUE noch andere Vorteile hat, kann ich nicht beurteilen.
Wenn die h264 verschicken ist natürlich mit dem PI machbar. Allerdings sollte das System doch eigentlich direkt die Sensordaten selbst auf das Display bringen können. Die paar Bytes als Telemetriekanal nebenbei sind doch ein Klacks. Und schon eine stromhungrige Komponente mit hoher Unzuverlässigkeit (bekannt auch als Pi) weniger.
Wenn die h264 verschicken ist natürlich mit dem PI machbar. Allerdings sollte das System doch eigentlich direkt die Sensordaten selbst auf das Display bringen können. Die paar Bytes als Telemetriekanal nebenbei sind doch ein Klacks. Und schon eine stromhungrige Komponente mit hoher Unzuverlässigkeit (bekannt auch als Pi) weniger.
ist der Pi son murks ??? (unzuverlässig)
Wenn ich den Takt nicht brauche nehme ich logischerweise einen kleineren ...
Der Due hat 4 serielle einen can und einen i²c und einen SPI und 53 GPIO (brauch ich ja gar nicht....) mit 84 Mhz
Wenn ich den Takt nicht brauche nehme ich logischerweise einen kleineren ...
Der Due hat 4 serielle einen can und einen i²c und einen SPI und 53 GPIO (brauch ich ja gar nicht....) mit 84 Mhz
Der Pi braucht viel Strom, hat eine SD-Karte die gerne ausfällt, ein dickes Os, das langsam bootet, und ist elektrisch deutlich empfindlicher als ein viel robusterer Arduino. Wenn es nur darum geht, ein paar Sensordaten auf den Transmitter zu kriegen, der mit dicker CPU problemlos overlays darstellen kann, dann würde ich das eben per Telemetrie-Kanal machen. Und H264 ist toll - für “natürliche” Bilder, also Videos von Landschaften. Scharf umrissene UI Elemente mit kleinteiligem Zeug sind da nicht so gut, oder erhöhen die Bitrate signifikant.
-
__blackjack__
- User
- Beiträge: 13572
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@Jens B: Der Pi ist kein Murks sondern vor allem erst einmal ein normaler Rechner mit einem normalen Mehrbenutzerbetriebssystem. Mit all den Problemen die mit der Komplexität von so einem System einhergehen. Zum Beispiel das sehr viel mehr schief gehen kann als auf einem Microkontroller wo im Grund nur Dein Programm ganz alleine läuft und die volle Kontrolle hat. Bei einem normalen Betriebssystem hast Du beispielsweise keine Garantien, dass nicht ein anderer Prozess Rechenzeit oder Speicher beansprucht. Das kann für zeitkritische Aufgaben problematisch sein.
„Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.“ — Brian W. Kernighan