Matthew10_28

Thanks for the detailed reply. Before I go too much further, I think we may be saying the same things; technical topics always work better in direct human-to-human form. I've already noticed that my hook deck clearance should be taken from the flat of the deck and not the rounded portion. That helps push things forward a bit. (a bit too far on my first quick attempt actually: I don't quite trust the tessellations for the round down though). One thing that stands out to me is that you seem to be implying that the glideslope relative to the touchdown center line is not actually 3.5 degrees; it effectively becomes something else. Is that basically what you're saying there?

Even thought I'm a bit off, this is still way more than you would want to know about carrier landing geometry and the IFLOLS. If you spot an error and can back it up, let me know. EDIT TO ADD: Found a big glaring error in the model of the carrier I used in the video. The scaling is off compared to Nimitz dimensions. I did the model import in meters but I think it might be in yards. (Reason 256 why the metric system is better and we should ban any other system) I've got to redo the whole shebang!

Yes, that's what I started out doing. In dissecting their model and the geometry from the IFLOLS according the the LSO NATOPS, there is a bit of funny business I can't quite make sense of right now. I think I've got a decent handle on where the optical focal point is to calculate everything to the pilots eyes. The problem is, it doesn't yield exactly what everyone says it yields. Namely, I show a perfect 8.1 AoA on a 3.5 degree glideslope catching a 2 wire by several feet. It should be striking between the 2 and 3 wire. I'm going to be making a video on it; something to the effect of, "Way more than you ever needed to know about the IFLOLS geometry"

Found the thread you were talking about. Although that would certainly satisfy the request, there are other things you can do with that data as far as plotting your position within the amber IFLOLS window during approach. Not only do you get a meatball export, you can log and graph your approaches to see how you adjusted yourself in the groove.

Flying ILS (really ACLS) all the way is a really bad idea for landing on the boat. The ILS can assist in set up, but IRL once you see the ball you fly the ball and only the ball all the way in. Aside from the skewed inertial reference frame from ILS, it gives you no information as to if you are in the amber window or not.

I got a workaround for use in VR Samsung Note 8 (or any tablet with a stylus or ability to draw) + Samsung Side Sync (or any phone display mirroring app) + OVRDrop Point OVRDrop to your mirrored device window. Position it in the world wherever you want (I have might over my right thigh to match where I keep my phone on my kneeboard) You can set the transparency and gaze in OVRDrop. The phone is super tiny and very transparent until I look at it, then it gets bit and I can see what is on my phone. I can write with the stylus since it gives me a hover over marker before I actually commit to writing.

Is there anyway to export the meatball data for use in another window? I'm flying VR and the screen door effect makes seeing it pretty difficult. I'm thinking that once I have a feed of the meatball data, I can maybe hook some sort of java window display around it and then get that back to the cockpit via ORVDrop.

So how would one go about doing this? Is the ball data able to be exported?

Thanks you for sharing your perspective. Coming from someone who’s further down the road than I am, your guidance certainly holds weight. Your analogy of planning a road trip from California to New York is a good one. Although I admit that programming is my weakest point, being a degreed mechanical engineer working in aerospace manufacturing of assemblies including systems integration does give me a solid leg up on each of those other areas. The problem I often see in design/build programs is best summed up by a quote from Jurassic Park: “Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.” Bad design decisions at the front end have a negative cascading effect at every step downstream. I’m just trying to avoid that by understanding as much as I can up front before I’m halfway in and realize I’ve committed myself to a system that doesn’t suit my needs. You’re probably right in that I should gain the experience of a simple build involving a few switches first. Getting my hands a little dirty will probably help me understand what’s going on behind the scenes. Thanks for showing me that control browser. I'm sure that will come in handy.

I think there are some floating out there from Dimebug still. I think that would server your purpose. https://forums.eagle.ru/showthread.php?t=76032

