Ranma13

You're right about this, my mistake. You're right, what I meant to say is that the flapping angle between the two sides stay the same when on the ground (and with no wind) because there's no difference in the airspeed that hits the blade on either side. Sort of; the amount of flap is determined by the blade angle (remember the hand-outside-the-car analogy, the more steeply tilted your palm, the stronger the air pushes it upwards), but adjusting the blade angle also changes the angle of attack, and thus the amount of lift generated. What you said is not wrong, but the flapping amount is not directly tied with the amount of lift, but rather the blade angle. You're correct that at the 3 o'clock position, the wind blowing directly against the blade would be the fastest. However, once past this point, the blade won't continue to flap upwards and will instead start to drop. Going back to the hand-outside-the-car analogy, imagine that you loosen your arm muscles while the car is going fast so that your arm will drop naturally due to gravity. When the car is going fast, the air will push against your hand and lift it up, but as the car slows down, so does the pushing force against your hand, and it will start to drop. Going back to the article I linked earlier, there's two things happening. Without any corrections, the top rotor creates more torque. Because it needs less angle of attack to achieve the same amount of lift as the bottom rotor, it has less drag and therefore spins ever so slightly faster, creating slightly more torque. As you stated, the top rotor moves clockwise, so the torque force is anti-clockwise, causing the aircraft to yaw left. To counter that, you need to input right pedal. At the same time, the advancing side of the blade generates more lift as the wind speed increases, while the retreating side generates less lift. Blade flapping and feathering counters this to equalize the lift on both sides, but as speed increases, it's less and less able to compensate for this, leading to an imbalance in lift. Because the top rotor generates more lift than the bottom one, the imbalance of the top rotor is larger and overrides the imbalance of the bottom rotor, and since the top rotor generates more lift on the left side of the helicopter, this causes the helicopter to roll right. To counter that, you need to input left cyclic. You can test this by keeping the cyclic centered for roll and only change its pitch; at low speeds the aircraft will stay level, but the faster you fly forward, the more the aircraft will start to roll to the right.

