Projekt Simple Chrony

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Für alle, die schon in Bastellaune sind.

      Um später jederzeit exakt messen zu können, ist eine Kalibrierung des Chrony wünschenswert. Mittels eines Arduino UNO Bards habe ich einen kleinen Calibrator aufgebaut. Dieser erzeugt eine endlose Schussfolge im 10 Sekunden Abstand mit einer Zeit von exakt 555 Mikrosekunden. Das entspricht bei einer Messstrecke von 10 cm einer Geschwindigkeit von 180.18 m/s. Auch die Impulslänge, beim Durchgang durch eine Lichtschranke, entspricht mit 20 Mikrosekunden der Abschattung durch ein Diabolo bei 180 m/s. Somit wird mit dieser Schaltung eine reproduzierbare realistische Schussfolge erzeugt.
      Ausgangspins zum kalibrieren:

      Lichtschranke 1: PORT C0 (A0-Arduino)
      Lichtschranke 2: PORT C1 (A1-Arduino)
      Quarzfrequenz: 16 MHz

      Im Anhang mal zwei Bilder dazu. Im ersten Bild die Schaltung mit angeschlossenen Tastköpfen, im zweiten Bild eine Messung auf dem Oszi. Weiterhin gibt es dasCalibrator.zip zum Testen und den Calibrator.pdf zum Verstehen.

      Gruß Joe



    • Für die erste Stufe ist ein Rohr (Durchmesser ca. 60mm – 80mm) geplant. Konkrete Versuche an größeren Durchmessern würde ich durchführen, wenn die Leiterplatten bestückt sind. Mein Laboraufbau auf dem Schreibtisch ist für Feldversuche nicht geeignet. Vorstellbar ist auch ein modularer Aufbau. Die Lichtschranken als separate Einheiten über einen Steckverbinder. So könnten die Bedürfnisse nach Pfeilen oder auch GK besser befriedigt werden. Aber immer ein Schritt nach dem anderen…
    • Der Kalibrator ist eine sehr gute Idee.
      Ist es ausreichend, den einen Kalibrierwert für alle Messbereiche anzuwenden oder könnte man leicht auch eine Kalibrierung im oberen Mesbereich einstellen?
      Gäbe der Arduino das her?
      Ich bin mittlerweile doch stark interessiert an dem Teilchen!
      Bin schon massiv gespannt auf den Prototypen.
    • Ein Kalibrierpunkt ist ausreichend. Zum theoretischen Hintergrund:
      Die Zeitbasis des Messsystems ist fest. Die kleinste Zeiteinheit beträgt 62.5 ns. Mit dieser Zeitbasis zählt der Zähler zwischen den zwei Lichtschrankenauslösungen. Die Software hat jedoch aufgrund der endlichen Zeit der Befehlsabarbeitung eine Latenzzeit zur Erfassung des Zählerstandes. Diese Latenzzeit muss durch die Kalibrierung einmalig erfasst werden. Ich überdenke gerade eine automatisierte Kalibrierroutine. Einmal Knopf drücken – fertig. Ansonsten kann im Calibrator natürlich jede andere Zeit eingestellt werden. Also auch viel höhere Geschwindigkeiten.
    • Feinmechaniker schrieb:

      Ein Kalibrierpunkt ist ausreichend. Zum theoretischen Hintergrund:
      Die Zeitbasis des Messsystems ist fest. Die kleinste Zeiteinheit beträgt 62.5 ns. Mit dieser Zeitbasis zählt der Zähler zwischen den zwei Lichtschrankenauslösungen. Die Software hat jedoch aufgrund der endlichen Zeit der Befehlsabarbeitung eine Latenzzeit zur Erfassung des Zählerstandes. Diese Latenzzeit muss durch die Kalibrierung einmalig erfasst werden. Ich überdenke gerade eine automatisierte Kalibrierroutine. Einmal Knopf drücken – fertig. Ansonsten kann im Calibrator natürlich jede andere Zeit eingestellt werden. Also auch viel höhere Geschwindigkeiten.
      Häh??? Das verstehe ich überhaupt nicht. Wieso muss ich die Verarbeitungszeit für die Lichtschrankenauslösung kalibrieren? Die sollte doch symmetrisch sein und damit für beide Lichtschranken die selbe Verschiebung auf der Zeitachse bedeuten?
      Der Hardwaretimer des Mega48 kann das doch schon fast im Selbstlauf.
      Könnte es sein das du den SimpleChrony ein wenig zu kompliziert strickst?
      Dich interessieren doch für die Zeitmessung entweder die steigenden oder die fallenden Flanken. Darauf würde ich differenzieren und das dem Counter zur Verfügung stellen. Wenn du die Durchgangszeit durch eine Lichtschranke messen willst, könntest du auch aber dann brauchst du auch nur eine Lichtschranke, dann und nur dann brauche ich wegen der unterschiedlichen Flanken, steigend oder fallend, eine Korrektur der Zeitabhängigkeiten.
      Oder verstehe ich da was völlig falsch? Ooh, zählst du etwa in Software? 8|
    • WhiteSAndS schrieb:

      Der Hardwaretimer des Mega48 kann das doch schon fast im Selbstlauf.
      Könnte es sein das du den SimpleChrony ein wenig zu kompliziert strickst?
      In der Schaltung sind beide Lichtschranken nicht mit einem ODER verknüpft. Das bedeutet, jede Lichtschranke geht an einen Pin am AVR. Zum Zählen wird der Timer1 verwendet. Lichtschranke 1 startet den Timer1 in einer ISR1 und Lichtschranke 2 löst ein Interrupt am Timer1-Capture-Pin aus. Somit kann davon ausgegangen werden, dass das Captureregister im Timer1 exakt (nicht zeitverzögert) ausgelesen wird. ISR1 benötigt jedoch einige Takte um selbst in ISR1 zu springen und den Timer1 Start auszulösen. Genau diese Zeit hängt vom Quarztakt ab und ob noch gerade eine andere ISR (z.B. USB oder LCD) ausgeführt wird. Nun können während der Messung die anderen ISR’s deaktiviert werden, bleibt jedoch immer noch die Latenzzeit zum Einsprung in die ISR.

      Die ISR fängt mit dem Start des Befehls nach dem Setzen des ISR-Flags an (minimal 4 Zyklen).
      Dabei beinhalten die minimal 4 Zyklen auch die Ausführung des nächsten Befehls mit (1 Zyklus). Benötigt der Befehl mehrere Zyklen, dauert es halt länger. Wenn das Flag gesetzt wird, wird also der zur Zeit laufende Befehl fertig abgearbeitet, ebenso der darauf folgende. Dann wird der ISR-Vector angesprungen. Da einzelne Befehle zwischen einem und drei Zyklen benötigen, dauert das ganze also zwischen 4 und 8 Zyklen. Dazu kommt dann noch die Ausführung des Sprungbefehls rjmp in der ISR-Tabelle mit nochmal 2 Zyklen (Summe 6 bis 10 Zyklen). 6 bis 10 Zyklen nach setzen des ISR-Flags ist man also erst am Beginn einer ISR-Routine. Hier kommen nochmals die Compilerabhängigen POP und PUSH Routinen dazu. Da ist man schnell über 1 Mikrosekunde. Das macht bei GK (so auch hier der Wunsch) schnell einen Messfehler von 1-2% aus.

      Eine Lösung ohne Kalibrierung müsste beide Lichtschrankensignale ODER verknüpfen und nur auf den Timer1-Capture-Pin führen. Macht halt ein zusätzliches Gatter notwendig. Genau das wollte ich einsparen.

      Möglicherweise hast du jedoch noch einen besseren Lösungsvorschlag.
    • Ähem, ja, schon mal daran gedacht das dieses besch...eidene Chrony nur eine einzige timingabhängige Funktion hat und zwar die Takte zwischen den Lichtschrankenauslösungen zu zählen? Welche anderen Interrupts sollen denn da eine Rolle spielen?
      Du liebst Interrupts, oder? Wenn du ein Betriebssystem stricken möchtest in dem es Funktionen gibt die halbwegs gerecht, was ist schon gerecht, Zeit zugeteilt bekommen sollen dann kannste das machen. Wenn ich etwas messen will dann geht die ganze Zeit an die einzige Funktion die das machen soll. Nix anderes. Alles was berechnet oder ausgegeben werden soll kann nach dem Schuss erfolgen. Selbst bei Dauerfeuer wirst du keine Schussfolge erzeugen können die das einschränkt und Dauerfeuer darfste eh nicht. Nicht in DE und macht echt auch kaum Sinn es sei denn du willst die Feuerrate messen.
      Apropos Interrupt, es gibt auch die Möglichkeit Interruptroutinen ohne Push und Pop zu schreiben nämlich immer dann wenn du keine Register veränderst, zumindest nicht gewollt, oder wenn du sie mit Absicht änderst weil du sie ausserhalb der ISR auswerten möchtest. Damit bekommst du eine recht feste Anzahl an Takten für die verzögerte Reaktion auf den Interrupt. Um genau zu sein, man kann sie im Debugger auszählen oder natürlich anhand der Befehlstabelle ausrechnen. Selbst bei Polling würde man mit 6-8 Takten auskommen.
      Was das für einen Fehler ausmachen würde kannste ja mal ausrechnen.
      Nehmen wir mal an wir haben eine v0 von 10km/s. Das sind etwa 10*1000*10=100 000dm/s wenn die Messdistanz 10cm oder 1dm ist. Bei einem Takt von 16MHz ohne Vorteiler haben wir 16 000 000 Takte pro Sekunde. Das heisst wir haben 160 Takte pro 1dm (10cm). Das macht pro Takt einen Fehler von 0,625%.
      Wohlgemerkt, das wäre bei der v0 einer Railgun.
      Bei den bei uns üblichen Feuerwaffen mit einer v0 von etwa 2000m/s ist das dann der Faktor 5 mehr Zeit oder eben kleinerer Fehler.
      Wenn du es schaffst da einen Fehler von 1% zu produzieren hast du eh ein grundlegendes Problem in deinem Konzept und mal davon abgesehen ist es wahrscheinlich sogar besser bei Feuerwaffen die hintere Flanke für die Messung zu nehmen weil durch die Form des Projektiles und die Taumelbewegung nach dem Verlassen des Rohres nicht garantiert ist das beide Lichtschranken gleich abgedeckt werden. Am Geschossboden eher schon.
      Wie auch immer, ich bin dann mal raus aus dieser Geschichte.
    • WhiteSAndS schrieb:

      Ähem, ja, schon mal daran gedacht das dieses besch...eidene Chrony nur eine einzige timingabhängige Funktion hat und zwar die Takte zwischen den Lichtschrankenauslösungen zu zählen?

      Danke für die konstruktive Kritik!
      Dann mache ich mal den folgenden Vorschlag:
      Als Feinmechaniker ist meine Affinität zur Software geringer als zur Hardware. Ich würde also deine geballte Kompetenz auf dem Gebiet der AVR-Programmierung gerne für das Projekt nutzen. Vielleicht schreibst du ein kleines Rahmenprogramm (nur die Routinen zur Zeiterfassung) und stellst sie hier der Allgemeinheit zur Verfügung. Gerne darfst du dabei auch die hintere Flanke der Lichtschranken verwenden. Anbei nochmals die Schaltung, damit du gleich die richtigen Anschlusspins für die Software verwendest.
      Danke!

      Schaltplan: Chrony_V1.0.pdf
    • Aah, Bananenware!

      Aber klar doch. Du hattest ja schon die tolle Idee. Die kleinen Problemchen können ja dann andere lösen.
      Soll ich auch gleich noch ein Gehäuse auf meine Kosten entwerfen und bauen lassen? Projekt-Managment und Wartung wäre dann natürlich auch besser in meiner Hand aufgehoben.

      Nee, lass mal. Mach mal am besten gleich ein Kickstarter-Projekt daraus.
    • WhiteSAndS schrieb:

      Aah, Bananenware!

      Aber klar doch. Du hattest ja schon die tolle Idee. Die kleinen Problemchen können ja dann andere lösen.


      Sorry, wir missverstehen uns gerade! Ich möchte nicht die Probleme von dir gelöst haben. Ich bat dich lediglich um deinen Vorschlag zu einer kurzen Routine für die Abfrage beider Lichtschranken. Kein Gehäuse, kein Projektmanagement, keine Wartung … Dabei reflektierte ich auf deine Kompetenz zur AVR-Programmierung, Zitat:

      „Der Hardwaretimer des Mega48 kann das doch schon fast im Selbstlauf.“

      Damit du siehst, dass ich mir selbst bereits Gedanken dazu gemacht habe, die folgenden Randbedingungen für den „fast Selbstlauf“ des Timers:
      1. Messroutine darf nicht in einer Endlosschleife laufen, muss also immer abgebrochen werden können.
      2. Fehlmessungen müssen detektiert werden, konkret:
        • Lichtschranke 1 löst aus, Lichtschranke 2 nicht
        • Lichtschranke 1 löst nicht aus, jedoch Lichtschranke 2
        • keine Lichtschranke löst aus
        • Lichtschranke 1 löst auf der hinteren Flanke aus, Lichtschranke 2 auf der vorderen Flanke
      3. Alle Varianten müssen immer exakt die gleiche Latenzzeit besitzen.
      Was meinst du, kommen wir nun zusammen?
    • Es gibt relativ sauberen und echt durchdachten Quelltext in Bascom für ein Eigenbauchrony. Die Lichtschrankenhardware würde ich so wie dort zwar nicht bauen aber der Quelltext ist gut. Suche ich bei Gelegenheit raus.
      Verwendet wird der SBIS bzw. der SBIC Befehl des AVR.
      ww1.microchip.com/downloads/en…nstruction-set-manual.pdf
      und für alle die besser deutsch als englisch können so wie ich:
      avr-asm-tutorial.net/avr_de/beginner/sprung.html#SBICS

      Das wäre der einfachste Ansatz ohne Interrupts und mit geringem Overhead.

      Tatsächlich wird ein Interrupt als Watchdog benutzt aber der ist für die eigentliche Funktion nur dann wichtig wenn was schief geht.



      Im wesentlichen wird der Programmablauf an der Lichtschranken 1 Abfrage so lange gestopt bis der Pin das korrespondierende Signal erhält, der Counter wird ausgelesen und gerettet und an der Abfrage der Lichtschranke 2 gewartet bis das passende Signal am Pin kommt. Kommt das passende Signal nicht,

      weil der Diabolo rückwärts geflogen ist oder es doch nur eine schnell fliegende Eintagsfliege war, klärt der Watchdog die Situation gibt eine Fehlermeldung aus und alles geht von vorne los.

      Hat man tatsächlich zwei passende Signale erhalten wird berechnet und wenn das fertig ist ausgegeben.

      Und dann alles wieder von vorne.


      Das einzige zeitkritische ist zwischen Signal 1 und 2 und da macht der Prozessor nix anderes aber auch gar nix anderes als auf das Signal warten. Der Watchdog läuft unabhängig im Hintergrund im Timer und braucht keine Prozessorzeit. Wenn er dann doch welche braucht wegen des Timeouts ist es eh egal weil etwas schief gegangen ist also auch nix zeitkritisches mehr kommen kann.


      Und ja, das geht auch mit Interrupts. Wenn man weiss warum Interrupts nicht das Allheilmittel sind und dementsprechend drum herum programmiert. Konkurierende Interrupts sind für zeitabhängige Programmierung wegen der mangelnden Vorhersagbarkeit der Ereignisse Mist.

      Sauber programmiert mit Interrupts würde man den Programmablauf an den Lichtschrankenabfragen in einer Schleife fangen die nur durch die passenden Interrupts verlassen werden können. Letztendlich hätte man das Beispiel ohne Interrupts nur komplexer mit Subroutinen nachgebaut.

      Wie gesagt, kann man machen muss man aber nicht aber wenn man es macht muss man es sauber programmieren.

      Eine andere Möglichkeit ist die Nutzung der ICU. Die kann praktisch im Alleingang externen Ereignissen Timestamps verpassen und da wir ja wissen aus welcher Richtung die Diabolos durch die Lichtschranken fliegen...also hoffentlich wissen wir das...
      ww1.microchip.com/downloads/en…_TOC_PROCESSING_d94e18652
      oder falls das nicht funktioniert:
      ww1.microchip.com/downloads/en…R-ATmega32A_Datasheet.pdf

      Punkt 19.6 Input Capture Unit

      Meiner persönlichen Meinung nach kommt hier aber sehr schön heraus warum komplexe Programmierumgebungen wie die Arduino IDE gerade bei solchen kleinen Wunderwerken wie den AVRs den Blick auf das Wesentliche versperren weil viele Sachen durch Abstraktion abgenommen werden und der direkte Durchgriff auf die Hardware verschleiert wird. Die tatsächlichen Eigenschaften der Hardware werden gar nicht mehr wahr genommen.
      Ein bisschen hardwarenah programmiert konnte das geforderte nämlich schon der AT90S2313 und selbst die etwas grösseren ATtinys schaffen das mit, zugegebener Massen, einem erhöhten Programmieraufwand auch weil man um die serielle Schnittestelle herum programmieren musste und der Counter etwas beschränkt ist.
      Letzter Punkt, ich finde das mit den Anzeigen im Gerät immer ein bisschen gaga. Der Ansatz ist oft das das Gerät "self contained" also für sich alleine arbeiten können soll. Letztlich baut aber jeder Hersteller der auf sich hält eine serielle oder USB Schnittstelle ein die entweder vom PC oder Smartphone aus abfragbar ist. Warum wohl? Weil ich eh die Schussfolge irgendwo speichern will und ein dedizierter Drucker ein bisschen Oberkante ist? Weil ich ein Smartphone in der Regel wesentlich besser ablesen kann und die Werte auch übersichtlicher dargestellt werden können? Weil die Berechnungen viel besser dort aufgehoben sind wo ich die notwendigen Daten auch besser eingeben, speichern und wesentlich komplexere Berechnungen in viel kürzerer Zeit ausführen kann? Weil es aus sicherheitstechnischen Erwägungen blöd ist wenn man mal nicht die v0 sondern die v10, v25 oder v50 will und nicht immer warten möchte bis man zum Gerät laufen darf oder die anderen Schützen dann genervt sind?

      Rausgesucht: nutsvolts.com
      nutsvolts.com/uploads/magazine…Ballistic_Chronograph.zip
      nutsvolts.texterity.com/nutsvolts/200906/?pg=36#pg36

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von WhiteSAndS ()

    • Vielen Dank für deinen Beitrag!
      Zunächst möchte ich meinem Gefühl etwas Raum geben. Ich musste schon schmunzeln über deinen Beitrag. Zunächst in dieser Diskussion als Riese gestartet und nun als Zwerg gelandet. Warum?

      Ich bat um eine mögliche Zuarbeit /Zusammenarbeit bezüglich einer ganz konkreten einfachen Programmieraufgabe. Was bisher kam waren Links auf Datenblätter des AVR, ein unschön programmiertes Bascom Programm eines fremden Beitrages, ein Statement zur Programmierung und der Hinweis auf die Hardware im Timer1. Zusammengefasst – NICHTS. Doch im Einzelnen:

      Das BASCOM Programm führt bei der Messung ein permanentes Polling von PB0 – PB2 durch. Lichtschranke 1 startet Timer1, Lichtschranke2 liest Timer1 im Polling, Lischranke3 auch. Das ganze in einer Polling-Routine „Shoot“ bei der der Auslösezeitpunkt einer Lichtschranke durch den Hochsprachenbefehl „Bitwait Pinb.0 , Set“ irgendwann in der Routine abgefragt wird. Das ist wohl mehr als ungenau und undefiniert.

      Den zweiten Hinweis zur Input Capture Unit verstehe ich nicht. Wenn du meine Schaltung und meine Erklärungen gelesen hättest, würde dir aufgefallen sein, dass ich es genau so mache. Die erste Lichtschranke startet den Timer1, und zwar genau definiert. Die zweite Lichtschranke liest den Counter aus der Timer Capture Logik mittels Timer capture Interrupt.

      Das Statement zur Arduino IDE verstehe ich auch nicht. Ich habe an keiner Stelle erklärt sie zu verwenden. Ich programmiere absolut Hardwarenah!

      Kleine persönliche Anmerkung am Rande:
      Bevor man unsachliche Kritik in die Runde wirft, sollte man sich mit der Kompetenz des zu Kritisierenden auseinander setzen. Auch wenn als Name „Feinmechaniker“ bei mir erscheint (ich habe diesen Beruf tatsächlich vor 39 Jahren erlernt), bedeutet das nicht, dass ich mich nicht weiterqualifiziert habe. Heute versuche ich jungen Menschen strukturiertes Arbeiten zu vermitteln, damit sie nicht solchen Unsinn wie in deinem letzten Beitrag verbreiten.
      mb.eah-jena.de/page/de/fachgeb…chatronik/studium/aktuell

      An Kompetenz entsprechende Hardware und Softwarethemen zu realisieren, fehlt es mir auch nicht.
      mikrocontroller.net/topic/354785?page=1
      mikrocontroller.net/topic/329265?page=1

      Darüber hinaus bin ich jederzeit bereit konstruktiv zusammenzuarbeiten und kritische Ratschläge zu diskutieren.