Perhaps it’s a misunderstanding of terms on my part. So DCS-BIOS does natively support shift registers, IC2, ect. It doesn’t mean it won’t work with those, but you have to write more code or integrate an external library to get your particular solution to work with DCS-BIOS. Even RS-485? So I could use shift registers, button matrix, IC2. Clearly for practical reasons, we have to find a way to expand the number of input pins the Ardunio(s) can recognize for all the buttons and switches possible in the game (the A-10c in my case). I appreciate your perspective on getting around the limitations of pins on the Arduino and the length of the cable runs. I’ve gone back and forth on this myself. Have one master hub where all of the inputs get bundled or using an Arduino (or shift register, etc) per panel and allowing the buttons wiring to have a shorter run to the hub, and allow only the serial wires to be the ones with the big run length back to the central Arduino. I think this comes down to a value judgement, both monetarily and build effort wise. To me, with either DCS-BIOS or MMjoy2, I’d rather buy cheap shift registers per panel than a full blown Arduino per panel using RS-485. Either way, you’d still daisy chain each panel to each other with only the serial connection between. Button wires stay local to that panel. I was not aware that DCS-BIOS could pick up things that aren’t in the controls settings. Is there a reference highlighting the controls that it pick up, but the control settings don’t? This might be the deciding factor should there be a large gap for the controls that matter to me. I’ve already had a few Arduinos I’ve played with in the past for other little fun projects. Nothing I needed more pins on though. I bought a pro micro for this project and a shift register (later realized I got a shift out instead of a shift in. whoops) and started working on it straight away with the shift register since I knew I’d run into that pin limit in short order. I think you’re probably right in that I can change my mind relatively easily at this point.

I’ve decided to pursue a home cockpit, but need help deciding on the electronics “ecosystem” it will be based off of. I’ve recognized three of these systems. Helios (Touchscreen monitor) DCS-BIOS (Arduino Based) MMJoy2 based button box/gamepad device. (Arduino based) I will be building a mixed reality cockpit for the A-10c to match the dimensions in game for all the “switches and buttons that matter”. This eliminates Helios as I’ll be under a VR headset and therefore can’t see any screen. This leaves me with DCS-BIOS and MMJoy2. It’s been a toss up between these two, but based on what I’ve learned recently I think MMJoy2 is the winner, but I want to make sure my assumptions are sound for my application. DCS-BIOS can send and receive information from the game. At first glance, it seems very easy to program the Arduino system it uses. The downfall I’ve recently realized is that it is not directly compatible with shift registers or any sort of port expander method (IC2) which I found to be a major flaw for a system so inclusive to all of the data coming from and going to the game. (A bit like hand loading individual sheets of paper into a printer that can print 500 sheets a minute) On its own, it’s full potential can’t be realized without some hardcore coding or more boards. I’ve learned that the intention is to connect slave Arduinos (basically one per panel) to a master Arduino over RS-485 (which I barely understand) in order to use more inputs/outputs. I’ve read recently that people are still running into limits and the solution appears to be USB hubs to connect each panel individually and avoid any conflict all together. Even this requires hard setting COM ports so they don’t randomly change should Windows feel like it. As I am not concerned with LED indicators, text readouts, gauge replication, I’m beginning to think this system allows for functionality I won’t use and to get it to use what functionality I do want is a bit expensive. MMJoy2 is also Arduino based. It’s major limiting factor is that DCS world (or Windows) won’t recognize a device with more than 128 buttons. I’ve seen others create HID USB devices that appear as two separate gamepads so you effectively get 256. It does allow for the use of shift registers (74HD165 in my case as I only care about inputs). Button assignment is done in game rather than hard coded into the board making it possible for me to use buttons and switches from this in other games and other DCS modules (although clearly a problem with mixed reality as I sit in an A-10c but fly something else). This solution is also more sensitive to reassignments to the control scheme should ED decide to change something. Also, I’m unsure if every cockpit function can technically be mapped. I have a TM WH and cougar MFD’s so I’ve honestly never even looked up to see if I could reassign some of those buttons to another device. I’m currently using the head tracked VR cursor with a shift modifier on my HOTAS to toggle switches and spin dials. Even still, as I only care about 1:1 tactile feel of buttons, switches, and dials, I believe MMJoy2 to be the most appropriate. The added benefit in my case, is that I only need a $0.48 cent shift register every time I want to expand functionality into another 8 inputs rather than a $5 or more Arduino for functionality from DCS-BIOS I don’t need. I can just daisy chain as many shift registers I need (until 128 of course). I recognize there are things I may not be considering. Given my application, what do you believe I should go with?