That's a good observation! Up until now I thought that the wind display on the PVI-800 showed the current wind, but I ran a quick test and it indeed seems to be showing the pre-programmed wind for the nav point because it doesn't change with altitude. That said, conceptually speaking the angle rate sensors on the nose (#29) should at least be able to measure the crosswind when in a stationary hover: but I haven't been able to find any sources that indicates how the cannon is wind corrected.

In the real helicopter and with FFB joysticks, you want to tap the trimmer because holding it down will remove the centering force on the stick, making it flop around. With a spring-based joystick and the Default and Central Position Trimmer Mode in the Ka-50's special options, due to the way they work you want to hold down the trimmer while maneuvering, then release when you're done. If you want to see what the difference is, change the trimmer mode in the special options to Joystick Without Springs and FFB, then maneuver around while rapidly tapping the trimmer. You should be able to control the helicopter no problem. Then try it again with the Default and Central Position modes. You will quickly lose control.

I can't follow the entire conversation because it's getting a little too deep into charts and the miniature of physics, but here's how I understand it. When a force is applied on a spinning object, the reaction to the applied force is 90 degrees later in the rotation from when the force is applied. Smarter Every Day made a video about this, and the effect is called phase lag: In the video at 4:36, he applies an upwards force (a tilt), which manifests 90 degrees later on the bicycle wheel. As the rotor spins around, when the blade is moving into the wind, the airspeed over the blade is increased, increasing lift, and when the blade is moving away from the wind, the airspeed is decreased, decreasing lift. If the blade maintained the same angle of attack throughout the entire rotation, this would cause one side of the aircraft to experience more lift than the other side, which will roll the helicopter. This is called dissymmetry of lift. To counteract this, two things happen. First, the blade pitch angle is constantly adjusted throughout the rotation. It's decreased on the advancing side (to reduce lift) and increased on the retreating side (to increase lift) to balance it out on both sides. You can see this effect in this slow motion video: Second, the blades are attached via a hinge to the mast (the hinge where the blue and orange pieces are connected): This allows the blade to move up and down, called flapping, to reduce the angle of attack when the blade is rotating into the wind (the upflap velocity is subtracted), and increase the angle of attack when it's moving away from the wind (the downflap velocity is added): This effect happens naturally. Imagine that you're driving down the freeway and you stick your hand out of the window, fingers facing forward, and you tilt your palm up. The wind will blow against your palm and move your hand upwards. Then if you reverse your hand so that your fingers are pointing backwards, but still tilt your palm up, the wind will blow against the back of your hand and push it downwards. You can see the flapping effect in this slow motion video of a Huey taking off: Both of these things will balance the lift on both sides of the aircraft, preventing it from rolling due to a difference in lift: Note that when the helicopter's on the ground, the lift is the same on both sides because there's no forward movement and therefore no advancing or retreating side of the disk, so the angle of attack doesn't need to change (figure a): Understanding this, we can also understand what the cyclic does. When there's a difference in the amount of lift on one side of the helicopter versus the other, the helicopter will tilt towards the direction with less lift. The cyclic controls the symmetry of lift by adjusting the blade pitch angle to produce unequal lift, which tilts the helicopter in the desired direction. This tilt is needed to move the helicopter; the rotor blades generate a lift force directly upwards, so in order to move, the lift vector also needs to tilt forward so that there's a forward velocity component (thrust) that moves the helicopter forward: So to try and answer what I think your questions are: 1. On the ground, the lift on both sides of the rotor is the same and the angle of attack doesn't change, so there's no flapping and the blades will have the same tilt on both sides. This is why when you push the cyclic forward on the ground, the blades appear to tilt forward as well. The blade itself is not flapping, it's the entire aircraft that's tilting forward, similar to swinging a ball on string in a circle, then tilting your entire arm forward. 2. When flying forward, the lift on both sides of the rotor is asymmetrical. The blade pitch angle changes and the blade flaps to balance out the lift, causing the rotors to squeeze together (because they're spinning in opposite directions, one flaps up while the other flaps down). They squeeze together on the right side because that's where the wind is pushing the strongest against the blades. 3. The top rotor flaps less than the bottom rotor because it's pulling in clean air from above, whereas the bottom rotor is pulling in the downwash from the top rotor. This causes the bottom rotor to generate less lift than the top rotor, which means it also generates less torque. To counteract this, the bottom rotor's blade pitch angle is set higher than the top one to generate more lift, which also causes it to flap more (i.e. the hand out of the car is tilted up more, causing the wind to push harder against the palm). This equalizes the torque between the top and bottom blades. 4. While the two rotors cancel out each other's torque, negating the need for a tail rotor, it's not 100% equal. This is why you still need to apply slightly left cyclic for level flight, because the left side is producing slightly more lift than the right.

The last time we looked into it, it looks like the cannon is hard-coded to correct for the wind at 1600 feet, but not for your current altitude. Relevant thread here:

Yes, the "no more than one effect" at a time is a bug in vJoy. I reported it to the author but they weren't interested in fixing it, mostly because they hadn't touched that code in a long time. Practically speaking though, no game I've tried uses more than two effects at once: a centering force and a periodic effect. The data for the various effects are unique enough that you can differentiate between most of them simply by checking for the existence of certain properties in the FFB data that vJoy sends, so while the effect bank will always be 1, you can tell them apart through their properties and layer the effects by hand. While I was still working on the app, I put together these two videos showing what that looks like, notice how the data for the centering and periodic effects are very different: QwuLX8X1UMU T12sFU0W5KM I see that you posted in the HOTAS Discord, I posted some info about my issue with the Brunner base here: https://discord.com/channels/4386883...03903190859780 I was using it with a Warthog stick without extension. The over-temp/over-current protection acts like a stamina bar; the more you use the FFB and the stronger the force, the quicker it depletes, and it takes some time for it to recover. It made the base unusable for me because the "stamina" would run out and the protection would kick in at the most inopportune times, making me lose control of the aircraft due to the sudden change in force. I don't know if it still happens because the company seems to arbitrarily release new firmware depending on individual customer's needs.

The link is broken, but you're probably better off doing it in software using vJoy, rather than requiring a separate micro-controller. I started some preliminary work on it here: https://github.com/danieltian/cls-ffb but I returned my Brunner base due to some issues I had with the over-temp/over-current prevention logic, so I'm no longer working on it.

