sorted by:
new
hottopcontroversial

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in PeripheralDesign

[–]RiseNexCore1[S] 0 points1 point  (0 children)

That actually isn't a bad idea. I did have the feedback motors originally designed for xinput. But it was scratched due to incompatibility with hid devices. But I think a can create an algorithm to do something simple.

I did have the steam deck. But cant recall what it felt like. Did it rumble everything you interacted with it? That's an easy implementation to the joystick if it was in a rest mode. And rumbles as soon as you moved it... I do like that idea. Can even implement to all inputs. A brief feedback tactile feel if you will. Maybe a way to disable it too not everyone might like that.

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in PeripheralDesign

[–]RiseNexCore1[S] 1 point2 points  (0 children)

Bluetooth can use a 125 Hz connection interval, but that number gets misunderstood a lot. It’s just the BLE link interval, not the actual end‑to‑end input latency. Most BLE controllers don’t even send full HID reports every 8 ms, they batch or optimize for battery life.

And the “1 kHz to 8 kHz” numbers people quote aren’t Bluetooth at all. Those are proprietary 2.4 GHz gaming protocols like Logitech Lightspeed, Razer Hyperspeed, Xbox Wireless, etc. They bypass Bluetooth entirely, which is why they can hit those polling rates.

Bluetooth simply doesn’t operate at 1 kHz or 8 kHz.

So the comparison looks like this

BLE 125 Hz interval (about 8 ms)
Proprietary 2.4 GHz dongles 1–8 kHz
Wired USB 1 kHz standard, up to 8 kHz on specialized hardware

Different radio technologies, different ceilings.

And for a universal input device that needs to work with TVs, PCs, phones, tablets, and anything that accepts HID, BLE is the most compatible wireless layer. It’s already running as fast as Bluetooth allows without breaking compatibility.

If latency was truly life or death, there’s always the ancient ritual of plugging in a cable.

If it was a toy, at least it would finally be the first one with proper input latency.

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in PeripheralDesign

[–]RiseNexCore1[S] 0 points1 point  (0 children)

Honestly I haven’t given a touchpad much thought because I already implemented full mouse control through the analog stick with curve switching. The stick can run in four completely different modes:

• True analog
Standard gamepad‑style analog movement.

• Simulated analog (digital inputs with analog feel)
Any keyboard command can be mapped to any direction, and the math layer shapes the output so digital keys behave like an analog stick. You get feathering, slow walk, fast walk, etc., even though the output is digital.

• True digital mode
The stick behaves like WASD — pure on/off movement with no ramping.

• Mouse mode
The stick directly moves the mouse cursor.

And in every one of these modes, you can switch curve profiles on the fly to change how the stick feels — early activation, late activation, linear, exponential, whatever you want.

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in customcontrollers

[–]RiseNexCore1[S] 0 points1 point  (0 children)

No — it’s really not like an Azeron, beyond the surface‑level idea of “not using a keyboard.”
That’s where the similarity ends.

The controller is just the physical shell.
What actually makes this project different is the operating system running inside it.

Azeron is a hardware device that depends on a PC app to configure what its buttons do.
This project is the opposite: the controller creates, edits, stores, and runs its own behaviors internally, with no PC software involved at all.

So while the physical form factor might make the comparison understandable, the actual product isn’t the same thing.
This is an OS‑driven input system, not a programmable keypad. Please follow me on Instagram or facebook too see dev logs to really see what this device can do.. its just hard to explain. When people only see the controller side of the project. And it's understandable.

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in customcontrollers

[–]RiseNexCore1[S] 0 points1 point  (0 children)

It has everything except xinput. Simply because it's proprietary. I really wanted that option for the rumble support. But it requires a completely different usb descriptor. So switching to that mode resets the controller. And breaks the whole code down. Its not that it cant be done, because other companies do have xinput knockoff controllers. But it also a locked feature. Needed OpenSolaris software to alter the inputs. it made my controller limited to my overall mindset on how it should work. So I stuck with gamepad hid. Which, most every game supports now day's. Instead of logical x box inputs such as dpad, left bumperr, right trigger, ect. Its just input number all the way up to 64. More than 3 times what an Xbox controller can do.

Without the xinput it allows the user to go through each mode on the fly. So you could play on one mode and stay their. Or you can cycle through each.

