Brun

I appreciate that, but the flip side is that with a momentary switch you can never be sure what state you're setting it to because it just works as a toggle. In other news, had some deliveries today... Initial tests with the BBI-64 are very positive. The encoders and toggle switches work exactly as expected which is a relief. Most of them feel very good physically as well. If anything the larger toggles actually feel better than the ones in the Warthog throttle. The only disappointment is the square push-buttons, which are heavy and don't have any sort of distinct contact. If there weren't twenty of them I might have considered trying an alternative, but there's no guarantee that would be any better. Dimensions of all the switches match up with the ones I'd modelled from their datasheets, so the 3D model is good from that point of view. Am expecting a delivery of cap screws tomorrow so I can check the holes I'm making for those (the ones around the display) are correct. Currently finalising the design of the case. Have a feeling I might be over-engineering the whole thing, but I guess that's better than the alternative. Unlike an aerospace engineer I have the luxury of no concerns over weight :)

I've ordered two and three position switches as they are in the aircraft. Don't see how the functionality would work otherwise. The only momentary ones are for the HDG and CRS although I don't think I'm doing that panel initially. That follows the same logic as the switches on the Warthog throttle, which have never given me any issues.

I've no intention of producing them to sell, sorry. The design will be available for people to make their own though. It shouldn't need any electronics skills beyond a bit of soldering. If it does I'm screwed, cos that's all I've got. It should be reasonably plug and play, the Bodnar controller will just appear as a USB device and need mapping in-game. Got the lettering done. Obviously this won't print white, but the hope is that the embossing will take paint quite easily. It's very small in scale though so I'm not sure how it'll print. Think I'll get a small test piece printed to practice on.

Can't help with Fusion 360 unfortunately, this is all modelled and rendered in Modo. General advice for getting good renders is to use a decent environment image to light the scene. No idea if that's an option in your case tho'. Finished the HUD panel and modelled the various knobs. The HUD panel is in two parts, with a front plate over the piece that the switches are mounted to. Just pulled the trigger on the components. No backing out now :)

Thanks. That figures, cos I've noticed similar when trying to change brightness using the mouse wheel. I wonder if they've just defaulted to standard 8-bit brightness which gives 256 levels, each requiring a single click? Using pots would throw a spanner in my plan to use the BBI-64. I do have a spare BU0836A which takes analog inputs but wouldn't have enough digital ones. Could always use both and just deal with two separate USB devices. If I stick with the encoders there's a 24 PPR version which might be more suitable.

Thanks. My 3D proficiency means the shiny renders look a lot better than the final product might :) I'm hoping that the electronics side of things will be fairly plug-n-play. Rather than me charging to procure and assemble stuff it'd make more sense to just make the 3D model available for people to have printed themselves. I've also not yet decided how to close the back of it. Rather than spend another ninety quid getting a custom-designed back printed, I'm thinking of finding a suitably-sized project box and making the 3D model fit that.

As for cost, DIY definitely doesn't mean cheap. The components total almost £90, the Bodnar board is £35. Getting the UFC (even without the HUD panel) 3D printed by Shapeways will be another £90. That's caused by the dimensions as far as I can tell, so there's no way to reduce the cost. Having said that, I've used Shapeways for a few smaller things and been very pleased with the results. Just a bit nervous that this is much more complicated and not getting it right first time would be an expensive mistake. Current plan is to buy the switches and stuff (assuming no objections to my questions above), then check those against my model to make sure the design works. Think the next step would be to get the Bodnar board and test all that works, before biting the bullet on the pricey 3D printing stuff. In the meantime I'm gonna add (subtract?) debossed lettering to the 3D model, which should make it easy to paint it (despite that being completely irrelevant in VR). Also have the various knobs to model but that shouldn't present any issues.

One important bit of info that should've been in the previous post is that I'm using VR, so thankfully don't have to worry about the displays. I reckon the rest is distinct enough to operate by touch, but will probably add something to the main keypad buttons to make them more easily distinguishable. Here's my current list of switches and stuff... Square switches x20 Round switches x6 Rotary encoder x7 Rotary encoder with push button x2 for COMM channels, even though they're pull IRL. Switch ON - ON x2 for HUD Day/Night switch and Alt Baro/RDR Switch ON - OFF - ON x3 for HUD Rej, HUD video and attitude source selector* Switch (ON) - OFF - (ON) x2 for HDG and CRS setting switches if I do that panel as well Switch ON - OFF - ON for ADF selection switch* *need to confirm whether these are set up (or if it's possible to) as 'special for joystick commands'. None of them are critical but it would be good to have everything working properly. Since my electronics knowledge is minimal, this is the bit where I worry the whole thing could go tits up. I don't fancy matrix wiring, so figured Leo Bodnar's BBI-64 should fit the bill. By my reckoning if I include the HDG and CRS switches I'm up to 62 inputs. Couple of questions... 1. Are my rotary enocoder selections suitable? Edit 03/09: Encoders seem to work fine, some issues with noise. 2. In order to match the physical characteristics of the switches on the HUD panel, the Apem toggle switches are 'high current' components. I'm smart enough to appreciate that using components rated too low for their application is a bad idea, but are their any issues with the opposite, specifically when used with the Bodnar board? Edit 03/09: No problems with switches, they all work perfectly

I've got this daft idea in my head that I should build a UFC for the Hornet. Currently this exists as a 3D model and a shopping list of components. All good so far but the next steps involve spending money, so I have a few questions before proceeding. 3D modelling and rendering (although not in any sort of product design way) is my day job so this bit was reasonably straight forward... The HUD panel is only in its early stages. More info and some questions to follow...

