Video

It's smooth. Similar resistance to a computer's touch pad. It's the same sensor as was used in the original Steam Controller -- and is the little square touchpad on the Steam Deck.

When used with the XBOX Adaptive Controller, it can be used for either the left or right analog thumbsticks. There is no press to click -- that would have to be handled by looking for taps. And I've not had reliable results with taps.

The GlidePoint is running in absolute mode. The "touch and hold" (relative-like) is handled in code. The code maps the X/Y coordinates to N/S/E/W (etc). The value tells me how far from center (pseudo vector). I found writing my own code (it's pretty basic) gave me more reliable control of what was happening. Scrolling, no. I'm still not happy with the tap response, and I'd need that to toggle scroll. (Tap -- scroll on, tap again, scroll off)

Yes, you'll find these mechanisms in a number of non-OEM controllers. The replacement caps are hard to source, but there are some on eBay and AliExpress. Try a search for "joystick cap small hole". You may have to do trial and error, as it looks like the shaft lengths vary. Personally, I don't like these mechanisms, as the less expensive ones are prone to grinding away metal. See this video for what I mean: czcams.com/video/I5jjty9eZTo/video.html

No. It does not currently work with the Nords. However, there is a work-around that I'm looking into. You route the Nord's key presses to MIDI OUT on Channel "A" -- pass it to a stick -- and stick "adds" in PB info and output to Channel "B". The Nord's voice engine is set to listen on Channel "B". That's supposed to work -- though it ties up both MIDI IN and OUT on the Nord, so the joystick would also need a pass-through for DAW work.

Unfortunately, not. The parts I'd need to bend the wire I wanted (4-6mm diameter) were not cost effective. I found the same thing with making springs -- it was more time and cost effective to go to a spring manufacturer. Not exactly "maker" I know -- but time is my #1 limiting factor.

You'd need to run it through the XBOX Adaptive Controller (XBOX AC). Going directly to a PC/Console will not give you enough buttons, and I've not tested it directly to consoles.

Using a AAA in place of a AA gives us a little bit of room (mainly in the differences in diameter) to put in a reed switch. It remains to be seen if it's enough space -- there's not a lot to work with. One of our design goals is a drop-in solution, so no actual mods to the toothbrush itself.

@@RonNelson If it's too convenient, how do you plan to prevent water entering?

@@tpwalters101 The conversion would be a drop-in replacement of the regular AA battery. So, it would be protected by the existing waterproof housing of the electric toothbrush. At this point I've modeled with AAA and AAAA batteries -- what I'm going to try next is an N cell battery. It's about the same diameter as a AA but 3/5ths the length. That should give me enough vertical room. (An N is similar in size to an A23, which is often found in remotes--but is 12 V. The N is 1.5 volts.)

@@RonNelson I shower with my toothbrush so the whole thing gets submerged pretty much. That's why I was asking. I have some questions about alternators too if you're ever bored and I could get your email.

@@tpwalters101 Gotcha. Yes, these battery conversions rely on the devices' waterproofing. You can reach me on gmail: ron.nelson.ii

The STLs and source code (OpenSCAD) are on GitHub. All are Public Domain. CORRECTED LINK: github.com/nelsonii/ATech I received feedback from the user and it's been positive so far. Everything was hand measured and modeled. So, even if you don't use OpenSCAD, you can look at the SCAD file and get all the measurements. It is a very fiddly piece. And it's a case where printing in medium res is better than high. For some reason those tiny tabs/catches print better in medium on my Prusa. If you have any questions, you can reach out there, or via gmail: ron.nelson.ii

@@RonNelson You're amazing, thank you so much. When I fit test them on a Glassouse I will let you know how it works out.

I see where you're going with this. :-) I wouldn't use Zigbee (too slow, too much lag, for gaming). But BLE would be an option. What you'd have is a box with 3.5mm wires between the XBOX AC and a receiver. Then the button box would have a transmitter. They would talk. Due to the amount of work involved, I'd re-consider a controller mod. I'm trying to avoid controller mods, but for wireless it may make the most sense. (Wireless and lag are tough problems to solve reliably.)

@@RonNelsontrying to cut down the wire monster lol

Yes, it can support Guitar Hero controllers, but only when connected to a PC. Detailed information for the buttons available are here: github.com/madhephaestus/WiiChuck What I'd have to do it map to come PC controller buttons -- so you'd need to re-map in Guitar Hero (not sure if this is possible).

I figured you were sick of seeing remote controls being adapted. 🙂

I don't believe so. To me, the Adaptive Hub is targeted to Windows machines. The PS5AC doesn't support USB joysticks -- only those which plug in via 3.5mm (1/8") jacks.

The banning has hurt a lot of folks -- where before I could recommend "get a Brook board" for my AT users, that's gone. The USB ports on the XBOX AC are VERY limited. Only a handful of buttons are supported, and no D-Pad at all. That's one of the reasons why many USB sticks won't work at all with the AC. So, you're left with the cabling nightmare of using the 3.5mm jacks on the AC for buttons. I've been working with an AT gamer on this issue and have yet to come up with any sort of reasonable solution. It comes down to either hacking into a "genuine" controller (which is very time consuming -- labor=$$$) or using an XBOX AC and have a dozen patch cables. (Hacking the XBOX AC is just as time consuming as a standard controller. They don't make it easy.) For now, we are going the "dozen cables" route as his setup is non-mobile.

@@RonNelson Thank you for your detailed answer. I guess I'll have to order a Mayflash Magic X converter. Mayflash will also be releasing a hitbox soon. They get around the ban by connecting an original Xbox controller to the Hitbox. The Xbox then recognizes the Hitbox as an official controller. I don't know how the converter stick gets around the ban, though. I'm a little worried that Microsoft will find a way to ban these devices too. According to Mayflash, that's not possible. How likely do you think it is that these devices will no longer work soon? Edit: I read that the Magic X converter uses an Xbox chipset and is therefore not affected by the ban.

@@sangha204 Yes, one of the ways around it is to have a genuine controller in-line -- I believe that's what the Titan Two does. I have a Mayflash -- but can't test it as I don't have an X|S console. 😞

It's definitely an outdoor thrower. Far too strong for indoors. The distance is adjusted by how the unit is angled.

@@RonNelson I was just looking at the instructions on the model that I have, and it appears there is a small adjustment loop on the bottom of the unit that you have to pull and set. It's still very strong but I think that there are other balls that you can purchase for indoor rainy day use. 😊👍

I just realized that I need to order more springs, so I had to de-list for the moment. Springs should be here early next week (2024-03-25).

Any news? @RonNelson

@@craigduncan8666 Yes, I have two in stock and more being made. sevenmilemountain.etsy.com/listing/1645131241/wheel-midi-pitch-bend-and-modulation

One of my earlier designs used magnets, but I wasn't sure if they would be strong enough. There's no shear force with this enclosure, as the joystick keeps the top from sliding. That sliding force I need to worry about on the Button Box. I am going to revisit magnets -- it makes the whole thing nicer.

Sure. You can reach me on gmail: ron.nelson.ii I try and respond quickly, but I often have many projects going on, so there may be a delay.

I just checked and it seems okay.

It is true, now I have audio. For some reason I did not hear anything before. Thanks

Yes, it's the same technology. The original Steam Controllers used Cirque GlidePoints. I'm not sure if the Deck uses GlidePoint tech, but its very similar -- capacitive input.

Ah, the Relative vs Absolute movement problem. I'm uploading a video that discusses this. Long story short: absolute movement is a big pain.

@@RonNelson Absolute position doesn't make sense for a circlepad on any device. I think what they were asking for is joystick input from just touching a coordinate rather than swiping from A to B. Basically a tap at (x,y) being a delta from (0,0) rather than calculating a vector from (x1,y1) to (x2,y2), where (x1,y1) acts as the center coordinate; the latter is how Mouse Joystick worked in Steam, IIRC actual joystick emulation was swipe from center and may also include the former delta from center input, but it's been some time since I've messed with the Steam Controller pad's various emulations. Honestly the various control schemes need better refined names and descriptions, because a coordinate-based joystick input isn't the same as a swipe-based joystick input. I'm thinking they want a glorified pointing stick (TrackPoint) with more refined steps, rather than a truer joystick emulation, if that makes more sense.

@@xaytana I need to hunt down the Steam Deck & Steam Controller configs -- I think that will give me a good set of different coordinate / movement systems. I'd like to code for as many as possible, and then allow the user to select which one they want. I'd be able to provide a "cheat sheet" so they can see what the different modes do -- I agree, better/clearer/consistent names would be nice.

@@RonNelson Unfortunately I'm not of much help there. Steamworks documentation doesn't cover anything but gamedev integration of Steam Input and user config stuff, along with some mention of compatible controllers, nothing on the hardware side, nothing on the pre-SI side, nothing about the coding of SI itself. You might poke around in the unofficial global variant of Steam Input, I believe the current one is still GlosSI by Alia5. Otherwise it's building everything from scratch; which the joystick emulation types themselves wouldn't be too bad, it's trackball emulation where things can get a bit iffy. Though, reWASD as of a year or so ago did include trackball emulation for the SC via their software, though I'm not sure how much traction you'll get considering its a paid service. Otherwise, Cirque themselves may have something, I know they have some amount of demo software for the circlepads (more specifically for the devkit board), but I'm not sure what's all included in the demo software. I also know there's been some various projects over the years using these pads, mostly Reddit posts with GitHub repos, but I'm not sure if anyone has gone in depth for non-pointer emulation. The entire Steam Controller - Steam Input situation is a mess anyways. But for your case for joystick types, it really does come down to how you execute the vector. Like I had mentioned, a swipe-based joystick makes (x1,y1) the origin of the vector, whereas a touch-based joystick uses the pads center as the origin of the vector. This is why the swipe-based solution is often called Mouse Joystick or Mouse-Like Joystick, because you can also do the same with a mouse sensor, you take the vector data and apply that to joystick emulation; you can also do some momentum stuff, but then you start getting into trackball emulation with this. This is also why touch-based joysticks don't necessarily need a center-endpoint drag, as your endpoint coordinate can generate a vector based on the origin being the static center-point of the pad. Unfortunately, I don't think these could ever really have a good naming convention, names could either apply to both considering they're touchpads or names are incomplete and require a technical understanding to get any value out of the name; Mouse Joystick is likely the best name that will exist for the two-coordinate non-center vector style, and I guess centered-joystick works well enough for the one-coordinate center vector style. Then, again, getting into different momentum algorithms and processing gets you more into the territory of pointing devices like mice and trackballs; thankfully joysticks are fairly simple devices in comparison, as they're literally just a one-value vector device via resistance in their physical counterpart and thus emulated with a simple vector, similarly with pointers like pointing sticks which are essentially joysticks but with a more limited range of movement. Though I will say, if you're making a discrete device that uses these, you might throw all of this into the microcontroller's code and have everything done on the device itself, rather than throwing values over HID and through an OS via RawInput and transcribing that to DirectInput or another API; offload as much onto the microcontroller as you can, especially if you're looking at a simplistic switch between touchpad input varieties. What I'm about to get into may be irrelevant to your needs, but in terms of Valve hardware and software it may be relevant for others, and is relevant to the whole Steam Controller hardware discussion. I do however know, at least with the Steam Controller, and I assume the Deck is the same way, the controller shows up as raw HID devices, i.e. generic. SC itself is four vendor-defined devices, all raw HID IDs, one HID mouse, and one HID keyboard, all using generic OS drivers. So all of the special programming is within Steam Input itself and not a dedicated driver; and is also how reWASD has configuration for the Steam Controller. This should also assume RawInput is being used, which Steam Input does support, there should not be a DirectInput layer within this due to raw HID being used, though Steam Input does support Dinput as well for generic controllers. So a ground-up solution should be as simple as any other custom controller, since it's all just generic HID devices. However, the potential issue with Steam Input support is that nobody really knows what it truly supports. Steamworks documentation says DirectInput and RawInput pads are compatible, but nobody really knows to what extent, as trackpad controllers are nearly unique to Valve hardware. I have no idea if a raw HID trackpad will just magically show up in Steam Input Configurator, and I assume it does not. The most amount of information I can find on this is someone attempting to bind a pre-release Yawman Arrow in Steam Input and being limited to what would otherwise be compatible under Xinput limitations, Dpad, four face buttons, three system buttons, two bumpers, two analog triggers, and two joystick assemblies with click. I have a feeling every actual feature of Steam Input is based on hardware IDs, what'll otherwise get a Switch Pro or DualShock 4to pop up as the proper controller, I also have a feeling that trackpads, gyro, anything outside of the Xinput suite is reliant on device IDs. I've been looking into SI integration lately due to the fact that the Steam Controller is long dead, Steam Deck doesn't have detachable controllers when it should by literal internal layout, and an SC2 is unlikely to happen anytime soon as SD2 and Index 2 are the prioritized hardware projects at the moment. Steamworks documentation lacks proper documentation outside of gamedev integration, so that's a roadblock. And until I have the hardware on hand to test if Steam Input is open enough for generic pads to have the full configuration suite, I'm assuming everything is linked to hardware IDs, meaning a custom controller would otherwise need to show up as Valve hardware for configuration compatibility. So the software solutions are either spoofing IDs and doing some trick on top of that (such as a secondary raw HID gamepad in the software composite device, SC has one physical chip but six reported devices), slogging through GlosSI to borrow software from it, or just building a companion app from scratch that provides everything needed. What I really want is to get in contact with a Valve dev that'd be friendly enough to help move these kinds of projects forward. Whether that be telling us that we need to otherwise spoof hardware IDs to force this, getting the devteam to open up the custom controller side of SI more, or just giving us a fork of the relevant SI code to help move custom companion software along. The ultimate solution would be getting vastly better SI integration of custom controllers, because people do want a SC/SD alternative due to the situation there. There's also the issue of just tech changing. Cirques later-gen parts aren't compatible with what the Steam Controller otherwise used, gen2 IIRC. This also doesn't include alternatives to Cirque, I'm not sure who else produces circles outside of Azoteq, and I'm not sure who OEMs for the Ayaneo Kun; and beyond circles, I'm not sure of what OEMs otherwise exist. Then you have a similar situation for haptic engines, similar situations with IMUs, etc. All of this essentially enforces a custom controller being needed, especially as most everything in the original SC is now long discontinued, which circles back to the issue of how you integrate a custom controller into Steam Input. Each IC has its own firmware, the microcontroller has its own firmware, and everything is passed over HID as otherwise generic devices for RawInput, which is why theoretically spoofing IDs for Steam Input may be viable even on wildly different hardware.

They can be purchased from Microsoft. www.microsoft.com/en-us/d/microsoft-adaptive-hub/8pbjx6zn089b?activetab=pivot:overviewtab

The floating is even easier to implement, if you can handle a slider: www.etsy.com/listing/1532822721/dual-trigger-cruise-control-for-xbox

That's a great mounting idea -- it's those kinds of "what if I tried this..." solutions that help everyone. The Slider joystick brings me joy and pain. Since I first introduced it, two years ago, it's been very popular -- because of the lack of tilt. But those darn mechanisms just aren't doing what I want them to do. I've been experimenting for ages (I don't want to count the time) to make a better one. My goal is silky smooth with good return. And able to handle different sizes/uses -- from fingertip to prosthetic.