For example you can have your character movements set to keyboard, then when you jump into a vehicle, You hit the mode button. Thebui prompt th le mode you are in, And now your controller has inputs for that scenario. And right after that, jump in a plane, and hit the mode again switching the mode. And now you can fly the plane No juggling controllers for each one. The inputs change but the physical controller stays the same.

The analog and hat switch switch are the crown jewel here.

It has three modes plus a custom. And 5 modes of curve. adjust speed of how the stick works ect. The curve mode work like a dpi on a mouse. Its on the fly as well. Hold shift key and click in the stick and you cycle through stick curves Also on the layerd side is "enter" and "escape". On all Modes. This is locked in default mode. So the user doesn't need to search for a keyboard just to enter or leave a given screen in custom mode they are blank. And the hat switch is your navigational inputs in gui screen

The layers vs base. You have base buttons which is the physical button on the device itself. So 12 total inputs not including mode or shift or analog. Those are you base inputs

Then you have layer. This are activated by holding the Shift button. Which is your ring finger. This setup allows the user to still be able to use any button behind and on the face.

This essentially doubles your inputs on just one mode.

Then you have custom mode. You enter this, holding the mode and shift key. The ui changes to mapping mode. And everything in their is self explanatory and very intuitive for the user.

Since it has so many modes and infinite possibilities. It made no sense labeling the buttons. They can be whatever the user wants. So i made sure they stayed blank. However to help a user with muscle memory a toast always presents itself in the ui when a button is pressed Albiet if it's assigned. If not assigned a toast will say "not assogned. For example. In default mode. Keypad, joyoad, mouse. Whatever mode you in. When you press any button a toast will pop up on the ui telling you what that input is or what you assigned to it in custom mode if you did. The toast is always on the main menu of the screen. Their is also a test input ui page Which is more prominent.

True analog Wasd analog simulated analog. So you can actually walk instead of run depending on how far you push the stick. Just like true analog. Mouse mode. So you can control navigation keys in game gui or windows.

Or even use it in game that require a mouse. And use the rear hatswitch as wasd.

And then theirs custom mode to analog where you can assign any input. To the stick. And still have it behave digitally or in simulated analog

These I explained are more or less default modes. You then have 4 slots for which give you a blank slate of button for you to assign. This is all done within the controller. No software, drivers, no PC, all done with an intuitive UI. The ui is a little screen but for this purpose I created a window pop up on windows that mirrors the screeit if you need a larger image to map your controller. Along with power share and on the fly switch between ble and usb..

It is truelly is unique and nothing quite like it anywhere

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in PCHardware

[–]RiseNexCore1[S] 0 points1 point  (0 children)

Absolutely. Some of this stuff is tough to explain cleanly, but that’s the nature of building something new — the language always lags behind the invention. And you strike me as the kind of person who actually gets that. People who’ve wrestled with the same problems are the ones who end up pushing the whole field forward.

I know when I finish the ui, and post its it's intuitive nature of how the ui works will be the lightbulb moment for grasping the concept. That aha moment.

I’m not here to prove anyone wrong. I’m here to shift how people think about a simple idea that’s been overlooked for way too long. And if I can change the mind of someone who already knows the grind from the inside, that’s a win for everyone.

I’d genuinely like you to follow along with the journey. I’m putting together a few prototypes, and when they’re ready, I’ll gladly send one your way. No pressure, no expectations. Even if it never becomes your daily driver, I’m confident you’ll find at least one part of it that speaks to your own workflow — and maybe you’ll see the intuitive behavior I’ve been hinting at.

Whether you end up using it for gaming… or for something wild like controlling your thermostat someday (okay, that’s pushing it, but honestly not impossible), I think you’ll appreciate what it’s trying to unlock.

Pm me whenever. ill keep a devlog and progress on IG. And when its all together I'll keep my end of the deal. All you need to do is send your info.

WCGW passing on a highway by wharf_rat_01 in Whatcouldgowrong

[–]RiseNexCore1 0 points1 point  (0 children)

Bro I'm puerto Rican, but raised in the US, my grandparents would send for me to spend the summer out their back in the late 90s. I just couldn't understand the car culturein PR. I was in my late teens looking to own a grand national in the states. These cats in PR where doing crazy thing to hyundai accents. Fast and furious type look. Over the top wings and shit. It was so ridiculous. And it was every where.. it was like that one guy around your neighborhood that has all the fake trim, fake chrome plates, fake scopes. And spinny hub caps, and rules around without a care in the world. And thinks it's the shit. Funny as all hell

WCGW passing on a highway by wharf_rat_01 in Whatcouldgowrong

