Projekt Zeiterfassung mit Funkübertragung

International Deutsch
1

Hallo zusammen,

ich habe hier ein kleines Projekt bei dem ein Arduino Node am Startpunkt und einer am Ziel mittels Lichtschranken Zeiten ermitteln und zu einem "Server-Node" übertragen sollen.
Dort soll die benötigte Zeit angezeigt werden.

Die Entfernungen zwischen Start und Server bzw. Ziel und Server sind jeweils etwa 150Meter.
Daher hab ich mich für eine Funkübertragung entschieden.
Ich verwende RF24 Module und die RF24Network Libraries

Zur Anzeige wird ein 20x4 Display verwenden.

Der Aufbau selbst ist fertig und funktioniert anständig. Ich habe allerdings ein Verständnisproblem was die Zeiten angeht.

Ich beschreibe kurz den Ablauf was bisher passiert:
Start und ZielNode haben je eine eigene ID bekommen und senden rythmisch alle 2 Sekunden eine Null an den Server. Somit weiß dieser, dass seine Clients noch da sind. Jeder versandt wird quittiert (das macht die Library selbst)
Um den Stromverbrauch brauche ich mir hier keine Gedanken machen, darauf kommt es nicht an.

Wird die Lichtschranke ausgelöst, sende der entsprechende Node seine Zeit (Millis) des Aulösezeitpunktes an den Server. Diese Zeit wird für den Client inkl der Serverzeit(Zeitpunkt des Empfangs) abgespeichert.
Hat der Server von einem Node eine Zeit empfangen, nimmt er keine weitere mehr an, bis das System zurückgesetzt wird.

Insgesamt scheint das so auch zu funktionieren, dachte ich. Nur ist mir erst später aufgefallen, dass wenn die Clients alle zwei Sekunden nur senden, im Ernstfall ein Versatz von bis zu 2 Sekunden auftreten können, was natürlich für Vergleiche unterschiedlicher Läufe schlecht wäre.

Hat jemand eine Idee, wie ich das prinzipiell korrekt umsetzen kann?
Ich brauche irgendwie eine Art synchronisation der einzelnen Nodes, vermute ich.

Über Vorschläge wäre ich sehr dankbar, da ich derzeit scheinbar ziemlich verbohrt auf der Stelle trete

2

derSchorsch:
Insgesamt scheint das so auch zu funktionieren, dachte ich. Nur ist mir erst später aufgefallen, dass wenn die Clients alle zwei Sekunden nur senden, im Ernstfall ein Versatz von bis zu 2 Sekunden auftreten können, was natürlich für Vergleiche unterschiedlicher Läufe schlecht wäre.

Diesen Abschnitt verstehe ich nicht. Wenn die Arduinos ihre jeweilige „millis()“ schicken und das ohne Verzögerung gespeichert wird, ist doch alles in Butter?!

Wenn ich Dich richtig verstehe, müsste doch genügen, wenn die Arduinos an Start und Ziel ihr „Anschlagen“ durch irgendein „Ping“ melden und das Ding dazwischen nachsieht, mit welchem Versatz die Meldungen kamen. Wie ich es verstehe, ist es keine Taktung, die Dir fehlt.

Aber was heißt schon „verstehen“ ... an einem Mittwoch ...

Gruß

Gregor

3

Da die beiden (Client und Server) keine einheitliche Zeit (Toleranz der Keramikresonatoren) haben, solltest du die Zeit nur an dem Server messen.

Das heißt, sobald der Startimpuls des Client kommt, anfangen zu zählen (nur auf dem Server) und wenn die Lichtschranke des Servers erreicht wird stoppen und rechnen.

4

Hallo,
danke für deinen Denkanstoß.

das würde heißen, setze ich zum Zeitpunkt des Auslösens einer der Lichtschranken, per sofort einen "Ping" ab, dann wäre das Problem schon gelöst?
Bisher sendet er stur alle 2 Sekunden, er merkt sich die Millis vom Zeitpunkt der Auslösung und sendet diese dann beim nächsten geplanten Versandzeitpunkt.
Der Server speichert den empfangenen Wert, sofern dieser nicht 0 ist, zusammen mit seiner Zeit ab.