Sigh...I wrote an entire breakdown of every erroneous point, yet you only quoted one phrase that doesn't even support your claim. Once again, entire quote was: In other words, those products are infringing on NaturalPoint's patents specifically because they're using TrackIR's hooks and code. Nowhere does it mention that it's against the contract to support other hooks. Just like how I can't show you that just because one person wrote sentences on a website, does not make it true. I'm not here to change your mind; either you believe the only website in existence that makes such claims with broken links, or you look at the source info and draw your own conclusions. Not a lot of people will do the latter because it's much easier to take one person's claims at face value and get all outraged over it, than it is to do your own research. Either way, the existence of the Tobii Eye Tracker in and of itself proves your anti-competitive claim to be false. Not gonna waste my time with you any longer.

That page is the only one on the internet that makes that claim, but like all of its other bullet points, the logic it uses under the Exclusive Dealing heading is extremely bad: What the agreement says is "don't emulate our hardware", or in other words, "don't write code that makes a standard webcam appear as a TrackIR camera to the SDK". This is no different than the license agreement that other companies use, for example Sony's Playstation Developer agreement that says "don't create a Playstation emulator". It's not clear what "potential restrictions" and who "everyone else" is, and because the source link is dead, it's impossible to verify. The author basically provided his own reason why this doesn't support his claim. ED had a distribution deal with NaturalPoint, which means that developing a head tracker plugin for non-TrackIR cameras was against the deal, similar to how if you sign an exclusive deal with Sony to release a game only on the PlayStation, you can't also release it on the Xbox. These kinds of deals means that one company is spending their time and resources to help sell a product, and when people buy that product, they also buy the company's product. In other words, NaturalPoint signed an exclusive deal with ED so that when people buy the game, they also buy a TrackIR camera. If ED released a head tracker plugin that supported non-TrackIR cameras while still under this exclusive deal, then NaturalPoint would be spending their time and resources, but not benefiting from the deal. Like all of the other links, the link to the SDK agreement is dead, and "creating software with similar functionality" is vague without any context. If I had to guess, I think "software" in this case means the official TrackIR software, so it's saying "don't create a clone of our official TrackIR software". However, this is impossible to verify. The 2011 petition is also a dead link, but it's for one of those useless online petitions where someone writes something out, then people click a button to sign it. In other words, it's just a poll. ED eventually released their head tracker plugin, likely not because of the petition, but because their exclusivity deal with NaturalPoint expired. The author links to his own page that gives more detail, but if you read through it, it very clearly states that the issue is that 3rd party devices are using TrackIR's SDK. He cherry-picked and joined together two statements from two separate quotes. The full quotes are "Any product that access the game for head tracking other than TrackIR is infringing upon NaturalPoint's patents as they use the hooks and code specifically designed for TrackIR that allow for control of the camera view.", and "This product [VRInsight HAT-Track] is a Korean rip off of TrackIR and it infringes on NaturalPoint's U.S. patents. We will never support such a device. Any product that uses the same TrackIR technology, both it's hardware and software patents without a license from NaturalPoint will not be purposely supported by us." The issue is not that other head tracking devices exist, it's that they're using the TrackIR SDK. This doesn't explain why PiBoSo refused to sign the agreement, and the original link is dead. Another dead link with a vague statement. Also note that the problem here is specifically with FreeTrack, because at one point they allowed standard webcams to be used with the TrackIR SDK. NaturalPoint obviously doesn't want to give out access to their SDK if it's just going to be used with standard webcams. This is just a statement of fact that doesn't prove or disprove anything. "Prefer" is not the same thing as "never", and giving out TrackIR cameras for testing and prizes is not the same thing as "purchasing support in games". The author says that the special support features claim isn't true because...hacks exist to access those special features? :confused:

