Alterscape

In precision machining (in metal), screws are avoided for positioning. Instead you'll usually find pins indexing the position of components (in reamed holes, so the diameters have specific fit tolerances), and screws holding the parts together. Given that we're 3d printing everything, I'm not sure we can get enough precision for pins to be relevant, but if we could, that's where I'd start. In 3d printing I tend to just torque things down but you can only go so far before you start to crack things.

I'm not sure either, but my guess based on what all was up for auction and where it was, is that it's a decommissioned modular cockpit trainer, so I think AVCATT or AVCATT-related (there was a proto-AVCATT that was apparently better but wasn't deployed, but I don't know details). Might be the proto-AVCATT thing since they're all dated early-00s. The interchangeable Apache/UH-60/Chinook controls are what point me that way. Of course we don't know that the TEDAC came from the same system as the collectives and cyclics (just a guess, since they showed up together at the same time) so.. who knows! One could probably do some sleuthing based on the part numbers on things but tbh I'm just glad I got my hands on it and it seems about 95% functional.

Thanks! I reached out to Damien (Delta Sim) and he took a look and agrees that it's probably safe to put 3v3 from 37 to 1 and then read 30 & 31 with the ADC on an Arduino or similar. At the same time, our Kansas based sim-surplus-pusher reached out and offered to sell me a TEDAC pedestal, which appears to have all the CAN electronics in it for the grips and the TEDAC screen. So I may not need to roll my own (yeah, I'll admit I just blew my hobby budget for the year, but, eh, it's fun!). But I'd still be happy to share knowledge based on poking at that, for folks who got the handles but not the CAN kit.

Aaaand I've got the collective! Bit rate for the CAN bus is 500,000. It has two CAN devices (mine are 0x3EC and 0x3EE, not sure if that will be universally true). When any state changes, each device transmits a 5-byte packet. The first 2 bytes of the packet are a bit-field for the switches connected to that CAN card. The remaining bytes encode the axes. On mine, 0x3EC is the cursor, and the bytes are (x axis as a signed 8-bit integer), (y axis as a signed 8-bit integer) (who knows, an additional 8-bit integer I can't make sense of yet). 0x3EE is the throttle, so the bytes are (the throttle axis as a signed 8-bit integer), (0x83), and a last byte that seems to switch between two values, I'm not really sure what's going on there).

Which trim switch? the only outright dummy on mine is the ND/Reset/NU switch on the flight grip. Good news: I've been sitting here patiently testing each switch on the collective and recording the CAN messages. I suspect I can have a library for this within the next day or so!

Oh, uh, validate with a meter before you just blindly plug 5v into something! I am 99% sure yours will be identical to mine but you should probably test first! My approach here was to pop out the board and look at the ICs. The big IC is a Fujitsu microcontroller, and the small IC is a CAN transceiver. I was able to look up the data sheets for both and beep out which pin on the DB9 went to which pin on the CAN transceiver, then validate that the microcontroller vcc/vss agreed. Putting 5v into the thing was a high-pucker-factor moment but it worked out okay. Also, some info: it looks like a bunch of switches on the flight portion of the collective grip are INOP/NC. The mission head is 100% connected, but like, JETT/CHOP, the tailwheel button (pinky) and the landing light hat/switch don't report anything on CAN when switched. My source says that since they're not required for the particular training this trainer was used for, they're just disconnected. At some point I plan to pop off the grip and see if there's at least wire to them. If there is, I might just replace the CAN board with my own design. If there's no wiring to the switches internally, I'm not sure what the next play is. Also edit, because apparently I can never fully compose my thoughts before clicking send: I plan to build up a set of PCBs to adapt the TEDAC handles. Minimum order quantity is 5 at the PCB shop I use, so assuming I don't botch anything, I should have at least one spare set. If you're in the US so mailing's plausible, we should talk. Also edit again: Did you get the TEDAC screen unit as well? THAT thing is going to be A Project. I suspect the DB9 5W2 is power, and the DVI jack is obviously a DVI jack, but beyond that.. that DB37 and the DB9s are intimidating. Let me know if you have any luck there.