Aus den daraus resultierenden Serverzeiten ermittle ich die Laufzeit.

Mein Problem aktuell ist:
StartNode sendet zum Zeitpunkt X seine 0
um X + 200ms löst die Lichtschranke aus, es wird lokal X+200 (entspricht aktuelle millis()) gespeichert
um X + 2000 wird der nächste Versand durchgeführt, es wird statt der 0 nun x+200 gesendet

Der Server merkt nun der empfangene Wert ist nicht 0 und speichert den Wert zusammen mit seinen Millis, nennen wir das mal S_Start

Ähnliches passiert am Ziel node
ZielNode sendet zum Zeitpunkt Y seine 0
um Y + 500ms löst die Lichtschranke aus, es wird lokal Y+500 (entspricht aktuelle millis()) gespeichert
um Y + 2000 wird der nächste Versand durchgeführt, es wird statt der 0 nun Y+500 gesendet

Der Server merkt sich nun auch diese Zeit in zum Beispiel S_Ziel
Rechne ich nun stumpf S_Ziel - S_Start bekomme ich zwar eine Zeit in Millisekunden, aber mit einem Versatz von 1800 ms vom Start und 1500ms vom Ziel, also effektiv einen Versatz von 300ms in diesem Beispiel. Im Worstcase wären aber bis zu 1999ms denkbar

Wenn ich den Post von Gregor richtig verstehe, reicht ein zusätzlicher Versand zum Zeitpunkt des Auslösens, richtig?

Die Signallaufzeiten kann ich vernachlässigen, da sie von beiden Nodes annähernd gleich sind und im Bereich von etwa 30ms liegen. da ich auf 100ms genau messen möchte sollte das schon passen

5

Du versuchst es wirklich sehr umständlich zu erklären.

Was der Client zwischendurch macht, ist hier mal egal.
Auf keinen Fall sollten hier delays zum Warten eingesetzt werden. Das wäre fatal.

Beim durchlaufen der "Client-Lichtschranke" setzt du ein Signal (ohne Verzögerung) vom Client ab.
Der Server empfängt dieses und startet seinen Zeitlauf.

Die "Server-Lichtschranke" wird erreicht und der Zeitlauf wird gestoppt und errechnet.

Stoppzeit - Startzeit = Ergebnis

Mehr ist nicht nötig und ein Versatz ist auch nicht vorhanden.

Und damit der Server den Start erkennt, sendest du eine ID z.B. "Start" mit aus.

6

hi,

prinzipiell gebe ich dir Recht, das Grundproblem ist einfach zu lösen.
Delays verwende ich nicht mehr, die Nachteile sind für fast alle meine Projekte doch zu groß.

Ich durfte feststellen, dass es bei Übertragungen per Funk immer wieder zu Fehlern kommt, auch wenn die Verbindung scheinbar gut ist, hin und wieder fehlt ein Packet. Fällt mein Trigger genau in so einen Fall hätte ich ein Problem.
Das ist der Grund warum ich hier angefangen habe komplizierter zu denken.

7

derSchorsch:
Ich durfte feststellen, dass es bei Übertragungen per Funk immer wieder zu Fehlern kommt, auch wenn die Verbindung scheinbar gut ist, hin und wieder fehlt ein Packet. Fällt mein Trigger genau in so einen Fall hätte ich ein Problem.
Das ist der Grund warum ich hier angefangen habe komplizierter zu denken.

Das Problem mit dem evtl. ausfallenden Paketen kannst du lösen, indem du unmittelbar nacheinander 3 Aussendungen machst. Da sollte doch was rüber kommen.

Da du nur den Startbefehl gibst, wird es so funktionieren.
Keine Zeit übertragen, das passiert nur alles im Server.

Und bitte nicht komplizierter denken oder machen, das wird dann nichts. :wink:

8