No, that's incorrect. That site has been used time and again as "proof" against NaturalPoint, but just because a website says something, that doesn't make it true. I don't want to get into it because nearly every point is incorrect, uses really bad logic, is unverifiable (there's tons of broken links), or simply puts out a vague and somewhat unrelated statement and says "draw your own conclusion, as long as that conclusion is the same as mine". I'd have to create my own website just to debunk it because of how much misinformation there is. In reality, NaturalPoint asked FreeTrack to remove TrackIR support, then subsequently password-protected their SDK because people were using FreeTrack with webcams to get TrackIR support, without buying a TrackIR camera. Anyone is free to create their own head tracking camera and SDK and work with game developers to integrate it into their game, they just can't do it with the TrackIR SDK and a non-TrackIR camera. This is no different than how if you want to use a Tesla Supercharger station, you need a Tesla car, or if you want to access the App Store, you need an iPhone. This isn't anti-competitive; Tesla's not saying "don't make electric cars" and Apple's not saying "don't make smartphones", just like how NaturalPoint isn't saying "don't make head tracking devices". What they're saying is "if you want to use this thing we made, you can only use it with the other thing we made". Case in point, the Tobii Eye Tracker is another head tracking device that has its own SDK and is supported in games that have TrackIR support as well, and NaturalPoint has no issues with that because it doesn't use anything that they created.

I was curious how the trim switch feels when mounted and I have a spare broken Warthog grip lying around, so I Dremel'ed out the trim switch hole to fit it. For comparison, the stock hole is about the same size as the other holes, so quite a bit of material has to be removed: The metal tabs on the inside of the body also have to be removed: The switch though fits great and looks like it was made for the grip: However, while it does feel better mounted (the spring force doesn't feel as strong as I initially reported), it's still a lot heavier than I'd like it to be, and it's just not for me. I also recorded this video with some other Otto switches: cROL7elmzyo If I had my choice, I'd want all the hats to use Otto T4-T switches. While it's not authentic to the actual stick, the tactile click feels very, very good and satisfying to actuate.

I picked up various Otto push button switches and someone may find this comparison useful: Both the Otto P1 and P8 switches come in 2.5lb and 4lb activation force variants. The Otto P1-1 switch is the one most people recommend, but it has a rather long body that won't fit into some of the holes on the Warthog stick without modifications. The Otto P8-1 has a shorter body and has two different actuator heights, 0.250" (style A) and 0.187" (style C). The 0.250" is just a tiny bit shorter than the P1-1 actuator, whereas the 0.187" version is slightly taller than the stock Thrustmaster button (the actuator is the same height, but the body on the P8 is taller). Although the P8 button has a version with a black body, only the silver body version is normally stocked. Feeling-wise, both are very close. The P1 has ever so slightly more travel than the P8, but if I blind-folded you and asked you to tell the difference between the two, I doubt you'd be able to differentiate them. For both of the push buttons on the F/A-18 stick (pickle and pinky button), the Otto P1 will fit with no problems. For the Warthog stick, only the pinky button can fit the P1 switch. The paddle switch requires the P8 style C because the paddle will be pushed too far outwards otherwise and won't line up with the hole for the rod that holds it in place. The pickle and index finger buttons will fit the P1 switch, but will be tilted slightly because the solder lugs rest on top of a hard stop inside the stick. Although the stock TM switch has the same body length as the P1, it only has wire leads instead of solder lugs, and the Warthog internals weren't designed for the solder lugs. You'd have to cut grooves in the Warthog body to make room for the solder lugs, or you have to cut the solder lugs to fit. The P8 switch will fit in all holes with no modifications needed.

I picked up 3 of the trim hats from the eBay auction: https://www.ebay.com/itm/381677953240 I haven't installed them yet, but I don't think I will. Each one feels a little bit different from one another; 2 tend to bind when pushing them to the right, and 1 is mostly good (it still binds, but only very slightly compared to the other 2). The main issue though is that the spring force is very heavy, which is fine when you're using gloves and flying in the actual aircraft and need a heavy spring to prevent the switch from getting activated accidentally, but not so much for home use when I'm using it with my bare hands and using it for other functions where I need to press it often. On the plus side, the Otto P1 switch fits in both the pickle button and pinky button slots, so I'll be doing that mod.