As an update, I was able so use my search-fu and find the same tools you did. I was able to import the .EDM into Blender and then export the whole thing in a number of formats including .STL. I've noticed that each "object" gets its own line item in the Blender tree view. I'm currently looking for a way to recursively save each object as its own .STL file which would be handy later on. I'm using dassault CATIA v5 (same thing fighters and pretty much everyone in aerospace uses). I haven't had much need to reverse engineer from an STL but I can see how this might come in handy in my day to day. I'm currently exploring various tools to create actual geometry (points, lines, planes, curves, surfaces, etc.) from the .STL This will give us very accurate means of measurement. If I'm able to recursively save as I mentioned above, I should in theory be able to create and assembly of sorts which would allow us to isolate dimensions for the components we actually would want. Another interesting thing I observed was that the .EDM had an ordinate system set at the eyepoint. This got carried over to the .STL as well so every component should sit correctly in aircraft geometry.

(Sorry if this eventually shows up twice; I had a message typed up but the forums logged me out. ) It appears you and I are on the same journey for the same reasons. Would you mind sharing how you got the model exported? Might I be so bold to ask for a raw copy of the results? Potential scaling issues aside for a moment, if you are building a physical cockpit for VR use, wouldn't you want it to match the scale of the in game cockpit regardless of mil spec. It needs to match what your eyes see in game. right? Now in regards to your scaling issue. I use aerospace grade modeling software on a daily basis and what you may be seeing is a result of some global scaling factors that are often applied to .STL files. What format did your export from EDM come in or what filetype options were there? I may be able to help investigate more. We have a Stratasys Fortus 400mc and the Insight software allows for a global scaling factor to accommodate for shrinkage of the thermoplastic after 3D printing. 4.1% sounds about right for certain materials. I think ours was a little north of 3%. I suggest looking for a global scaling factor somewhere that might be automatically applied to you .STL. STL's are garbage to model from anyway. The other consideration is the system of measurement be it metric or sae. You'd be able to tell that right away usually. But again, depending on your import/export process, its possible your could induce some error. The STL creation is literally dependent on your graphical fidelity settings of your modeling software and not any sort of math/formula based model. It's possible to induce error there too. This can get carried over to cylinder-to-cylinder measurements for scale. It boils down to your tessellation accuracy. I doubt this is occurring but it's worthy of mention. PM me? I'd love to see what you are seeing. I'd love to lend a hand.

Yep. That's the first thing I do as well. Oddly enough, that was always working in both the VR menu and the cockpit. (Even though it was recenterng me outside the cockpit). I just couldn't use the subject commands to move the pit to my centered eyepoint. I must have mashed the right buttons cause I got it working somehow. The only thing I can think of is that I've always had to hit esc after a mission loads, adjust controls, and then just click ok withoit actually doing anything. I have my left/right/scroll on modifiers on my hotas and they don't get recognized unless I do this. Why this may effect they keyboard commands I do not know. I may have skipped this step before trying to move the eyepoint as I do not think it was dependant on this hotas functions being fully recognized. If I'm able to recreate the non responsive condition, I'll try to pay attention to the sequence that fixes it.

I've been messing with my real world cockpit to get it to line up with the in game dimensions. I've got a TMWH and MFD's so I've been measuring models and adjusting lots of things. I've been stepping outside the cockpit to get a better view from the side to see if components are at the proper station line relative to each other. Some how I haven't been able to move the eye point at all and I've been stuck just outside the right side of the cockpit and just in line with the dash. The commands don't work. Did I toggle something? Whats going on here?