Gareth Barry

Generally yes- although i admit this is probably one of the many bad habits one can pick up (ie not cranking) when playing against AI red team in singlw player, who dont have fox 3s. In this scenario, they might launch a fox 1 at me, but they will eventually have to defend my fox 3, which trashes their fox 1. I usually go full burner when launching at high altitude to give the missile as much KE as possible, pull back the throttle after launch and then crank. Perhaps im not cranking enough? Anyways, im not saying that it's wrong that i seem to usually catch up with the missile- perhaps i worded that badly- it's just not how i imagined missile shots to play out. One of the main reasons i play dcs is to really educate myself on how these aircraft really work. Before DCS, I had no idea about search bars, radar modes, doppler filters, PRF and and and....

Does the missile behave differently against AI when online vs when playing single player? The reason that i ask, is that i am currently playing through 'Cage The Bear' on single player, and have got plenty of kills with the phoenix, including tonight in a pretty tough mission (mission 9, which was bugged and hence almost impossible- thankfully kaba was kind enough to send me an updated file that fixed this mission.) Whether these are correct tactics or not i dont know, but vs fighters, it really does seem like two different missiles-when above 25000 ft, kills of around 40 miles or more seem to have a decent probability- although it does seem strange that at impact, you are pretty much within visual range of the target. At high altitudes and long ranges, i pretty much always fire in tws- keeps SA as well as options to fire another one. At low altitudes, its pretty much a 10 mile missile, and seems to have pros and cons vs the sparrow. I almost always fire from a PAL lock in these situations. This is assuming a head on target- if in a tail chase, the distances seem to be much closer (like half) in order to have enough energy. Well, thats how i use it anyway, which may or may not be correct, but seems to be working for me at least.

Has anyone completed this campaign recently? I have tried and tried to have success in mission 9 'clearing the way' but am absolutely stuck! The times when i dont get shot down, one of the strike package gets shot down and results in a draw. If i am more aggressive to try to attack the airspace around the base where the strike package is targeting, i get swarmed and shot down mig 29s and 23s. I wonder if this campaign was designed before the aim54 got reworked? I maybe i just really suck? If anyone has any tips, id be very grateful!

Rustbelt, is something like a co-ordinated turn with rudder something you can accurately feel in real life, or is it something requiring an eye on instruments? I find the little white dot thingies on the acm panel of the f14 to not be very useful, they oscillate around so much. Maybe im using them wrong?

Victory205, In case you havent heard it enough, i want to thank you for all of your input into this module and on this forum. I really cant express how grateful i am. One thing that i am trying to figure out is, why it would require so much muscle to shove the stick into the corner when in a spin? Please hear me out on this, whoever is reading this, to see where i have a misconception. My understanding (from reading NATOPS)is that the f14 had a very old-school system of providing artificial feel to the pilot, use a cam+roller+springs with bobweights. The bobweight would provide inertia against centripetal acceleration in the longitudinal axis, the the pilot needs to overcome in order to pull back on the stick. This system gives a more-or-less constant 'stick force per g.' Now with that being said, in a spin, i would have thought that the major vector of acceleration is towards the nose of the plane, the so called 'eyeball-out g'. This, combined with near zero indicated airspeed, would have made me believe that the stick would become quite 'soft.'? The reason that i ask this, is that i am working on a simple upgrade that could be attached to any of the non force feedback sticks, that would give increased force required in the pitch axis for a given deflection as airspeed increases. This would not be nearly as good as a proper ffb gimbal, but i think might still be a useful upgrade and much much cheaper. However, if there is something about the f14 stick that i am misunderstanding, i would like to re-educate myself. Thanks to anyone who read through all of this, and sorry if its slighty OT.

