Joystick test built for throttles, twist and hat switches

Because it is two separate controllers. A stick-and-throttle set connects as two USB devices with their own descriptors, their own button numbering and their own axis lists, and every operating system since USB gaming devices existed has enumerated them that way — your simulator binds them separately too. This page stacks all of them rather than making you pick one, which is the whole reason it does not draw a picture. Slot numbers come from the order the devices woke up, so unplugging one and plugging it back in can reshuffle them.

That is the normal encoding for a point-of-view hat and not a fault. DirectInput describes a hat as a single value in hundredths of a degree with a separate 'released' state, and a browser rescales that onto one axis instead of splitting it into buttons. The eight directions land on an even ladder between -1 and 1, and the released hat lands at about 3.29 — outside the range an axis is permitted to use at all, which is precisely how this page recognizes a hat and starts printing compass directions for it. Some sticks do expose the hat as four real buttons instead; those show up as ordinary numbered chips.

Because the standard mapping stops at four axes and has no vocabulary past them. Names exist only for a left stick and a right stick, and only when the browser recognized the device well enough to remap it — which it rarely does for flight hardware. Everything beyond that arrives in raw firmware order with an index and nothing else. No web page can do better, because the information genuinely is not sent; the HID report descriptor that would name them is not exposed to JavaScript.

No, that is what a throttle should do. A stick axis is centered and swings both ways, so its rest is zero; a throttle is a one-way lever with idle at one end, so its rest is one extreme of the range and full power is the other. Rudder pedals with a toe-brake axis behave the same. What matters is that the value moves smoothly across the whole band as you push, and that both ends actually reach their stop — the range figure beside each bar is there to check exactly that.

Older pedal sets combine the two toe brakes into a single differential axis and report rudder separately, which gives you two axes for three physical inputs. That is a hardware design choice from the days when axis counts were scarce, not something software can undo. Some sets have a switch on the underside to change between combined and separate modes. If you see three axes but one of them never moves, check whether the pedals need a separate USB connection from the stick — a set daisy-chained through a throttle sometimes enumerates only when the throttle is powered.

Yes — the operating system's calibration is applied before the browser sees anything, so a stick you have just centered and ranged in the game controller panel reads correctly on this page too. What does not carry over is anything a game does on top: response curves, in-game dead zones, sensitivity and axis inversion all live inside the simulator and are invisible here. That difference is useful. If an axis looks correct on this page and wrong in the sim, the sim's own settings are where the problem is.

The inputs, yes; the force feedback, no. A wheel enumerates as a gamepad with the steering as one axis and the pedals as one axis each, and all of that reads normally here — including whether the wheel returns to exactly the same center after a full lock-to-lock sweep. Force feedback is a different matter: the only haptic command the Gamepad API defines is a two-motor rumble, which a force-feedback base does not implement, so a wheel that goes limp in a browser is behaving exactly as designed.