Q: I see, so this basically handles everything over to the user for a complete standalone solution. No BAD needed anymore. So the Arduino connected directly to MSFS? No in between software required?
Answer:
It replaces BAD (Bits and Droids). The app becomes the intermediary between MSFS 2020 and your arduino.
I designed this for fast SimVar data retrieval.
It should be faster than BAD because of the design of the simvar data retrieval system and the design of the serial port code. You only need to send one uint8_t for any simevent or simrequest so that is two bytes outgoing to the PC, unless you are sending a parameter as well. There are 4 bytes in reply returning to the arduino. I meant this to be an arduino driven data subscription system. Currently, the app monitors for SimVar requests coming from the serial port and it if sees something new, it resubscribes all the SimVars again in a new definition package. The counterpart of this system, which would unsubscribe SimVars , has not been written yet.
Winforms app were designed for UI responsiveness, so it prefers to offload tasks that might stall the main UI to background tasks. Therefore, the serialport code is executed in a different thread. And the serialport code also offloads the execution of SimEvents and SimVoice to different threads. This frees the Serialport code to only handle outgoing SimVar data replies.
The request <> response mechanic for SimVar data retrieval is one to one, so the serial port stream is not cluttered by unecessary repeats of the same data. However, I found out that if you interact with the arduino via buttons and such ( which means usually a SimEvent is firing) , the requeset<> response mechanic goes out of alignment , so I added the id byte and tail byte for data integrity. As a final optimization if it is really necessary, I could remove the tail byte and end up with only three data byte replies. Also, to further speed things SimEvent and SimVoice could be put in a separate Comm Port as a future avenue for optimization.
It is designed to give as much control to the user with regards to which SimVar or SimEvent they want to use.
If you can find the SimVar and it returns a DWORD ( even a Boolean returns a Dword, and actually I think most all of them return DWORD except the ones that return structs), then it should work. I realized that not all SimVars are enumerated in :
https://www.prepar3d.com/SDKv2/LearningCenter/utilities/variables/simulation_variables.html
And likely not all SimEvents are enumerated in :
https://www.prepar3d.com/SDKv3/LearningCenter/utilities/variables/event_ids.html#Aircraft%20Lights%20IDs
For example, AP_VS_HOLD, which was needed to create the Cessna Autopilot Panel in my box was not in the list. Also just FYI for anybody else recreating the Cessna Autopilot panel, AP_VS_VAR_INC and AP_VS_VAR_DEC do work but you don’t see the changes in the Autopilot Panel Display in the game but firing the simevent for them does change the ingame value. So you need to display AP_VS_VAR in your LED panel if you want to see it. You have to request the data from Simconnect by:
simrequest(AUTOPILOT_VERTICAL_HOLD_VAR)
Cheers,
Chris