derSchorsch:
Ich durfte feststellen, dass es bei Übertragungen per Funk immer wieder zu Fehlern kommt, auch wenn die Verbindung scheinbar gut ist, hin und wieder fehlt ein Packet.

Ich würde dann wohl zunächst andere Übertragungsmöglichkeiten testen. Z. B. per IR. Wenn es nur um „Pings“ geht, sollte das gut funktionieren, sofern eine Sichtverbindung zwischen den Beteiligten möglich ist. Ich spiele seit einiger Zeit mit IR-Empfängern (Tastern, manche meinen, das sei eine Reflexlichtschranke) von Vishay (TSSP4P38). Die können als „Beam-Break“-Lichtschranken zwar nicht so irre viel, aber das bisschen genügt mir derzeit vollkommen.

Gruß

Gregor

9

gregorss:
Ich würde dann wohl zunächst andere Übertragungsmöglichkeiten testen. Z. B. per IR. Wenn es nur um „Pings“ geht, sollte das gut funktionieren, sofern eine Sichtverbindung zwischen den Beteiligten möglich ist. Ich spiele seit einiger Zeit mit IR-Empfängern (Tastern, manche meinen, das sei eine Reflexlichtschranke) von Vishay (TSSP4P38). Die können als „Beam-Break“-Lichtschranken zwar nicht so irre viel, aber das bisschen genügt mir derzeit vollkommen.

Und du bist sicher, dass IR über 150 Meter funktioniert?

10

HotSystems:
Und du bist sicher, dass IR über 150 Meter funktioniert?

Uh. Das mit den 150 m hatte ich wohl erfolgreich verdrängt. Wenn Zeit vorhanden wäre, würde ich es jedenfalls probieren (wenn ich nicht so viele andere schöne Sachen vorhätte :slight_smile:

Gruß

Gregor

11

gregorss:
Uh. Das mit den 150 m hatte ich wohl erfolgreich verdrängt. Wenn Zeit vorhanden wäre, würde ich es jedenfalls probieren (wenn ich nicht so viele andere schöne Sachen vorhätte :slight_smile:

Naja ein Versuch wäre es Wert.
Aber ich denke Funk ist da ok, wenn es richtig konfiguriert ist.

12

HotSystems:
Naja ein Versuch wäre es Wert.
Aber ich denke Funk ist da ok, wenn es richtig konfiguriert ist.

Zusätzlich würde ich mal mit Blechdosen experimentieren. Als „Richtfunkhilfen“ kämen z. B. Raviolis oder Pringles in Frage.

Versuch macht kluch :slight_smile:

Gregor

13

erstmal vielen Dank!

Ich denke mit IR wird es schwierig, die Entfernung kann durchaus mal variieren und die Gefahr, das jemand oder etwas im Weg steht ist leider gegeben. Daher denke ich, dass ich mit Funk schon auf dem richtigen Weg bin. Ich hatte davor mit 433Mhz experimentiert, das Ergebnis war aber nicht so pralle.
Jetzt mit den 2,4Ghz Modulen sieht das schon anders aus, die Chinabude hat was von theoretischen 1000m Reichweite bei freier Sicht drauf geschrieben, da sollten die 150 bis 200m, die ich brauche drin sein.

Ich will nur irgendwie ein zuverlässiges System erreichen, was auch bei Ausfall einzelner Pakete immer noch auf die hundertsel Sekunde genau arbeitet.

Daher war die Idee die jeweiligen Zeiten der Nodes an den Server zu senden, statt nur zum Zeitpunkt X den Äther zu fluten, nur brauche ich dafür ein Synchronisation in irgendeiner Art und Weise.

14

Wenn du etwas mit Funk machen willst, kommst du nicht umhin das Startsignal mehrmals auszusenden.
Egal ob du nun die Zeit mit sendest oder nur eine Start-ID sendest.

Wenn du das Signal z.B. 5 mal sendest, gibst du der ID auch die Position der Aussendung mit und kannst dann zurück rechnen wann der tatsächliche Start erfolgte. Das wird sicherer als mit irgendwelchen Zeitaussendungen ohne Synchronisation.