Sure thing, here's what I've got: For anyone else approaching a problem like this, the trick was to take one of the held-on switches and set it. I then connected a DB37 breakout board to the connector (so I could get a numbered grid of screw terminals to easily probe) then used a multimeter in continuity mode (the beeper) to find which two pins were shorted. That was.. 36 and 4 I think. Then I tried the other position on the switch, and figured out Pin 36 is common. From there everything else was just "connect one multimeter lead to pin 36, and swipe the other lead across all the pins while holding exactly one switch. Note that UPDT is not connected to anything on my left handle, nor is the 'W setting on the WAB switch. (image-tracker polarity). According to a guy I know who flies these in real life, those are seldom-used settings so I'm not going to fuss with it. If you got a collective/cyclic too, the DB9 connectors are CAN. 5v on 5, gnd on 6/3, CANL and CANH on 2 and 7. I was able to get data out of a cheap Amazon USB-CAN interface at the default baud rate (100k, IIRC). You'll need a 100 ohm resistor between 2/7 to terminate the bus. My project for today is to reverse engineer the CAN protocol (it looks like it's one bit per switch for the binary switches; will have to do a bit more work for the cursor and throttle). [edit] I think my long-term plan is to write Teensy code to parse the CAN for the collective/throttle, and expose them as HID devices. I have no idea when I'll get it done but I'm happy to throw it on github, with the caveat that the CAN boards in the collective/cyclic have jumper settings that I bet control the base address. I'd actually be curious what your jumpers are set to, if you have these boards too, Fusedspine33.[/edit]

I suspect this isn't what I have. I would expect hall sensors to be unresponsive when unpowered. If not for the 500 ohm between 1-37, I'd be tempted to put 5v on 1, gnd on 37, and connect 30 and 31 to analog inputs. The 500 ohm between 37/1 seems like it might turn into a heater under those drive conditions, though, unless I stuck a current-limiting resistor in series ahead of 1, and then I'm right back into amplifying a tiny voltage like a load-cell setup, only janky!

