Beiträge von WhiteSAndS

    ...und um mal das Thema Kamera über Funkstrecke und Long Range abzuhandeln, entgegen der Bastelei von CommerzGandalf würde ich zu einer 5GHz Bridge mit zwei locoM5 von Ubiquiti tendieren. Die sind perfekt legal, einfach in der Anwendung und haben eine hohe Transferrate. Beide Stationen schön hoch montieren so das die Fresnellzone1 frei bleibt, ist entfernungsabhängig, und schon kann man seine Kamera locker bis 300m weit weg aufstellen. Kostet auch nur so ab 110€ für ein Pärchen.

    Kein Antennenbasteln und kein Softwareschrauben.

    Wegen der überwältigenden Resonanz habe ich das Projekt mal nach Github Mikrosko-Pi transferiert. Dort liegen auch ein paar fix und fertig Images aber noch keine tiefergehenden Beschreibungen.
    Wer Lust hat das mal auszuprobieren hat 3 Möglichkeiten:
    1. entsprechend der hier hinterlegten Informationen per Hand alles schön selber eintippern
    2. entsprechend der auf Github hinterlegten Skripte und Packages ein selbst downgelodetes Raspbian Buster lite selbst vorkonfigurieren
    3. eines der vorkonfigurierten Images mit Balena Etcher auf eine mindestens 4GB große uSD packen, in den Raspi stecken und booten und wenn am Raspi eine Kamera angeschlossen ist und niemand die Selbstzerstörungssequenz ausgelöst hat sollte nach dem zweiten Boot alles gut sein....wenn nicht, License lesen und selbst Abhilfe schaffen.

    Falls bis hierher alles geklappt hat, und ich zweifele nicht daran, dann werden wir jetzt das System so anpassen das es automatisch nach dem booten in Tarpi landet.

    Weil es häufig vorkommt das man am Skript rumschraubt, man die alten Skripte aus Sentimentalität oder zur Sicherheit behalten möchte man aber nicht überall den Aufruf anpassen möchte erzeugen wir uns einen verallgemeinernden Link auf das Skript mit:

    Code
    ln tarpiXXX.py tarpi.py


    Wenn es eine neue Version gibt wird einfach nur der Link angepasst, alles andere funktioniert aber wie zuvor.
    Da es störend ist bei jedem Boot das Passwort eingeben zu müssen aktivieren wir mit raspi-config

    Code
    sudo raspi-config

    die Autologin-Funktion:

    Code
    # 3 Boot Options         Configure options for start-up 
    #       B1 Desktop / CLI            Choose whether to boot into a desktop environment or the command line 
    #             B2 Console Autologin Text console, automatically logged in as 'pi' user

    Jetzt würden wir nach jedem Boot bereits eingeloggt auf der Shell landen. Das ist gut aber wir wollen ja das Tarpi automagisch startet also editieren wir die sich im Nutzerverzeichnis befindliche .profile mit nano:

    Code
    nano .profile

    und hängen dort ganz ans Ende folgendes an:

    Code
    #Autostart von Tarpi auf der lokalen Console
    if ! [ -n "$SSH_CLIENT" ] && ! [ -n "$SSH_TTY" ]; then
      ./tarpi.py
    fi

    Das würde bereits genügen um Tarpi zu starten aber wir möchten auch noch das Numlock auf dieser Konsole aktiviert wird also editieren wir auch noch die .bashrc:

    Code
    nano .bashrc

    und hängen hier ans Ende:

    Code
    #Tastatur NumLock setzen
    setleds -D +num

    Ganz Mutige können jetzt neu booten und hoffen das jetzt sofort nach dem Start Tarpi läuft. Wenn nicht, es gibt ein schönes langes Wochenende zum debuggen....

    Heute beschäftigen wir uns damit ein laufendes System zu erzeugen.

    Als erstes eine aktuelle Version von Raspbian Buster lite von der offiziellen Homepage:

    Raspbian Buster Downloadpage

    und folgen der Anleitung von der offiziellen Anleitungsseite:

    Installation How to

    Wenn ihr mit Balena etcher arbeitet müsst ihr noch 2 Sachen machen:

    1. die uSD Karte kurz aus dem Reader entfernen und neu einlegen
    2. in der Boot-Partition folgende Änderungen durchführen:
    -wenn ihr nur über SSH auf den PI zugreifen wollt müsst ihr eine leere Datei "ssh" erzeugen
    -wenn ihr nur über WLan auf den PI zugreifen könnt müsst ihr eine Datei "wpa_supplicant.conf" mit folgendem Inhalt:

    Code
    country=DE
    ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
    update_config=1
    network={
           ssid="wlan-bezeichnung"
           psk="passwort"
           key_mgmt=WPA-PSK
    }

    in der Bootpartition erzeugen.
    Das funktioniert aber nur wenn der Editor in der Lage ist Zeilenenden Unixkonform zu erzeugen. Notepad++ wäre eine Möglichkeit. Direkt und Linux geht natürlich auch.
    Wer jetzt clever ist kopiert sich auch noch gleich das Tarpi-Skript in die Bootpartition weil dann muss man nicht erst noch mit SSH, SCP, WGET oder Ähnlichem herumbasteln.

    Jetzt könne wir mal riskieren den PI mit der erzeugten uSD Karte zu booten. Beim ersten BOOT sollte dias Filesystem automatisch expandiert werden und der PI nochmal booten.
    Jetzt kommt der spannende Teil. Wir operieren den Pi im laufenden System.

    Wie auch immer ihr auf den Pi zugreift, also direkt über Tastatur und Bildschirm oder per SSH, als erstes MUSS der Pi sicher gemacht werden. Dazu MUSS das Nutzerpasswort geändert werden und dazu ist es nötig sich mit dem Standardpasswort einzuloggen:

    Code
    User: pi
    Pass: raspberry

    Doch Obacht, die Tastatur ist eher nicht auf deutsch also müssen wir entsprechend der amerikanisch/englischen Belegung:

    Code
    Pass: raspberrz

    eingeben.
    Ist diese Hürde genommen werden wir ein Tool benutzen um in einer leidlich grafischen Umgebung wichtige Voreinstellungen zu treffen.
    Mit:

    Code
    sudo raspi-config

    gehen wir in das Konfigurationsprogramm und stellen als erstes die Tastatur auf deutsch um. Es sei denn ihr bevorzugt die englische Belegung. Ach ja, und wer das "-" Zeichen sucht, das ist auf der Fragezeichentaste. :)

    Das sind die Menüpunkte die abzuarbeiten sind.
    Wichtig auch das die Kamera aktiviert wird sonst führt das zu merkwürdigen Fehlern die schwer zu lokalisieren sind.
    Nach dem Reboot und dem Enloggen mit dem neu vergebenen Passwort werden wir erst einmal das System Updaten.

    Code
    sudo apt-get update
    sudo apt-get upgrade
    sudo apt-get autoremove
    sudo apt-get autoclean
    #und wieder ein Neustart:
    sudo reboot

    Und ja, das ist notwendig. Gerade bei Buster.
    Jetzt sind wir soweit uns an Tarpi heranzuwagen.

    Mit:

    Code
    sudo apt-get install python3-pip
    pip3 install picamera

    installieren wir die Abhängigkeiten ohne die Tarpi nicht funktionieren kann. Ausserdem installiere ich gerne den MidnightCommander der viele Dinge vereinfacht.

    Code
    sudo apt-get install mc

    Wenn ihr euch im Nutzerverzeichnis von pi befindet und ihr so clever wart das tarpi994.py Skript in der Bootpartition zu hinterlegen dann könnt ihr jetzt mit:

    Code
    cp /boot/tarpi994.py .

    das Skript ins Nutzerverzeichnis kopieren. Hier muss es noch ausführbar gemacht werden:

    Code
    chmod +x tarpi994.py

    Wer mutig ist kann es jetzt bereits testen:

    Code
    ./tarpi994.py

    Wenn es läuft, alles gut, wenn nicht, die Selbstzerstörung wurde eingeleitet...

    Eigentlich ist die Bedienung ziemlich einfach. Es gibt nur eine Bedingung. Wer es über den Zehnerblock der Tastatur bedienen möchte, dafür ist es konzipiert, der MUSS den Numlockmodus aktivieren sonst funktionieren einige Tasten im Zehnerblock nicht so wie sie sollen. die normalen Nummerntasten funktionieren immer.

    Zu Anfang bekommt man das Kamerabild und in der Mitte Oben wird für etwa 3 Sekunden die Programmversion und die Bildschitrmauflösung des angeschlossenen Bildschirms eingeblendet.
    Rudimentäre Hilfe gibt es wenn man die [Enter] Taste drückt. Drückt man sie noch mal ist der Bildschirm wieder sauber. Wenn kein OSD eingeblendet ist kann mit [+] bzw. [-] rein oder raus zoomen. Wenn man reingezoomt hat kann man den Bildschirmausschnitt mit den Tasten [8][4][6][2] durch die Gegend schieben. Die [5] stellt die ursprüngliche Auflösung wieder her. Die Tasten [/] ändern die Exposurecompensation. [1][7] sind für den kontrast sowie [3][9] für die Helligkeit verantwortlich. Mit der [0] werden die Anzeigeparameter gespeichert und mit der [,] Taste kann der Bildschirm geflippt werden. Letzteres ist wichtig wenn man die Kamera über Kopf montieren muss.
    Wenn man mit der [Enter] Taste das OSD aktiviert hat kann man mit [+][-] die Schriftgrösse des OSD an den Bildschirm anpassen. Mit der [5] wird ein Bild im Unterverzeichnis ~/pictures aufgenommen. Dabei werden die Bilder durchnummeriert und wenn eine Serie bereits existiert wird durch erhöhen um 100 eine neue Serie gestartet.
    Weiterhin kann man in diesem Mode durch drücken der [0] das System-Menü aufrufen aus dem heraus man neu booten [8], ins System wechseln [5] oder aber herunterfahren [2] kann.
    Wenn man Tarpi also verlassen möchte drückt man [Enter] um das blaue OSD anzuzeigen, [0] um ins Systemmenü zu kommen und [5] um wieder auf der Shell zu landen.

    Um mal zu zeigen welche Möglichkeiten der Digitalzoom bietet habe ich mal ein paar Aufnahmen mit dem Bruder des Programmes, mit "Mikrosko-Pi" gemacht.
    Benutzt habe ich eine 8M-Pixel Kamera mit 12mm Objektiv bei einem Arbeitsabstand von ca 21cm. Beleuchtung ist leider mies aber ausreichend. Die Bilder sind über den Video-Kanal der Raspi-Camera aufgenommen und somit immer exakt so groß wie das Darstellungsdevice es zulässt also 1280x1024. Ich habe lediglich die Farbtiefe reduziert und eine etwas höhere Kompression im JPG gewählt.









    Natürlich kann man auch Bilder in maximaler Auflösung über den Still-Picture-Kanal aufnehmen, macht aber für Zielscheibenbeobachtung so gar keinen Sinn. Schon einfach mal weil man ja dokumentieren möchte was man sieht und, nicht zu unterschätzen, die Größe des belegten Speichers auf der uSD Karte.

    Nun ist ja ein bisschen Zeit vergangen und ich musste einiges umbauen weil natürlich während der Nutzung sich neue Erkenntnisse ergaben. Logisch, immer wenn man denkt man ist fertig kommt das Leben und haut einem sowas von in die ... Ausserdem bin ich eher Perfektionist.

    Also, Raspicam ist gut aber nicht gut genug. Man braucht eine alternative Raspicam mit M12 Objektivanschluss denn man will ja mit der Cam in etwa das sehen was man auch sehen würde wenn man mit eigenen Augen durch das Spektiv sieht. Okularprojektion ist nett wenn man heftig mit Croppingfaktor und Abbildungsproblemen kämpfen möchte. Wollen wir nicht. Wir wollen in etwa das Sehen des menschlichen Auges nachbilden.
    An meinem Spektiv hat sich eine alternative Raspicam mit M12 Objektivanschluss und 8mm Objektiv als guter Kompromiss herausgestellt. Damit kann ich in der kleinsten Vergrösserung des Spektives die Kurzwaffenscheibe auf 25m komplett sehen und in der grössten Vergrösserung kann ich die Langwaffenscheibe auf 50m komplett abbilden und das mit durchaus akzeptabler Abbildungsleistung.

    Ja, ich schiesse so schlecht.

    Das ist mit der KK Kurzwaffe auf 50m auf die Langwaffenscheibe. Egal...
    Wichtig war mir der Komfort. WIe schon geschrieben, hinstellen, anstellen, justieren, fertig. Helligkeit, Kontrast, Exposurekompensation, Zoom und Shift können über ein kabelloses und/oder kabelgebundenes Numpad während des Betriebes angepasst werden. Ich kann Aufnahmen, Bilder, machen und ich kann das Bild flippen. Gut letzteres braucht man nicht so oft aber gut wenn man es hat.
    Das Programm hat inzwischen ein paar Nettigkeiten erhalten weil ich öfter über Unzulänglichkeiten von Hardware und oder Software gestolpert bin wie z.B. eine Abfrage nach der nativen Auflösung des Monitores weil es öfter dazu gekommen ist das gar nichts angezeigt wurde, ausserhalb des Anzeigebereiches, oder in schlecht scalierter runtergerechneter Auflösung. Dann wird die Kamera immer in der höchsten Auflösung benutzt die meist wesentlich grösser als die native Displayauflösung ist. Das ist gut weil ich damit den VideoCore des Raspi zum skalieren benutzen kann und ich bekomme die Möglichkeit einen ... na sagen wir Softwarezoom zu benutzen bei dem ich das Abbildungsfenster durch die Gegend schieben kann. Anders ausgedrückt, ich kann mir Teile der Zielscheibe in höherer Auflösung ansehen und das über die gesamte Sensorfläche.
    Ein bisschen OSD hab ich auch gebastelt weil ich in der Anfangszeit immer vergessen hatte auf welchen Tasten Helligkeit und Kontrast uns so liegen :)

    Gut, wer damit rumspielen will, ich hänge das Teil mal an.

    Als .zip tarpi994.zip
    Als .txt der wieder in .py umbenannt werden muss tarpi994.txt


    Es läuft derzeit auf Buster lite funktionierte aber auch auf Stretch lite. Als uSD Karte würde ich keine uSD unter 4GB nehmen weil man ja möglicherweise auch mal ein paar Bilder machen möchte und die sind gross. Ausserdem sind moderne uSD mit mindestens A1 zu empfehlen was so Bootgeschwindigkeit angeht. Als Raspi geht alles ab PiZero weil der Raspi praktisch nix macht als warten. Alle Funktionen werden im Wesentlichen im VideoCore ausgeführt.

    Noch so ein, zwei Sachen vergessen. Es gibt folgende Abhängigkeiten:
    python3-pip, picamera
    Also erst auf dem Raspi mit:

    Code
    sudo apt-get install python3-pip
    
    
    pip3 install picamera

    die Vorraussetzungen schaffen sonst läuft das Skript nicht.

    ...und davon mal ganz abgesehen wäre es schon schön wenn wenigstens nicht immer Äpfel mit Birnen verglichen werden würden.
    Die Lösung von Commerzgandalf ist nett wenn ich auch eher EZ-Wifibroadcast bevorzugen würde.
    Falls jemand Gandalfs Lösung nachbauen möchte, ich würde an die Kamera ein langbrennweitigeres Objektiv schrauben. So ca. 25-50mm und dann die Cam weiter weg von der Scheibe. Das reduziert die Verzeichnung ganz gewaltig. Die Antennen so hoch wie möglich. Möglichst aus der Fresnelzone raus. Wenn es irgendwie geht lieber ein Netzwerkkabel ziehen. Das erspart vor allem Frust wenn mehrere Cams gleichzeitig betrieben werden sollen.

    Bullseye ist noch mal was anderes. Das zu "emulieren" ist "eigentlich" ziemlich simpel. Nimm OpenCV, vergleiche aufeinanderfolgende Pictureframes, wenn die Differenz grösser ist als ein vordefinierter Schwellwert und nicht wieder verschwindet, durchfliegende Fliege und so, hast du ein neues Einschussloch, stell das Zentrum der Änderung fest, lege einen farbigen Kreis um das Zentrum der Änderung, fertig.
    Ist aber nicht Teil des Digiskopaufbaues. Da haste eher so Probleme das sich Leute an den Tisch lehnen auf dem das Stativ steht und alles verschiebt sich und so. Aber auch dafür würde es Lösungen geben.
    Hier geht es nur und ausschliesslich nur um den Komfortgewinn den man erreicht wenn man nicht mit einem Auge durchs Spektiv blinzeln muss und andere Personen können gleichzeitig gucken und so.
    Aber wie gesagt, dann lass ich es.

    Besteht Interesse sich ein Digiskop mit Raspi und Kleinteilchen zu bauen? Sonst spar ich mir die Zeit.

    Grund:
    Nicht jeder Stand hat schon hochmoderne elektronische Scheibenanlagen mit und oder Scheibenbeobachtungskameras und auf manchen Ständen, Outdoor z.B., ist es auch nicht so einfach möglich. Spektiv ist schon was feines aber jedes mal beim durchs Spektiv schauen wird auch die Schusshaltung aufgebrochen und man muss sich an andere Lichtverhältnisse anpassen.
    Ich jedenfalls nutze es gerne beim Kurz- und Langwaffe schiessen selbst bei 10m zu Hause.

    Kosten:
    1* RaspberryPi (ein oller 1er genügt so lange er einen Anschluss für die RaspiCam hat, ein Zero geht aber zur Not auch)
    1* Raspicam, egal welche so lange sie funktioniert
    1* uSD Karte für das Betriebssystem so ab 2GB. Nehmen würde aber eher eine etwas neuere, grössere und schnellere...
    1* USB-Keyboard, wer möchte kann natürlich auch drahtlos arbeiten
    1* Spektiv, es sollte schon ein gut durchkorrigiertes Spektiv mit guter Linienauflösung sein das ruhig etwas lichtstärker sein sollte und die passende Vergrösserung anbietet
    diverse Kabel, Netzteil, alter LCD-Monitor...

    Also alles über alles zwischen 70€ bis nach oben offen.

    Zeitaufwand:
    der grösste Zeitfaktor ist die Anpassung der RaspiCam an das Spektiv. Da braucht man Geduld, Einfühlungsvermögen, Vorstellungskraft, Durchsetzungsvermögen, sagte ich schon Ausdauer?
    Den Raspi herrichten schafft man so in etwa 15-20 Minuten. Wenn man weiss wie es geht.

    Warum so und nicht anders:
    Weil mir die Handymontagen am Spektiv zu wackelig sind und ich bis jetzt noch keine Lösung gefunden habe die das Bild in derart hoher Auflösung mit einer derartig geringen Latenz auf den Bildschirm zaubert und dabei alle Parameter, zumindest die notwendigen wie Zoom, Shift, Helligkeit, Kontrast, Schärfe einfach einzustellen lässt.
    Ja, ich weiss, USB-WebCam an PC, Laptop, Tablet... anschliessen. USB ist leider ein sehr bandbreitenlimitiertes Medium was bedeutet das man sich zwischen Auflösung oder Bildwiederholrate entscheiden muss. Von der Latenz mal zu schweigen. Dann könnte man sicher auf eine WebCam mit USB3.0 umsteigen. Das löst das Bandbreitenproblem aber auch den Geldbeutel auf. Eine Cam mit h264 oder h265 wäre/ist super doch leider verliert man durch das für die Kompression gewählte Profil Details. Darf jeder selber ausprobieren.
    Dann gibt es noch den usability Faktor. Das Teil muss hingestellt, angeschaltet und fertig sein. Ich will da nicht erst eine PC Reparaturwerkstatt mit dutzend Geräten aufbauen müssen. Zu Hause den Akku laden und gut.

    Es gab bei Aldi vor kurzem einen "Fahrrad Montage Ständer" für 24.99€. Die besten 25€ die ich seit langem angelegt habe. Taugt, je nach zusammenbau, als Gewehrmontageständer mit Schnellklemmung und als Gewehrauflage für das Stehend schiessen. Echt klein zusammenzupacken und relativ leicht. Die Ablage kann man je nach Nutzung für Munition und/oder Putzstock und Werkzeug verwenden.

    Moin, gibt es denn schon funktionierende Prototypen, Software, ein Konzept oder wenigstens ein Pflichtenheft?

    Nach dem ja Interrupts alle Probleme lösen können sollen, Brot für die Welt und so, und Hirn einschalten ja scheinbar eher nicht so funktional scheint würde es mich schon interessieren was so das letzte halbe Jahr passiert ist.

    Ich finde es ja immer noch überaus ambitioniert, in einem Forum dessen Nutzer wenn denn überhaupt nur nebenbei mal ein bisschen mit Elektronik zu tun haben, ein Eigenentwicklungs- und Bauprojekt ins Leben zu rufen ohne einen Plan geschweige denn ein Konzept zu haben.

    Für alle die wenigstens wissen was sie tun, zwei Gabellichtschranken kaufen, ja, die gibt es auch mit grösserem Arbeitsabstand, einen Arduino, dazu ein bisschen programmieren, etwas Holz und Klebeband für die Montage am Lauf und, Voila, fertig ist ein "Simple Chrony" für vielleicht 20€. Roh, keine Spannungsversorgung, keine Anzeige, kein Nichts.
    Wenn ihr alles zusammenzählt was an Aufwendungen notwendig ist dann kommen eher 100-150€ zusammen. Und das für ein wirklich simples Teil ohne Komfort.
    Ganz ehrlich, wenn ihr das nicht beruflich macht, begrabt die Idee und kauft euch eines.
    Viel weniger Frust.
    Und es funktioniert, meistens.
    Weil sich da jemand Gedanken über die Analogelektronik und Umweltbedingungen gemacht hat. Weil der Entwickler wusste das man das Signal integrieren und differenzieren muss, weil sich da jemand Gedanken über die Optik gemacht hat und weil sich jemand Gedanken über die Mechanik gemacht hat.
    Aber das sind ja alles nur Kleinigkeiten...wird das Forum schon lösen...

    Sorry, aber nach den "wissensbasierten" Vorlagen konnte ich mich echt nicht zurück halten....

    Jetzt verstanden?

    Oh, ich verstehe dich schon das ändert aber nix daran das deine Annahmen falsch sind.
    Die korrekte Loopkonstruktion wäre:

    • loop:
    • sbis PIND, 0
    • rjmp loop

    und die braucht bei mir 2-3 Takte. Jedenfalls sagen das mein Debugger und die Auskunft von den Jungs bei Microchip ob sich da was geändert hätte: https://www.microchip.com/about-us/contact-us ist auch das das immer noch ein RISC ist und alle Befehle, ausser Spezialitäten, innerhalb eines Taktes abgearbeitet werden. Hätte ja sein können das die von RISC zu mixed Design gegangen wären und das in Software emulieren.

    "Normalerweise deaktiviert man am Anfang der ISR alle Interrupts und lässt sie am Ende wieder zu."

    ...und verliert einen Interrupt? Nee, läuft ein bisschen anders.

    "Der Vorteil der Interrupts ist natürlich, dass ich potentiell auf verschiedene Ereignisse reagieren kann, ohne dass ich die Loop länger machen muss. Das nennt man technischen Fortschritt, also den von vor 40 Jahren..."


    Ja genau! Ich bewundere deine Kenntnisse zutiefst. Ich bin ja erst später, so der Zeitraum des 8008, eingestiegen aber der kannte schon Interrupts. Ich verneige mein Haupt vor dir der du noch mit Prozessoren ohne Interruptbehandlung arbeiten musstest. Da lernt man strukturierte Programmierung.

    @WhiteSAndS: Als interessierter Mitleser dieses Threads würde ich gerne darauf hinweisen, dass ich deinen Ton als sehr aggressiv und beleidigend empfinde. Wäre es möglich, so sachlich-nüchtern zu schreiben, wie es @Feinmechaniker angesichts seiner Bemühungen verdient?

    Komisch, eigentlich bediene ich mich des nahezu gleichen Tonfalles den er in anderen Threads von sich gegeben hat.
    Aber du machst mich neugierig, definierst du für mich zum nachlesen, ausdrucken und an die Wand hängen bitte "seine Bemühungen"?

    Der Trick liegt darin, nicht den Timer1 selbst auszulesen, sondern das Timer1-Capture Register (siehe ISR2 meiner Beschreibung). Dieses Register sichert den Zählerstand von Timer1 unmittelbar im Moment der H>L Flanke am Portpin. Die Sicherung wird komplett durch die Hardware, quasi nebenbei, erledigt. In der ISR des Timer1 wird dann nur noch das Capture Register in eine Variable übernommen. Die Zeit zwischen dem Auslösen der Hardwareflanke am Pin und dem Schreiben der Speichervariable spielt somit keine Rolle mehr.

    Oh, die Funktion der ICU gefunden. Schön.

    Die Konstruktion deiner Loop ist falsch.
    Der Ansatz das "meine" Konstruktion 5 oder 6 Takte bzw. die ISR Reaktion 4 bis 8 Takte braucht ist falsch. Aber ich weise gerne noch mal Oberlehrerhaft darauf hin. Es ist fast egal wie lange die Reaktionszeit ist so lange sie immer gleich bleibt. Davon abgesehen braucht "meine" Konstruktion entweder 2 oder 3 Takte. Wie stellst du das sicher wenn du konkurrierende Interrupts hast?
    Ja, man kann den Programmablauf fangen damit die ISR immer gleich aufgerufen wird. Das macht die ISR dann irgendwie ... überflüssig.

    Ich bin eine absolute Eletronik-Fünf und stelle mal jetzt die Frage als Anwender, weil mich das hier interessiert (evtl. ist die Antwort hier schon im Thread und ich verstehe sie nicht)

    Es müßte doch einen Error geben, wenn ich schräg durch das Ding schiesse (innerhalb einer gewissen Toleranz). Da wär es schön, wenn man genau das auch anzeigt, anstatt nur Error (Das ist immer ein Rätsel, warum nun Error) Aber wie das bei "Hochschuss" funktionieren soll, wär mir nicht klar. Da bräuchte man ja noch seitliche Lichtschranken ?(

    Deswegen arbeiten Profilösungen mit optischen Gittern weil sie dann auch gleich die Fehler durch die Längenänderung kompensieren können. :rolleyes:
    Das ist ja meine Argumentation, was nutzt mir eine Fehlermeldung die mir nicht hilft ausser das ich jetzt weiss es kommt kein neuer Wert und selbst die GGM hat das bemerkt. Vielleicht ist sie ja klüger als ich... ?(
    Irgendwie kommt mir die ganze Diskussion windowsdomestiziert vor.Wollen sie Windows wirklich beenden? Ganz ganz wirklich? Aber es ist doch sooooo toll...

    Code
    loop:
          sbis PIND,0
          rjmp weiter
          rjmp loop

    Das soll genauer sein sein als ein Interrupt? Wie das denn?

    Falsch! Nochmal die Befehlsbeschreibung lesen. Alternativ Debugger benutzen und ansehen.

    Interrupt, was genau passiert eigentlich bei einem Interrupt und was muss ich tun damit die Reaktionszeit auf eine Interruptauslösung so gut wie möglich gleich bleibt?
    Was passiert wenn ich mehrere Interrupts zulasse und während der Ausführung einer Interruptserviceroutine ein weiterer, möglicherweise zeitkritischer, Interrupt ausgelöst wird?
    Was unterscheidet einen bedingten Sprungbefehl wie sbis/sbic von der Auslösung einer ISR wenn ich gezwungen bin immer nur einen einzigen Interrupt gleichzeitig zuzulassen?
    Oh man, wieso mache ich mir eigentlich euren Kopf?!?

    @WhiteSAndS:

    Ja, auf jeden Fall braucht man gescheite Fehlermeldungen, um überhaupt nachvollziehen zu können, was schiefgegangen sein könnte! Meist wird das, was der Chip wahrnimmt von dem abweichen, was man selbst wahrnimmt. Dafür kann es massig Gründe geben."Senilitätshilfe?" :cc
    Was du das über das Jagen nach Einzeltaktcounts schreibst, finde ich schon richtig. Interrupts sind eine aufwändige Operation, kann schon sein, dass die nicht immer die gleicher Anzahl Takte braucht (bin nicht sicher). Wenn nicht und wenn man die vermeiden könnte, könnte das der Genauigkeit natürlich schon helfen. Bei v = 500 m/s, 10 cm Meßstrecke (oder weniger?) und 8 MHz Taktfrequenz entspricht der ganze Durchflug gerade mal 1000 Takten, da ist es schon sinnvoll, dass die Zeitmessung auf möglichst wenige Takte genau stimmt.

    Ok, sagen wir mal du bekommst die Fehlermeldung das Lichtschranke 1 ein Signal gegeben hat, Lichtschranke 2 aber nicht.
    Was genau möchtest du mit dieser Information in einem fertigen Gerät anfangen?
    Richtig, nichts!
    Während der Debugphase KANN es nützlich sein. Wenn die Optik deiner Hardware aber so unzuverlässig ist das das eher Glück als Können ist dann solltest du eh wieder zurück an den Arbeitstisch und ein paar grundlegende Probleme klären.
    Das sollte man eh bevor man ein derartiges Projekt anfängt aber dazu später.
    Es ist keine Jagd nach Einzeltakten sondern nach Konsistenz. Die Reaktion soll so gut es geht immer die gleiche Reaktionszeit haben. Wie lange genau ist gar nicht sooo wichtig nur eben immer gleich lang.
    Man kann das ganze auch mit Interrupts lösen aber eben nicht mit konkurrierenden Interrupts. Wenn du nicht sicher stellen kannst das ein Interrupt während eines zeitkritischen Interruptes ausgelöst wird hast du verloren und zwar massiv an Genauigkeit oder Verlässlichkeit. Wie du willst.
    Aber wie gesagt man kann. Bloss verkommt dein schönes Interruptsystem zum blanken Aufruf von Subroutinen wenn du das sauber programmierst und dann kannst du es auch ohne lösen.
    Wie ich schon schrieb, wie haben es eigentlich die Altvorderen geschafft genau zu messen ohne CPU und Interrupts nur mit ein bisschen Logik und ein paar Countern?
    Gab es dazu nicht einen schlauen Spruch? "Wer die Geschichte ignoriert ist dazu verdammt sie zu wiederholen"
    Man muss sich einfach mal angucken aus welcher Zeit das Design der Counter in den AVRs stammt. Das war noch eine Folge der Übertragung digitaler Daten über PWM, PPM bzw dPPM und die Leute die den Befehlssatz konstruiert haben WUSSTEN was sie taten.
    Aber mal zurück zu diesem "Projekt".
    Was glaubt ihr eigentlich wird das am Ende kosten? Nehmen wir mal an die Hardware, also Platine mit Controller und Lichtschrankenelektronik plus Anzeige, liegt so bei 15-20€. Da habt ihr keine Optik, keine Stromversorgung, geschweige denn ein funktionierendes Gehäuse dazu. Ihr werdet noch unzählige Arbeitsstunden versenken, elendig viel Material verbrauchen bis etwas halbwegs brauchbares rauskommt was hoffentlich zuverlässig ab und zu brauchbare Werte anzeigt. Ohne anständige Optik, und hier reden wir eher von mehr als 30€, ist das dann mehr oder weniger nur für Preller oder PCP einsetzbar. Jedenfalls wenn IR-Lichtschranke und wenn nicht verhindert werden kann das der Schmauch von Feuerwaffen die Optik beeinträchtigt. CO2 geht nur mit genügend Abstand wegen des Absorbtionsverhaltens.
    Dann braucht ihr ein Gehäuse. Gibt es ja nicht umsonst und MUSS zuverlässig funktionieren sonst muss man ständig neu bauen. :cursing:
    Lange Rede.... wenn ich nur so ein Ding anwenden wollen würde hätte ich ja als erstes mal in das Pflichtenheft dieses Projektes geschaut, ups, gibt keines, wurde auch nicht diskutiert, nur hingeknallt, ob es denn meine Anforderungen auf welche Weise erfüllen wird. Dann hätte ich mir überlegt ob es nicht sinnvoller ist, finanziell oder zeitökonomisch, eines zu kaufen und, so ich es denn kann, diese meinen Ansprüchen entsprechend zu verbessern. Wobei ich mich da schon frage in welche Richtung das gehen soll denn wie schon geschrieben, die meisten haben ein Interface aus dem man eine Menge holen kann. Wenn ich eine eigene Firmware möchte, gut, aber dann hat man eine funktionierende Optik auf der man aufbauen kann.
    Was genau habt ihr? Snakeoil, Unobtanium...ein Versprechen in eine goldene Zukunft.
    Selbst wenn ich das aufbaue, so als Fingerübung, würde ich eine preiswerte fertige Platine mit MEGA328, einen preiswerten serial/USB Wandler oder preiswerten serial/Bluetooth Wandler und wäre dann mit vielleicht 12-16€ dabei. Noch etwas Lichtschrankenmagie und fertig wäre der Versuchsaufbau. Doch wofür?
    Auf der anderen Seite, wer Spass am basteln hat, nicht unbedingt darauf angewiesen ist und wo Zeit und Geld eher eine untergeordnete Rolle spielen...warum nicht. Dümmer wird man nicht. Und vielleicht lernt ja der eine oder andere sich Informationen an der Stelle zu holen wo deren Ursprung ist denn wie heisst es so schön: "Wissen ist Macht!". Ooh, Tag der Retrosprüche :rolleyes:

    Ähem, nettes "State-Machine"-Diagram. Nicht wirklich konsistent aber lassen wir das mal dahingestellt.

    Stellen wir uns mal ganz dumm. Was wollen wir messen? Wir wollen die Geschwindigkeit eines Geschosses das den Lauf der Waffe verlassen hat in definierter Entfernung von der Laufmündung messen. Dabei werden folgende Dinge IMMER eintreten:

    1. Geschoss verlässt Lauf und begibt sich auf die Reise zur GeschossGeschwindigkeitsMessstelle oder kurz GGM
    2. Geschoss durchquert die erste Lichtschranke und löst, hoffentlich, ein Signal aus
    3. Geschoss durchquert die zweite Lichtschranke und löst, hoffentlich, ein Signal aus
    4. die GGM berechnet ein bisschen und gibt die Werte aus, wie auch immer man das löst und
    5. zurück zu 1.

    Welche Fehler können auftreten:

    1. Geschoss verlässt Lauf und trifft GGM genau zwischen die Augen, keine weiter Aktion erforderlich, GGM abbauen, in einer Tüte verstauen und pfeifend nach Hause gehen
    2. Geschoss durchquert erste Lichtschranke löst aber kein Signal aus, keine Aktion erforderlich weil eh keine Messung erfolgen kann
    3. Geschoss durchquert erste Lichtschranke löst Signal aus, Messung beginnt scheint aber zwischen den Lichtschranken die Flugrichtung geändert zu haben, tunnelt durch die GGM oder verlässt auf andere Weise die vorgeschriebene Flugbahn, Aktion erforderlich!!!
    Die einzige angemessene Reaktion darauf ist es nach angemessener Zeit entweder über einen Watchdog oder auch einfach über den Overflowint des Counters die Messung ergebnislos zu beenden und wieder zum Anfang der Messung zu springen. Um mal das Thema Ausgabe anzusprechen, wenn ich geschossen habe aber keine Messung erfolgen konnte, aus welchem Grund auch immer, braucht ihr da echt eine Senilitätshilfe der Art das euch das Gerät sagt ja, ihr habt geschossen aber ich kann damit nix anfangen? Wenn es soweit ist solltet ihr gar nicht mehr schiessen.

    Bei genauerer Betrachtung sieht man das das ein konsequent linearer Ablauf ist. Nix kompliziertes. Latenzen sollten zwar immer gleich sein, besser ausgedrückt, die Latenz der Signalantwort per Lichtschranke sollte so konsistent wie möglich sein sie müssen aber nicht bei beiden Lichtschranken gleich sein. Hauptsache sie sind bekannt. Debugger und auszählen oder, warum habe ich wohl in einem meiner Vorpostings einen Link auf ein Herstellerdokument gepostet wo die Befehle inklusive der Bearbeitungszeiten beschrieben waren, halt in der Tabelle nachgucken und zusammenrechnen.

    Den geringsten Bearbeitungsoverhead für eine konsistente Reaktion auf die Signale hätte eine Kombination aus sbis/sbic und relativem Jump nämlich 2-3 Takte weil ja auch noch der Quantisierungsfehler mitspielt. D.h. man hätte eine Gesamtungenauigkeit von +-1Takt wenn man das bei beiden Lichtschrankensignalen machen würde.
    Aber das könnte man alles selber wissen wenn man denn mal die wirklich hervorragende Doku von Microchip zum AVR lesen und verstehen würde.

    Ich frage mich ja manchmal wie die Leute es geschafft haben ohne Microcontroller und Interrupts auszukommen und trotzdem präzise Messungen hinzulegen nur mit ein paar binär- oder BCD-Countern und ein paar Gattern Logik drum herum.
    Also so wie ich das sehe braucht ihr MINDESTENS einen RaspberryPi der 4. Generation mit Counter-Hut damit überhaupt was verlässliches rauskommt.

    Ich weiss, ich bin ein Idiot, aber anstatt den Überflieger raushängen zu lassen, eine Wertung zu BASCOM rauszuhauen die ich mir an deiner Stelle echt verkniffen hätte, einen "Hochsprache"-Befehl mies zu machen der in Realität mehr einem Assembler Makro ähnelt als einem "Hochsprache"- Befehl, was man leicht gesehen hätte wenn man denn die Befehlstabelle hätte lesen können und vielleicht mal in einen Debugger guckt, hätte ich mir wirklich mal die Struktur des von mir verlinkten Beispielprogrammes angetan denn da hat jemand gezeigt das er verstanden hat wie so ein AVR tickt und wie man die vorhandene Hardware zu den eigenen Gunsten nutzen kann.
    Doch dazu hätte man die Dokus lesen und verstehen müssen...

    Ich mach dann mal Urlaub von diesem Selbstbeweihräucherungsthread.

    Für die Freunde des gepflegten Live-HD-Videos vom Quadrocopter aus könnte ich:

    https://github.com/bortek/EZ-WifiBroadcast/wiki

    empfehlen. Aufwand ist überschaubar und die Videoqualität um Welten besser als bei den meisten Systemen. Doch Obacht, Reichweite ist Normenkonform nur etwa 300-400m. Dafür in Farbe und Hochauflösend. Lag ist systembedingt ein wenig höher als bei analogen Systemenalso nix für Rennquadros. Wenn man möchte kann man mit diesem System auch gleich den Quadrocopter steuern also nur einmal HF für Video und RC.
    Fast vergessen, und aufgezeichnet auf uSD-Karte wird auch.

    Noch ein Wort der Warnung, das hier ist ein öffentlich einsehbares Forum und einige der hier verlinkten Videos sind nicht LuftVG kompatibel.