shreddersa

and so say all of us...and so say all of us...

I saw the Smith paper on Cambridge University Press. However, to fork out GBP25 for a paper published in 1947 (should be free and in public domain after 70 years) is a bit rough. So I will work on the figures I can get. These all seem to corroborate the NACA tests as far as I can see. I will compile a set of what I have and publish it here. Cheers, Roel

Hi DD, I regret that you too are working on assumptions. I went through the NACA L-334 report again which formed the basis of my force calculations. It states explicitly on page 2 and again on page 12 that the ailerons were metal covered. All that said, I would dearly love to get hold of the lecture notes by Smith to better understand the context of the figures you present. It's all a very interesting journey! :thumbup:

Very interesting info and very valuable, thank you DD! I will have a good look at the figures and see how they might be incorporated. It would indeed mean that for the IX the forces are overstated. That's a bit of a relief really as it means I can go for weaker springs and less forces are induced in the system overall. Currently the FF provides the following results:

So I checked and regrettably, this does not seem to be modeled properly in the DCS Spitfire. This in spite of the purported Professional Flight Model. My tests indicated a roll rate to port of 360deg in 5 seconds, whether at 180mph or 300mph. This in contrast to say the P47 modeled by FlyingIron Simulations for X-Plane, where the roll rate is 5 seconds at 200mph and 2.5 seconds at 300mph. I look forward to their Spitfire Mk.IX for X-Plane 11!

Thanks for the heads up! Those were the only figures I have been able to find. That said, I understand that metal ailerons were being fitted by June 41. They were fitted to MkV, so the NACA tests done in September 1942 would most likely have been with metal ailerons.

As the airspeed increases, less control movement is required to achieve the same roll rate. I need to test whether this is properly modelled in DCS.

Hi Boris, Apologies for this late response. My post notifications dont seem to be working correctly. Thank you for the kind words. Yes, we believe this will be providing an amazing experience. It will marry an accurate Spitfire MkIX cockpit to the DCS World Spit, giving an unparalleled VR immersion. Yes we have thought about (and designed) a spade grip with gooseneck compatible with the VKB base ( not sure if that is also compatible with the Warthog, TM technology is not as accessable as VKB). They have been somewhat busy though, getting their new factory going and orders shipped, so it hasn’t progressed much further at this time. For us the priority is to complete the cockpit but will pick up on it again in the new year.

Disappointing It's disappointing that there seems to be a total lack of response from ED on this matter...:(

Thanks for pointing that out Ranma. Very useful info. :thumbup:

Gentlemen, I am extremely grateful for your help and responses. I have no doubt that it will be valuable for others too. Tekkx, you were on the right path that this could be solved programmatically, thank you.:thumbup: Draken152, fantastic info, thank you. This will be extremely useful in understanding the underlying programming to DCS-BIOS, and I have no doubt your suggestion would work. Great work on the Dora by the way, I will be following your build with interest! :thumbup: TechRoss, yours presented the simplest potential solution, so I tried that first :) DcsBios::Switch2Pos starterCover("STARTER_COVER", 3, true); Very pleased to say that IT WORKS!!! :thumbup: I am so happy and excited! Thank you all again! I will post a little video of my testwork, hopefully it helps others too.:pilotfly: For details on my design/build, check out my website: heritageflightsim.com

Thanks Tekkx, not sure which value you would be referring to? The only value given is that of the pin number. The magnet and Hall sensor work great, just the wrong way round. My understanding is that reed switches may not be terribly robust?

I have just started using DCS-BIOS and am very grateful for this fantastic tool. I have set a test panel to include ON-ON and ON-OFF switches, RotaryEncoders and pushbuttons. It is all working great. My question comes in for a specific application in the Spitfire. I have rigged the starter button cover with a little magnet in the cover and a Hall Effect non-latching switch in the base. As a result the Hall Effect switch switches ON when the cover is closed and OFF when the cover is opened, ie. the magnet is removed. This has the opposite effect to that which is desired in-cockpit. Is it possible to add code in the Arduino sketch which will reverse this effect? It currently reads as follows: DcsBios::Switch2Pos starterCover("STARTER_COVER", 3); The full sketch is as follows: /* Tell DCS-BIOS to use a serial connection and use interrupt-driven communication. The main program will be interrupted to prioritize processing incoming data. This should work on any Arduino that has an ATMega328 controller (Uno, Pro Mini, many others). */ #define DCSBIOS_IRQ_SERIAL #include "DcsBios.h" /* paste code snippets from the reference documentation here */ DcsBios::Switch2Pos starter("STARTER", 2); DcsBios::Switch2Pos starterCover("STARTER_COVER", 3); const byte flapsPins[2] = {4, 5}; DcsBios::SwitchMultiPos flaps("FLAPS", flapsPins, 2); DcsBios::Switch2Pos magneto0("MAGNETO0", 6); DcsBios::LED ucDownC(0x5412, 0x4000, 7); DcsBios::Switch2Pos buttonCan("BUTTON_CAN", 8); DcsBios::Switch2Pos buttonMg("BUTTON_MG", 9); DcsBios::Switch2Pos iffCover("IFF_COVER", 10); DcsBios::Potentiometer pitliteLh("PITLITE_LH", A0); DcsBios::RotaryEncoder clkPinion("CLK_PINION", "-3200", "+3200", 11, 12); DcsBios::Switch2Pos clkPinionPull("CLK_PINION_PULL", 13); void setup() { DcsBios::setup(); }

