Hi weiss jemand welche Datenrate ein Bluetooth mouse maximal erreicht? Danke
Welchen BT-Standard unterstützt deine Maus konkret? Mit dieser Info schaust Du in die entsprechenden BT-Spezifikationen und weißt es. Man kann das nicht generell beantworten, es gab und gibt eine Vielzahl an Varianten.
Die ct hat vor einem Jahr speziale Gamer Mäuse mit 8kHz vorgestellt und getestet, gängig ist 1kHz. Fazit: alles für die Katz ;-) https://www.heise.de/select/ct/2022/16/2213116202879925547 Sollte ich Parkinson bekommen, könnte ne schnelle Maus das Zittern realistisch auf den Mauszeiger übertragen ... aber wer will das schon.
https://de.wikipedia.org/wiki/Bluetooth#/media/Datei:%C3%9Cbersicht_zur_Entwicklung_des_Bluetooth-Standards.png Auch wenn auf der Maus "Bluetooth 5.0" steht, wird sie keineswegs solche Datenraten, die laut Standard möglich sind, benötigen oder benutzen.
Harald A. schrieb: > Welchen BT-Standard unterstützt deine Maus konkret? Mit dieser Info > schaust Du in die entsprechenden BT-Spezifikationen und weißt es. Und innerhalb eines Standards gibt es verschiedenen Profile, für Mäuse ist HID ("Human Interface Device) das Gesuchte. Das BT-HID-Profile ist vom USB-HD-Profile abgeleitet, das isochrones (?) Polling mit 125 Hz vorsieht. Und da eine mouse nur ein paar bytes pro Polling zu übertragen hat ist die Datenrate entsprechend gering aber völlig ausreichend für Mauszeiger-Walzer über den gesamten Screen. https://en.wikipedia.org/wiki/USB_human_interface_device_class#Mouse
Wozu sollte diese Info relevant sein? Wenn sie relevant wäre, würden die Hersteller sie angeben.
Mat. K. schrieb: > 100-1000 Hz lese ich. Aber wieviel Byte den? Wenn Du den Hintergrund deiner Frage erläutern würdest, könnte man evtl. zielgerichtet antworten. Jeweils ein 16Bit Wert für X und Y, dazu noch noch ein Byte für Tasten/Mausrad würden reichen. Also netto 5 Byte x 125Hz x 8 Bit = 5 kbit/s als untere Grenze. Mit dem ganzen Overhead (den ich nicht kenne) wird es sicher ein Vielfaches davon.
:
Bearbeitet durch User
Kaj G. schrieb: > Wozu sollte diese Info relevant sein? Und was an Info an den Gamer als potentiellen Käufer an "Infos" weitergegeben wird, bestimmt eh die Marketing-Abteilung. Und die kann meist nur "Muss man haben" :-( > Wenn sie relevant wäre, würden die Hersteller sie angeben. Papperlapapp, für den Hersteller isz nur die Differenz zwischen Erstellungs- und Verkaufspreis relevant. Mat. K. schrieb: > 100-1000 Hz lese ich. Aber wieviel Byte den? Kommt auf die Message drauf an, mouse status sind 3 byte. Es gibt aber auch eine HID report long item message mit bis zu 256 byte data.Musst halt in den Standard/Lehrbuch/Tutorial/AppNote schauen, bspw.: http://ww1.microchip.com/downloads/en/AppNotes/01163a.pdf (Das ist USB, BT ist davon abgeleitet)
Klaus schrieb: > Jeweils ein 16Bit Wert für X und Y Wozu 16 Bit? Mäuse positionieren nicht absolut, sondern relativ, und geben nur die Änderung gegenüber der letzten Position aus, und für die werden 8 Bit je Achse dicke reichen.
Harald K. schrieb: > Klaus schrieb: >> Jeweils ein 16Bit Wert für X und Y > > Wozu 16 Bit? Mäuse positionieren nicht absolut, sondern relativ, und > geben nur die Änderung gegenüber der letzten Position aus, und für die > werden 8 Bit je Achse dicke reichen. Typischer Trugschluß eines von jeder praktischen Erfahrung unbedarften und auch theoretisch nicht ganz sattelfesten. 1) Es gibt "Mäuse", die eigentlich physisch keine sind, sich aber trotzdem als solche ausgeben. Typisch: Die (resistive) Toucheinheit von Displays. Und mit denen fällt es sehr leicht, Touch-Ereignisse zu generieren, die die 16Bit tatsächlich brauchen. 2) Mäuse mit besonders hoher physischer Auflösung. Auch bei denen kann es sehr leicht passieren, dass die Änderung zwischen zwei Abfragen nicht in 8Bit passen. 3) (last but not least) sieht der Standard halt an dieser Stelle einfach mal 16Bit-Werte vor. Mit einiger Wahrscheinlichkeit genau deshalb, weil die Entwickler des Standards halt einen deutlich weiteren Horizont hatten als du...
Danke für die überaus freundliche Art der Wissensvermittlung, es ist immer wieder schön, Deine sachlichen Beiträge zu lesen. Ich muss zugeben, mich nicht explizit mit BT-Mäusen beschäftigt zu haben; als ich die erste Maus protokolltechnisch untersuchte, gab es BT noch lange nicht.
Angehängte Dateien:
-
HID-Mouse_reprt.png
36 KB
> 3) (last but not least) sieht der Standard halt an dieser Stelle einfach > mal 16Bit-Werte vor. Nein, siehe Auszug im Anhang. Falls das in einem anderen Standard anders ist, kann man das sich mit einem Auszug aus diesen anderen Standard belegen.
DSGV-Violator schrieb: > Nein, siehe Auszug im Anhang. Wir reden über BT, nicht über USB. Das ist dir schon klar, oder?
Angehängte Dateien:
> Wir reden über BT, nicht über USB. Das ist dir schon klar, oder?
BT-HID ist aber von USB-HID abgeleitet. Das ist manchen Groß-Posaunisten
hier komplett entgangen, obwohl schon oben darauf hingewiesen wurde.
Deshalb der Standardauszug als Screenshot im Anhang.
Ich möchte diese dringend bitten, an der Beratungsresistenz zu arbeiten.
Und immer noch fehlt ein Link/Referenz auf die Standardvariante in der
angeblich 16bit Werte von der Mouse übertragen werden.
DSGV-Violator schrieb: > Und immer noch fehlt ein Link/Referenz auf die Standardvariante in der > angeblich 16bit Werte von der Mouse übertragen werden. Kurz reingesehen: Das USB-HID Protokoll sieht 8 Bits für den vereinfachten Boot-Modus vor, um dem BIOS den Umgang mit Maus und Tastatur zu erleichtern. Im normalen Modus scheint das Protokoll hinsichtlich der Länge der Datenfelder ziemlich flexibel zu sein, nicht nur 2x 16 Bits sondern auch z.B. 2x 12 Bit zuzulassen.
:
Bearbeitet durch User
> Kurz reingesehen: Das USB-HID Protokoll sieht 8 Bits für den > vereinfachten Boot-Modus vor, um dem BIOS den Umgang mit Maus und > Tastatur zu erleichtern. Im normalen Modus scheint das Protokoll > hinsichtlich der Länge der Datenfelder ziemlich flexibel zu sein, nicht > nur 2x 16 Bits sondern auch z.B. 2x 12 Bit zuzulassen. Und jetzt bitte mal nachrechnen, welche bitbreite für die Delta-Werte, also Änderung der Position pro Zeiteinheit für die Position x und y (Abtastung) nötig ist. Tipp: Auch bei Bewegungen in der Ebene genügen zur korrekten Beschreibung nicht die beiden Positions-dimensionen x und y, es muß auch ∂t als weitere Dimension in das Modell einfließen. Und bei einer endlichen Geschwindigkeit braucht man bei ausreichend schneller Positionsübermittlung (kleines ∂t) auch nur kleines ∂x und ∂y. Das sollte doch aus dem Schul-Physik-Kurs bekannt sein?!
DSGV-Violator schrieb: [...] > Tipp: Auch bei Bewegungen in der Ebene genügen zur korrekten > Beschreibung nicht die beiden Positions-dimensionen x und y, es muß auch > ∂t als weitere Dimension in das Modell einfließen. Als Polling-Frequenz wurden 100–1000 Hz genannt. Darsu ergibt sich ein ∂t von 1–10ms. > Und bei einer > endlichen Geschwindigkeit braucht man bei ausreichend schneller > Positionsübermittlung (kleines ∂t) auch nur kleines ∂x und ∂y. Das > sollte doch aus dem Schul-Physik-Kurs bekannt sein?! Rechnen wir doch mal. Ich schaffe aus dem Handgelenk locker eine laterale Mausbewegung mit 1m/s über eine Distanz von ca. 10cm. So eine schnelle Bewegung sollte noch korrekt gemeldet werden. Als Auflösung haben heutige Mäuse leicht auch hohe Werte wie z.B. 8000dpi. 10cm (also ca. 4 inch) in 100ms gibt damit also 32000 Punkte, die in 10 bis 100 Abfragen zu melden sind. Also zwischen 320 und 3200 Punkte als ∂x in jeder Meldung. Jetzt klar, warum man da 12 oder 16bit benötigt?
Für BT kann ichs nicht sagen, aber ein (absolutes) Grafiktablet meldet sich über USB genauso wie eine Maus als HID Device. Der Deskriptor ist genau der gleiche, nur das das Tablet sich eben als absolutes Device anmeldet. BTDT. Damit erklären sich auch die 16-bit Felder zwanglos.
:
Bearbeitet durch User
> Als Polling-Frequenz wurden 100–1000 Hz genannt. Darsu ergibt sich ein > ∂t von 1–10ms. Der Maus-Status wird aber im HID-Mouse-profile nicht per Polling sondern per Interrupt-Endpoint übertragen ... 3 Octets aller 100 Hz ... steht so im Standard. Und die Interruptfrequenz ist auch nicht variabel sondern konstant. Nehmen wir jetzt mal 100 Hz und einen Kreis der vom user in 100 ms gezeichnet wird. Dann übermittelt die Mouse 10 Punkte für den Kreis aus denen der Renderer bestenfalls ein 10-Eck, aber keinen Kreis am Monitor darstellen kann. Verbessern wir jetzt die Ortsauflösung der Mouse von 8 bit auf 12bit, bleiben es immer noch 10 Punkte für die Rekonstruktion der Mousespur. Das ist genauso krakelig wie bei der ersten Mouse, bestenfalls liegen die Eckpunkte des Krakelecks im (nicht sichtbaren) subpixel-bereich genauer auf der Kreislinie. Will man von dem Krakeln weg, muss man die Übermittlungsrate erhöhen beispielsweise auf 100 Punkte pro Kreis (1kHz bei 100 ms) was gleichzeitig den Bedarf an bits für ∂x und ∂y verkleinert. Was hilfreich ist weil man für die Übermittlung eines Datenpunktes auch weniger Zeit hat. > Rechnen wir doch mal. Ich schaffe aus dem Handgelenk locker eine > laterale Mausbewegung mit 1m/s über eine Distanz von ca. 10cm. So eine > schnelle Bewegung sollte noch korrekt gemeldet werden. Als Auflösung > haben heutige Mäuse leicht auch hohe Werte wie z.B. 8000dpi. > > 10cm (also ca. 4 inch) in 100ms gibt damit also 32000 Punkte, die in 10 > bis 100 Abfragen zu melden sind. Also zwischen 320 und 3200 Punkte als > ∂x in jeder Meldung. 32000 Punkte pro Dimension sind aber Quatsch für heutige Monitore mit Auflösungen im Bereich 3840 x 2160 . Ob die Mouse nun 16001 oder 16010 meldet, der Mousezeiger wird auf das selbe sichtbare Pixel bei ca 1600 geschoben. Ein typisches mousepad hat Abmaße im Bereich 200 mm x 150 mm. Falls damit ein Monitor mit 3840 x 2160 Pixel angesteuert werden soll, sind ca. 20 dots pro Milimeter also ausreichend. Verzehnfacht man jetzt die Dots pro Milimeter jur jeweils eine Dimension fährt man den gesamten Monitor schon auf einem Ausschnitt von 20 x 10 Milimeter (etwas größer als Daumennagel ab). Dazu muss man aber die Mouse auf den Hunderstel Milimeter genau Positionieren um ein einzelnes Pixel zu treffen. Das ist dann eher Benutzer-un-freundlich, und der Computer schaltet bei einer high dpi Mouse automatisch in den Modus in dem die zusätzlich übermittelten dot-bits ignoriert werden. Merke: Nicht alles was die Software konfigurieren kann, macht in der Praxis Sinn.
DSGV-Violator schrieb: > Und die Interruptfrequenz ist auch nicht variabel sondern konstant. > Nehmen wir jetzt mal 100 Hz Bei Gaming-Mäusen sind eher 1000 Hz üblich. Aber nicht bei Bluetooth-Mäusen. Hier kann man recht einfach die Rate prüfen: https://cps-check.com/polling-rate-check
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.