Überlegungen und Working an eigener Standsoftware

  • Der erste Schritt wäre jetzt glaube ich erstmal die Daten aus dem Messrahmen zu bekommen per RS232. Danach die Anbindung der Handsteuerung. Dann kann man sich um die Anzeige kümmern etc. Bei dem Bedienteil mache ich mir weniger sorgen, im Notfall ließe sich sowas auch mit einer Numpad-Tastatur über USB und einer eigenen Abdeckung aus dem 3D Drucker abbilden.

    Also für mich Prio 1, das Auslesen des Rahmens.

  • Deine Visualisierung gefällt mir übrigens sehr gut.

    Ich hatte damals mal einen Renderer für Zielscheiben in der Optik der Papierscheiben gebaut ,der die RMIII Daten ausgewertet hat. Aber davon würde ich eigentlich bei einer elektronischen Anlage absehen.

    Wir könnten ja mal versuchen das Protokoll für den Messrahmen zu analysieren und zu dokumentieren. Was hälst du davon? SebastianL

  • Hallo,

    ich bin jetzt schon ein ganzes Stück weiter:

    Fast alles funktioniert im Webinterface, ich baue gerade mit NixOS ein passendes Betriebssystem, das hoffentlich für ein einfaches Installieren sorgt. Die Wahl viel auf NixOS, weil eigentlich alle Konfigurationen in einer einfachen Textdatei liegen und sehr gut reproduzierbare Betriebssysteme gebildet werden.


    Des weiteren kam heute der folgende Beitrag von Meyton online: Meyton-Forum

    Zitat

    Das intern zwischen Messrahmen und SteuerPC verwendete Protokoll zur Übertragung von Trefferdaten ist ein Betriebsgeheimnis, welches nicht an Außenstehende weitergegeben wird, um externe Maniplation von Ergebnissen auszuschließen.


    Ich bin jetzt mal gespannt, was wir demnächst alles erreichen können.

    Evtl. könnte es auch besser sein, mit dem Protokoll von Disag anzufangen, da das definitiv nur Informationen und keine Sensordaten weitergeben kann (RS232 ist für 2 Kamerabilder viiiiiiiiiiel zu langsam).

    Ich melde mich, wenn ich eine vorerst brauchbare Version erstellt habe, evtl. stelle ich das Webinterface auch mal zum Testen online zur Verfügung, damit ihr testen könnt.

    Gruß
    Sebastian

    OSSS - Open Source Shooting System in Programmierung, nähere Infos findet ihr HIER

  • Deine Visualisierung gefällt mir übrigens sehr gut.

    Ich hatte damals mal einen Renderer für Zielscheiben in der Optik der Papierscheiben gebaut ,der die RMIII Daten ausgewertet hat. Aber davon würde ich eigentlich bei einer elektronischen Anlage absehen.

    Wir könnten ja mal versuchen das Protokoll für den Messrahmen zu analysieren und zu dokumentieren. Was hälst du davon? SebastianL


    gerne,
    ich kann euch nur aus der Ferne nicht wirklich unterstützen,
    ich kann euch nur den Hinweis geben, dass man zum Mitschneiden von RS232 insgesamt 2 RS232-Adapter benötigt, da man pro Adapter immer nur eine Empfangsleitung hat.

    OSSS - Open Source Shooting System in Programmierung, nähere Infos findet ihr HIER

  • SOOOOO,

    es ist wieder ein bisschen Zeit vorbei, jetzt hab ich mich mal dazu entschieden, den vorläufigen Code und eine Online-Demo zur Verfügung zu stellen:

    OSSS - Codeberg


    und hier ein online-Beispiel:

    OSSS - Stand Demo

    dabei sei gleich gesagt, dass es sich bei der Demo um den kleinsten verfügbaren vServer (1 Prozessorkern und 1GB RAM) handelt, und trotzdem läuft bei mir alles sehr flüssig. Schaut es euch mal an, was ihr dabei denkt.
    Aktuell läuft im Hintergrund einfach ein Skript, dass alle 5 Sekunden "einen Schuss abgibt", daher das schlechte Schussbild, da wird aktuell nur im Raum von x=-1000; y=-1000 bis x=1000; y=1000 ein Zufallswert ausgegeben und übertragen.

    Noch gut zu wissen sind folgende funktionierende Shortcuts (Taste in []):

    • [1] Zoomen Stufen 1 - 6
    • [1 - langer Tastendruck] Zoomen Stufe 7
    • [2] Treffer zurück (nur bis zum nächsten Schuss)
    • [3] neue Probescheibe
    • [4] umschalten auf Wertung
    • [5] Treffer vor
    • [6] Umschalten zwischen ganze Ringe, zehntel Ring und Teilerwertung

    OSSS - Open Source Shooting System in Programmierung, nähere Infos findet ihr HIER

  • Ach, und bevor ich es vergesse:

    Es ist aktuell so, dass jeder Stand nur exakt eine API hat, das bedeutet auch, dass jeder Befehl, der z.B. von mir in Bayern abgesetzt wird, auch bei demjenigen, der gerade von Hamburg aus darauf zugreift, gilt.
    Somit ergibt sich der Fall, dass die Anzeige immer für alle gleiche ist.

    OSSS - Open Source Shooting System in Programmierung, nähere Infos findet ihr HIER

  • Hallo beieinander,

    es ist wieder einiges weiter gegangen, der Code kann wieder mehr.

    Was ist neu:

    • MQTT-Server für die Steuerung
    • Die API ruft über MQTT nun noch zusätzlich Standinformationen ab, um z.B. den Schütz:innen-Namen auf diesem anzuzeigen. (oder Disziplin / Regelnummer)
    • Für die Verwaltung der Software und der Rechner, die notwendig sind, wird einige Magie in NixOS durchgeführt (zusätzliches Repro für die Konfigurationen):
      • Konfiguration über eine einfache Textdatei
      • System kann einfach geupdatet werden


    Ich möchte möglichst schnell ein brauchbares System aufbauen, damit dann auch andere Testen können. Das bringt mich zu meiner aktuellen Frage an euch:

    • Was braucht es für euch als Minimalsystem, damit ihr etwas testen würdet?
    • Was bräuchtet ihr, um es evtl. in eurem Verein einzusetzen.
    • Welche Meilensteine sollte ich als erstes anpacken?

    Für mich sind aktuell folgende Punkte die möglichen Meilensteine:

    • Software zur Verwaltung der Schütz:innen:
      • Datenbankverwaltung
      • normale Rundenwettkämpfe
      • Wettkampfmodus
      • RWK-Auswertungen
    • Visuallisierung der Ergebnisse für TV / Beamer
    • Ergebnisausdruck vom Stand aus
    • ...

    Was aktuell noch nicht zur Debatte steht, sind andere Scheiben als LG und LP. Spaßscheiben und anderes stehen momentan nicht in meiner Macht.

    Bei dem Wichtigsten, der tatsächlichen Standanbindung, geht es langsam voran, mittlerweile habe ich einen "Zwischenstecker", mit dem ich die ganze Kommunikation abhören kann, was mir fehlt ist ein Stand, um zu testen. (Evtl. kann ich nächste Woche in meiner Heimat kurz im Verein was testen, aber das ist ungewiss und mit ca 200 km Fahrtweg auch nicht einfach mal eben machbar. )


    Gruß
    Sebastian

    OSSS - Open Source Shooting System in Programmierung, nähere Infos findet ihr HIER

  • Lustig, ich spiele seit längerer Zeit mit dem Gedanken mir das Kommunikationsprotokoll der DISAG-Anlage anzuschauen. Die Software von DISAG überzeugt mich leider nicht konsequent und es kommt kaum noch Bewegung bei DISAG rein.

    Walther GSP .22/.32 Wechselsystem
    Feinwerkbau P8X

    Browning FN .22

    Kampfrichter B - national

  • Hallo Floxxe ,

    dann bist du herzlich willkommen. Mein Code ist ja auf Codeberg online, und eigentlich braucht es wirklich nur einen kleinen Webaufruf, der von dem gleichen Rechner kommt, wie die FastAPI, um einen Schuss einzufügen.

    z.B. wie folgt:

    Code
    curl -s -w "%{http_code}" -o /dev/null "http://127.0.0.1:8000/shot?x=X-WERT&y=Y-WERT"

    Wobei X-WERT und Y-WERT einfach Zahlen sein sollen.

    Es würde mich freuen, wenn du das ganze mal aus Disag-Sicht evalluieren würdest.


    Ich habe jetzt tatsächlich seit einer Woche einen Meyton-Stand und hab auch schon mal ein paar Daten mitgeschnitten, das wird aber wohl etwas mehr Arbeit als gedacht. . .

    Gruß
    Sebastian

    OSSS - Open Source Shooting System in Programmierung, nähere Infos findet ihr HIER

  • Du greifst die Daten ja per RS232, ich würde tatsächlich gerne beim Ethernet bleiben. Hier kommunizieren die Messrahmen mit dem Gate, allerdings ist die Software auf dem Gate verschlüsselt und mir fehlt das entsprechende Passwort (was mich so oder so annervt, nach einem Updatefehler musste ich den ShuttlePC einschicken, da eine Neuinstallation für den Enduser nicht möglich ist)

    Walther GSP .22/.32 Wechselsystem
    Feinwerkbau P8X

    Browning FN .22

    Kampfrichter B - national

  • Hallo,

    das Problem an allen Ethernet-Übertragungen ist, dass diese von "verhältnismäßig" starken Recheneinheiten verarbeitet werden und damit der Theorie nach auch eine Verschlüsselung sehr einfach umgesetzt werden kann. Das ist bei RS232 nicht ganz so einfach, da (zumindest in den alten Meyton-Anlagen) keine sonderlich starken Microcontroller verbaut sind, somit ist die Wahrscheinlichkeit, die Daten sinnvoll rekonstruieren zu können deutlich höher.

    Des weiteren muss ich mich dann auch nicht mit den Anzeigen von Disag/Meyton rumplagen und z.B. Änderungen in einer Disziplin in deren proprietärem Format vornehmen. Stattdessen kann ich mir die Disziplinen als einfache JSON-Strings vom Server zum Stand übertragen und gut ist.

    Ich wünsche dir trotzdem viel Erfolg, das Netzwerkprotokoll zu reversen, wenn du es hast, würde es mich tatsächlich interessieren, einfach der Neugier wegen.

    Gruß
    Sebastian

    OSSS - Open Source Shooting System in Programmierung, nähere Infos findet ihr HIER