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
Wenn Du meinst, dass es dafür hier schon mal eine Anl. gegeben hat,dann verlinke mir das bitte. ich hab nichts dazu gefunden.
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.
Karl schrieb: > 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. Wohl weil Start, Zwischenzeit und Ziel weit auseinander liegen dürften. Als Lichstchranken am einfachsten sowas: https://www.conrad.de/de/lichtschranke-bausatz-kemo-b213-9-vdc-12-vdc-50-m-117536.html?WT.mc_id=google_pla&WT.srch=1&ef_id=WUfGjQAAAGlU-TDx:20180801015343:s&gclid=CjwKCAjwkYDbBRB6EiwAR0T_-vxJ7knOD8tyyjAXyuGrSoXLV5CsaiMqg6gLKo8COMNK6JdXgLB4JhoC9zsQAvD_BwE&hk=SEM&insert_kz=VQ&s_kwcid=AL!222!3!254339639483!!!g!! und das Relais genau so verwenden wie einen Schalter oder Taster am Raspberry (dazu gibt es 1001 Tutotrials im Netz). Wlan wirst du einfach die Daten auf der grafischen Oberfläche eintragen. Betriebssystem kannst du beim Standard Raspbian bleiben. Auf dem vierten, oder einen der 3 Raspis muss ein Webserver laufen auf den die anderen über das Netzwerk zugreifen und die Zeit senden. Also eine einfache Webseite die auf den Zugriff durch die anderen Raspis reagiert. Auch dazu gibt es etliches im Netz. Ganz ohne Vorwissen wird das allerdings ein langwieriges Projekt.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Andreas B. schrieb: > 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. Die Latenz ist auch nicht direkt relavant. Alle Raspis so synchronisieren: https://www.logicals.com/de/forum/raspberry-pi/48-aktuelle-uhrzeit-aus-dem-internet-holen Und dann die Zeit als Text oder ähnliches senden!
:
Bearbeitet durch User
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.
Ersteinmal vielen Dank für die Infos und Tipps! - Die Genauigkeit sollte schon 1/100 betragen. - Dass mit der abgespeckten Raspian-version bekomme ich bestimmt hin.(Welche Komponenten müssen denn zwingend installiert sein?, Apache,...) -NTP Synchronisierung bekomme ich hin. Alex G. schrieb: > Als Lichstchranken am einfachsten sowas: > https://www.conrad.de/de/lichtschranke-bausatz-kemo-b213-9-vdc-12-vdc-50-m-117536.html?WT.mc_id=google_pla&WT.srch=1&ef_id=WUfGjQAAAGlU-TDx:20180801015343:s&gclid=CjwKCAjwkYDbBRB6EiwAR0T_-vxJ7knOD8tyyjAXyuGrSoXLV5CsaiMqg6gLKo8COMNK6JdXgLB4JhoC9zsQAvD_BwE&hk=SEM&insert_kz=VQ&s_kwcid=AL!222!3!254339639483!!!g!! - Bei der Lichtschranke von Conrad müssen doch beide verkabelt werden, wenn ich das so sehe.Da wäre mir eine Reflexionslichtschranke mit Reflektor lieber wo nur 1 Seite verkabelt wird oder sehe ich das falsch? -Strom sollte das ganze System mit Powerbänken für Raspis beziehen. Oder andere Vorschläge? LG Hardy
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.
:
Bearbeitet durch User
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:
1 | $ uptime |
2 | 14:47:45 up 172 days, 1:07, 1 user, load average: 0.00, 0.00, 0.00 |
3 | $ ps axu | grep -v ' 0:00 ' |
4 | USER PID %CPU %MEM VSZ RSS STAT START TIME COMMAND |
5 | root 1 0.0 0.7 3752 1768 Ss Feb11 4:45 init [3] |
6 | root 3 0.0 0.0 0 0 S Feb11 4:25 [ksoftirqd/0] |
7 | root 4 0.0 0.0 0 0 S Feb11 38:35 [kworker/0:0] |
8 | root 8 0.0 0.0 0 0 S Feb11 2:34 [watchdog/0] |
9 | root 11 0.0 0.0 0 0 S Feb11 0:06 [khungtaskd] |
10 | root 83 0.0 0.0 0 0 S Feb11 0:05 [jbd2/sdb1-8] |
11 | root 96 0.0 1.3 22892 3192 Ssl Feb11 0:04 /usr/sbin/rsyslogd |
12 | ntp 107 0.0 1.2 8056 3100 Ssl Feb11 102:23 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 108:112 |
13 | 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 |
3 | ========================================================================== |
4 | +212.18.3.19 212.18.1.106 2 u 38 512 377 8.186 1.035 0.824 |
5 | 176.9.40.142 30.20.35.61 2 u 22h 512 0 17.920 1.411 0.000 |
6 | 192.9.200.43 192.9.200.44 3 u 14 64 377 0.307 -0.801 0.109 |
7 | *127.127.20.0 .GPS0. 1 l 58 64 377 0.000 -0.341 0.521 |
8 | 127.127.1.0 .LOCL. 11 l 172d 64 0 0.000 0.000 0.000 |
:
Bearbeitet durch User
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-system http://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
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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 :)
:
Bearbeitet durch User
Vielen Dank. Werde es, wenn es mit dem Kabel komplett fertig ist, dann auf jeden Fall mal drahtlos angehen.... Kann aber etwas dauern. LG Hardy
Joe F. schrieb: > Und wie weit reicht das in Metern? Hinweis: Für meine geplante Anwendung würden 50m reichen.
Dann ist WLAN ja schon raus aus dem Rennen. Jedenfalls mit "normalen" Mitteln.
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.
Konnte mir schon denken, dass das Akkus sind. (Google) Wie begrenzt ist denn die Reichweite Meinung nach? Evtl mit Antennen ausstatten? Gruß Hardy
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
:
Bearbeitet durch User
> Was käme denn sonst noch dazu?
Ich denke, das ergibt sich aus einem detaillierten Plan.
Beitrag #5544632 wurde vom Autor gelöscht.
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.
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.