Latenz bei Vorsatzgeräten

[WAKAN]

Ach ja, hätte ich fast vergessen.

Habe ich schon erwähnt, dass das Nadelöhr der Latenz der Sensor ist?

LG.WAKAN

 

[Conram]

Ach ja, hätte ich fast vergessen.

Habe ich schon erwähnt, dass das Nadelöhr der Latenz der Sensor ist?

LG.WAKAN

Ich will ja nichts sagen, aber die meisten Hersteller im Jagdbereich verwenden FPGAs … zB HIK, Infiray

 

[cast]

Und?

 

[WAKAN]

Ich will ja nichts sagen, aber die meisten Hersteller im Jagdbereich verwenden FPGAs … zB HIK, Infiray

Hallo Conram.

Ja, kein Wunder bei diesen guten Marktpreisen und den kurzen Produktzyklen.

Habe aber auch vor Monaten auf der iRay-Homepage eine Jubelmeldung gesehen, dass sie ab sofort ASICS verwenden. In welchen Geräten genau, weiß ich allerdings nicht. Auch ist mir nicht bekannt, ob sie noch die billigeren FPGAs verwenden.

Pulsar verwendet ebenfalls FPGAs.

GUIDE hatte ASICS verbaut, ob sie mittlerweile auf billigere Alternativen umgestellt haben, weiß ich nicht. Ich habe die Entwicklung nicht weiter verfolgt. Die TA35, also die alten F1.2 Geräte, wurden jedoch mit ASICS gebaut.

LG. WAKAN

 

[Conram]

Nuja ASICs sind hierfür auch etwas teuer in der Herstellung weil unflexibel … also nicht unbedingt der einzelne Chip … bin beruflich in der Halbleiterbranche unterwegs.

PS: Spannend, dass Guide in der Consumerbranche für ein Nischenprodukt diesen Weg ging.

PPS: Bei der großen Produktpalette von Infiray kann ich mir sogar vorstellen, dass es sich für Teilbereiche der Geräte lohnt. Ich vermute, dass sie insg. nicht nur den europäischen Markt „Jagd“ bedienen.

 

[AughtSix]

Eine Software im eigentlichen Sinne gibt es im Thermal Core nicht. Irgendeine Software, die annähernd so bezeichnet werden kann, liegt außerhalb der Signalverarbeitung und ist nur kosmetischer Natur und nahezu irrelevant für irgendwelche zeitkritischen Signalwege.

Hallo WAKAN,

ich weiß deine langen technischen Posts zu schätzen, aber das war doch der springende Punkt. Du meinst immernoch die "Signalverarbeitung im Sensor", richtig?

Nehmen wir ruhig mal die von dir genannten GUIDE. Ein TA435 (hab ich einfach mal gegoogelt, ich besitze es selber nicht).

Der Sensor hat eine Auflösung von 400x300.
Das OLED Display, auf dem unsere Umgebung und das Wild dargestellt wird, hat aber eine Auflösung von 1027x768. Wer übernimmt die Skalierung?
-> SOFTWARE

Durch was ist der digitale Zoom implementiert ?
-> SOFTWARE

Durch was ist die Farbpalette implementiert, die du auswählen kannst?
-> SOFTWARE

Warum sieht man überhaupt ein Menü und kann alles mögliche an der Darstellung steuern?
-> SOFTWARE

Das Ding hat eine Bluetooth Fernbedienung!
-> SOFTWARE

Ich kann noch sehr, sehr lange so weitermachen.

Die komplette Darstellung auf dem Display ist Software gesteuert. Die reinen elektronischen Signalwege natürlich nicht. Aber das Display ist für die Interaktion mit dem Menschen das entscheidende! Je nachdem was wir dort sehen, dann schießen wir oder eben nicht. Und da können sehr schöne Nebeneffekte entstehen, wenn die Software nicht gut auf die Hardware abgestimmt ist. (Neue Software erscheint ständig, weil eben sehr häufig irgendwelche Dinge optimiert werden müssen, oder weil sie fehlerhaft ist.) Es gelten die Regeln, die ich schon mal genannt habe... Laufzeitanalyse mit allem drum und dran. Und damit kenne ich mich seit einigen Jahren eben im professionellen Bereich aus.

Für die schon mal erwähnten Diycon Geräte gibt es eigene Firmware-Updates -> SOFTWARE.

 

[WAKAN]

...Du meinst immernoch die "Signalverarbeitung im Sensor", richtig?

Hallo AughtSix.

Ja klar, gemeint waren nur die zeitkritischen Signalwege und nicht die assemblersprachlichen oder hochsprachige µController-Programme.

LG. WAKAN

 

[Totto]

Gehts nur mir so oder versteht noch wer gerade nix mehr?

Ich wünsche mir mal zum Thema "Latenz" einen Poscast mit Vertretern von Herstellern. Sagen wir mal Pulsar, Infiray, Hikmikro, Thermtec.

 

[AughtSix]

Doch ich finde, wir nähern uns dem Knackpunkt an.

Wie viel an der Darstellung im Display ist durch FPGAs optimiert, und wie viel ist Software, die
durch Assembler oder Hochsprachen wie C/C++/Rust implementiert ist.

Dann könnte man eventuelle Laufzeitprobleme besser einschätzen.

 

[AughtSix]

Ich fürchte nur, ohne detaillierte Einblicke in die Entwicklungsabteilungen der jeweiligen Firmen lässt sich das nicht so leicht heraus bekommen.

 

[Carpenter]

Am Ende hilft doch nur wenn man einen vergleichbaren Test (Beispiele dafür wurden schon genannt) an den bekannten Geräten durchführt. Das inkludiert SOFTWARE und HARDWARE.

 

[AughtSix]

Bin da bei dir.

Derartige Tests sind halt schwierig zu gestalten, so dass sie wirklich objektiv, mehrere Geräte, unter allen Bedingungen, miteinander vergleichen.

Das ist leider der Grund warum die Hersteller das nicht gerne angeben.

 

[Carpenter]

Bin da bei dir.

Derartige Tests sind halt schwierig zu gestalten, so dass sie wirklich objektiv, mehrere Geräte, unter allen Bedingungen, miteinander vergleichen.

Das ist leider der Grund warum die Hersteller das nicht gerne angeben.

Wenn das nicht gemacht wird, eiern wir hier noch mehr mit Vermutungen rum.

 

[Vale]

Ich versuche mal zusammen zu fassen:
Sau ist warm -> Lichtgeschwindigkeit -> Sensor ->geringe Reaktionszeit (tau?) -> Signalverarbeitung bei optimierter "Halbleitertechnologie -> "keine Reaktionszeit" -> Signalaufarbeitung (Schönes Bild, Upscaleing etc.) -> je nach Software und "Rechenleistung" länger bzw. kürzer -> Bild an Display // Sau ist warm aber 3 cm weiter links -> Lichtgeschwindigkeit -> Sensor ... usw...

Könnte man das so in einem nicht wissenschaftlichen Kontext zusammenfassen?
Bitte korrigieren falls falsch.

 

[Carpenter]

Da bekommt der Begriff "Game Loop" eine neue (doppel) Bedeutung...
https://de.wikipedia.org/wiki/Game_Loop