5 ms·

The proprietary protocol can use absolute positions between device/dongle, and then the dongle can translate to relative positions at the edge, by returning the

by hmry 1y ago

The proprietary protocol can use absolute positions between device/dongle, and then the dongle can translate to relative positions at the edge, by returning the difference since the last poll

freehorse 1y ago
Is position estimation from the signal that accurate for that?
- tehbeard 1y ago
  They don't mean the absolute real distance between dongle and mouse. They mean the mouse communicates an absolute position (relative to some arbitrary 0,0 the mouse decides upon) instead of a relative direction. Dongle can then take latest coord packet and diff it against previous coord packet to get a relative coord to pass via HID to the system. If the RF packets are lost, some latency occurs but the dongle still has the previous mouse coord and can make a fairly accurate correction once a packet gets thru (get's from A to D, but might skip points B+C).
  - pwg 1y ago
    What happens with that "absolute position relative to some arbitrary 0,0 picked by the mouse" when the user picks the mouse up off the table/pad/etc. and repositions it (i.e., they hit the edge of the pad and now "re-center" to continue moving left (or right) on screen). The mouse loses its 0,0 point reference as soon as it is picked up. It could send a "reset 0,0" packet of some form in this case, but now reception of that packet becomes critical to continuing to properly communicate motion to the attached computer.
    - justsomehnguy 1y ago
      > It could send a "reset 0,0" packet of some form in this case, but now reception of that packet becomes critical to continuing to properly communicate motion to the attached computer. And those "how I would have designed a wireless mouse protocol" guys are back at the square one.
    - hmry 1y ago
      That's not how mouse input works though, right? If I move my mouse cursor to 10,10, and then pick up the mouse and set it down somewhere else, it's still at coordinates 10,10. You don't need the mouse's physical absolute position, but just the cursor position (which is the sum of all the relative movements)
      - pwg 1y ago
        > That's not how mouse input works though, right? No, mouse input data does not work that way. My reply was referring to @tehbeard's suggestion that the mouse could be modified to send absolute coordinates instead, and I was pointing out a reason why that modification would not work out so well.
  - freehorse 1y ago
    That sounds like a software problem to me, not one that requires a hardware solution. There is nothing in what you describe that cannot be performed through bluetooth packets. I am not sure which dongles make these corrections, but my experience with dongles is worse than bluetooth. Typically, a mouse is very close to the bluetooth antenna of a computer, and I have not really experienced any sort of connection issues due to missing packages etc. In contrast, I have had tons of issues with usb dongles due to usb interference.
- numpad0 1y ago
  No, mice sensors are far from being SoTA linear encoders. They return approximate instantaneous movements somehow when read request is received. Mouse controller chips(USB or RF or Bluetooth) pack and report up the movements, that's it. (psa: none of Chinese ADNS-2610 clones have the raw pixel output debug command. Maybe security implications or maybe something else, either way, mouse-as-microscope hacks don't work on sensors extracted from e-wastes)
Findecanor 1y ago
Precisely. That is how I would have designed a wireless mouse protocol: using wrapping counters and sending the counter values. The HID protocol does not support an input value that is Absolute/Wrap (although it could be extended to do so, and I think that it should) I'd think it would also be possible to get around congestion problems by using tricks such as multiple channels and/or interference detection on top of BLE. But only Logitech knows how Bolt actually works.

by hmry 1y ago

The proprietary protocol can use absolute positions between device/dongle, and then the dongle can translate to relative positions at the edge, by returning the difference since the last poll

freehorse 1y ago

Is position estimation from the signal that accurate for that?

tehbeard 1y ago
They don't mean the absolute real distance between dongle and mouse. They mean the mouse communicates an absolute position (relative to some arbitrary 0,0 the mouse decides upon) instead of a relative direction. Dongle can then take latest coord packet and diff it against previous coord packet to get a relative coord to pass via HID to the system. If the RF packets are lost, some latency occurs but the dongle still has the previous mouse coord and can make a fairly accurate correction once a packet gets thru (get's from A to D, but might skip points B+C).
- pwg 1y ago
  What happens with that "absolute position relative to some arbitrary 0,0 picked by the mouse" when the user picks the mouse up off the table/pad/etc. and repositions it (i.e., they hit the edge of the pad and now "re-center" to continue moving left (or right) on screen). The mouse loses its 0,0 point reference as soon as it is picked up. It could send a "reset 0,0" packet of some form in this case, but now reception of that packet becomes critical to continuing to properly communicate motion to the attached computer.
  - justsomehnguy 1y ago
    > It could send a "reset 0,0" packet of some form in this case, but now reception of that packet becomes critical to continuing to properly communicate motion to the attached computer. And those "how I would have designed a wireless mouse protocol" guys are back at the square one.
  - hmry 1y ago
    That's not how mouse input works though, right? If I move my mouse cursor to 10,10, and then pick up the mouse and set it down somewhere else, it's still at coordinates 10,10. You don't need the mouse's physical absolute position, but just the cursor position (which is the sum of all the relative movements)
    - pwg 1y ago
      > That's not how mouse input works though, right? No, mouse input data does not work that way. My reply was referring to @tehbeard's suggestion that the mouse could be modified to send absolute coordinates instead, and I was pointing out a reason why that modification would not work out so well.
- freehorse 1y ago
  That sounds like a software problem to me, not one that requires a hardware solution. There is nothing in what you describe that cannot be performed through bluetooth packets. I am not sure which dongles make these corrections, but my experience with dongles is worse than bluetooth. Typically, a mouse is very close to the bluetooth antenna of a computer, and I have not really experienced any sort of connection issues due to missing packages etc. In contrast, I have had tons of issues with usb dongles due to usb interference.
numpad0 1y ago
No, mice sensors are far from being SoTA linear encoders. They return approximate instantaneous movements somehow when read request is received. Mouse controller chips(USB or RF or Bluetooth) pack and report up the movements, that's it. (psa: none of Chinese ADNS-2610 clones have the raw pixel output debug command. Maybe security implications or maybe something else, either way, mouse-as-microscope hacks don't work on sensors extracted from e-wastes)

Findecanor 1y ago

Precisely. That is how I would have designed a wireless mouse protocol: using wrapping counters and sending the counter values. The HID protocol does not support an input value that is Absolute/Wrap (although it could be extended to do so, and I think that it should) I'd think it would also be possible to get around congestion problems by using tricks such as multiple channels and/or interference detection on top of BLE. But only Logitech knows how Bolt actually works.