I am releasing a Sim Connector Application

It’s for interfacing Arduino Boxes with FS 2020 via SimConnect SDK. You can retrieve SimVars, Fire SimEvents, and have voice annunciation with SimVoice which might be of interest to VR users.

The software could be as feature complete as you wish because you create your own configuration files and decide for yourself which SimVars and SimEvents to use.

It’s Beta software so there is a console output window attached.

Let me know how it works for you.

The instructions on how to run are on the Blog section.
The Features are on the About Page.

Cheers,
Chris

7 Likes

In reply to :

"So, you basically have rewritten the BAD library and connector? "

I did not rewrite the BAD library and connector. However, the BAD library could be easily emulated because the connector functions are just wrappers to a generic method. For example:

float connectorTX.sendAPHeadingHold(){
               return simevent(AP_PANEL_HEADING_ON); 
}
 float connectorTX.sendHeadingBugDec(){
              return simevent(HEADING_BUG_DEC);
}
 float connectorRX.getFeetAboveGround(){
               return simrequest(PLANE_ALT_ABOVE_GROUND);
}
float connectorRX.getApHeadingLock(){
                return simrequest(AUTOPILOT_HEADING_LOCK_DIR)
}

It becomes a simple matter to write a connector class and simply populate it with the above methods. Here is a quick pseudo code. Haven’t tested it yet.

    class BitsAndDroidsFlightConnector {
    public:
          HardwareSerial* serial;
     
      #ifndef ARDUINO_SAM_DUE
      BitsAndDroidsFlightConnector(
              bool isLeonardoMicro, HardwareSerial* serial) {
              this->serial = serial;
              if (isLeonardoMicro) {
              serial->begin(115200);
              serial->setTimeout(50);
      }
      }


       float sendAPHeadingHold(){
               return simevent(AP_PANEL_HEADING_ON); 
       }
       float sendHeadingBugDec(){
               return simevent(HEADING_BUG_DEC);
      }
       float getFeetAboveGround(){
               return simrequest(PLANE_ALT_ABOVE_GROUND);
     }
       float getApHeadingLock(){
                return simrequest(AUTOPILOT_HEADING_LOCK_DIR)
     }

  };

This transfers control to you because you can decide which functions you want. You wouldn’t have to wait for BAD to release updates with more connector functionalities. All the Simvars that return a DWORD are immediately available to you. Just write them in the configuration file. All SimEvents are immediatel available to you, even the ones that require a parameter as long as the parameter is just a number. I believe it can take structs as well but the function for that takes a void pointer and a size of data type. However I haven’t fully tested that though I have code that supports that.

I am crossposting this reply as others might be interested.
Chris

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

Released Bugfix 0.62 - Prevents generation of serialport backlog on the PC side to keep Simevent processing responsive. Adjusted timing on the arduino functions.
Chris

Released version 0.70

Overhauled string validation for all Events and SimVars. There is support for 100 SimVars which could be settable or not and 100 Events which could be settable or not and 50 SimVoice phrases. The settable SimVars and Events can be seen in the GUI Tab Settable for both the Variable Section and the Events Section. You can enter a parameter in the GUI and click the button to see the effect in the game. There is a Readme page on the Site Navigation panel because there is no preformatted text option in the blog. Read that for updated instructions on how to set this up. Hope I didn’t break anything.

Cheers,
Chris

1 Like

Released 0.71 with preliminary SimSound support:

Release 0.70 had a nonworking Load SimSound button which would have thrown an exception if clicked.
This release adds SimSound to the GUI Tabs. Just Click Load SimSounds and select your mp3 audio folder. The files should get listed under the SimSound Tab in the Events Section. You can click the Play button to listen to the music. There are no arduino side functions yet. But at least you can listen to some music when you are playing the game. My intention is to be able to call simsound(uint8_t x) function from the arduino and that plays a sound in Windows corresponding to the ID number. There will eventually be separate functions for volume control and up/down selection (if you want to use this as a mp3 player or radio) or to use this to select custom cabin audio such as boarding, safety announcements, welcome aboard, or simply to play click and encoder rotation sounds as audio feedback when you press buttons or turn the rotary encoders.
Enjoy!
Chris

Update: Also posted an article about Propwash encoders and how to solve the issue of 2 detents being required before registering a direction.

Posted another article about Port manipulation and how the TM1637_6D library could be recoded to apply port manipulation techniques using DirectIO library.

The speedup: The original code took 2968 microseconds to finish writing the word “hello” to the display. The converted code took 640 microseconds.

Enjoy,
Chris

Released version 0.81

Even if you are not a Flight Sim enthusiast, it would be interesting to use your arduino box as an internet radio. Of course, you can have this functionality along with SimVars and SimEvents as well but it could work as standalone.

All you need is one encoder and you have a fully functioning radio:

You have to use the ArduinoBox.ino file and setup the Encoder and Button line to your own GPIO pins. Then Load SimVoice and SimRadio using the default config in the User directory.

Turn the encoder to activate the Radio and change stations. Press the encoder switch to change to “Volume” mode and use the encoder to increase or decrease volume. Press the encoder switch to go to “Tuner” mode again and change channels. If you press and hold the encoder switch, you will engage “Scan” mode and SimRadio will scan through the channels available. Once you hear the channel you want, press the Encoder switch again (don’t hold) and this returns you to “Tuner” mode from which you can toggle back and forth with “Volume” mode.

To turn off the radio, turn the volume all the way down. To turn it on again, turn the volume up.

IMPORTANT: DON’T JUST RUN THE SKETCH. You need to change the encoder pins to your own set of GPIO pins first.

Have fun,
Chris