Very nice work. However there seems to be an issue with a lot of transparent space at the top of the image, might cause problems for anyone wanting to print it.

^ Was just about to say the same after watching the track.

That's the same one I used. Glad to hear the suggestion is helping people out.

Even on the ground the finger lifts are only required when either the hook or launch bar are down.

I'm pretty certain I'm not wrong. The only thing causing most things on the HUD to 'move' is your point of view changing - i.e. if using either 6-dof TrackIR or VR. This is absolutely necessary because it's a function of the HUD optics (collimated to infinity) which make sure that the symbology - for example the artificial horizon - correspond to the outside world. If you want the HUD to behave as it did in your favourite old-school sims, the solution is to disable whatever it is that allows you to move your head.

Having previously done the manual lua install, I found another solution: Create a symbolic link at the location where windows thinks DCS is installed, pointing to its actual location. Never used one before but - much to my surprise - it worked first time. Fixing the registry would be the best solution, but this is preferable to the other options because it won't need repeating if you have to reinstall the plugin.

These look absolutely amazing. I'm really tempted to build a UFC+HUD panel (already have two thrustmaster MFDs and am considering a third). Am confident enough of my design and 3D modelling skills, even though my day job is animation rather than manufacturing related - the few bits I've had printed by shapeways have turned out perfectly. Very much a novice when it comes to electronics, but thought I could manage with bodnar board of some description. If possible, at some point I'd really appreciate a build list for the various switches required. Browsing online stores for things like rotary encoders makes my brain bleed. Fortunately I'm using VR so don't have to worry about displays. Subscription added, can't wait to see more progress.

Since the Case III approach is flown at 250kts, does the case II maintain 250 into the break rather than the 350kts for a case I recovery?

Blue water ops means the carrier group is too far from shore for there to be a divert airfield. I'm guessing at the rest, but it might be the amount of fuel available from each tanker.

This makes no sense. Almost all of the HUD *is* locked, and the bits that aren't have the option to be via the cage function.

That's great news, thanks guys. I did try a few numbers around 38. Don't think I'd have got round to 13 tho.

I took a look into this. Compared the updated file with the original, and there's these differences: Oiginal -- VHF AM -- Set radio data _data.radios[2].name = "AN/ARC-210 - 1" _data.radios[2].freq = SR.getRadioFrequency(39) _data.radios[2].modulation = SR.getRadioModulation(39) _data.radios[2].volume = SR.getRadioVolume(0, 108,{0.0,1.0},false)* SR.getRadioVolume(0, 362,{0.0,1.0},false) -- _data.radios[2].encMode = 2 -- Mode 2 is set by aircraft -- UHF -- Set radio data _data.radios[3].name = "AN/ARC-210 - 2" _data.radios[3].freq = SR.getRadioFrequency(40) _data.radios[3].modulation = SR.getRadioModulation(40) _data.radios[3].volume = SR.getRadioVolume(0, 123,{0.0,1.0},false) * SR.getRadioVolume(0, 361,{0.0,1.0},false) _data.radios[3].encMode = 2 -- Mode 2 is set by aircraft Update -- VHF AM -- Set radio data _data.radios[2].name = "AN/ARC-210 - 1" _data.radios[2].freq = SR.getRadioFrequency(38) _data.radios[2].modulation = SR.getRadioModulation(38) _data.radios[2].volume = SR.getRadioVolume(0, 108,{0.0,1.0},false)* SR.getRadioVolume(0, 362,{0.0,1.0},false) -- _data.radios[2].encMode = 2 -- Mode 2 is set by aircraft -- UHF -- Set radio data _data.radios[3].name = "AN/ARC-210 - 2" _data.radios[3].freq = SR.getRadioFrequency(39) _data.radios[3].modulation = SR.getRadioModulation(39) _data.radios[3].volume = SR.getRadioVolume(0, 123,{0.0,1.0},false) * SR.getRadioVolume(0, 361,{0.0,1.0},false) _data.radios[3].encMode = 2 -- Mode 2 is set by aircraft The only changes being the numbers in brackets after 'getRadioFrequency' and 'getRadioModulation'. Thinking I might be onto something I had a look through the VAICOM lua files, but can't see anything similar.

I'm having exactly the same problem. There do seem to be some commands which work correctly, I set up a simple mission in the Persian Gulf with me starting on the runway, and asking for permission to take off was immediate. However, in that mission I also have the Stennis and a tanker, neither of which will respond until I press the COMM1 key binding (RALT # on a UK keyboard). Sometimes I have to press it twice before anything happens. I also noticed the way that commands seem to 'queue up' and then each press of the COMM1 key activates them in the order that they were issued. I'm using direct X buttons on the throttle for TX1 and TX2, so there's no conflicts in that respect. As a (hopefully temporary) workaround I was considering using TARGET to fire 'RALT #' after each button release, but worry that might cause other problems.

It's not an issue that should be fixed. During development stuff changes which affects config files, and this means the existing ones have to be replaced. Attempting to merge a user's custom configs with new ones (either during the update or manually) is prone to errors, which would make identifying actual problems much more difficult. Best advice is to leave controller default as much as possible, and do the remapping (both keybinding and curves etc.) in the respective profiling software. Takes a bit of effort, but is far more robust.

Dunno about the NVGs, but people using an LSO mod for the carrier have found it prevents the ICLS option appearing.

KC-135 BDA is bugged, see here.