Dokumentation des Jow Warrior 24f14

Dies ist das deutsche Forum für alle Themen um den JoyWarrior. Beiträge bitte nur in Deutsch.

Moderator: Guido Körber

Post Reply
karula
Posts: 4
Joined: Tue Nov 08, 2011 6:01 pm

Dokumentation des Jow Warrior 24f14

Post by karula »

Moin,
neu hier und Besitzer zweier der o.g. Sensoren.
An Hand der downtilt demo läßt sich zusammensuchen, wie man diesen
Sensor in den Grundfunktionen in Betrieb nimmt. Klappt auch soweit.
Das ganze wird ein einfacher und kostengünstiger Demonstrationsversuch
zum Thema Ladungsbeanspruchung.

Davon ab bleiben eine Reihe unbefriedigender Punkte in der Nutzung der Software.

Der JW erhält nach Enumeration zwei hidhandles (Terminologie des downtilt).
Welcher ist wozu? Hier kann man nur raten; eine klare Dokumentation finde
ich nicht.
Die HID reports haben alle ID=0. Heißt das, es werden grundsätzlich keine
ID ausgewertet oder gibt es doch welche, die nicht im Beispiel vorkommen?

Das nächste Byte nach der ID ist CMD und nimmt im Beispiel die Werte 0 oder 0x82 an.
Was ist das?
Was ist 'das andere Interface' - der Begriff findet sich in einem Diskussionsbeitrag hier
im Forum.

Vielleicht mag mich ja jemand erhellen ...

Walter
User avatar
Christoph Jung
Posts: 670
Joined: Sun Oct 08, 2006 3:43 pm
Location: Germany / Berlin
Contact:

Re: Dokumentation des Jow Warrior 24f14

Post by Christoph Jung »

Die Handles (hidhandle) sind die Zugriffswege auf den JoyWarrior, bzw. bei allen HID-Geräten (Tastatur, Maus, Joystick, etc.)
Es sind in diesem Falle zwei, da das erste (0) beim JoyWarrior ist dafür da die Daten permanent zu senden. Darüber kommen also die Daten für die Achsen und Buttons. Der JoyWarrior sendet diese permaneten an das System. Über die ReadFile()-Methode klinkt man sich in diesen Datenstrom ein.

Das zweite Handle (1) ist zur kommunikation für die Einstellungen. Im Falle des JoyWarriorF8 und -F14 wäre das Einstellungen wie Frequenz, diverse Flags zum einschalten von Hysteresekurven und auswertung von Statusregistern. Diese sind allerdings direkt vom Sensor (Bosch-Sensor) und sind im jeweiligen Datenblatt des Sensors zu finden. Wir gehen darauf nicht näher ein, da hier auch viel verkehrt gemacht werden kann und man so z.B. die Kalibrierung ändern kann, was dann eine Verfälschung der Daten nach sich zieht.

Die ReportID ist hier immer 0, da keine benötigt wird. Beim IO-Warrior gibt es diverse IDs um die Funktionen zu aktivieren und zu nutzen. Beim JoyWarriorF gibt es das nicht.

Das "CMD" Byte ist muss ich leider zugeben etwas zweidutig. Es gibt hier zwei Zustände 0x00 und 0x82. Das hat die Bedeutung, dass wenn man 0x82 setzten muss um Einstellungen vorzunehmen. Ebenfalls wird dadurch der JoyWarrior dazu veranlasst, das Senden der Achsdaten abzuschalten. Auf diesem Weg kann man auch direkt die Daten ungefiltert (RAW-Daten) des Sensors auslesen. 0x00 veranlasst den JoyWarrior wieder dazu Daten zu senden. Wenn man das Byte 0x82 vergisst wieder zu "deaktivieren", dann wird der JoyWarrior keine Daten mehr senden, es sei den man zieht den USB-Stecker, dann vergisst er diesen Status.

[Anmerkung]
Wenn man nur die Daten des JoyWarriorF auslesen will kann man auch die API-Funktionen des Betriebsystems oder DirectInput verwenden. Es ist zum lesen nicht zwingend notwendig die ReadFile()-Methode zu verwenden.
Abteilung: Softwareentwicklung
Folge uns auf Twitter
Follow us on twitter
karula
Posts: 4
Joined: Tue Nov 08, 2011 6:01 pm

Re: Dokumentation des Jow Warrior 24f14

Post by karula »

Danke, das hilft doch weiter.
'direkt die Daten ungefiltert auslesen' verstehe ich so, daß man dann über Interface 1 die entsprechenden
Register des Bosch-Chips einzeln auslesen kann? d.h. die Datenrate bleibt dann entsprechend niedrig.

Viele Grüße

Walter
User avatar
Christoph Jung
Posts: 670
Joined: Sun Oct 08, 2006 3:43 pm
Location: Germany / Berlin
Contact:

Re: Dokumentation des Jow Warrior 24f14

Post by Christoph Jung »

Im prinzip schon.
Die Daten sind für jede Achse in jeweil 2 Registern hinterlegt, die man sich dann zusammenbauen muss. Das bringt aber keinen Vorteil von der Geschwindigkeit her und ist auch nicht präziser. Das Rausch, was wir in unserem Chip rausfiltern ist um ein vielfaches größer und man müsste das alles in Software implementieren, was Laufzeit frisst.
Abteilung: Softwareentwicklung
Folge uns auf Twitter
Follow us on twitter
Post Reply