The short answer is you can't. The XBOX X1/X2/TL/TR are voltage divider circuits. You have to apply a resistance, not a voltage. And that resistance has to total 10K (otherwise you won't get the full range). The only way into the analog ports is pots -- either mechanical or digital. That's why you see "dumb" (no microcontroller) sticks used for X1/X2. For smarter sensors, it's most common to use a microcontroller and go through the USB ports. However, that just gets you joystick -- not Triggers. If you want triggers, and non-pot sensors (ex. Hall, laser, etc) you need to go the microcontroller and digital potentiometer route. Same holds true for the PS5AC.

Thanks, I appreciate it. Glad I didn't waste a bunch of time going down the X1/X2 route. Or do anything that would wreck the XAC.

The other thing I've been doing successfully is using a Python script to turn key activations (Alt-Controller overlays) into a bit string and using the position of bit to trigger different pins that lead into optocouplers and relays. Works really well on the XAC and Hori. It's more for eyegaze and head trackers. BTW, any idea why my optocouplers never work on DC switch adapted toys? Just the relays work. It's the pc817s

@@mystreteacher For the toy issue, it's likely a matter of output current. The 817 is rated for up to 50 mA -- fine for logic level, but not stuff that requires more juice. That's why you almost always see optocouplers mated with transistors (for <12V) and relays (for line voltage). www.nutsvolts.com/magazine/article/optocoupler-circuits Another route is to go with a solid state relay. But read the specs! Most you find on Amazon are the cheaper AC only ones. (They rely on the AC cycle to reset themselves--so they don't work with DC/toys.)

One other thing I've used is reed relays. I've been able to direct drive them from an Arduino pin without destroying anything. This one will do 500mA on the output side: www.digikey.com/en/products/detail/coto-technology/9007-05-00/301696

Search for "circuit board holder" -- the same device is sold under different names, so find the cheapest one. You should be able to find one for under $15 USD. amzn.to/49jTiw8 I don't own this one, but it looks to be better made: amzn.to/3SLwZso Also, in "related products", check out jig fixture clamps -- these clamp boards very close to the work surface. (You can also make your own, if you have parts on hand.)

What sort of force are you looking at? There are resistive pressure sensors -- most go down to 30g -- which, while low, I've found too high for those with limited strength/movement.

I am not really sure how much, I have SMA type II. Definitely lower than a traditional trigger on a controller. Also, I do really like the idea of a slide mechanism for a trigger.@@RonNelson

@@jakfan711 My SMA customers often go with a GlidePoint based device. It's a touch sensor, so no force. So far I've used it for joysticks. I have some ideas floating in my head and I'll be posting more videos about them.

I've held off doing any "trigger" work because other options were out there -- like the Logitech. But the release of the PSAC motivated me to get more analog into 3.5mm TRRS jack setups. I was thinking of mini (fingertip) gas/brake pedals, too.

Once I get the thing to quit making grinding noises, I'm going to look to mounting. I'm leaning toward snap-in, as 3D printed threads aren't always that great.

Based on the part sizes, this idea can be implemented in 15 to 30 mm. This might be something that I make in 24 mm and have adapters for different hole sizes. (Why didn't I think of that before?) The height (not counting the plunger) is 25mm for rear clearance.

so adding a few more buttons (is that possible) which could then be used to turn on and off the record feature, and other settings, would also be very very useful. Although it appears you can push on the joystick so that could be the way to switch on and off record.

Also another "silly" idea. Not sure of the memory, but it would be cool (when you have the display), to have a variety of LFO shapes that can be triggered that transmit with a rubber-band adjustment when touching the joystick. Secondly, memory to "record" the joystick movement and then play it back in a looping cycle (so rough custom LFO generator)- that could then also be partnered up with that rubber-band adjustment again. It would allow for some fantastic custom motion and actually negate the need for my extra buttons idea.

Hi Marcel, we already talked on Etsy, but for the wider audience: I don't have Orb, so can't test it. :-) However, my customer found that the newest code is working, so I'll be able to make this available. Because of the additional work (hand wiring) involved, this controller gets more expensive, but still sub-$100. (Right now, it's looking like $90.)