I guess Grumman expected that pilots would fly according to the manual, and not lower the flaps above 220 knots? -\/(",)\/- On a serious note, I have found myself, on more than one occasion, being a bit late in raising the flaps after a cat-shot, see the plane start to shudder and shake, look at the airspeed indicator, see that I'm doing 300 knots, with the flap lever still down, and think 'thank goodness I was never a Navy pilot....' I wonder if that ever happened in real life? I am thinking maybe it is just down to complexity, but having said that, I wonder why logic wasn't programmed in that the flaps would be raised if above a certain airspeed regardless of handle position, and could not be fully lowered if above a certain airspeed? I mean, the f14 did have the first real microprocessor as I understand it, in the form of the CADC? I wish we could interview more Grumman engineers from this time period.

Just to conclude this, I dunno if Heatblur read my comment, or I was just a dumbass and didn't see that the wingsweep handle is now available as an axis, but there it is! Man I love the Heatblur team and the f14!

Thanks, Rustbelt also rexommended those exact mods- guess i will just havs to bitw the bullet and go with them.

Dear Heatblur I am currently, and have been working on for ages, a throttle quadrant that is as close as possible to the real thing. Initially, I was going to have throttles that move when in autothrottle as well as a moving wingsweep handle. I have shelved moving handles for the moment, until I can get the rest of it satisfactory. My issue is this - I have gone to great lengths to have a wingsweep handle that has the '4 degree notches' and is also extendable. The action of extending the handle triggers a microswitch, opening the cover triggers a mercury tilt switch, and I am very grateful that these actions are available to be mapped as buttons. Now I know that the wing sweep handle is not just a simple axis, and obviously the thing moves when in auto, but surely a 'button' to push it forwards and a 'button' to push it backwards isn't any more realistic than just making it an axis? Yes, I know that there is the potential mismatch between the actual position of the handle, and when a user moves it, but surely this is no different than disengaging auto-throttle? Very few of us have moving auto-throttles, and the game accounts for this 'mismatch' without a problem? Surely, a simple solution is a conditional statement in which if the wingsweep handle is moved by the user, quickly but smoothly move the in game handle position according to the value from the axis mapped by the user? When 'master reset' is pressed, then ignore the axis value and just move it in game as it would according to the CADC etc etc? Again, this is very similar to the way auto-throttle works in the game, and even though almost none of us have throttles that physically move when in auto-throttle, the current compromise is surely a good one- just do the same thing for the wingsweep handle and master reset? This post comes across a whining and I really don't mean it to - it's just that I love your F-14, and I not competent enough currently at coding to go through the pain of trying to do all of this myself through DCS BIOS. Thanks!

Personally, id like to see all of the clickable switches become bindable- i have made a left panel that is ready to go. Yes i know i could always use DCS Bios, but i think personally that a basic HID input is easier. I also know that there are some mods that can fill this gap, but id personally rather not use any mods. Please add things like the intake ramp switches etc to be bindable. Thanks

Just been thinking about this, please excuse my musing- but upon further thought, if the current kinematic model of the phoenix matches the NASA simulation across a range of altitudes, then that is more than good enough for me `\/(••,)\/`

Shucks so there never was an actual physical test by NASA. Goodness, need to process that. Does the Heatblur model kinematically match the NASA results across a range of altitudes? Or is it specific to one altitude only? Not trying to point fingers or throw mud in any direction at all, just want to understand where we are.

Firstly, i want to thank Mr Palkovnik for his work on this- i have enjoyed being educated about nozzle exit area vs altitude and its effect on thrust and impulse. Let me also preface what i am about to say with this- there are few purchases i have ever made that i have been as happy with as Heatblur's F14. But for us nerds who like things to be as accurate as possible, even if just to understand how things really were historically, it is interesting to know where the current model is off. Can i ask for a somewhat condensed, descriptive version of Mr Palkovnik's findings versus the current model? From i can gather so far, the current DCS model is a somewhat simplified model that is sort of an 'average' across the altitude range. That is, Mr Palkovnik's model shows that the missile as currently modeled is somewhat underperforming at high altitude, and perhaps overperforming at low altitude. The motor of the phoenix is quite different in that it has pressure and nozzle exit area make its thrust quite dependant on altitude. Perhaps then, the missile matches the NASA test because that is where the current model is tuned to? As i said, im not really even asking for any changes, just trying to understand this better. And my comments/summary could be very far off.

Yogi Another thing i wanted to mention, is that it is very possible to code the 'axis' of the flap handle to act as a switch, without swapping the potentiometer for a microswitch. In fact i personally think its the better way to do it. Simply have something like; If (flap_axis_value < 100) { Joystick.pressButton(20); Joystick.releaseButton(19); } Else { Joystick. pressButton(19); Joystick.releaseButton(20); } I havent debugged the above code because i typed it out on my phone, but im sure you get the idea. Doing it this way, you could even have a third artificially created 'button' the acts as the emergency flap position. To clarify, in the above code, 'buttons' 19 and 20 wouldnt be actual physical buttons, just artificial ones created by the code in order to send the switch state to DCS based on the value read in from the pot/hall effect sensor. I might just redo the flap handle on mine for this very reason. I am definitely going to use this idea for the idle cutoff- so that i dont have to put actual buttons or microswitches at that detent position.

Hi Yogi I will watch the video later but just wanted to ask- did you see some of my suggestions in the other thread to the stability issues you were having? Personally i cured all of mine by averaging 50 values of analogRead and then passing that to the joystick.h library, without having to use shielded wire or a low-pass filter capacitor from signal to ground- although i may just do the shielded wire part simply because i think it's better practise.

Yogi It seems i was right regarding using shielded wire. Essentially, the spikes on the signal wire voltages are most likely due to noise coming into the wire, be it from a faulty connection (make sure you solder the wires well) or coming into the wire from stray RF signals, for shielded wire is an excellent fix. Another thing we would sometimes do in building audio amplifiers is to twist the two power wires together, ie the ground and 5v wires running from the pot to the arduino. Another thing you can try is soldering a 1nf or so capacitor between the signal wire and ground- the higher the capacitance value the more 'smoothing' you will get of the voltage. And finally, i think another thing you can do, and a simple fix i was going to try, was to run a sub-loop in the code of the main loop, that samples say 20 readings, averages them, and then sends that as the actual output value from the throttle. I am having some spikes as well, which i thought i had fixed, but seem to come back intermittently. Oddly enough, it doesnt seem to affect the handling of the tomcat too much, i guess the latency of the engines themselves overwhelmes any small throttle input spikes that there may be. My bigger problem at the moment is that the two leonardos do in fact seem to be conflicting with each other, in that the button and axis mapping has to be reset everytime DCS is loaded up. Going to fix this after christmas. I hope you get your code working Yogi! I guess if push comes to shove, you could always use a cheapish but decent PC compatible 'joystick' (the ones shaped like a playstation controller) and gut the boards inside and rewire that? Perhaps just use your arduino for any extra buttons, as i need like 16 or so on my throttle, 4 more than a PC gamepad controller. These gampad controllers i think have all sorts of filtering to make sure that the signal output is super stable. I hope this is helpful!

Hey Yogi I guess we are both fighting arduino! The first thing i will say, have you soldered the actual connections to the board? As soon as i did that i noticed an increase in stability. The other thing, are you using the Joystick.h library for a leonardo or promicro? If so, you can remap the input to reduce the resolution from 1024 to 256 bits, which also increases stability. The decrease in resolution has not made my flying any better or worse. Another thing that helps is calibration- sometimes going through the calibration makes it stable and sometimes it messes everything up- i find i just need to persist until i get a good outcome. Are you using Hall effect sensors or pots? My understanding is that a hall effect sensor has a high gain amplifier in it, so i am wondering if using shielded wire for the signal wire could help reduce interference that may be causing voltage spikes. This works well when building for example high gain guitar amplifiers (a hobby i used to have a few years ago). I guess if nothing else, i would think that keeping the signal wire run to the microcontroller fairly short would help some. I could be wrong re the shielded wire for the signal from the hall effect sensor but i was going to try it, but good solder connections to the arduino along with calibration seemed to have made the spikes acceptable. I hope that helps? I found out that it is possible to use a leonardo for example with the joystick.h library and still get information back from DCS bios. I dont think a leonardo can send information to dcs via dcs bios.

And now I find out that DCS BIOS doesn't work with the Leonardo...gosh. Ok, will just enjoy the throttles as they are for a week or two and will then get a nano and try to do the axes with that.

Hi Draconus That's my son's corn snake - he handles it pretty much every day! -it actually crapped on my other son and I had to wash clothes and bedding (yuck!) You are exactly right regarding the joystick , it's a t16000m that I replaced the 'shell' with ont that I 3d printed. It was my first foray into this world of cockpit building - and now the bug has bitten pretty hard. At first I was going to do the same thing to the t16000 throttle and use it's electronics, but i am so glad I didn't. On the one hand, I have learnt so much about microcontrollers, and have gotten my son into arduino as well. Also, who knows, maybe one day I will build another gimbal and restore the t16000m back to another more generic joystick, then I can dogfight my kids and show them who's boss. Ultimately I want to build pedals that also more closely match the tomcat's.

Time for another update - Been learning how to code arduinos. The problem that I had was that I don't have enough pins on one leonardo to operate all the buttons, axes and stepper motors. I tried and failed to use shift registers and I2C components. I could have tried a multiplexer, but in the end I just bough a pro-micro to handle the buttons - the Leonardo handles the axes and will also control the stepper motors. I was worried that DCS would confuse the two boards but that doesn't seem to be a problem. Now that the axes and buttons are working, with sufficient pins to add the stepper motors, I went and installed in my crude simpit chair. Pretty happy with how it has turned out. I ran out of room in the box itself to contain the leonardo and stepper motor boards, hence you can see them poking out the front. Nevertheless, as a simple axis with all the buttons in the right place, it works. It's pretty cool to open the wingsweep cover and see the same thing happen in DCS.

Apparently you have to rename one of them in the 'boards.txt' file as well as chanigng two other numbers. But this is not without risk of bricking the microcontroller. And to make matters worse, arduino updated the IDE so that changing the name as I mentioned above is not nearly as simple as it used to be. I don't know if you have had success with this?

Hi all I'm hoping this is the correct place for this question- I am wanting to build my own throttle replica for the f14. I am at the point of coding and connection an arduino leonardo, and I would like to use to CD4021 shift registers daisy-chained together to handle the 15 buttons that I am going to need. I am having some trouble understanding the 'shiftin' function for arduino, and how to use it work with the joystick.h library in order to use the shift registers to handle the buttons. I have found this tutorial; CD4021B Shift Registers | Arduino Documentation I am still struggling to make sense of how I would modify it to handle the buttons of the joystick. Any help would be greatly appreciated.

**********update*********** sorry for the lack of progress, been a bit busy with work. Nevertheless, some progress has been made. All of the hardware side of things has now been hooked up and is functioning correctly, as far as I can tell. Funny how certain things that one thinks will be trivial end up being a hassle- namely, getting the magnetic field oriented correctly so that the Hall effect sensors will work properly. Got there in the end though. On the plus side, the wing sweep handle system that locks into the 4-degree notches is working perfectly. The next step is to get it working as a basic throttle, without the stepper motors moving anything- even though I have tested those on both throttles and the wing sweep-handle and they work perfectly. I have ordered an Arduino Leonardo and two CD4021B shift registers to get all the buttons to work. I'm still struggling to make sense of shift registers and the 'ShiftIn' library of Arduino - the basic joystick with the joystick.h library seems fairly simple.

I think what helps me is to hear "Slammer" Richardson's voice in my head telling me to be '2 steps ahead of the jet.' In this particular instance, for me that means working the throttles by small amounts, but constantly. I know that kinda contradicts what I said earlier, but at this stage in my 'flying' (250 hours in the 'cat) I have my hands full trying to manage lineup, ball and groove time and being consistent. I find that I land better after I've done some inflight refuelling, as it forces me to have finesse with the throttle, particularly in terms of being 'ahead' of it, ie accounting for the delay in perceptibe repsonse from whatever input i make from the throttle. Oh, and some interviews do mention small blips of DLC here and there. I know victory 205 says it's really just to counteract ballooning over the ramp, but I have heard other pilots talk about using in other parts of the pattern. In any case, I do try to keep it to a minimum. Personally, I found that a mistake i was making was not adding sufficient power prior to the final turn onto the groove - all because I didn't want to spoil my beautiful on-speed trim that I had worked to achieve on the downwind leg. This would result in my losing too much altitude during the final turn, then intercepting the glideslope too close to the boat, and with a hell of a lot of work to do to get properly trimmed when I finally did get the ball in the right place but with very little time left to keep it there. Far better to add some power in the final turn, manage the descent properly, to come out right smack bang where the needles cross on the TID, giving me sufficient time to trim for the groove onto (hopefully) a perfect 3 wire. Sorry if some of this if OT.

I've also wondered about this, particularly since I am building a set of f14 throttles that have functioning autothrottles- the NATOPS specifically says that autothrottle can be selected on the downwind leg before final 'if desired', thereby implying to me at least that it is perfectly valid to select autothrottle for even CASE 1 approaches. In that case, the way to get more power if you need it is to pull back on the stick, and vice versa. Having said that, listening to interviews with LSOs, they seem to imply that the only perfect landing is one which has zero corrections at all, not pitch, throttle, nada, but coming into a perfect 3 wire in around 17 seconds of groove time. In other words, the turn on to final approach is managed such that when the jet has rolled out, it is lined up perfectly laterally, at the correct altitude, on speed and with perfect sink rate, with zero subsequent corrections needed. Seems almost impossible to me, but there you go. Interviews also seem to suggest that it was all the more difficult with the tomcat to get good scores because the jet telegraphed any and all corrections to the LSO.