Hallo zusammen, ich hoffe, das ich hier mit meinem Problm richtig bin. Ich bekomme von einem Sensor Daten über eine Leitung im Halbduplexmodus. Nun möchte ich die Daten auf dem Arduion verarbeiten und dann auch wieder im Halbduplexmodus weiterreichen an ein anderes Gerät. Ich hab irgendwo gelesen, das ich das mit je einem digitalen Eingangspin des Arduino machen kann, ohne den UART zu benutzen. Als Neuling hab ich da so nicht den richtigen Durchblick. Kann mir da jemand in den Sattel helfen? Programmierung in anderen Umgebungen am PC mach ich schon ne Weile, so das ich 'nur' bischen Hilfe beim Anschluss und einen Einstieg in die Programmierung brauche. Danke......
:
Bearbeitet durch User
Da fehlen einige Informationen. Ist das eine serielle Verbindung? []Musst du denn auch Daten zum Sensor schicken? []Musst du auch vom Empfänger der Daten Daten empfangen? Wenn die Antwort auf die beiden letzten Fragen Nein und auf die erste ein Ja ist, kannst du den RXD Pin des Arduino an den Sensor knüppern und am TXD Pin die Daten zum Empfänger weiterreichen, wobei du evtl. zwischendurch die Baudraten umschalten musst. Wenn zumindest eine der beiden Fragen mit ja beantwortet werden muss, solltest du eine 'Software' UART (Suchbegriff) implementieren, da du ja 2 vollständige serielle Schnittstellen brauchst. Software UARTs sollte es bei den Arduino Jungs geben. Wenn du uns mehr von der Problemstellung (Baudraten, Hardware, Protokolle) verrätst, trudeln auch bessere Antworten ein.
:
Bearbeitet durch User
Im Betreff steht schon serielle Daten...... Das steht also schon mal :) Grundgedanke ist, das ich vom Sensor Daten bekomme (halbduplex mit einer Leitung), die auswerte und über einen anderen Port seriell (auch halbduplex mit einer Leitung) an ein anderes Gerät weiter schicke. Eine Kommunikation in die andere Richtung ist erst mal nicht vorgesehen. Die nächste 'Ausbaustufe' wäre der Empfang von mehreren Sensoren auf mehreren Pins. Die Weitergabe der ausgewertenen Daten erfolgt aber trotzdem immer nur auf einer Leitung. Protokoll, bzw. Datenstrom ist herstellerspezifisch, die Bytefolge ist mir aber bekannt. Die muss ich halt aufdröseln und auswerten. Da denke ich, werd ich kein Problem mit haben. Baudraten der Sensoren und des 'Empfängers' sind unterschiedlich, aber auch bekannt. Software UART hab ich schon was drüber gelesen, aber die Beispiele hab ich immer nur im Vollduplex gefunden.
:
Bearbeitet durch User
Hans S. schrieb: > Grundgedanke ist, das ich vom Sensor Daten bekomme Der Sensor sendet also selbsttätig ständig Daten? Das nennt man nicht "halbduplex". Halbduplex wäre, wenn Du auch mit dem Sensor kommunizieren müsstest, und dazu zwischen Sende- und Empfangsbetrieb hin- und herschalten würdest.
Ja, der Sensor sendet selbstständig Daten auf einer Datenleitung, deshalb Halbduplex. Ich muss also nix anfordern, etc. Bei Halbduplex können Daten abwechselnd, aber nicht gleichzeitig, in beide Richtungen fließen ( 1 Leitung ). Bei Vollduplex können Daten in beide Richtungen gleichzeitig übertragen werden ( 2 Leitungen ). So hab ich es gelernt.... Das ich hier Daten immer nur in eine Richtung verschiebe, bzw. erhalte, hat ja nix mit der eigentlichen Übertragungstechnik zu tun, ich könnte ja rein theoretisch auf beiden Leitungen also zum Sensor und zum Empfänger senden und empfangen. Aber halt nur abwechselnd. Aber Egal, Problemstellung sollte ja nun bekannt sein. Es kommen ständig Daten auf einer Datenleitung pro Sensor seriell rein und sollen genau so wieder raus.
:
Bearbeitet durch User
Hans S. schrieb: > ich könnte > ja rein theoretisch auf beiden Leitungen also zum Sensor und zum > Empfänger senden und empfangen. Aber halt nur abwechselnd. Die Frage ist doch (und die habe ich auch in der ersten Antwort gestellt), ob du auch Daten zum Sensor senden musst - meinetwegen Halbduplex. Wenn nein, reicht dazu also der RXD Pin deines Italieners. Der TXD Pin ist immer noch frei, um Daten an deinen anderen Empfänger weiterzureichen. Halbduplex impliziert nämlich, das du auch zum Sensor Daten senden willst, eben in den Pausen, wo der Sensor nichts schickt - deswegen das 'Duplex' im Begriff. Hans S. schrieb: > Software UART hab ich schon was drüber gelesen, aber die Beispiele hab > ich immer nur im Vollduplex gefunden. Na und? Dann sendest du über diese Software UART eben nichts und fertig ist dein 'Halbduplex' Empfänger. Umgekehrt kannst du eine Software UART lediglich zum Senden nehmen.
Gibts bei Arduino Software-UART? Wäre doch eine Möglichkeit, wenn du ziemlich viele serielle Verbindungen benötigst und diese nie gleichzeitig kommunizieren (wobei ich mich frage, woher die Sensoren wissen, wann sie senden dürfen) Wenn es möglich ist, kannst auch den Arduino für ein anderes Projekt zur Seite legen, dir einen FPGA oder entsprechend großen CPLD nehmen und in diesem so viele UART-Schnittstellen implementieren, wie du kannst/willst/brauchst.
Danke für eure Infos bisher. Das Protokoll, bzw. die Bytefolgen eines Herstellers hab ich vorliegen, das ist offen. Von anderen Sensoren, deren Daten auch verarbeitet werden sollen, liegt das Protokoll nicht offen, so das ich Testen oder auf Erfahrungen / Tests anderer zurück greifen muss. Nach den letzten Erkenntnissen sieht es so aus, das die Daten vom Sensor doch abgerufen werden müssen, also auf der Leitung muss gesendet und empfangen werden. Genaus so sieht es mit dem Empfänger aus, der fordert Daten an. Also auch dort 2 Wege Kommunikation. Wird wohl alles doch aufwendiger als gedacht. Frage zum Anschluss: Vom Datenempfänger bekomme ich 3 Leitungen, Daten/Plus/Minus. Er liefert mir den Betriebsstrom für den Arduino und die Sensoren. Ich habe 3 Leitungen von jedem Sensor, Daten/Plus/Minus. Ich habe ja am dann Arduino und am Sensor das gleiche Massepotenzial. Wenn ich nun die Datenleitung von einem Sensor beim Arduino Uno z.B. auf Pin 5 lege, sollte es doch schon mal funktionieren wenn ich nen Software UART dort erzeuge, oder hab ich nen Denkfehler? Klar das der Empfänger und andere Sensoren auf nen anderen Pin kommen.
Hans S. schrieb: > Wenn ich nun die Datenleitung von einem Sensor beim Arduino Uno z.B. auf > Pin 5 lege, sollte es doch schon mal funktionieren wenn ich nen Software > UART dort erzeuge, oder hab ich nen Denkfehler? > Klar das der Empfänger und andere Sensoren auf nen anderen Pin kommen. Wenn du den DigitalPin 5 meinst, wäre das PortC6... das sollte eigentlich problemlos funktionieren, allerdings ist dort kein UART-Modul angeschlossen! Das heißt du bräuchtest Software-UART. Von wie vielen Sensoren ist denn eigentlich die Rede? Welche Baudrate wird verwendet? Wie groß ist ungefähr der Datenstrom? In welchem Zeitintervall werden die Sensoren ungefähr abgefragt? Bei mehreren Software-UART sollte man sich im Klaren sein, dass das Abfrageintervall pro Sensor begrenzt ist. [EDIT] Die Sensoren sind aber nicht über das Protokoll adressierbar oder? Wenn doch, mach dir doch das Leben nicht schwerer, als es ist und verwende RS-485! Quasi: +-> RS-485-Transceiver <-> Sensor1 | Arduino <-> RS-485-Transceiver <-+-> RS-485-Transceiver <-> Sensor2 | +-> RS-485-Transceiver <-> Sensor3 | +-> RS-485-Transceiver <-> Sensor4 RS-485-Transceiver gibts als Halb- und Vollduplexvarianten und würde in deinem Fall viele Probleme lösen.
:
Bearbeitet durch User
Ich denke es werden bis zu 4 - 5 Sensoren maximal. Je nach Sensorhersteller gibts unterschiedliche Baudraten, die derzeit bekannte maximale Länge des Datenstroms sind 39Byte, der Empfänger pollt alle 20ms Daten vom Arduino. Es ist aber nicht erforderlich jedes Mal aktuelle Daten vom Sensor anzufordern, so zeitkritisch sind die Daten nicht.Da würde eine Aktualisierung alle 250 - 500ms reichen. Die Sensoren sind von unterschiedlichen Herstellern und haben unterschiedliche Protokolle und Baudraten. Daher muss ich mir anfangs ne Routine schreiben, die feststellt, an welchem Pin welcher Sensor hängt, denn die sollen austauschbar sein. Danke für den Tipp mit dem RS-485-Transceiver, aber damit kann ich nix anfangen. Ich bin kein Elektroniker, sondern komm aus der PC Softwareschiene. Der sagt mir gar nix.
Hans S. schrieb: > Die Sensoren sind von unterschiedlichen Herstellern und haben > unterschiedliche Protokolle und Baudraten. Daher muss ich mir anfangs ne > Routine schreiben, die feststellt, an welchem Pin welcher Sensor hängt, > denn die sollen austauschbar sein. Wie soll denn der Arduino erkennen, ob ein Sensor angeschlossen/gewechselt wurde? Etwa wenn auf eine Anfrage keine Antwort kommt? Das würde ja bedeuten, dass du bei jedem Timeout nach einer Anfrage testen müsstest, ob mit verschiedenen Baudraten und/oder verschiedenen Protokollen nicht doch eine Antwort kommt. Wenn man da ein großzügiges Timeout spendiert, kommen schon einige Millisekunden bis Sekunden zusammen, oder? Und wenn an Anschluss 3 zum Beispiel nie ein Sensor angeschlossen wird, testest du so bei jedem Durchlauf alle möglichen Varianten, er kann sich ja nicht merken, dass dort kein Sensor ist. Muss es wirklich so aussehen?
:
Bearbeitet durch User
Ein Sensor wird nur in ausgeschaltetem Zustand gewechselt. Die Feststellung ob und welcher Sensor angeschlossen ist wird nur beim Initialisieren des Arduino durchgeführt. Danach sollte feststehen ob und welcher Sensor angeschlossen ist. Das kann ich mnr ja in Variablen merken und in den Routinen verwerten. Ein Timeout wäre daher kein Problem. In der nächsten Schleife würde dann wieder der Sensor abgefragt.
Hans S. schrieb: > Die Sensoren sind von unterschiedlichen Herstellern und haben > unterschiedliche Protokolle und Baudraten. Daher muss ich mir anfangs ne > Routine schreiben, die feststellt, an welchem Pin welcher Sensor hängt, > denn die sollen austauschbar sein. müssen tust du gar nicht. Also ich würde mal damit anfangen, n serielle Schnittstellen in Betrieb zu nehmen, da (bekannte) Sensoren anschliessen und dann die Protokolle eines nach dem anderen implementieren. Zwischendurch immer wieder: testen, testen, testen. Als nächstes würde ich die Schnittstelle zum Host in Betrieb nehmen. Dann würde ich mir auf das LCD, das von Anfang an am Arduino drann war ein Menüsystem zaubern, mit dem ich jeden Anschluss konfigurieren kann. Welcher Sensor hängt drann und wenn es nicht eindeutig ist: bei welcher Baudrate hängt der da drann. eine automatische Erkennung ist so ziemlich das unwichtigste. Daher kommt das, wenn überhaupt, ganz zum Schluss. Da jede Automatik ihre Schwächen hat, muss es sowieso eine Möglichkeit geben, wie ich die Automatik umgehen kann. Womit dann wieder das Menüsystem ins Spiel kommt. Ihr seid alle viel zu Plug&Play verwöhnt. Nur gibt es da einen kleinen Unterschied: Plug&Play bzw. USB wurde von vorneherein so designed, dass diese automtischen Dinge möglich sind. Bei Sensoren ist das aber nicht so. Wer die Anfänge von Plug&Play noch miterlebt hat, weiß warum man das damals "Plug and Pray" (Einstecken und Beten) nannte.
:
Bearbeitet durch User
Danke für deine Ausführungen, Karl Heinz. Aber ich bin nicht Plug & Play verwöhnt und die Anfangszeiten davon hab ich auch mitgemacht. Das Problem hier ist, das ich ein Minimum an Platz und Gewicht zur Verfügung habe ( Modellbau ). Also erübrigt sich fürs 'Endprodukt' ein LC Display. Karl Heinz schrieb: > Also ich würde mal damit anfangen, n serielle Schnittstellen in Betrieb > zu nehmen, da (bekannte) Sensoren anschliessen und dann die Protokolle > eines nach dem anderen implementieren. Zwischendurch immer wieder: > testen, testen, testen. Natürlich ist das ein Projekt, das wächst. Mit einem Sensor anfangen und dann Stück für Stück erweitern. So handhabe ich das bei der 'normalen Programmierung' auch. Jedes Problem Stück für Stück angehen, fertigstellen, ausgiebig testen und 'vergessen'.
> Ich bekomme von einem Sensor Daten über eine Leitung im Halbduplexmodus. > Modellbau Was soll das denn werden? Erst dachte ich an einen Multiprotokollsensor, aber du schreibst ja dass du Daten von Sensoren bekommst. Also willst du ein eigenes Telemetriesystem bauen welches mit allen gängigen Sensoren arbeitet?
Ja, Sensoren von verschiedenen Herstellern an einem Arduino verwenden und in ein Telemetrieprotokoll ( mal sehn welches ) übersetzen. Wichtig ist erst mal das Einlesen der Daten hin zu bekommen.
:
Bearbeitet durch User
Hans S. schrieb: > Ja, der Sensor sendet selbstständig Daten auf einer Datenleitung, > deshalb Halbduplex. Das nennt man Simplex. Duplex ist nur wenns in beide Richtungen geht.
Ich würde die verschiedenen Sensoren z.B. mit Arduino Nanos "kapseln" (kostet als Nachbau ca. 5 Euro). So verschwinden die Protokollunterschiede und man kann die Daten der Protokollwandler an einer Art intellgentem Hub mit einem einheitlichen sekundären Protokoll zusammenführen. Die Implementierung von Testroutinen oder die automatische Erkennung des Sensortyps vereinfacht sich so drastisch. Statt RS232 oder USB würde ich auch mal über Netzwerk nachdenken - mit Arduino keine große Sache ...
Frank schrieb: > Ich würde die verschiedenen Sensoren z.B. mit Arduino Nanos "kapseln" > (kostet als Nachbau ca. 5 Euro). oder micro noch billiger 2€
Ich möchte vorhandene Sensoren verwenden, wir reden von Messsensoren für Drehzahl, Strom ( 150A ) , Spannung, LiPo Einzelzellenüberwachung, Höhe.... Netzwerk ist nicht möglich da die Daten vom vorhandenen Empfänger über den Rückkanal der Funkstrecke übertragen und am Sender ausgewertet und gespeichert werden.
Bernd K. schrieb: > Hans S. schrieb: >> Ja, der Sensor sendet selbstständig Daten auf einer Datenleitung, >> deshalb Halbduplex. > > Das nennt man Simplex. Duplex ist nur wenns in beide Richtungen geht. Aber das klappt bei Modellbausensoren nicht. Die meisten Systeme sind Bidirektionale Slaves und antworten nur auf Anfragen eines Masters. Somit ist es natürlich auch nicht richtig dass die Sensoren einfach mal Daten senden.
:
Bearbeitet durch User
cyblord ---- schrieb: > Aber das klappt bei Modellbausensoren nicht. Die meisten Systeme sind > Bidirektionale Slaves und antworten nur auf Anfragen eines Masters. > Somit ist es natürlich auch nicht richtig dass die Sensoren einfach mal > Daten senden. Ausschnitt aus der Dokumentation: ..... Topology The bus has a topology called “point to point”. Every sensor is marked as a “master” because it always initiates communication. A device connected to the sensor is marked as a “slave”. If several sensors are connected, it is mandatory to use a multiplexer (Expander), that processes all inputs and transforms them into one single output. ..... Accessing shared data bus The only one active element of a network at a time, and which initiates all communications, is a “master”. It sends a packet and then releases the bus for at least 20ms. At this time, “slave” is allowed to respond. This situation repeats periodically. “Slave” doesn't have to respond immediately and it doesn't have to respond at all. .....
Von welchem System ist denn diese Doku nu? Nenn doch mal Roß und Reiter. Das klingt alles eher nicht nach einem Modellbautelemetriesystem. Mit Expandern und die Sensoren als Master. Irgendwie wirr.
:
Bearbeitet durch User
Das ist die Dokumentation von Jeti, die man auf deren Seite als PDF Dokument runterladen kann.
Hans S. schrieb: > Das ist die Dokumentation von Jeti, die man auf deren Seite als PDF > Dokument runterladen kann. Dann würde ich damit mal anfangen und die anderen Systeme mal aussen vor lassen. Wie gesagt, bei anderen Systemen läuft das ganz anders. M-Link ist ne ganz andere Topologie. Hott wohl auch. Außerdem ist JETI doch sehr verbreitet, da sollte es viele Sensoren und auch günstige Nachbauten geben. Was aber IMO alle gemeinsam haben ist eine bidirektionale halbduplex Verbindung auf einer einzigen Signalleitung.
:
Bearbeitet durch User
cyblord ---- schrieb: > Was aber IMO alle gemeinsam haben ist eine bidirektionale halbduplex > Verbindung auf einer einzigen Signalleitung. Das stimmt, denn es stehen nur 3adrige Leitungen zur Verfügung, Plus, Minus, Signal. cyblord ---- schrieb: > Außerdem ist JETI doch sehr verbreitet, da sollte es viele Sensoren und > auch günstige Nachbauten geben. Günstige Nachbauten gibts da ( leider ) nicht, weder Empfänger, noch Sensoren. Jeti wäre in meinem Falle aber erst mal der Empfänger der Daten. Günstige Sensoren gibts z.B. von FrSky. Da würde ich mich dann erst mal ans Einlesen geben. Wenn ich dann was an 'Futter' habe, würde ich versuchen, das an Jeti auszugeben. Am einfachsten Wäre wahrscheinlich ein LiPo Sensor für nen 6 Zeller, dann hab ich diekt mehrere Werte, die baknnt sind. Ich kann ja parallel nen Lipo Checker dranhängen. Mal recherchieren, ob einer schon mal das FrSky Protokoll 'geknackt' hat. Ne offizielle Doku, wie bei Jeti gibts wohl nicht.
@Hans, bist du sicher dass die kein "1-Wire" Sensoren sind? 1-Wire Wiki: "Die Verbindung arbeitet seriell und bidirektional, d. h. mit einer Datenleitung für Senden und Empfangen." EDIT: OK, also Jeti. Es gibt was für Arduino: http://forum.arduino.cc/index.php/topic,20569.0.html
:
Bearbeitet durch User
Hans S. schrieb: > Ausschnitt aus der Dokumentation: > ..... > Topology > The bus has a topology called “point to point”. Every sensor is marked > as a “master” because it always initiates > communication. A device connected to the sensor is marked as a “slave”. Soweit erstmal eindeutig Simplex. Es wird keine bidirektionale Kommunikation zwischen den vielen Masters und dem einen Hub-Slave benötigt, sondern der Slave muß nur reihum (oder parallel) die Ausgaben der Master belauschen. > Accessing shared data bus > The only one active element of a network at a time, and which initiates > all communications, is a “master”. It sends > a packet and then releases the bus for at least 20ms. At this time, > “slave” is allowed to respond. > This situation > repeats periodically. “Slave” doesn't have to respond immediately and it > doesn't have to respond at all. Also doch nicht ganz Simplex. Optional ist auch Halbduplex möglich. Diese Option ist aber in der konkreten Anwendung weder nötig noch wird sie in irgendeiner Form genutzt. Also doch ganz eindeutig: Simplex.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.