Pindrought

I've been a bit busy also haven't been able to work too much on it. I was considering having it set up like the following... Have Master control server running on PC with DCS World. Have raspberry pi + other controls in the future connect to master control server. Have DCS World connect to master control server via Export.lua and have it send updates accordingly to the master server. Have master server dispatch the updates to the controls that the given update is related to. Was just going to use tcp sockets for the communication between the three.

That sounds great. I have a photoshop template, so i'm thinking that once this is all set up people should be able to design how they want theirs to look without too much trouble. Been making some good progress. Here is where we're at now. The camera does a really bad job at picking up this LCD screen for some reason. There is some screen tearing, but I will work on figuring out a fix for that later. Here is a video showing what it will look like at certain pitch/bank angles. I wasn't able to embed the video on here for some reason. Still need to add in the horizontal pitch ticks for 25-90 degrees. Next going to start working on the programs for communicating between DCS World->Computer->Raspberry PI.

Thanks for the info. I wasn't sure because there are no tick marks on the examples i've seen past 90 degrees like on the wikipedia article so it made me unsure of if the indicator would even rotate past 90 degrees. https://en.wikipedia.org/wiki/Attitude_indicator Glad to get that cleared up. So the only thing i'm wondering about now is exporting the attitude indicator data - is the best method going to be just calculating it based off the radian values returned from the LoGetADIPitchBankYaw() function?

I'm working on a little project where I simulate the Attitude Indicator display with a raspberry pi. One thing i've noticed is the attitude indicators in DCS don't seem to work like the ones i've seen videos/articles on. I wanted to get something clarified on the functionality of them as well as exporting data from Export.Lua. Exporting Is the only way to export data to determine the attitude by using the function that exports out the pitch, bank yaw and determining degrees from the radians returned? Functionality Should the attitude indicator be able to rotate more than 90 degrees for bank? If you're upside down should the whole view essentially be flipped? For example, Example 1: Pitch 0 degrees, bank upside down (180 degrees) Example 2: Pitch -10 degrees, bank -140 degrees Does this look right?

Just an update. Built a mockup texture for the attitude indicator. (I suck at art, but trying.) Restructured the opengl program and got it set up where I can load in textures, loaded in the mockup texture. Still need to add the horizontal lines for pitch and remove the bottom lines for banking that were left over. One issue i've noticed with the 5" screen i'm using is it kind of needs to be viewed at a specific angle. At harsh angles, the screen is not usable as seen in the next pic.

Thanks for sharing! Very good stuff. Look forward to future results.

Just an update on the raspberry pi. There is good news and bad news. The good news is the raspberry pi supports opengl. The bad news is the latest version that the raspberry pi 3 model that i'm using supports is opengl 2.1 which is very old school opengl. Regardless, i'm currently learning how opengl 2.1 works so I can play around with this. Had some issues getting opengl projects to compile, but got it figured out and currently i've got a rotating blue rectangle on a 5" lcd connected to the pi. Not much so far, but some progress is still progress.

Just an update - I ended up going with https://www.amazon.com/gp/product/B01EUVJYME/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1 and did some basic testing with the Arduino UNO. It takes 217ms to just refresh a solid color on the screen with nothing else. I don't think it would be advisable to use a TFTLCD screen + arduino for attitude due to the low update speed. It just doesn't seem appropriate. I am getting in a raspberry pi + lcd for that later this week and was going to test with that when it comes in.

I ordered one of these online and was going to mess with it when it comes in. I'll let you know what I find! By the way, could you let me know which aircraft attitude indicators you were going to look at specifically so I could mess around with them when it comes in?

Are you able to provide a link of the LCD screen you're talking about? Most of the LCD displays i've seen meant for arduinos are very simplistic. I would think that a raspberry pi would be a better fit for this situation, but I could be wrong. I believe raspberry pis can render opengl now so technically if it made a socket connection to the server running on your pc, i'd think that you can just send the altitude data and a program can render the graphics to a lcd connected to the raspberry pi via opengl.

I was doing the 2nd training mission for navigation, and i'm stuck. I can't figure out why I can't get an accurate reading past 300. The mission made it seem like I would just hit the switch by altitude hold and change it to BR from RD, but I get the same altitude reading with both of these. Here is a video of what I am getting. Thanks so much for any input

Thank you so much Ian this is exactly the type of thing I was looking for. Will look into this.

I know programs like HeliOS have the ability to somehow get data from the game like when switches are toggled, system failures, etc. Does anyone have any good links to resources for how exactly people are accomplishing this? I was going to try and develop some ipad apps to connect to the pc and display some cockpit visuals with buttons which would transmit the data back to the pc, but the issue i'm having is I can't even figure out how to properly get cockpit data on the pc. I was going to do ReadProcessMemory calls but I feel like this will be inefficient calling it every 100ms and also I would have to update every offset for when the game gets updated which would be too time consuming and unrealistic per update. I saw some people were saying you can read the data using udp transmission, but I couldn't find any clear examples of something as simple as reading if the engine was turned on in a SU-25T. I really wanted to try to make this on the ipad or some form of tablet instead of just using HeliOS because I feel like it would be a lot more efficient (not require a NASA cpu/gpu) and not require the multiple monitors that helios requires. If anyone has any links to any helpful resources i'd really appreciate it. Just really looking for the most basic possible way to read a single cockpit control value.