Teensy Mouse 3'rd axis operates at reduced resolutions.

AMaraklov

Active member
Using Teensy 4.1 or 3.2 and Mouse+Keyboard+Joystick profile
Arduino 1.8.19
Teensyduino 1.56

This is the latest code for the teensy 4.1 I've been using to test
Code:
/* Complete USB Joystick Example
   Teensy Mouse Input Test, Print Each Axis
*/

#include "QuadEncoder.h"

int pullup = 1; // Weather or not to use a pullup resistor

// Change these pin numbers to the pins connected to your encoder.
// Allowable encoder pins:
// 0, 1, 2, 3, 4, 5, 7, 30, 31 and 33
// Encoder on channel 1 of 4 available
// Phase A (pin0), PhaseB(pin1), Pullup = pullup(variable)
QuadEncoder encRed(1, 0, 1, pullup);
// Encoder on channel 2 of 4 available
//Phase A (pin2), PhaseB(pin3), Pullups = pullup(variable)
QuadEncoder encYellow(2, 2, 3, pullup);
// Phase A (pin4), PhaseB(pin7), Pullups = pullup(variable)
QuadEncoder encBlue(3, 4, 7, pullup);
//!! Avoid using pins with LEDs attached

//Debug Enable
bool debug = false;

// Mouse Sensetivity for all 3 wheels as it's presumed you're using the same encoders
const float multiplier = 1.0;

void setup() {
  // you can print to the serial monitor while the joystick is active!
  if (debug) Serial.begin(9600);
    
   // Setup Encoders
   encRed.setInitConfig();
   //Optional filter setup
   encRed.EncConfig.filterCount = 5;
   encRed.EncConfig.filterSamplePeriod = 255;
   encRed.init();
   encYellow.setInitConfig();
   encYellow.EncConfig.filterCount = 5;
   encYellow.EncConfig.filterSamplePeriod = 255;
   encYellow.init();
   encBlue.setInitConfig();
   encBlue.EncConfig.filterCount = 5;
   encBlue.EncConfig.filterSamplePeriod = 255;
   encBlue.init();
}

//Set Default Movement Values for mouse axis
long positionRed  = -999;
long positionYellow = -999;
long positionBlue = -999;

//Encoder History
int newRedEnc, newYellowEnc, newBlueEnc;
int oldRedEnc, oldYellowEnc, oldBlueEnc;

void loop() {   
  // Read The Encoders
  
  newRedEnc = encRed.read();
  newYellowEnc = encYellow.read();
  newBlueEnc = encBlue.read();

  // To Debug values being sent to the mouse driver, this doesn't show the behavior of the mouse.
  // Values are sequential but mouse bahvior seems to skip values, like a scroll wheel.
  if (debug) {
    if ( newBlueEnc != oldBlueEnc || newYellowEnc != oldYellowEnc || newRedEnc != oldRedEnc){  
      Serial.print("Red : ");
      Serial.print(newRedEnc);
      Serial.print(" Yellow : ");
      Serial.print(newYellowEnc);
      Serial.print(" Blue : ");  
      Serial.println(newBlueEnc);    
    }
  }

  // Update Mouse (Steering Wheel) position(s) if it's changed
  if (newRedEnc != oldRedEnc){
    Mouse.move(newRedEnc - oldRedEnc, 0);    
  }
  if (newYellowEnc != oldYellowEnc){
    Mouse.move(0, newYellowEnc - oldYellowEnc);    
  }
  if (newBlueEnc != oldBlueEnc){
    Mouse.scroll( newBlueEnc - oldBlueEnc);     
  }

  // Populate Old Values before moving on to the next sample
  oldRedEnc = encRed.read();
  oldYellowEnc = encYellow.read();
  oldBlueEnc = encBlue.read();
    
  // a brief delay, so this runs "only" 200 times per second
  delay(2);  
}

The issue is not in the input as it's consistent when you look back at the log, the values are sequential, and consistent. The issue is how the input is perceived by applications X and Y are smooth and operate like mouse wheels, Z/ Scroll Wheel seems to be more buffered or more jerky... which for a mouse wheel would make sense, you're scrolling so you want some lines to be skipped to make scrolling faster. But it's throwing software that needs this as a 3'rd encoder like Mame Etc... The result is that it judders all over the place, now to eliminate this I moved the encoders around, and the problem stuck with blue, I then moved the wiring and whatever was connected to the mouse scroll wheel input was misbehaving no matter the physical connections or encoder. I tried this with a 3.2 first and then with the QuadEncoder.h library and the result is the same.