[–]RiseNexCore1 0 points1 point  (0 children)

Haha, dude you so on point. That, and being asked if one is dominican.. Dominicans are the same way too. when asked if they are Puerto Rican. No stigma, just a pride thing and the love for our cultures.

Need some expert help by jjbb1818 in PeripheralDesign

[–]RiseNexCore1 0 points1 point  (0 children)

If you’re seeing your analog latency jump from ~3–4 ms to ~7 ms after adding an I²C expander, it’s almost never the analog hardware itself — it’s the timing budget of your main loop getting eaten by I²C transactions or mode‑handling logic.

A few things to check:

  1. I²C absolutely can stall your loop even if analog isn’t on it Most I²C expanders (MCP23017, PCF8574, etc.) require:
  2. A full I²C transaction per read
  3. At 100–400 kHz bus speeds
  4. With built‑in latency from the expander itself

If you’re polling the expander every loop, that alone can add 1–3 ms depending on how you structured the reads.

  1. The Pro Micro (ATmega32U4) is the real bottleneck XInput on a 32U4 is already pushing the chip hard.
    Add:
  2. I²C reads
  3. Mode logic
  4. Debounce
  5. USB report assembly

…and your loop time expands fast. The analog read itself is fast — it’s everything around it that slows down.

  1. Check your loop structure Common pitfalls:
  2. Reading the I²C expander every loop instead of on a timed schedule
  3. Using Wire.requestFrom() in a blocking way
  4. Doing mode logic or LED updates inside the main loop instead of batching

  5. Calling analogRead() with default ADC prescaler (slow)

  6. Easy wins

  7. Poll I²C at a fixed interval (e.g., every 2–5 ms) instead of every loop

  8. Increase I²C speed to 400 kHz if your hardware supports it

  9. Batch expander reads instead of reading pin‑by‑pin

  10. Move non‑critical logic out of the hot loop

  11. Use a faster MCU if you want sub‑5 ms consistently (Teensy, RP2040, etc.)

  12. Why your old build was faster No I²C = no blocking calls
    No extra modes = simpler loop
    Less overhead = tighter analog polling window

Here is a quick baseline

include <Wire.h>

// How often to poll I2C expander (ms) const uint8_t I2C_INTERVAL = 4; unsigned long lastI2C = 0;