I wrote a Node/JS library to decode the data here: https://github.com/danieltian/dcs-bios-api/blob/master/lib/dcs-bios-export-parser.js I wrote comments that hopefully should help with figuring out how the decoding works, but to give an overview, you need to look at the .json files in the %APPDATA%\DCS-BIOS\Plugins folder. They will contain information on the address of a control, which I'll refer to as a control definition. When you receive incoming data, the first 2 bytes is the control's address, the next 2 bytes is the number of bytes to update starting from that address, and the remaining is the new data that you need to set. All integers are little endian. For example, let's assume the aircraft name is at address 5412. You'll receive the following message: 12 54 05 00 65 45 49 48 67 Broken up it will be: [12 54] [05 00] [65 45 65 45 49 48 67] Converted to decimal, that becomes: [5412] [5] [65 45 65 45 49 48 67] Or in other words, for the address 5412, update 5 bytes, and [65 45 65 45 49 48 67] is the data to update with. Since the aircraft name is a string, we can assume it's ASCII text, which translates to "A-10C". If you're interested in strings, it's a bit involved. You need to create an array with a length of 65536 to hold all the incoming data because updates can be partial updates. For example, if the aircraft name changes, you might not get the entire string at once; the first update can be for address 5412, 2 bytes, with the characters "A-", and the second update for address 5414, 3 bytes, with the characters "10C". Because 5414 might not match up with any of the addresses in the control definition .json files, you will also need to keep track of all the control addresses: https://github.com/danieltian/dcs-bios-api/blob/master/lib/dcs-bios-json-parser.js#L49 Then if the message has an address that doesn't match up with a control address, it's a partial update and you need to count down from the update address until you find the control: https://github.com/danieltian/dcs-bios-api/blob/master/lib/dcs-bios-export-parser.js#L172-L174 In picture form: Address: [5411] [5412] [5413] [5414] [5415] [5416] [5417] ... ^ ^ Aircraft name Some other control Address 5414 is in between two controls, so we have to count down to find the control at 5412 to know which control 5414 is a partial update for. If you're interested in integers, it seems like the updates will always be full updates and you probably don't need to create an array to hold the incoming data. To parse an analog value like a knob position, you can just read the two bytes as an Int16 and use that value (analog numbers in DCS BIOS will always be 0 to 65535). To parse a boolean value like a light on/off, you'll have to look at the control definition and use the mask and shift_by properties to get the value. This is because a byte can represent up to 8 on/off lights where each bit is the state of an individual light. For example: 01101011 ^ you only want this light The mask will be 32 and the shift_by will be 5. To get the value of the light, you simply logical AND the byte, then shift right by the shift_by value: 01101011 // our byte AND 00100000 // mask value of 32 -------- 00100000 00100000 shifted right 5 times becomes 001 = 1 = on Another thing to look out for is if the address and count are both 0x5555. This is a "sync command" that lets you know that all the updates for this particular frame are done and it's safe to process the data. Using the earlier example, we might get one update that gives us "A-" and a second update that gives us "10C", but if we processed the aircraft name after the first frame, we'll have the wrong string. So we wait until the we get the sync command, then we know it's safe to read the aircraft string at that point. One last thing to be aware of is that some aircraft have overlapping addresses. For example, the F-14 addresses overlap with the A-10C addresses, so if you're trying to write something generic that applies across multiple aircraft, you might also need to check the currently-active aircraft in MetadataStart json to ensure that you're not processing the wrong aircraft's controls. Here's an example of how to do that: https://github.com/danieltian/dcs-bios-stream-deck-plugin/blob/master/src/server/dcs-bios-api/index.js#L111-L116

Sort of, but not really. There are two components, the lua script and the Arduino library. The lua script opens a multicast UDP server on 239.255.50.10, with port 5010 for receiving data from the server and port 7778 for sending it data. The message that it sends is in a binary format and is documented. Unfortunately, like all binary formats, you need to know what each bit/byte stands for, and you'll either decode the message or get back gibberish, but not much in between. DCS BIOS uses this binary format in order to keep the data size down so that it's faster to send to the Arduino via serial, so that's the "sort of" part, but the "not really" part is that it's just binary data, so if you can create a UDP client and parse the binary data, the consumer of the data can be anything, not just an Arduino. I've written a library to parse the binary data and expose it as JSON: https://github.com/danieltian/dcs-bios-api/ But it's a Node library and it looks like your project is in C++. The COM port is only needed to communicate with an Arduino. For other apps, you can use a UDP client. The UDP client is set up in the lua script, so you don't need to do anything in the DCS BIOS UI (aside from downloading the correct plugins for the aircraft) to get it working. At one point, DCS BIOS development stopped and all work was done in the DCSFlightpanels branch. That's no longer the case, and the installer at https://github.com/dcs-bios/dcs-bios/releases should be used going forward.