Projekt Simple Chrony

Hätte auch Interesse...egal ob selbst löten oder fertig bestückt....

Die Elektronik ist ja eine wichtige Sache, aber wie ist der mechanische Aufbau geplant? Der Durchschusskanal sollte so groß wie möglich sein, damit man auch Pfeile durchschießen könnte.

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.

Zitat von Feinmechaniker

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?

Ä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.

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.

Diese Argumentation kommt mir verdächtig bekannt vor.
Laut Trommeln und wenn´s an´s Eingemachte geht kneifen....

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.
http://ww1.microchip.com/downloads/en/d…-set-manual.pdf
und für alle die besser deutsch als englisch können so wie ich:
http://www.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...
http://ww1.microchip.com/downloads/en/D…SSING_d94e18652
oder falls das nicht funktioniert:
http://ww1.microchip.com/downloads/en/D…A_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
http://www.nutsvolts.com/uploads/magazi…Chronograph.zip
http://nutsvolts.texterity.com/nutsvolts/200906/?pg=36#pg36

Zitat von Flitzpiepe

Strike!

Ja, sollte man meinen. Nicht wahr?

Aber vielleicht auch ein wundervolles Eigentor... wer weiss...

... und ich möchte das hier was positives für uns Laien herauskommt