So the constant is the mouse input, not what's driving the value, or how it's wired.

I'd add a second teensy, but then I have to deal with identifying which mouse and axis is driving what. I'd also have 3 devices driving the x axis, the mouse and 2 teensy's, I suspect that the scroll wheel is configured differently in Teensy or the HID where this occurs. As I have turned off all mouse acceleration, it's possible the scroll wheel deals with an internal acceleration factor.
 
Hmmm. It's not uncommon for 3-axis accelerometers to have lower resolution on the Z axis. I wonder it that is what's going on.
 
Mice use encoders, not accelerometers - (that's a Wii controller!). Scroll wheels are deliberately coarse
in my experience as nominally each click is intended to jump one line of text, not a pixel.

I think rather than tinker with the hardware you may be wanting to low-pass filter the Z-axis readings
to reduce/eliminate the steppiness?
 
Can the Mouse Move function be modified to accept a 3'rd axis, and if so where would I attempt this? This would be great beyond my use case, as you could make a controller like a Space Mouse, with 3D Inputs...
 
Can the Mouse Move function be modified to accept a 3'rd axis, and if so where would I attempt this? This would be great beyond my use case, as you could make a controller like a Space Mouse, with 3D Inputs...

Sorry I have not done much with this end of the USB, more on the usb host code...

But you may need to be more explicit on what you are wanting as the move function already takes 4 values:
void move(int8_t x, int8_t y, int8_t wheel=0, int8_t horiz=0) {
 
Yeah I've explored a little further on how Mice are actually implemented in Teensy, and I've walked right into the weeds...
https://forum.pjrc.com/threads/68580-usb_mouse_move-16-bit-x-and-y-request
So from your accurate assessment the mouse does take 4 values, X, Y, ScrollX, and ScrollY as there are some mice that have a horizontal scroll mechanism, I think the R.A.T. Line of mice
proA-rat-6plus-img03_5smd-fk.png
Have that when you look at the left of the mouse slightly above where your thumb would rest.
The issue is both are 8 bit values being sent... Which is fine, and could work, I'm just seeing something radically different in the third axis than the other two when I run the application I want to use it in.

Maybe I need to record what I'm seeing. I also don't know if it's the application's fault. I may try a U-Hid device which has 3 Axis to do this same thing, and I may have to fall back on, the issue for me using the U-Hid is when it sees a rotary potentiometer it expects to see its full deflection to map that to the given input axis of a joystick, and with the Driving application I'm using the pot is only used for 1/4 or less of the actual range, so re-mapping the values in teensy seemed like a viable alternative, which is was and works. The issue now is, that one device does the pots well, and the other could do the encoders, neither does both, and that seems ridiculous to me.

And because the U-HID supposedly can do this, I figure it's a configuration issue on the teensy side to be able to do this also... I'm just not experienced enough to dig THAT deep into teensy to figure out why the values aren't being received by Mame in a way that it needs.
 
Sorry, I know nothing about that mouse and how it works.

For example, does that mouse do everything using just the simple standard windows mouse driver or do you install some driver on windows that processes some of the data. I know with some mice, like some of the Microsoft and Logitech and the like they install drivers that may do special things.

That is if you plug the device in, is there just one HID endpoint defined or does have multiple endpoints? If it is all HID are all of the pages/usages like normal mice...
(top usage of 0x10002 or 0x10001)

And the values are in the normal cases... From USB Host we look for:
Code:
	} else if (usage_page == 1) {
		switch (usage) {
		  case 0x30:
			mouseX = value;
			break;
		  case 0x31:
			mouseY = value;
			break;
		  case 0x32: // Apple uses this for horizontal scroll
			wheelH = value;
			break;
		  case 0x38:
			wheel = value;
			break;
		}
	} else if (usage_page == 12) {
		if (usage == 0x238) { // Microsoft uses this for horizontal scroll
			wheelH = value;
		}
	}
As you see we had to special case... We also look at page 9 for the buttons...

So again without seeing more data like a formatted HID description and endpoints, hard to say...

Now if you plug it into usbhost of t3.6 or t4.x and ran the HIDDeviceInfo sketch maybe would know more.
 
I didn't mean to distract from the issue I'm having, the mouse depicted is an example of the HID packages that come from that have a horizontal scroll and that works without a driver, so does the U-HID so there has to be some hardware spec (HID Device) that can make all 3 axis act the same with the same resolution / bit depth.

Where is that code from? I may need to change that to pickup on the changes I made in the HID definition...
 
It's interesting I got a U-Hid today, and I was looking at the HID Definition with USBlyzer, and it looks like it has two mice hid devices, so maybe that's how it's doing 3 axes... 2 from one and a 3'rd from a second hid... but they'd have to be merged as I would remember mame saying Mouse2_X Mouse2_Y Mouse3_X... and it doesn't it says Mouse2_X, Mouse2_Y, Mouse2_Z... Mouse1 being the actual mouse in my hands...
UHID.jpg

I'm not giving up yet... there has to be a way...
 
Again sorry, not an expert here, but:

If we look at Hid page 1 in the HID Tables
https://www.google.com/url?sa=t&rct...ut1_12v2.pdf&usg=AOvVaw37jTa_X9_oNnwzAFuWxTDL

You see:
screenshot.jpg
And I know USB Host code Mouse code looks at
X: 0x30 Y: 0x31 WheelH: 0x32 and 0x38 for Wheel

I don't see 32 in the usb_desc.c code (T4)...
Code:
#ifdef MOUSE_INTERFACE
// Mouse Protocol 1, HID 1.11 spec, Appendix B, page 59-60, with wheel extension
static uint8_t mouse_report_desc[] = {
        0x05, 0x01,                     // Usage Page (Generic Desktop)
        0x09, 0x02,                     // Usage (Mouse)
        0xA1, 0x01,                     // Collection (Application)
        0x85, 0x01,                     //   REPORT_ID (1)
        0x05, 0x09,                     //   Usage Page (Button)
        0x19, 0x01,                     //   Usage Minimum (Button #1)
        0x29, 0x08,                     //   Usage Maximum (Button #8)
        0x15, 0x00,                     //   Logical Minimum (0)
        0x25, 0x01,                     //   Logical Maximum (1)
        0x95, 0x08,                     //   Report Count (8)
        0x75, 0x01,                     //   Report Size (1)
        0x81, 0x02,                     //   Input (Data, Variable, Absolute)
        0x05, 0x01,                     //   Usage Page (Generic Desktop)
        0x09, 0x30,                     //   Usage (X)
        0x09, 0x31,                     //   Usage (Y)
        0x09, 0x38,                     //   Usage (Wheel)
        0x15, 0x81,                     //   Logical Minimum (-127)
        0x25, 0x7F,                     //   Logical Maximum (127)
        0x75, 0x08,                     //   Report Size (8),
        0x95, 0x03,                     //   Report Count (3),
        0x81, 0x06,                     //   Input (Data, Variable, Relative)
        0x05, 0x0C,                     //   Usage Page (Consumer)
        0x0A, 0x38, 0x02,               //   Usage (AC Pan)
        0x15, 0x81,                     //   Logical Minimum (-127)
        0x25, 0x7F,                     //   Logical Maximum (127)
        0x75, 0x08,                     //   Report Size (8),
        0x95, 0x01,                     //   Report Count (1),
        0x81, 0x06,                     //   Input (Data, Variable, Relative)
        0xC0,                           // End Collection
        0x05, 0x01,                     // Usage Page (Generic Desktop)
        0x09, 0x02,                     // Usage (Mouse)
        0xA1, 0x01,                     // Collection (Application)
        0x85, 0x02,                     //   REPORT_ID (2)
        0x05, 0x01,                     //   Usage Page (Generic Desktop)
        0x09, 0x30,                     //   Usage (X)
        0x09, 0x31,                     //   Usage (Y)
        0x15, 0x00,                     //   Logical Minimum (0)
        0x26, 0xFF, 0x7F,               //   Logical Maximum (32767)
        0x75, 0x10,                     //   Report Size (16),
        0x95, 0x02,                     //   Report Count (2),
        0x81, 0x02,                     //   Input (Data, Variable, Absolute)
        0xC0                            // End Collection
};
#endif
I do see the other three... Not sure how hard it would be to add. My quick look at the t3 version looks the same.
But again not sure what your mouse does
 
So because 32 is being used for the Mac side scrolling, according to the Mouse.cpp
Code:
case 0x32: // Apple uses this for horizontal scroll
			wheelH = value;
			break;
I mean, I should be able to utilize it just not with a mac? Or I don't really care, as I want to use it with mame, and what the OS does with it is not pointless but much less important to me... in my use case... The issue for me is that it acts erratic, moving back and forth, I really do need to make a video and link it, I'll try and do that tomorrow...
 
Sorry again not an expert on the USB types from teensy to pc... Although have picked up a little knowledge.

What I have said was there are some standards for HID, in which for example if the descriptor says that a field is in the desktop page (0x01) and has the usage of 0x30 it is an "X" value. 31->Y, 32->Z ...
The comment in the usb host code that Apple 0x32... was that someone had some form of Apple mouse that appeared to generate an 0x32 with their mouse when you were doing a horizontal scroll...
So we added support to retrieve that value...

And I was trying to say I did not see in the HID descriptors for Teensy the usage of 0x32... So not sure if that may or may not be the values that a different joystick uses for a third axis. It could could instead use
Rx, Ry, Rz or ... Or could be on Custom page or ...

Sorry beyond that without seeing more actual data like I mentioned dumping the HID information, or USB dumps or ... Really not much more I can guess at here.
 
Right, so is it possible the 0x32 is causing issues for me to implement a Z Axis.
I don't know where I read it, but in a mouse driver it said anything beyond 0x31 were additional axes...

This has a mention of 0x32 being Z but in general USB HID terms not specific to mice...
https://www.freebsddiary.org/APC/usb_hid_usages.php

And I understand I'm in the minority here, as most people only care about X,Y but I feel I may have stumbled across a bug or inconsistency, in the way the axes are being driven, I mean I can't definitively say I was able to get 16 bit values out of the 3'rd axis, as I don't know if a cast later down the road caused the value to be truncated, but in the other post I was able to successfully implement a 16 bit register for 0x32, as it "worked" or drove the scroll function on a PC, but still lacked consistency in Mame, from X and Y
 
I don't know if you are int the minority or not...

What I don't know is if Windows and/or linux and or MAC have support in their device driver to support additional axis and if there is a standard for what it should be.

The question is, more do you have an actual device, that you wish for the Teensy to emulate and what does that device output for different axis, buttons, etc. Without that information we are flying blind.

Again if you have one of these devices and you have a teensy (3.6, MMOD, T4 or T4.1) with USB host setup that you can plug in the mouse, you can get a lot more information. HIDDeviceInfo which I mentioned earlier.

Example I plugged in a Glorious HQ ... Mouse into a Micromod...

Like sets of Endpoints and the like:
Code:
USB HID Device Info Program

This Sketch shows information about plugged in HID devices

*** You can control the output by simple character input to Serial ***
R - Turns on or off showing the raw data
C - Toggles showing changed data only on or off
<anything else> - toggles showing the Hid formatted breakdown of the data


USBDeviceInfo claim this=2000B664

****************************************
** Device Level **
  vid=258A
  pid=36
  bDeviceClass = 0
  bDeviceSubClass = 0
  bDeviceProtocol = 0
09 04 00 00 01 03 01 02 00 09 21 11 01 00 01 22 47 00 07 05 81 03 08 00 01 09 04 01 00 01 03 01
01 00 09 21 11 01 00 01 22 D5 00 07 05 82 03 08 00 01 

USBDeviceInfo claim this=2000B664

****************************************
** Interface Level **
09 04 00 00 01 03 01 02 00 09 21 11 01 00 01 22 47 00 07 05 81 03 08 00 01 09 04 01 00 01 03 01
01 00 09 21 11 01 00 01 22 D5 00 07 05 82 03 08 00 01 
 bInterfaceNumber = 0
 number end points = 1
 bInterfaceClass =    3
 bInterfaceSubClass = 1
    HID (BOOT)
 bInterfaceProtocol = 2
report descriptor size = 71
  endpoint = 81
    attributes = 3 Interrupt
    size = 8
    interval = 1

USBDeviceInfo claim this=2000B664

****************************************
** Interface Level **
09 04 01 00 01 03 01 01 00 09 21 11 01 00 01 22 D5 00 07 05 82 03 08 00 01 
 bInterfaceNumber = 1
 number end points = 1
 bInterfaceClass =    3
 bInterfaceSubClass = 1
    HID (BOOT)
 bInterfaceProtocol = 1
report descriptor size = 213
  endpoint = 82
    attributes = 3 Interrupt
    size = 8
    interval = 1
*** Device HID1 258a: 36 - connected ***
  manufacturer: SINOWEALTH
  product: Wired Gaming Mouse
HIDDumpController Claim: 258a:36 usage: 10002 - Yes
*** HID Device hdc1 258a: 36 - connected ***
  manufacturer: SINOWEALTH
  product: Wired Gaming Mouse

But then for each HID input like moving the mouse I get messages like:
Code:
ID(10002): 00 01 00 00 00 00 00 00 
Begin topusage:10000 type:2 min:0 max:1
  usage=90001, value=0 (BUTTON 1)
  usage=90002, value=0 (BUTTON 2)
  usage=90003, value=0 (BUTTON 3)
  usage=90004, value=0 (BUTTON 4)
  usage=90005, value=0 (BUTTON 5)
  Begin topusage:10000 type:6 min:-32768 max:32767
    usage=10030, value=1(X)
    usage=10031, value=0(Y)
    Begin topusage:10000 type:6 min:-128 max:127
    usage=10038, value=0(Wheel)
    Begin topusage:10000 type:6 min:-128 max:127
    usage=C0238, value=0(AC Pan)
  END:
HID(10002): 00 00 00 FF FF 00 00 00 
Begin topusage:10000 type:2 min:0 max:1
  usage=90001, value=0 (BUTTON 1)
  usage=90002, value=0 (BUTTON 2)
  usage=90003, value=0 (BUTTON 3)
  usage=90004, value=0 (BUTTON 4)
  usage=90005, value=0 (BUTTON 5)
  Begin topusage:10000 type:6 min:-32768 max:32767
    usage=10030, value=0(X)
    usage=10031, value=-1(Y)
    Begin topusage:10000 type:6 min:-128 max:127
    usage=10038, value=0(Wheel)
    Begin topusage:10000 type:6 min:-128 max:127
    usage=C0238, value=0(AC Pan)
  END:
Where the usage like 90001 is showing page 9 usage:1 which translates to Button 1.

likewise the 10030, 10031, 10038 for x, y, z (upper word is page in hex so page 1)...

You can also set it to output only what changed... so you click a button you see which one...
As for AC Pan not sure what that one does...

It may simply turn out that your 3rd axis is simply mapped to something like wheel, and maybe they tell the windows driver to reconfigure such that each click is not N lines or N pages but N pixels or the like.
But again only guessing.
 
Yeah that helps out immensely! I didn't understand that I could plug the U-Hid into the teensy to interrogate its output. I thought you meant that I could ask teensy to tell me what it's outputting, which is useful in a sense, but because the behavior isn't what's needed its usefulness is limited to what I don't want... with the ability to have teensy act as a pseudo logic analyzer that's much more valuable... I'll have to look as to how to do that and if I need to fashion a USB connector to do so...
 
So I got the information, sorry with the weekend, I had to wait 'till the house settled down...

This is the Raw Data :

Code:
D209:1501: Universal Human Interface Device - UHID Mouse Device
PATH:\\?\hid#vid_d209&pid_1501&mi_03&col02#7&135daf0&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}
DESCRIPTOR:
  05  01  09  02  A1  01  85  02  09  01  A1  00  05  09  19  01
  29  03  15  00  25  01  35  00  45  01  65  00  55  00  75  01
  95  03  81  02  95  05  81  03  05  01  09  30  26  FF  7F  45
  00  75  10  95  01  81  06  09  31  81  06  09  32  81  06  C1
  00  C1  00
  (67 bytes)

And this the converted output
Code:
0x05, 0x01,        // Usage Page (Generic Desktop Ctrls)
0x09, 0x02,        // Usage (Mouse)
0xA1, 0x01,        // Collection (Application)
0x85, 0x02,        //   Report ID (2)
0x09, 0x01,        //   Usage (Pointer)
0xA1, 0x00,        //   Collection (Physical)
0x05, 0x09,        //     Usage Page (Button)
0x19, 0x01,        //     Usage Minimum (0x01)
0x29, 0x03,        //     Usage Maximum (0x03)
0x15, 0x00,        //     Logical Minimum (0)
0x25, 0x01,        //     Logical Maximum (1)
0x35, 0x00,        //     Physical Minimum (0)
0x45, 0x01,        //     Physical Maximum (1)
0x65, 0x00,        //     Unit (None)
0x55, 0x00,        //     Unit Exponent (0)
0x75, 0x01,        //     Report Size (1)
0x95, 0x03,        //     Report Count (3)
0x81, 0x02,        //     Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x95, 0x05,        //     Report Count (5)
0x81, 0x03,        //     Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x01,        //     Usage Page (Generic Desktop Ctrls)
0x09, 0x30,        //     Usage (X)
0x26, 0xFF, 0x7F,  //     Logical Maximum (32767)
0x45, 0x00,        //     Physical Maximum (0)
0x75, 0x10,        //     Report Size (16)
0x95, 0x01,        //     Report Count (1)
0x81, 0x06,        //     Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0x09, 0x31,        //     Usage (Y)
0x81, 0x06,        //     Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0x09, 0x32,        //     Usage (Z)
0x81, 0x06,        //     Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0xC1, 0x00,        //   End Collection
0xC1, 0x00,        // End Collection
 
It does look interesting:
Like it does put Z on 0x32 (0x10032)

And like the Glorious ... Mouse I showed above, both of these mice have 16 bit values for X, Y and in your case Z

They show different ranges for the Min/MAX which could simply be differences on how the reporting showed up here...

Again this is an area that I have not played that much with, nor am owner of code, nor have time/energy to try to solve this...
This will require code changes in the cores.

But the approaches I would take and questions I would ask include:

Like Ask Paul: If someone made a version that supported 16 bit mice, should the be in replacement for the 8 bit support, or should it be like Joystick usb code where you can choose to use the little/simple version or the many more controls version...

Lets assume T4.x... similar changes would be needed to be made in cores\teensy4 ... cores\teensy3 for others...

Note: I will probably miss a few places that may need updates:

usb_desc.c -
Area that starts off:
Code:
// Mouse Protocol 1, HID 1.11 spec, Appendix B, page 59-60, with wheel extension
static uint8_t mouse_report_desc[] = {
        0x05, 0x01,                     // Usage Page (Generic Desktop)
Would need to be updated to have the HID definitions ...

usb_desc.h - probably #define MOUSE_SIZE 8
Might need to change. Easiest to see what it actually outputs.

usb_mouse.h/usb_mouse.c: these all have functions with 8 bit values:
Code:
       void move(int8_t x, int8_t y, int8_t wheel=0, int8_t horiz=0) {
Would need to change them from int8_t to int16_t

The code in usb_mouse_move and other places that assumes the layout of the binary data would need to be updated for the new layout out data to be transmitted.

Again sorry I know that is not a complete description, but if it is something that you wish to try out, that is what I would do.
 
Well I'm glad I'm not stark raving mad... thinking I was nuts to want 16 bit values... :)

https://forum.pjrc.com/threads/68580-usb_mouse_move-16-bit-x-and-y-request

The post I linked way back in reply 2 or so has a bunch of the files that need the changes to make the jump to 16 bit.. with the exception of the changes to Z... so I may go back to that and see if I can implement those and make my own core libraries.. what I'm not certain of, it seemed if I make changes to The Teensy4 folder, I didn't need to re-compile... externally outside of Arduino, in C or C++ is that accurate, does the library get compiled on the fly? Or is there a process for me to make changes to the core?

Also I guess the question like you posed is, is it a valid "Alternative" Device to facilitae a "HR Mouse" device, or some kind of switch in the code to state that you want to emulate a High Rez Mouse?

And how do I get Paul's attention on this? PM?
 
So I've not had any luck, if I implement swapping everything to 16bit (I must be missing something) it still doesn't' work on the third encoder (although all 3 axes are getting data), if I implement the U-Hid HID profile I get nothing on any axis even though it defines 0x30, 0x31, 0x32... must be that the profile for those is a definition or so deeper... I don't know I feel like I'm missing a file or something I also tried to use #define USBHOST_PRINT_DEBUG in the top of my script, as well as un-commented in the header, and it doesn't seem to say / log anything where would I find / look for this output?
 
I know this thread is a bit old, but I ran into the same issue and Google directed me to this thread. Not sure if it'd work for your needs, but I ended up solving the 3rd and 4th axis issue by adding USB emulation of two mice, and then simply used X and Y on each mouse for the 4 encoders. I posted the project here: https://forum.pjrc.com/index.php?threads/teensy-two-mouse-modification-demo.74515/ .

Note that the Windows mouse cursor itself doesn't differentiate between the two mice (e.g. if Mouse 1 moves left and Mouse 2 moves right, they cancel each other out)... but for example MAME supports mapping inputs from separate mice using the "multimouse" option.

DogP
 
Back
Top