Dont wish to spam mods so remove this if inappropriate, however I thought this might be of broader interest. The HFS cockpit design is just about complete and the prototype construction will be starting this month, with plans proven and available targeted by end of the year. https://heritageflightsim.com/2018/07/08/free-desktop-wallpaper/

The DCS Spitfire undercarriage indicator (the little window on the "Chassis Control") currently shows "Down" when the U/C is at rest in the down position and "UP" when it is at rest in the retracted position. This is incorrect. As per the 1946 Air Ministry pilots notes for the MkIX, the following is the correct indication: "An indicator in the quadrant shows DOWN, IDLE or UP depending on the position of' the hydraulic valve. UP and DOWN should show only during the corresponding operation of the undercarriage and IDLE when the lever is in either gate." Perhaps something that could be fixed? Many thanks, Roel Heritage Flight Simulation

Hi Nineline, Any idea when this might be fixed? Cheers, Roel

How was that achieved please? I dont need the extreme accuracy or the ability to flick switches, only to see where my hands are in the cockpit. ( I am building a real cockpit to scale around me using the Spitfire, but still need to see where my hands are. )

Hi Krupi, Whatever happened to your cockpit build? Looked really good what you had done. Cheers, Roel

Thank you Sith. Also thanks Krupi, I note you picked this up in 2016 already. Best regards, Roel http://www.heritageflightsim.com

Dear ED, I am taking great joy out of flying the Spitfire in VR. So much so that I have been designing a physical cockpit for kit distribution: (Heritage Flight Simulation) While closely studying the cockpit layout in VR last night, I noticed that your control column elevator action was not pivoting from the bottom of the column, but was swiveled at a point just below the seat. You may wish to have a look at that and correct the model. I have attached the relevant original drawing for reference, but you can also check with your colleagues at the Fighter Collection. There is also a picture of the control column and rudder pedals layout as it should look. The swivel point for the column is at the bottom, the elevator control rod sits just below the seat. Thank you for a great simulation, I was one of your first customers and hope to be still enjoying your products in another 25 years! Roel Stausebach Heritage Flight Simulation

103 views and not a single reply from ED? :( I have copied this thread to the Spitfire bugs page, this was probably the wrong place...

Dear ED, I am taking great joy out of flying the Spitfire in VR. So much so that I have been designing a physical cockpit for kit distribution: (Heritage Flight Simulation) While closely studying the cockpit layout in VR last night, I noticed that the control column elevator action was not pivoting from the bottom of the column, but was swiveled at a point just below the seat. You may wish to have a look at that and correct the model. I have attached the relevant original drawings for reference, but you can also check with your colleagues at the Fighter Collection. Thank you for a great simulation, I was one of your first customers and hope to be still enjoying your products in another 25 years! :) Roel Stausebach Heritage Flight Simulation

Thanks Dmitry!

Other than the obvious server overload problems I have not been able to download the 2.5 update, I believe because of the following error in the log file: ERROR: D:\DCS World OpenBeta\_downloads\Mods/terrains/Caucasus/Surface/Caucasus.surface5: (112) There is not enough space on the disk. I am running the install from the command line "D:\DCS World OpenBeta\bin>dcs_updater update" It is an external disk where 1.5 resides and is formatted in FAT32 with 615GB free space. Further down in the log there is the message "ERROR: size mismatch: got only 4294960758 out of 6218194912 bytes for Mods/terrains/Caucasus/Surface/Caucasus.surface5", so I am wondering if the problem is related to the file not being able to unpack because the format of the disk does not allow it? I had a problem copying the Nevada map across from my C drive to the terrain directory in 1.5, with a message that the surface file was too large for the drive format, more of the same? How can one get around this? autoupdate_log.txt