Hallo,
ich habe folgendes Projekt vor:
Ich würde gern eine Zeitmessanlage für u.A.Leichtathleten basteln. Mein
Gedanke ist folgender:
- je ein Raspi mit einer Reflexionslichtschranke ausstatten für ein
EIN/AUS-Signal, davon 3 Raspis für Start/Zwischenzeit/Ziel.
- dann die Rapis wegen der Kommunikation per Wlan oder Bluetooth mit nem
Laptop, besser Smartphone/Tablet verbinden und Messungen darüber
steuern/ablesen. Die Raspis würden per Akku versorgt werden sollen, die
dann den Laser mitversorgt.
Oder ein weitere Raspi mit Display für die Zeitanzeige...wäre noch
besser.
-Welche Bauteile würden sich eignen?
-welches Betriebssystem?
Würde mich sehr über Infos, Anregungen, Hinweise freuen.
LG Hardy
Hardy schrieb:> davon 3 Raspis
Warum? Ein Raspi ist schnell genug, um alle Messungen zu erfassen, per
Webserver zur Verfügung zu stellen und nebenbei noch das Display zu
bedienen.
Alex G. schrieb:> Wohl weil Start, Zwischenzeit und Ziel weit auseinander liegen dürften.
Und damit kommen wir zum eigentlichen Problem: Wie wird die Zeit der
verschiedenen Raspis synchronisiert?
Andreas B. schrieb:> Alex G. schrieb:>> Wohl weil Start, Zwischenzeit und Ziel weit auseinander liegen dürften.>> Und damit kommen wir zum eigentlichen Problem: Wie wird die Zeit der> verschiedenen Raspis synchronisiert?
Wenn es sich beim Netzwerk um eines mit Internet handelt, geht das
automatisch (synchronisierung mit dem Web). Nehme mal an der TE braucht
keine höhere Genauigkeit als 1/10 Sekunde oder so denn das ist schon
besser als ein Mensch mit Stoppuhr.
Alex G. schrieb:> Wenn es sich beim Netzwerk um eines mit Internet handelt,
dann kann die Latenzzeit auch mal mehr als 1/10s betragen. Für eine
Stoppuhr wäre mir das zu unsicher.
Edit: Gerade mal geschaut: Mit NTPv4 würde es funktionieren.
Alex G. schrieb:> Betriebssystem kannst du beim Standard Raspbian bleiben.
Solltest du sogar, es gibt nichts besseres. Jedes andere ist nur eine
mehr oder weniger schlechte Kopie davon.
Wozu braucht eine Stoppuhr die Uhrzeit (und deswegen Internet)? Nur,
weil jede Kaffeemaschine so eine Anzeige hat? Die drei müssen nur für
die Messung auf die gleiche Zeit synchronisiert werden. Dazu wird
einer als "Master" = NTP-/Server/ eingerichtet und die anderen holen
sich die Zeit von dort. Über eine gute WLAN-Verbindung sollte NTP einen
relativen Fehler von ±0.01s schaffen. Ich glaube, in dem anderen Thread
gab es noch raffiniertere Verfahren.
Bauform B. schrieb:> Alex G. schrieb:>> Betriebssystem kannst du beim Standard Raspbian bleiben.>> Solltest du sogar, es gibt nichts besseres. Jedes andere ist nur eine> mehr oder weniger schlechte Kopie davon.
Naja, nüchtern betrachtet wäre ein stark abgespecktes OS schon
"ökonomsicher" oder schlicht sinnvoller bei dieser Aufgabenstellung.
Allerdings bringt das für einen Anfänger nur mehr Schwierigkeiten mit
sich, darum hast du recht.
Das ist aber auch der Grund wieso ich die Webmethode erwähnte, weil die
am einfachsten umzusetzen ist.
Bin dabei, habe aber noch grundsätzliche Fragen:
- wieviel Schalter (Lichtschranken) könnte ich direkt an einen Raspi
anschließen? heißt: kann der Raspi auf Pin1(Start) dann Pin2
(Zwischenzeit)und Pin3(Ziel) reagieren?
Hardy schrieb:> Bin dabei, habe aber noch grundsätzliche Fragen:>> - wieviel Schalter (Lichtschranken) könnte ich direkt an einen Raspi> anschließen? heißt: kann der Raspi auf Pin1(Start) dann Pin2> (Zwischenzeit)und Pin3(Ziel) reagieren?
Klar geht das. Dann brauchst du aber lange Kabel und das wird elektrisch
entsprechend anspruchsvoller (Schutzbeschaltung, Zuverlässigkeit der
Signalübertragung).
1/100,.... vergiss alles was mit NTP via WLAN zusammenhängt.
Studenten an unserer UNI hatten mal einen ähnlichen Ansatz gewählt, um
die Beschleunigung von E-Fahrzeugen zu messen.
Alles am Ende nur Kappes, die Lehre nehmen die definitiv mit in Ihren
Ingenieursaltag!
Es funktionierte über Lichtimpulse von Station zu Station, wurde aber
aufgrund zu vieler Störgrössen ad Acta gelegt.
Letztlich half ein "Klingeldraht" bis 1/1000 Sekunde Auflösung...
Ein Wald- Feld und Wiesencontroller kam zum Einsatz (Atmel).
LG
Studentenquäler
> Dass mit der abgespeckten Raspian-version bekomme ich bestimmt> hin.(Welche Komponenten müssen denn zwingend installiert sein?,> Apache,...)
Da ist noch mehr nötig, zum Beispiel ein spezieller Kernel für Real-Time
Anforderungen. Der normale Linux Kern hat die Freiheit, sämtlich
Programme unregelmäßig anzuhalten, und das tut er auch. Ist bei Windows
auch nicht anders.
Ich glaube schon im Ansatz lauern ein paar Pferdefüße.
Eine Lichtschranke ist sehr demokratisch. D. h. wenn zwei Sportler
(fast) gleichauf den Lichtstrahl unterbrechen, sieht es eher
mittelprächtig aus. Die teilen sich dann nämlich eine Unterbrechung. Da
hilft es auch nichts, wenn sich die Zeit des Dritten richtig zuordnen
läßt.
Kommt ein Pulk ins Ziel, so werden Dir die Finger schnell glühen. Es sei
denn Du hast ein photografisches Gedächtnis und kannst nachträglich die
Unterbrechungen den einzelnen Sportlern zuordnen.
Usw.
Also vergiß nicht am Ziel einen Engpass zu installieren, so dass immer
nur einer die Lichtschranke unterbrechen kann.
1/100stel ist schon sehr sportlich für Eigenbau Lösungen über Funk! In
der Tat ist man damit auch im Bereich wo die von Stefanus erwähnten
Unterbrechungen relevant werden.
Da würde ich ehrlich gesagt auf was professionelles sparen. Hab nach
kurzer Suche was für 1000€ gefunden.
Stefanus F. schrieb:> Da ist noch mehr nötig, zum Beispiel ein spezieller Kernel für Real-Time> Anforderungen. Der normale Linux Kern hat die Freiheit, sämtlich> Programme unregelmäßig anzuhalten, und das tut er auch. Ist bei Windows> auch nicht anders.
Völliger Schwachsinn. Du kannst getrost Raspbian verwenden.
Dein grösstes Problem wird die Synchronisation der Zeit auf deinen
Raspberries sein. Ich vermute, du wirst im freien Feld keine
Internetanbindung haben.
Hier evtl. ein Ansatz:
https://www.raspberrypi.org/forums/viewtopic.php?p=968536#p968536
> Dein grösstes Problem wird die Synchronisation der Zeit auf> deinen Raspberries sein. Ich vermute, du wirst im freien> Feld keine Internetanbindung haben.
Wozu braucht man Internet, um zwei Uhren gleich zu stellen? In der
Analogen Welt, würde man beide Uhren nebeneinander legen und eine an die
andere angleichen. Das geht auch digital (mit dem besagten NTP daemon).
>> Da ist noch mehr nötig, zum Beispiel ein spezieller Kernel für Real-Time>> Anforderungen. Der normale Linux Kern hat die Freiheit, sämtlich>> Programme unregelmäßig anzuhalten, und das tut er auch. Ist bei Windows>> auch nicht anders.> Völliger Schwachsinn.
So harten Worten sollte mindestens eine knappe Begründung folgen. Was
ist an meiner Aussage völliger Schwachsinn?
Stefanus F. schrieb:> Da ist noch mehr nötig, zum Beispiel ein spezieller Kernel für Real-Time> Anforderungen. Der normale Linux Kern hat die Freiheit, sämtlich> Programme unregelmäßig anzuhalten, und das tut er auch. Ist bei Windows> auch nicht anders.
Der Unterschied zu Windows ist, dass du genau kontrollieren kannst,
welche Programme überhaupt laufen. Während die Zeiterfassung läuft, muss
nur genau ein Programm laufen. Das hat dann den ganzen Rechner für sich
alleine, warum sollte es unterbrochen werden? Damit kann man ohne Tricks
die Eingänge mit 250Hz pollen. Der Kernel kann auch auf 1000Hz
konfiguriert werden (evt. ist es bei Raspbian schon so).
Das Programm könnte durch Warten auf eine SD-Karte blockiert werden.
Aber warum sollte jemand auf die Karte zugreifen? Ich gehe natürlich
davon aus, dass systemd, dbus und ähnlicher Müll deinstalliert werden.
Das ist bei Raspbian kein Problem, es funktioniert wie bei Debian.
Apache als Webserver ist vielleicht ein klein wenig überdimensioniert
und entsprechend mühsam zu konfigurieren. Es gibt aber ca. ein Dutzend
kleine bis sehr kleine Webserver. Sehr gute Erfahrungen hab' ich mit
bozohttpd gemacht - auspacken, einschalten, geht.
> Der Unterschied zu Windows ist, dass du genau kontrollieren kannst,> welche Programme überhaupt laufen
Na den Linux Rechner möchte ich mal sehen, auf dem nur ein einziges
selbst geschriebenes Programm läuft.
> Damit kann man ohne Tricks die Eingänge mit 250Hz pollen.
Da stimme ich zu. Aber nur, wenn die betroffenen I/O Pins nicht über
einen internen seriellen Bus laufen, der über umfangreiche Treiber
gesteuert wird, wie das beim Rapberyy Pi meines Wissens nach der Fall
ist.
> Das Programm könnte durch Warten auf eine SD-Karte blockiert werden.> Aber warum sollte jemand auf die Karte zugreifen?
Dafür fallen mir ganz viele Gründe ein. Hauptsächlich weil ich davon
ausgehe, dass doch mehr als ein Programm wechselweise von der CPU
ausgeführt werden. Nicht vergessen, dass auch die Gerätetreiber in
diesem Sinne Programme sind.
> Ich gehe natürlich davon aus, dass systemd, dbus und ähnlicher Müll> deinstalliert werden.
Genau davon gehe ich nicht aus. Für Anfänger die solche fragen wie der
TO stellen, geht das zu weit.
Stefanus F. schrieb:> Na den Linux Rechner möchte ich mal sehen, auf dem nur ein einziges> selbst geschriebenes Programm läuft.
Da habe ich schon einige gesehen, einschl. der von mir selbst
geschriebenen; ich schätze mal, Du musst zum Augenarzt.
bingo schrieb:> Da habe ich schon einige gesehen, einschl. der von mir selbst> geschriebenen; ich schätze mal, Du musst zum Augenarzt.
Vielleicht hast Du es nicht richtig verstanden: Unter Linux, selbst in
der abgespecktesten Vesion, laufen immer irgendwelche Dienste im
Hintergrund, die zufällig ins Geschehen eingreifen und für Verzögerungen
sorgen können.
Selbst bei RTOS ist das der Fall, aber dort wird garantiert, dass die
Verzögerungen eine bestimmte Zeit nicht überschreiten.
Sollte es wirklich darum gehen, weit entfernte Messpunkte zu
synchronisieren, würde ich an die Messpunkte Arduinos mit nRF24L01
Sendern setzen. Der Raspi synchronisiert die Messpunkte über sein nRF
zyklisch. Die Messpunkte senden das Ereignis mit Timecode zurück, dann
ist es egal, wie lange die Übertragung dauert (mehrfaches Retransmit bei
Störungen) und wie lange der Raspi für die Verarbeitung braucht.
Ich würde unbedingt einen internen Timecode-Counter im Programm
verwenden, zum Beispiel über Millies (interne Millisekunden seit
Rechnerstart) und nicht über die "Uhr" des Raspies. Dazu ist die zu
unsicher. Den Rechner gestartet und die Uhr läuft noch auf der "alten"
Zeit, plötzlich bekommt der Rechner ein Wlan und die Uhr springt auf die
neue synchronisierte Zeit, und der Timecode hat einen Sprung von 3
Stunden oder 3 Tagen drin.
Man kann Linux schon soweit stutzen, dass wirklich nur noch ein einziges
Programm läuft und keine anderen Timer dazwischen funken. Aber dann ist
es kein Linux Betriebssystem mehr, sondern nur noch ein nackter Linux
Kernel, der aus seinem natürlichen Lebensraum gerissen wurde.
Mit einem RT Preempt Kernel bekommt man mit ein paar Tricks und
Klimmzügen bei 1kHz Takt einen Jitter von durchschnittlich 10µs hin,
worst case in Gegend von 100µs-150µs. Inzwischen gibts auch von der Pi
Foundation einen "offiziellen" Pi-RT-Preempt-Zweig. Um den Jitter zu
begrenzen empfiehlt es sich, KMS zu deaktivieren (also "legacy OpenGL"),
den Kern auf dem die Realtime-Anwendung läuft per bootparam isolcpus von
"weltlichen" Aufgaben zu entbinden, und die Realtime-Anwendung auf die
isolierte CPU zu legen. Z.b. mit taskset.
Programmierbeispiele wie man die APIs anspricht gibts in linuxcnc bzw.
machinekit, eventuell könnte man den HAL-Layer da auch weiterverwenden.
Nicht vernachlässigbar ist am Pi alles was über den USB-"Hostcontroller"
muss, das Ding verursacht schwer vorhersagbare Latenzen. Dranhängen tun
da nicht nur die USB Geräte, sondern vor allem auch die SD-Karte und das
Netzwerk, WLAN und Blauzahn sowieso.
NTP am Pi könnte funktionieren, wenn man jedem Pi ein GPS verpasst, und
das als Referenz für den NTPD verwendet.
Genauigkeit von +-5ms wird aber so oder so mehr als sportlich.
Genauer und einfacher würde es vermutlich mit einer GPS-disziplinierten
Uhr in einem kleinen Mikrocontroller, der dann die Lichtschranke etc...
auswertet, und die Zeiten einfach per UART an einen Pi weitergibt, der
kommt dann mit normalem linux aus, insgesamt entsteht weniger Code, etc
etc etc, man muss dann auch nicht paranoid sein wegen OpenGL oder WLAN
und den dadurch verursachten Latenzen.
Karl K. schrieb:> Unter Linux, selbst in> der abgespecktesten Vesion, laufen immer irgendwelche Dienste im> Hintergrund, die zufällig ins Geschehen eingreifen und für Verzögerungen> sorgen können.
Unter "Dienste" würde ich sowas wie ntpd verstehen und genau die hat man
als Benutzer ja im Griff. Auf unserem internen ntp-Server sieht das z.B.
so aus:
1
$ pstree
2
init-+-cron
3
|-dnsmasq
4
|-6*[getty]
5
|-lpd
6
|-ntpd---{ntpd}
7
|-rsyslogd-+-{in:imklog}
8
| |-{in:imuxsock}
9
| `-{rs:main Q:Reg}
10
`-sshd---sshd---sshd---bash---pstree
Oder anders gefragt, welche Dienste (im weiteren Sinne) haben im letzten
halben Jahr CPU-Zeit verbraucht:
root 175 0.0 0.8 3580 2144 Ss Feb11 0:35 /usr/sbin/cron
Da fällt vor allem der jbd2 auf. Da die Stoppuhr ihre Logfiles auch in
ein tmpfs schreiben kann, macht der keine Schwierigkeiten. Was der
kworker genau macht, weiß ich nicht und der ntpd könnte durch das
Netzwerk blockiert werden. Aber dass einer von beiden mehr als eine
Millisekunde am Stück braucht kann ich einfach nicht glauben.
Gegen den ntpd, falls man ihn überhaupt braucht, hilft auch noch das
normale nice(1). Aber gut, theoretisch habt ihr Recht.
Karl K. schrieb:> Ich würde unbedingt einen internen Timecode-Counter im Programm> verwenden, zum Beispiel über Millies (interne Millisekunden seit> Rechnerstart) und nicht über die "Uhr" des Raspies.
eh klar; man clock_gettime
rµ schrieb:> Genauer und einfacher würde es vermutlich mit einer GPS-disziplinierten> Uhr in einem kleinen Mikrocontroller
GPS ist ein sehr guter Plan. Das geht auch auf einem Pi-ähnlichen
Rechner ganz gut, mehr gibt ein billiges GPS-Modul eh nicht her. Man
könnte natürlich ein u-blox M8F mit PPS- und Frequenz-Ausgang
spendieren...
1
$ ntpq -pn
2
remote refid st t when poll reach delay offset jitter
rµ schrieb:> Mit einem RT Preempt Kernel bekommt man mit ein paar Tricks und> Klimmzügen bei 1kHz Takt einen Jitter von durchschnittlich 10µs hin,> worst case in Gegend von 100µs-150µs. Inzwischen gibts auch von der Pi
Die 100µs-150µs ist die Zeit bis der eigene Code ausgeführt wird, oder?
Zur Zeitmessung wäre ein 'Timer-Capture' wie bei den µCs hilfreich.
Hat ein rPi so etwas?
Wenn man wirklich real-time braucht, sollte man Mikrocontroller mit
Quarz und Assembler nehmen, die mit Kabel (am besten über RS-485)
verbinden, die messen dann die Zeiten und das weitere (Darstellung etc)
macht man dann entweder über einen Laptop oder Raspi, das kann dann auch
über WLAN.
Bauform B. schrieb:> Unter "Dienste" würde ich sowas wie ntpd verstehen und genau die hat man> als Benutzer ja im Griff.
Was ist mit Wlan? Ausgabe der Werte über eine Webseite via Webserver?
Ich mache es nun doch anders, ist wohl etwas zu kompliziert für
mich...:-)
Habe mir:
- 3 "gute" gebrauchte Lichtschranken (ebay) 100€ (NPN)
- 3 dazu passende Kabel 70€ (die sollen ja lange halten!)
- 1 USB-Box (hatte ich mir 2016 gekauft ca.150€ von
https://dillinger-engineering.de
- 6 Stative ca 120€
- Kleinkram ca 20€
gekauft.
Vorteile:
- Preis ca 450€ gegenüber sonstigen Fertigangeboten (um die 1200€ mit 3
Messpunkten.
- extrem genaue Ergebnisse (4,096 ms)
- Software (Windows) ist sehr umfangreich mit vielen Funktionen!
- man braucht nur wenig Spezialwissen.
- eine Stromquelle für alle Geräte.
Nachteile:
- Laptop muss immer dabei sein.
- Verkabelung finde ich nicht so gut (gegenüber Funk)
Dennoch vielen Dank an Euch! Vielleicht hilft es ja auch anderen die
Ähnliches vorhaben.
Hardy schrieb:> Ich mache es nun doch anders, ist wohl etwas zu kompliziert für> mich
Manchmal wird einem eben erst bei der genaueren Planung eines Projektes
klar, wie kompliziert das ganze werden wird und wo die Risiken liegen.
Selbst mit vielen Jahren Berufserfahrung in der Entwicklung würde ich
persönlich in diesem Fall auch eher ein System kaufen. Den Preis von 450
EUR finde ich vollkommen angemessen.
Kabel verlegen ist zwar etwas lästig, aber es ist die zuverlässigste
Lösung.
Nichts ist peinlicher, als den Läufern nach einem 2000m Lauf erklären zu
müssen, dass leider, leider die selbstgebastelte Zeitmessanlage eine
Fehlfunktion hatte... ;-)
WiFi und Bluetooth scheiden meiner Meinung schon allein wegen der
geringen Reichweite aus, und wenn der Empfang schlecht ist, steigt die
Latenz unplanbar an. Hier bräuchte man auf jeden Fall synchronisierte
Zeitbasen in jedem Empfänger.
Die Website von "Tag Heuer" verrät ein bisschen was darüber, wie deren
Funkübertragungssystem arbeitet:
http://www.tagheuer-timing.com/de/timekeeping-hl615-100mw-wireless-impulse-systemhttp://www.tagheuer-timing.com/resources/Product/86/DescriptionFile/de-DE/HL615-DE.pdf
Sie nutzen das 869MHz Band mit 100mW, Reichweite bis 1 km.
Witzig finde ich den Satz "Wegen seiner Niederenergie kann dieses System
von anderen Funksysteme zerstört sein". Ich denke, hier ist "gestört"
gemeint, aber da sieht man, dass selbst die Profi-Funksysteme mit
Vorsicht zu genießen sind.
"Fixe Verzögerung von 200ms mit einer Präzision besser als 0.13ms"
deutet für mich darauf hin, dass die Sender bei einer Unterbrechung der
Lichtschranke einfach ein kurzes Telegramm auf 869MHz absetzen. Die
Übertragungszeit ist bekannt (200ms) und wenn alle Sender die gleiche
Verzögerung kann die Zeitdifferenz zwischen den Lichtschranken korrekt
ermittelt werden.
Wenn du jetzt dein System mit Kabel hast, kannst du ja im nächsten
Schritt an einer Funklösung basteln, und die kann dann auch parallel zum
Kabel betrieben werden, um sie zu testen.
Ich würde dazu ebenfalls 869MHz nutzen und einen kleinen Mikrocontroller
(Raspberries sind für diese Aufgabe total überdimensioniert), der ein
32-Bit Telegramm rausschickt, sobald die Lichtschranke unterbrochen ist.
Für die Übertragungssicherheit empfiehlt es sich das Telegramm mehrmals
zu schicken.
Damit der Empfänger Widerholungen des gleichen Telegramms und die
unterschiedlichen Lichtschranken-Events unterscheiden kann, baut man
einen Counter in das Telegramm ein.
Das Protokoll könnte z.B. so aussehen:
Erste 16-bit "Vendor-ID", damit der Empfänger erkennen kann, dass die
Daten von einer deiner Lichtschranken kommt.
Nächste 8-bit: "Lichtschranken-ID", um verschiedene Lichtschranken auf
der Strecke zu unterscheiden
Unterste 8-bit: "Event-Counter" um Events von Telegramm-Wiederholungen
zu unterscheiden.
Beispiel:
1. Lichtschranke, 1. Unterbrechung
Funk-Daten: 0x55550101 0x55550101 0x55550101
0x5555 ist die Vendor-ID
0x01 -> Lichtschranke 1
0x01 -> Event-Counter = 1
1. Lichtschranke, 2. Unterbrechung
Funk-Daten: 0x55550102 0x55550102 0x55550102
2. Lichtschranke, 5. Unterbrechung
Funk-Daten: 0x55550205 0x55550205 0x55550205
Richtig gut wird es, wenn man noch ein Prüfbyte einbaut... ;-)
Wenn man die Daten mit 9600 Baud überträgt, dauert es pro Telegramm
(32-bit) etwa 3.3ms, bei 3-maliger Wiederholung sind es max. 10ms.
D.h. selbst wenn Funk-Telegramme verloren gehen, liegt man immer noch
bei einer Genauigkeit von ca. <1/100s
Wenn das Teil draußen steht, kann man auch einfach GPS zur
Zeitsynchronisation verwenden. Das ist weitaus genauer als für diese
Anwendung notwendig. Dafür gibts auch entsprechende fertige Module.
Ja Linux ist jetzt nicht für richtige Echtzeitanwendungen gedacht, aber
das hier ist ja quasi keine "echte" Echtzeitanwendung, da es hier ja
ausreicht, die Ports 100 Mal pro Sekunde abzufragen. Ein typisches
Linuxsystem ist auf 1000 Taskwechsel pro Sekunde konfiguriert, das kann
das locker. Mit nanosleep kann man wahrscheinlich sogar noch genauer
bestimmen wann der Prozess aufgeweckt wird. (müsste man mal
ausprobieren)
Wenn es genauer sein muss ist die logische Alternative einen kleinen
Mikrocontroller mit einem trivialen Programm zu verwenden. Dieser hängt
per PPS am GPS-Empfänger und gibt jede Änderung des Portzustandes als
Text auf der seriellen Schnittstelle aus. Von da aus kann man das
trivial per RasPI oder Laptop weiterverarbeiten. Man kann auch noch die
NEMA Daten auf den Controller geben, dann kann er die Zeitstempel sogar
noch absolut (und nicht relativ zur aktuellen Sekunde) angeben.
Die Zeitstempel kann man dann per Mobilfunk weiterleiten. (z.bsp
WLAN->Mobiltelefon)
Warum so kompliziert? Du brauchst:
- 3 ESP32-Module.
Die werden (modul-)intern mit einem 40MHz, 10ppm-Oszillator getaktet und
haben genug schnelle Hardwaretimer.
Funktionalität: Ein ESP32 ist der Master, der das WLAN aufspannt, die
anderen beiden (und dein Laptop/Handy) verbinden sich mit dessen WLAN.
Jeder ESP32 hat einen frei laufenden Hardwaretimer. Bei jedem
Sync-Impuls (z.B. Lichtschranke) den ein ESP32 bekommt schickt er seinen
aktuellen Timerwert an den Master. Der berechnet eventuelle Differenzen
(z.B. Rundenzeiten) und stellt sie dir durch seinen eingebauten
Webserver zur verfügung.
Am Anfang deines Events liegen alle drei ESP32 direkt nebeneinander und
alle drei bekommen gleichzeitig einen Sync-Impuls, der den Hardwaretimer
zurücksetzt. Dann trägst du die ESPs da hin wo sie sein sollen.
Mit 10ppm driftet das System im worst case um jeweils 3,6 Hundertstel
pro Stunde auseinander. Wenn du also ein einstündiges Rennen stoppen
willst, könnten die Endzeiten schlimmstenfalls 3,6 Hundertstel zu lang
oder kurz sein. Sollten deine Messdauern länger als eine Stunde sein,
kannst du immer noch trivial einen NTP-Client implementieren.
Edit: Du bekommst ESP32-Boards mit Anschluss für einen Lithiumakku und
externer Antenne für unter 10€, dann brauchst du nur noch ne 18650
einstecken und hast deine mobile Sendestation fürs Feld. Solltest du
größere Reichweiten als ca. 150m benötigen, gibts auch ESP32-LoRa-Module
mit denen dann auch Kilometer-Reichweiten möglich sind. Alles fürs
kleine Geld :)
Philipp M. schrieb:> Warum so kompliziert? Du brauchst:>> - 3 ESP32-Module.>> Die werden (modul-)intern mit einem 40MHz, 10ppm-Oszillator getaktet und> haben genug schnelle Hardwaretimer.>
Hört sich, so wie du es schreibst einfach an. :-)
Habe eine Riesenbitte an Dich.
könntest Du mir alle Bauteile nennen, die ich dafür brauche?
Weiß z. B. nicht was ein 18650 ist.
Habe mir 3 ReflexionsLichtschranken gekauft die 10-30 Volt benötigen. Da
ist die Stromversorgung das Hauptproblem. Sollte ich das auch einfacher
lösen? Welche Lichtschranken wären deiner Meinung für diesen Zweck
geeignet? Stromversorgung/Genauigkeit Viele LS arbeiten ja mit
Sender/Empfänger - da bräuchte man ja pro LS 2 Funkstationen. Bei
ReflexionsLichtschranken nur eine.
Gibt es eine App für Android die dann mit den Funksignalen/Webserver
etwas anfangen kann? Heißt eine Stoppuhr die das kann oder reicht da ein
simples Terminal zur Auswertung?
ESP32-Module und Arduinos habe ich da.
Blink habe ich auch schon mal geschafft drauf zu packen ;-) Aber das
alles dann selbst zu programmieren... weiß nicht genau, ob ich das
hinbekomme...
LG Hardy
Mit 18650 meint er einen Lithioum Ionen Akku. Frisch geladen liefert der
aber zu viel Spannung für die ESP Module. Außerdem haben die zu wenig
Reichweite.
Christian B. schrieb:> Wenn das Teil draußen steht, kann man auch einfach GPS zur> Zeitsynchronisation verwenden.
Die Anlage soll für drinnen und draußen sein, also GPS unabhängig.
LG Hardy
Joe F. schrieb:> Ich würde dazu ebenfalls 869MHz nutzen und einen kleinen Mikrocontroller> (Raspberries sind für diese Aufgabe total überdimensioniert), der ein> 32-Bit Telegramm rausschickt, sobald die Lichtschranke unterbrochen ist.
Heißt die LS sendet ein Signal an den Microcontroler z.B. Arduino und
der per 869MHzSender an einen Empfänger (Arduino mit Display und 869MHz
Empfänger,der von allen LS die Signale verarbeitet?
So richtig?
> Wie begrenzt ist denn die Reichweite Meinung nach?
Bei mir erreichen die ESP8266 Module etwa 10 Meter durch zwei
Backsteinwände und etwa 20 Meter ohne Hindernisse. Ich nehme an, dass es
beim ESP32 nicht anders sein wird.
Irgendwo habe ich gelesen, dass man die Sendeleistung erhöhen kann, aber
das ist vermutlich illegal. Mit Richtantennen kann man sicher mehr
erreichen, aber wer will damit schon auf dem Sportplatz herum hantieren?
Im 866Mhz bereich kann man draußen locker einige hundert Meter erreichen
und wenn man sich anstrengt sogar ein paar Kilometer. Deswegen würde ich
eher auf diese Funkfrequenz setzen.
Stefanus F. schrieb:> Im 866Mhz bereich kann man draußen locker einige hundert Meter erreichen> und wenn man sich anstrengt sogar ein paar Kilometer. Deswegen würde ich> eher auf diese Funkfrequenz setzen.
Danke.
Also brauche ich dafür:
3 866MHz (oder 869MHz?)Sendemodule
1 866/869MHz Empfänger
3 Arduinos (habe Nano-Arduinos)
1 Arduino mit Display und Taster (zum zurücksetzen der Startzeit) mit
866/869MHz Empfangsmodul
ist das so richtig?
LG Hardy
Sind dafür kleine Antennen notwendig?
> 866/869MHz
Bei Wikipedia steht: 868Mhz. Jedenfalls meine ich das SRD Band von 863
bis 870 MHz.
Zu den anderen Teilen: Das kannst nur du wissen. Ich weiss ja nicht wo
du wie viele Displays aufstellen willst.
Stromversorgung, Verkabelung und Gehäuse vermisse ich. Ich nehme an, Dir
ist klar dass da noch eine Menge mehr Teile zu gehören und die werden
wohl auch die teuersten sein.
> Sind dafür kleine Antennen notwendig?
Kommt logischerweise auf die Funkmodule an.
Stefanus F. schrieb:> Bei Wikipedia steht: 868Mhz. Jedenfalls meine ich das SRD Band von 863> bis 870 MHz.>> Zu den anderen Teilen: Das kannst nur du wissen. Ich weiss ja nicht wo> du wie viele Displays aufstellen willst.>> Stromversorgung, Verkabelung und Gehäuse vermisse ich. Ich nehme an, Dir> ist klar dass da noch eine Menge mehr Teile zu gehören und die werden> wohl auch die teuersten sein.>>> Sind dafür kleine Antennen notwendig?>> Kommt logischerweise auf die Funkmodule an
Natürlich habe ich auch viele andere Komponenten schon:
Stative, Batterien, Gehäuse, LS usw habe ich alles.
Was käme denn sonst noch dazu?
Es soll natürlich nur 1 Display verwendet werden, sodass der Zeitnehmer
die Zeiten sehen und auf Null stellen kann.
LG
Alex G. schrieb:> 1/100stel ist schon sehr sportlich für Eigenbau Lösungen über Funk!Studentenquäler schrieb:> Letztlich half ein "Klingeldraht" bis 1/1000 Sekunde Auflösung...
GPS-Empfänger liefern am 1pps-Ausgang Impulse mit einer Genauigkeit von
besser als 100ns bezogen auf eine Atomuhr. Und da wird hier über 1/100s
bzw. 1/1000s und 100m lange Stolperfallen diskutiert.
p.s. Ich gehe mal davon aus, dass es sich hier nicht um Hallensport
handelt.
Stefanus F. schrieb:> Irgendwo habe ich gelesen, dass man die Sendeleistung erhöhen kann, aber> das ist vermutlich illegal. Mit Richtantennen kann man sicher mehr> erreichen, aber wer will damit schon auf dem Sportplatz herum hantieren?
Mit Richtantennen erhöhst du auch die Sendeleistung im Sinne der SRD
Allgemeinzuteilung. Dort ist die maximale ERP festgelegt.
Für die Funkübertragung sollte man LoRa in Erwägung ziehen (z.B. mit
RFM95/96...)
Alex G. schrieb:> Andreas B. schrieb:>> Alex G. schrieb:>>> Wohl weil Start, Zwischenzeit und Ziel weit auseinander liegen dürften.>>>> Und damit kommen wir zum eigentlichen Problem: Wie wird die Zeit der>> verschiedenen Raspis synchronisiert?> Wenn es sich beim Netzwerk um eines mit Internet handelt, geht das> automatisch (synchronisierung mit dem Web). Nehme mal an der TE braucht> keine höhere Genauigkeit als 1/10 Sekunde oder so denn das ist schon> besser als ein Mensch mit Stoppuhr.
Das ist Murks. Da nimmt man 1 Raspi so wie es Karl schon geschrieben.
Wenn die Messpunkte weit auseinander liegen, dann überträgt die
Schaltsignale an den jeweiligen Messpunkten per Funk oder falls ein
Netzwerk da ist eben über selbiges an diesen einen Raspi.
Hardy schrieb:> (Welche Komponenten müssen denn zwingend installiert sein?,> Apache,...)
Bei dieser Fragestellung bezweifle ich mal das Du eine abgespeckte OS
Version hinbekommst. Bleib lieber beim Standard.
Zeno schrieb:> Wenn die Messpunkte weit auseinander liegen, dann überträgt die> Schaltsignale an den jeweiligen Messpunkten per Funk oder falls ein> Netzwerk da ist eben über selbiges an diesen einen Raspi.
Dann stehst du aber ganz gewaltig auf dem Schlauch, wenn mal der Funk
durch das Außenthermometer vom Platzwart kurzzeitig gestört wird und das
Schaltsignal deswegen nicht durch kommt. Für störsicheren Betrieb muss
jede Station funkunabhängig den Zeitpunkt bestimmen und dann nur den
Timestamp innerhalb vernünftiger Zeit zum Master übertragen. Da darf der
Master dann auch ruhig mal nachfragen, wenn er was nicht mitbekommen
hat.
bingo schrieb:> Da habe ich schon einige gesehen, einschl. der von mir selbst> geschriebenen; ich schätze mal, Du musst zum Augenarzt.
Wie soll das funktionieren? Selbst der Kernel ist im Endeffekt ein
Programm, also laufen mindestens 2 Programme nämlich der Kernel und Dein
selbst geschriebenes. Aber selbst das ist sehr unwahrscheinlich, da der
Kernel noch einige Programme drum herum brauch um mit der Peripherie zu
kommunizieren.
Geh mal lieber Du zum Augenarzt oder träum weiter.
my2ct schrieb:> Zeno schrieb:>> Wenn die Messpunkte weit auseinander liegen, dann überträgt die>> Schaltsignale an den jeweiligen Messpunkten per Funk oder falls ein>> Netzwerk da ist eben über selbiges an diesen einen Raspi.>> Dann stehst du aber ganz gewaltig auf dem Schlauch, wenn mal der Funk> durch das Außenthermometer vom Platzwart kurzzeitig gestört wird und das> Schaltsignal deswegen nicht durch kommt. Für störsicheren Betrieb muss> jede Station funkunabhängig den Zeitpunkt bestimmen und dann nur den> Timestamp innerhalb vernünftiger Zeit zum Master übertragen. Da darf der> Master dann auch ruhig mal nachfragen, wenn er was nicht mitbekommen> hat.
Kabel ist immer besser als Funk, aber wenn ich den TO richtig verstanden
habe wollte er es ohne Kabel machen. Sein Vorschlag per WLAN oder gar
WiFi dürfte nicht zuverlässiger sein.
Karl hat im Prinzip beschrieben wie es sehr wahrscheinlich ordentlich
funktioniert.
Wenn schon die Profis, wie Stefanus schrieb, Probleme haben, wird man es
mit seinen bescheidenen Mittel wohl eher nicht oder schwierig
hinbekommen, zumindest mit der geforderten Genauigkeit von 1/100.
Richtig blöd wirds halt, wenn man dem Sprinter der gerade einen super
Lauf hingelegt hat, sagen muß, daß er noch mal ran muß weil die
Zeitmessung versagt. Da sollte man wahrscheinlich selbst sehr sportlich
sein und schneller als der Sprinter rennen können. Aber das wurde ja
bereits schon geschrieben.
Hardy schrieb:> Die Anlage soll für drinnen und draußen sein, also GPS unabhängig.> LG Hardy
Dann gibts noch NTP, dafür brauchst Du aber eine brauchbare
Netzwerkanbindung, zum Beispiel LTE. Als Richtwert kannst Du annehmen,
dass NTP maximal den Fehler einer halben Ping Schleifendauer hat.
Abhängig von der Genauigkeit geht natürlich auch DCF-77, das geht (fast)
überall, auch in Gebäuden. Wenn Du einen Korrelationsempfänger baust
kommst Du sogar in die Größenordnung von µs. Billige Geradeausempfänger
haben eine Unsicherheit im Bereich >10ms. Das kann evtl schon reichen.
Besser als irgendwelche kruden Quarzuhren ist es auf jeden Fall.
Mir ist gerade noch eine andere Idee eingefallen.
Reflexionslichtschranken macht man ja in aller Regel moduliert, damit
der Gleichanteil des Sonnenlichts weg fällt.
Wenn man jetzt einfach das mit einer Frequenz von einigen Kilohertz
moduliert, dann kann man es mit normalem Audioequipment (Soundkarte)
aufzeichnen. Da Audioequipment meist 2 oder mehr Kanäle hat, kann man
auf einem Kanal das Signal vom Phototransistor auflegen, auf dem anderen
das Signal eines Radiosenders.
Alle Lichtschranken der Installation empfangen dann den selben
Radiosender und per Kreuzkorelation kann man sehr simpel die
Aufzeichnungen zeitlich korrekt aufeinander legen.
Hardy schrieb:> Danke.> Also brauche ich dafür:>> 3 866MHz (oder 869MHz?)Sendemodule> 1 866/869MHz Empfänger> 3 Arduinos (habe Nano-Arduinos)> 1 Arduino mit Display und Taster (zum zurücksetzen der Startzeit) mit> 866/869MHz Empfangsmodul
Hier noch ein paar Kommentare (hab den Thread erst jetzt wieder
gesehen):
Arduino Nanos: Vorsicht! Meine Idee war ja, dass die drei Module einmal
synchronisiert werden und dann deren Takte gleich genug sind dass sie
innerhalb eines Tages weniger als deine gewünschte Genauigkeit
auseinander driften. Reguläre Nanos sind da viel zu ungenau, weil sie
nur Keramikresonatoren als Taktquelle haben (760ppm * 2[1] = 547
Hundertstel pro Stunde, oder ein Hundertstel alle 13 Sekunden). Der Witz
an den ESP32-Modulen war, dass sie eben eine genaue Taktquelle haben.
Du kannst natürlich deine 8xxMHz-Module nehmen und jeden
Lichtschrankendurchlauf sofort senden. Eine eventuelle
Messwertverfälschung durch Latenz (weil die Module natürlich auch ein
paar Millisekunden brauchen bis der Messwert gesendet ist) ist dann bei
allen Durchgängen dabei, d.h. für den Vergleich der Sportler
untereinander ist es auf jeden Fall kein Problem, wenn du mit
offiziellen Messwerten vergleichen willst müsstest du halt die
Verzögerung über die Funkmodule messen und kompensieren.
Zur Darstellung bietet sich immer noch ein ESP8266/ESP32 an (wenn nur
ein bis vier Handys/Laptops gleichzeitig drauf zu greifen sollen, z.B.
Schiedsrichter und ein Laptop mit Beamer), sonst halt ein Raspberry o.ä.
1: siehe hier: http://jorisvr.nl/article/arduino-frequency
Frage: Würde mir jemand den Code dafür Scheiben und mich bei diesem
Projekt unterstützen? Natürlich nicht umsonst.
Ich habe schon viel zuviel Zeit investiert und komme doch nicht weiter.
Es sollte mit ESP32 OLED LoRa umgesetzt werden. Andere Hardware ist
iaber auch vorhanden.
Nur bei Interesse einfach per 01761 3322 199 melden.
VG Hardy
Hardy schrieb:> Frage: Würde mir jemand den Code dafür Scheiben und mich bei diesem> Projekt unterstützen? Natürlich nicht umsonst.
Entwicklung lohnt sich nur, wenn die Kosten später durch
Massenproduktion wieder rein geholt werden oder wenn Geld keine Rolle
spielt.
Stelle deine Anforderungen zusammen und frage dann nochmal. Mit den
wenigen bisherigen Infos ist weder die Machbarkeit noch der Zeitaufwand
abschätzbar.
> Es sollte mit ESP32 OLED LoRa umgesetzt werden. Andere Hardware ist> aber auch vorhanden.
Diese ESP Module sind samt Firmware mit der heißen Nadel zusammen
gestrickt. Ich würde auf keinen Fall das damit verbundene geschäftliche
Risiko tragen wollen.
Stefanus F. schrieb:> Entwicklung lohnt sich nur, wenn die Kosten später durch> Massenproduktion wieder rein geholt werden oder wenn Geld keine Rolle> spielt.
... ist rein privat.
Stefanus F. schrieb:> Diese ESP Module sind samt Firmware mit der heißen Nadel zusammen> gestrickt. Ich würde auf keinen Fall das damit verbundene geschäftliche> Risiko tragen wollen.
... damit kann ich wenig anfangen. Entweder die Dinger funktionieren
oder nicht. Wie gesagt, kein geschäftliches Risiko, da privat.
Stefanus F. schrieb:> Stelle deine Anforderungen zusammen und frage dann nochmal. Mit den> wenigen bisherigen Infos ist weder die Machbarkeit noch der Zeitaufwand> abschätzbar.
Anforderungen: Drei LoRas mit angeschlossenen Lichtschranken sollen per
866mhz eine auf einem weiteren LoRa laufende Stoppuhr steuern.
Ob es nun LoRas sind oder Wifi genutzt wird ist eigentlich egal. Es soll
einfach nur funktionieren :-)
VG Hardy
Philipp M. schrieb:> Du kannst natürlich deine 8xxMHz-Module nehmen und jeden> Lichtschrankendurchlauf sofort senden.
Senden kannst du schon, aber ob da beim Empfänger ankommt, steht auf
einem anderen Blatt. Funk ohne genauen Timestamp wird nichts.
my2ct schrieb:> Dann stehst du aber ganz gewaltig auf dem Schlauch, ...
Hardy schrieb:> Anforderungen: Drei LoRas mit angeschlossenen Lichtschranken sollen per> 866mhz eine auf einem weiteren LoRa laufende Stoppuhr steuern.
Das genügt nicht, um den Arbeitsaufwand einzuschätzen. Ich sehe das das
gesamte Projektkonzept noch zu erstellen ist. Wenn der ESP Chip oder
seine Firmware versagt, was dann? Willst du dann die Bezahlung
verweigern oder kommst du damit klar?
Ich schätze, du bist nicht bereit, einige tausend Euro auszugeben,
richtig? Nenne mal eine konkrete Zahl, wie teuer das maximal werden
darf.
Bei einigen tausend Euro wäre ich sicherlich nicht hier in diesem
Forum.
Also es scheint mir, als wäre das ein kaum umzusetzendes Projekt zu
sein.
Sparen wir nun alle unsere Zeit und belassen es dabei..
Vielen Dank allen Mitstreitern.
Hardy schrieb:> Bei einigen tausend Euro wäre ich sicherlich nicht hier in diesem> Forum.>> Also es scheint mir, als wäre das ein kaum umzusetzendes Projekt zu> sein.>> Sparen wir nun alle unsere Zeit und belassen es dabei..
Manchmal muss eben auch die Vernunft siegen.
Ein professionelles System mit 4 Sendern und 1 Empfänger kostet hier
1300 EUR:
http://www.sport-zeitmessung.ch/?Produkte:Funk_-_Kabellose_Zeitmessung:Funk%26uuml%3Bberagung_HL_615
Günstiger wird eine Eigenentwicklung auf keinen Fall.
Hardy schrieb:> Also es scheint mir, als wäre das ein kaum umzusetzendes Projekt zu> sein.
Mach bar ist es schon, aber es wird sich wie gesagt nur in
Serien-Produktion lohnen, denn der Entwicklungsaufwand* wird mit
Sicherheit mehr als 4 Wochenenden x 2 Personen sein.
*) nicht nur Programmierung, sondern auch die Planung.
Hardy schrieb:> Also es scheint mir, als wäre das ein kaum umzusetzendes Projekt zu> sein.
Na ja, wenn man von einem Tütchen Haribo ausgeht muss man da natürlich
enttäuscht werden. Entwickler können von Gummibärchen langfristig nicht
leben.
Einfach falsches Forum.
Georg
my2ct schrieb:> Für die Funkübertragung sollte man LoRa in Erwägung ziehen
LoRa ist für diese Anwendung absolut nicht geeignet!
1. Duty Cycle per Regolatorium ist einzuhalten. Bei 868MHz ist 1%
definiert. Wenn du z.B. ein Frame mit Übertragungsdauer 0.5s versendest,
darfst du während 49.5s nichts mehr über den selben Node senden.
2. Es wird nicht gewährleistet, dass die versendeten Pakete auch
tatsächlich ankommen (Stichwort: Packet loss, collision)
3. Lange Übertragungsdauer für diese Anwendung vermutlich nicht
erwünscht. (Bei SF12 250b/s, bei SF7 11'000b/s)
Mick schrieb:> my2ct schrieb:>> Für die Funkübertragung sollte man LoRa in Erwägung ziehen>> LoRa ist für diese Anwendung absolut nicht geeignet!
Du hast das Prinzip nicht verstanden.
Du kannst in dem Frequenzband wegen nicht exklusiver Nutzung keine
Echtzeitanforderungen erfüllen. PUNKT
Also muss jede Messstation über eine ausreichend genaue Uhr verfügen
(z.B. GPS-gestützt), um bei einem Lichtschrankenereignis einen
Zeitstempel speichern zu können. Genau dieser Zeitstempel wird dann, im
Prinzip irgendwann - notfalls per reitendem Boten - an die Hauptstation
weitergeleitet. Und wenn die Hauptstation sie nicht verstanden hat,
fragt sie nach.
Die Übertragung der Daten ist dann von jeglichen Echtzeitanforderungen
befreit. Und jetzt erkläre nochmal, wo du da Probleme mit LoRa siehst.
> Duty Cycle per Regolatorium ist einzuhalten. Bei 868MHz ist 1%> definiert.
Das ist Unsinn. Lies dir mal die Vfg 30/2014 der Bundesnetzagentur und
die zugehörigen Änderungen genau durch.
my2ct schrieb:> Das ist Unsinn. Lies dir mal die Vfg 30/2014 der Bundesnetzagentur und> die zugehörigen Änderungen genau durch.
Und bitte, was steht da?
Mick schrieb:> Und bitte, was steht da?
aus Vfg 30/2014, geändert mit Vfg 36/2014, geändert mit Vfg 69/2014:
"Es sind Frequenzzugangs- und Störungsminderungstechniken einzusetzen,
deren Leistung mindestens den Techniken entspricht, die in den gemäß
Richtlinie 1999/5/EG bzw. des FTEG verabschiedeten harmonisierten Normen
vorgesehen sind.
Alternativ kann ein maximaler Arbeitszyklus von 1% verwendet werden."
Die 1% DC-Beschränkung gilt nur, wenn man sich mit seiner Sendetechnik
nicht an die genannte Richtline halten möchte.