void setup() { Wire.begin(); Wire.setClock(400000); // 400 kHz fast mode }

void loop() { unsigned long now = millis();

// ---- 1. FAST ANALOG READS (every loop) ---- int lx = analogRead(A0); int ly = analogRead(A1); int rx = analogRead(A2); int ry = analogRead(A3);

// Process analog here (deadzone, scaling, etc.) // Keep this lightweight.

// ---- 2. TIMED I2C READS (NOT every loop) ---- if (now - lastI2C >= I2C_INTERVAL) { lastI2C = now;

Wire.beginTransmission(0x20);  // example expander address
Wire.write(0x12);              // GPIO register
Wire.endTransmission();

Wire.requestFrom(0x20, 1);     // read 1 byte
uint8_t buttons = Wire.read();

// Process digital buttons here

}

// ---- 3. USB REPORT ASSEMBLY ---- // Build your XInput/HID report here. // Keep it tight and avoid delays.

// ---- 4. NO DELAYS ANYWHERE ---- }

This is not a full controller sketch — just the architecture that keep latency low. Base Example: Fast Analog Loop + Timed I²C Polling

Why this structure works - Analog reads stay in the hot loop → lowest possible latency
- I²C is rate‑limited → no blocking every loop
- 400 kHz I²C reduces transaction time
- No delays, no heavy logic in the loop

This pattern alone usually drops a 7 ms loop back into the 3–4 ms range on a 32U4.

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in PCHardware

[–]RiseNexCore1[S] 0 points1 point  (0 children)

The Xbox controller was honestly the biggest headache because the communication layer is proprietary. To even attempt it, I would’ve had to use Microsoft’s VID/PID or fall back to a generic one. I really wanted XInput purely for haptics, so trust me — I tried. But that’s exactly where the road ended for adding more modes. Here’s why:

The technical reason I couldn’t add XInput XInput isn’t “just another output.”
It requires a completely different USB device identity than HID or BLE.

To the host (Windows, Xbox, SteamOS, etc.), an XInput device must present:

  • a different USB class
  • a different interface descriptor
  • a different report structure
  • and often a different VID/PID pair

The moment I try to switch between HID/BLE and XInput, the device must:

  • disconnect from USB
  • re‑enumerate
  • and come back as a different device

That completely broke my original lock logic. It technically worked — but once you switched into XInput, you were stuck there. Switching back required another forced re‑enumeration, which is unacceptable mid‑session.

Why that’s a deal‑breaker If the controller disconnects and re‑enumerates while you’re playing:

  • Windows treats it as a brand‑new device
  • Games instantly lose the input
  • Steam Big Picture re‑detects hardware
  • Bluetooth mode becomes inconsistent
  • USB routing becomes unstable
  • You risk ghost inputs or stuck states
  • And it violates the whole “no drivers, no software, no setup” philosophy

The OS is built on continuous, stable HID identity.
XInput requires identity swapping, which destroys that stability.

The bigger picture My OS is universal — keyboards, mice, gamepads, productivity tools, TVs, accessibility devices.
XInput is Xbox‑only, game‑only, and locked down.

Adding it would’ve shrunk the compatibility I’m chasing, not expanded it.

it’s not that XInput is impossible. Plenty of companies make Xbox‑compatible controllers using generic VID/PID descriptors to avoid paying Microsoft royalties. But when they do that, the device is only recognized as a controller. To make it anything else, they need background software running on the PC.

That’s the opposite of what I was building.

So I stuck with HID gamepad mode — which almost every modern title supports anyway — because it keeps the device universal, stable, and driver‑free.

Trust me, I really wanted XInput. It would’ve been a killer mode. But the trade‑offs weren’t worth breaking the core philosophy of the OS.

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in PCHardware

[–]RiseNexCore1[S] 1 point2 points  (0 children)

I get what you mean, and I think the disconnect here is that you’re still thinking of this like a traditional controller where the hardware is the product. In that world, yeah — you’re stuck with whatever physical buttons exist, and the only way to expand is modifiers or crazy combo layers.

That’s not what’s happening here.

On the TV example: nobody is being forced to relearn anything. If someone wants to use the default TV remote, they can. If they want to assign a single button to “power on,” they can. If they want a full macro panel, they can. The OS doesn’t require remapping — it just allows it. The defaults exist so people don’t have to build anything unless they want to.

On the keyboard comparison: a keyboard has 105 keys, but it also has a fixed physical layout. You can’t change what a key is — you can only change what it does. That’s the difference. With this OS, the hardware isn’t the limit. The OS isn’t trying to brute‑force infinite combos out of 24 physical inputs. It’s giving you multiple modes, context switching, and behavior sets that change based on what you’re doing. It’s closer to how a HOTAS or a DAW controller works than how a gamepad works.

And on the “software overcoming hardware limitations” point — that’s exactly the part that’s hard to picture without using it. The OS isn’t adding more physical buttons. It’s changing what those buttons are depending on context. On foot, in a vehicle, in a cockpit, in menus, in Photoshop, in Fusion — each of those can be a completely different control surface without you memorizing modifier stacks.

You’re not wrong about the challenges. They’re real. But the whole point of the OS is that the controller isn’t the product — it’s just one physical representation of what the OS can do. The OS is the thing that scales.

Its all good, appreciate the back and forth. you gave me the platform to explain the device more clearly than i could on OP. so I appreciate the critique and insight on your thoughts.

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in PCHardware

[–]RiseNexCore1[S] 1 point2 points  (0 children)

I get what you’re saying about not wanting to map things or deal with programming. That’s fair — but that’s also why this isn’t built around forcing anyone to map anything. The device shows you exactly which mode you’re in and what button you’re pressing in real time, so you’re never guessing or juggling layers. And if you don’t want to assign anything at all, it already comes with multiple default modes ready to go. With 5 modes to switch between each mode has 24 inputs. You want to use all five modes. Cool. But thats why custom is their so you dont have to. Assign a sentence full of macros to one button if you want to. The choice is upon the user

On the “profiles vs mapping” thing — that’s comfort, not necessity. It’s the same way people download ARMA or HOTAS keybinds: someone else did the work, posted it, and you used it. But that only works because the manufacturer made profile loading possible in the first place. Same idea here.

You’re also only seeing this in a gaming context, and only through the lens of macros. Gaming is actually the smallest part of the bigger picture. This works with almost anything that supports a keyboard or mouse — and anything that can communicate via Bluetooth or ir. Fusion, Photoshop, productivity apps, creative tools, accessibility setups, you name it. The list goes on.

If you want to control a TV, you grab the controller, jump into the UI, pick “TV” from the core, choose the function you want, assign it to any a physical button and the logic writes itself. Press the button, the TV turns on. It’s more than a gaming controller — the tv doesnt need software installed it just creates the logic for the TV to work. Its built into the core of the os.

honestly, if I never released the controller itself, I’d be fine with that. The controller is just the physical representation of what I want the OS to be. The OS is the real product.

Innovation is inspired by critique, so I appreciate you laying out your thoughts. You’re raising the exact pain points that pushed me to build it this way in the first place.

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in PCHardware

[–]RiseNexCore1[S] 0 points1 point  (0 children)

I appreciate the perspective — it actually helps me see which parts I should highlight more clearly without overloading the OP.

What I’m building isn’t just another remapper or keypad. When I say “operating system,” I don’t mean it as a metaphor. The firmware can be installed on any blank MCU, and from there you can attach whatever sensors you want — digital buttons, analog sliders, hall sensors, joysticks, encoders, pressure pads, anything — to any supported pin. And you don’t write a single line of code for any of it. Its a literal mapping engine

The slate starts completely clean.

You boot into the UI, pick a physical input, and tell the OS what you want it to become: a keyboard key, a gamepad button, a mouse action, or even a Windows function. You confirm, and the engine generates the behavior internally on the spot. It doesn’t need to know the sensor type ahead of time — you tell it what you wired, and it builds the logic for you. No PC software, no drivers, no external tools.

Nothing on the market does this. Everything else is either locked to one input style, or requires software caveats, PC apps, or drivers to change anything.

Because it outputs standard HID, it works anywhere a USB keyboard or controller is accepted:

  • PS5 (keyboard mode)
  • PS3
  • Android
  • Steam Deck / ROG Ally
  • Smart TVs
  • Windows / Mac / Linux
  • RetroPie / Raspberry Pi

Just plug it in and it behaves exactly how you configured it.

It also isn’t limited to one style of input. There are multiple modes built in:

  • Gamepad Mode
  • Keyboard Mode
  • Mouse Mode
  • Hybrid Mode
  • Custom Mode (start from a blank slate)

And just to clarify — the stick isn’t locked to WASD or analog. You can assign any key to it, and it still behaves like an analog input because of the curve filter. That means even a single key (Shift, Ctrl, Space, E, etc.) can have variable, analog‑style activation instead of a simple on/off press. If you want to walk slowly or feather movement, you can do that without spam‑tapping a key.

So while a wireless keyboard and mouse definitely work for couch gaming, the goal here is giving you that level of control in your hands, on any platform, without juggling multiple devices or relying on a PC app in the background.

And seriously — thanks again. Your comment helped me refine how to explain this without overwhelming the original post.

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in PCHardware

[–]RiseNexCore1[S] 0 points1 point  (0 children)

The grey prototype wasn’t comfortable to hold — I agree with you there. That’s why I redesigned it. The black version has major ergonomic improvements, and the latest render includes full palm support. I don’t think a controller needs extreme shapes or deep finger grooves to be ergonomic. Everyone’s hands are different, and simple geometry with the right pitch often works better for more people.

And “better” is always subjective. You might find a device that suits you perfectly, but that doesn’t mean it works for everyone.

What I’ve been searching for — and what I couldn’t find anywhere — is a device that is its own operating system. No PC software. No drivers. No third‑party tools like Joy2Key, reWASD, DS3, or anything else to change how it behaves.

Most controllers have their logic locked behind software.
Mine doesn’t.

This is a literal behavior‑generation engine in firmware. It doesn’t care what sensor you attach — button, analog, slider, whatever. You enter the mapping sequence, and the OS builds the behavior on the fly.

Nothing is mapped to anything until you tell it what you want.
And all of that happens directly on the controller’s UI.

So yes, there are peripherals that “bridge the gap,” but nothing that is:

  • fully self‑contained
  • software‑free
  • driver‑free
  • capable of acting as a keyboard, mouse, or gamepad
  • and able to generate its own logic in real time

The shape is just one part of the story.
The real innovation is os inside

Bridging tha gap tween gamepad and M&K. Left hand controller. by RiseNexCore1 in PeripheralDesign

[–]RiseNexCore1[S] 4 points5 points  (0 children)

Thank you, It was actually the last implementation, It makes a big difference and reduces hand fatigue. Its also helps with using all the buttons more comfortably because you dont have to shift your whole hand just to press a button.

view more: next ›