Jump to content

Alterscape

Members
  • Posts

    112
  • Joined

  • Last visited

Everything posted by Alterscape

  1. 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.
  2. 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.
  3. 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.
  4. 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).
  5. 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!
  6. 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.
  7. 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]
  8. 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!
  9. 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).
  10. 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.
  11. 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]
  12. 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.
  13. 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..
  14. 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!
  15. 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.
  16. Hi Propeler, could you share the ODrive firmware with me as well, please? I've got a current ODrive with AS5048s and the motors you specified. Still waiting for cut/bent parts to arrive, but the plan is to build your gimbal as drawn!
  17. Yes, you've got it exactly. The force trim button is a DCS bind, and the functionality adjusts the commands the sim is sending to the stick. You still get control authority. It's simulating the functionality of the trim system in real helicopters. The others have described the functionality in fixed-wing planes too, which I also use and like (I just generally stick to my other stick for the modern fighters, because I need the buttons). As far as other sims go: I've used it extensively in Condor, a soaring simulator. I used to fly sailplanes in real life (RIP my budget / ability to commute to rural areas where gliderports exist) and I'd say FFB is vastly superior to spring centering for that use, where control feel is really everything. It's close enough that I didn't find the differences objectionable when I was flying the sim on and off along with real gliders. IL-2 also has support (good IIRC, but it's been a while). I believe you need a (relatively inexpensive) plugin for XPlane 11, not sure about MSFS2020, as I don't own it yet.
  18. Yes, the joystick moves freely if the motors are powered off. In the helos with good FFB trim implementations (so, anything except the Gazelle), if you hold the trim switch, the forces on the stick are greatly reduced, and when you release it, that becomes the new center point. Highly recommend the FFB2 if you can get one. I've got one, and I want more buttons, so I'm in the process of frankensteining something together, but.. if you're okay with relatively few buttons on your grip and relatively short throw (no extensions w/o hacking) go for it!
  19. This may be an ignorant question, but can anyone give me a quick summary on why the hub version of DCS BIOS was abandoned? I understand that Ian decided to take a break, but the idea of a shim layer in between the export.lua in DCS and the serial port, which is aware of what module is loaded in DCS and can rewrite the incoming/outgoing messages, seems like a no-brainer. Like, it wouldn't need to have all the complexity that Ian was building into the hub -- just needs to translate from the data coming in over UDP (I think?) to serial, and potentially transform it a little.. Am I missing something obvious here?
  20. I'd like to connect a rotary switch to DCS to directly set the active radio on the Ka-50 (the rotary on the left knee radio panel). Is it possible to edit default.lua to bind specific radios, rather than just "increment left" and "decrement?" I'm pretty sure DCS BIOS can do it, and I'll probably go there eventually, but I'm trying to set up something quick and dirty for now.
  21. I am not an expert DCS BIOS user, but you're still uploading Arduino sketches to boards, right? If so, you could write a simple function/method to scale. Example below (pseudo-code, haven't tried to compile it, but it should work, more or less). These assume that DCS BIOS treats RPM input and output to the gauge as a floating-point percent (0 = 0%, 1.0 = 100%). If it treats it as an integer (0 = 0%, 100 = 100%) you might have to do slightly different casts but the idea holds. /// Convert from one range to another. /// value is the input value (e.g.: from the DCS output) /// in_min = minimum input value we care about for this part of the range. /// in_max = maximum input value we care about for this part of the range. /// out_min = minimum output value. If value were in_min, we'd return out_min. /// out_max = maximum output value. If value were in_max, we'd return out_max. float scale_value(float value, float in_min, float in_max, float out_min, float out_max) { // First, calculate the percent of the input range. // This doesn't do any bounds-checking, so do that first. float pct = (value - in_min) / (in_max - in_min); // Then multiply the output range by the percent, and offset it by the min value. return out_min + (pct * (out_max - out_min) } /// Now we can use scale_value to scale the range. /// This function assumes that everything is a floating point percent. If it's an integer you float scale_gauge(float value) { if (value < 0.25) // if the RPM is between 0 to 25% { // scale the range to between 0 and 75 degrees (which is 20.8% of a circle). return scale_value(value, 0, 0.25f, 0, 0.208); } else if (value < 0.5) { // scale to between 75 and 100 degrees (which is 27.7% of a circle). return scale_value(value, 0.25f, 0.5f, 0.208f, .277f); } else { // If value is greater than 50% rpm, scale between 27.7% and the ful circle. return scale_value (value, 0.5f, 1.0f, .277f, 1.0f); } }
  22. Does anyone know the name (or, better, a part number) for the 4-way toggle switches used in the Ka-50 and Mi-8? They are used for the Ka-50 engine start selector (up = APU, lower left = left engine, lower right = right engine) and some cockpit brightness controls on the right side wall. Believe the Mi-8 also uses the same or a very similar switch for the same purpose on the engine startup panel, at least. I'd love to replicate these for some cockpit panels I'm CAD-ing up, and it's probably easier to just buy the thing rather than trying to figure out and then implement the mechanism. While we're at it, how about the backlit+indicator light switches on the Ka-50's targeting panel and datalink panel? My current plan is to use Cherry MX switches+LED and 3d-printed keycaps with light guides for the indicators, which is cheap and easy, but it'd be cool to get the backlit key legends as well..
  23. I built a few Ka-50 panels/button boxes for DCS, and in order to make some of the two-state switches work the way I wanted (for instance, the Shkval 7x/23x toggle), I had to add a new binding to the Shark's default.lua that essentially says "this switch, when pressed, fires command 'zoom in' and when released, fires command 'zoom out'." LUA-wise, the command is {down = iCommandPlaneZoomIn, up = iCommandPlaneZoomOut, name = _('Shkval 23x/7x'), category = _('Ins Collective Stick')}, for anyone playing along at home. Anyhow, I've got a bunch of these, but any time DCS updates, it overwrites default.lua. Is there an existing tool to automate re-applying my patches after update? I could probably write a simple script (I'd use Python, but, whatever language) that appends my custom binds to the end of the file automatically, but if I don't have to re-invent the wheel, that would be spiffykeen.
  24. As per Deadman's awesome switch list, the Hawg uses Janco A /Cole 3600 rotary switches, and it seems a fair bet that that style of rotary is used lots of other places you see rotary switches (Tomcat RIO pit, etc). Right now I'm working on ka-50 panels, but sooner or later I'll probably do a RIO switch box too. I've been trawling eBay for the last several years and got some great deals on eg: Otto pushbuttons, Honeywell toggles, etc. Haven't been able to find a good source of rotaries, though -- in part I think because there's so many options that the odds of someone surplus-ing what we want (mostly 4 position. <35 deg switches) is exceptionally low, relative to eg: 2 pos, 8 pos, 12 pos, etc. I've got a couple of good deals on ASM/Electroswitch and Grayhill switches that are in the ballpark, but they're rare and usually not what I actually want (eg: wrong shaft diameter, more positions than I need, etc). Considering we don't actually need environmental sealing / non-shorting / other qualities of the mil-spec lines, what alternatives are people using? Hopefully in the "better than those crummy $4/ea Chinese rotaries that are two PCBs and some stamped metal" bracket -- I know I can get dirt-cheap rotaries (and I've actually used them for projects) but, man, they suck and feel awful.
  25. Tobii just uses a CPU-based face detection algorithm for 6dof head position. If you look at their product page for the 4C tracker, they point out that "head position does not use EyeChip." You can convince yourself of this by covering the off-axis IR emitters (far left and right of the 4c) while leaving the central camera uncovered. This will cause gaze vectors to fail, but you still get head position. Therefore, I'd say, unless you really need gaze detection, you should be able to get a comparable experience out of eg: OpenTrack with the "FaceTrackNoIR" plugin (forget what it's called since I don't use it, but I know it's in there).
×
×
  • Create New...