I had a little too much fun on eBay last week and ended up with a set of TEDAC grips. Both the left and right grips have a cursor control, similar to the slew control on the A-10C or F-16 slew. These came out of a simulator, so the grip wiring is broken out to a D-Sub 37 male connector. The switches are mostly trivial to beep out (pin 36 is common across all; everything else just shorts pin 36 to another pin. That leaves the cursor/slew control. I'll start with the left grip first, which has a xy slew + depress for the cursor. It has a little bit of motion but it isn't a mini-stick, so I suspect there's an actual load-cell thing happening here. Based on my meter, and by process of elimination, there are four pins connected to the slew control: 1,30,31, and 37. Holding a meter to any pair of those pins and manipulating the cursor changes the resistance. I'm not sure what I should expect from these, so I'm not sure if this is "actual article" or "simulator part." (the case is not hermetically sealed and the actual bit you touch is plastic, so I'm guessing it may be a cost-saving part, unsure how much it differs from the flight article). I plotted each pair of contacts and their behavior below: Neutral Resistance Pins (Ohms) Notes ============================================== 1 & 37 500 Minimal response to deflection 30 & 31 450 Minimal response to deflection 30 & 37 375 Up = 440, down = 330 31 & 37 375 Left = 330, right = 440 30 & 1 375 Up = 330; down = 400 31 & 1 375 Left= 430; right =330 So clearly there's something like a voltage divider going on here (1 - 30 - 37 for vertical and 1 - 31 - 37 for horizontal). I guess I could just put 5v across 1-37 and measure the voltage on 30 and 31. I'm not sure if that's how this is meant to be interfaced with or not, though, especially since 1-37 also has relatively low resistance (500 ohms)! Any thoughts? All the "real force-sensing sticks" I've seen (eg: Hansolo's, the original delta sim retrofits based on the Chinook slew sensor) have more than 4 pins, so I'm unsure what to make of this. And yes, I've checked and none of 1, 30, 31, and 37 are connected to the common pin (36).

Thank you! I do in fact have a pile of Pro Micros with ATMega32U4s, so I will start here. I keep thinking I'm going to develop some fancy STM32 Rust-based firmware, but realistically I can hack this up in an afternoon as you propose, and if I'm unsatisfied with the ATMega32U4 performance, go through the pain of writing descriptors later.

propeler, do you have an estimate for when you might release your custom ODrive firmware, or the firmware for the custom board on github? I bought the APS motors and would love to build your gimbal design, but every time I've tried to write microcontroller code for FFB, I've failed, so I'm not motivated to start building until the software is available. (Alternatively, would you be willing to post just the FFB endpoint part of the code? Based on my prior experience, having a worked example of implementation would make troubleshooting my own code much easier...) [edit]Jumping back into this on my own, I found https://github.com/hoantv/VNWheel which looks like a pretty solid worked example. The good news is, every time I revisit this idea, the community's figured out and published a bit more, and I've got a bit more context between my other projects and my working life (which is hardware, but not gaming hardware!), so everything makes a bit more sense. So, no pressure propeler, publish when you're ready! [/edit]

I can say from experience building a DIY collective circuit on a breadboard that the AS5048B is very sensitive to power supply noise, in addition to noise on the data lines. Resistance in the connections of the low-quality solderless breadboard I was using reduced the voltage at the AS5048B board to ~3.0v from 3.3v at turn-on, and I guess voltage drop from power-up of the Teensy I was using as an MCU pulled the voltage just a bit lower right when everything is first connected to USB. This manifested in functioning I2C communications, but complete junk data -- the angle value returned was just noise, and the status registers showed auto gain was at max. Removing and re-applying power to just the AS5048 was the only way to recover the IC. Building a real PCB with negligible resistance, and adding some bulk and decoupling capacitors set things right. So it might be worth looking into the stability of the power. If the ODrive VCC is 5v, the AS5048 datasheet also specifies a 10uF capacitor between 3v3 and GND, which is not present on the eval board. I've been doing 3v3 work so I'm not sure how failing to add that manifests.

I was thinking about this while front-seating in the Hind with some friends last night. The ergonomics are goofy, with your hands to the right and your face to the left! I fly in VR, so I tried using the 3d world as a guide to where I'd need to put my hands and my face, and it's.. about zero percent ergonomic. That said, it's a pretty simple system and you'd only need a few actual bits to make it work: Pitch/Yaw input. I can't remember whether the whole grip controls the sight, or if it's just a thumbstick. IIRC the Apache/Cobra sight grips are adjustable for comfort, and the actual control happens with a force transducer under the operator's thumb. Tried to google this for the Hind, but have so far failed. The shapes are pretty simple so 3d printing should get it done, possibly with some uhmw bushings and grease for smooth rotation if that ends up being important. Probably use my old standby AS5048 sensor for both axes if they matter, or an off-the-shelf thumbstick if that's how it works in real life. Weapon release button (under one of the flip-covers on the grips, I guess?) Zoom toggle (maybe under the other flip-cover? I'm not sure.) Observe switch (cage/uncage) Missile select 9-position rotary Right now I've got it all bound up on my MCG Pro (just using one of the hats) but it would be _satisfying_ to have a rotary and the observe switch, at least..

Stock, yes. I've read that there are some G940 software and hardware mods that may improve its performance, but I've never owned one so I'm not familiar with all that. I know some folks on the forums have worked with them, and probably have opinions!

The MS FFB2 sensor has a photocell + IR LED pair on the front of the grip. Unless something like your hand blocks the sensor, it disables the motors. This is probably good for the lifetime of the motors/drivers, since it means it's only driving the motors when you're actively holding it, but it can be frustrating because the stick flops over if you let go, which can be a pain if you're using a mouse or similar to click things while flying.