Primary Buffer Panel v2

The Primary Flight Display PFD is loosely based on a modern aircraft instrument and is added to the MDF automatically near planetary surfaces e.g. when descending on a planet in Elite Dangerous or when hooning around in Fly Dangerous.

Not a pilot

Far from it. In fact I don’t even enjoy “real” flying. Aviation does have a certain effect on me though and I’m even sometimes found at an airfield.

And while I can crash a virtual Cessna anywhere nowadays, and even got some other virtual planes in the air, I’m not qualified for any real flying.

Please keep this in mind for everything on this page especially when I describe any flight systems of mine.

This reduces the screen space for other system messages somewhat but is totally worth it. It comes also with the proper visuals for selected airspeed, heading and altitude. The vertical speed is still missing but on my list. I went totally overboard with showing a Mach indication over 0.5 Mach as well 🤓 (Yes, yes you Mr. Smartguy over there. I know this is not 100% correct, doesn’t work for other planets and we don’t even have pressure values from a Pitot Tube. Go get yourself a juicebox. This is for a game!)

On precision

Flight instruments usually display data in realtime. This is not possible with some games like Elite Dangerous that drop data only after a certain threshold was reached. Other games, like Fly Dangerous have a real hose of a data stream going and allow thus for way more precise data. In the end it’s just a game though so who cares how exact this gimmick is when we race around with speed that would leave us splattered all over the next bulkhead in reality.

I’m still tweaking this while gaining more experience. It works pretty decent already though, which can be observed in this demo playing Fly Dangerous.

There is also an unlisted demo video in 4K available on YouTube. It’s from an earlier development phase though and a lot more clunky so keep that in mind: https://www.youtube.com/watch?v=MC-XpirO920

I’ve yet to record a better demonstration of this.

Originally posted at https://simpit.dev/systems/pfd/

While seeking through the available data in the Status JSON of Elite Dangerous I noticed that I don’t get any airspeed from Elite. That’s not so important in space but kinda interesting in planetary flight to satisfy the flight sim gamer in me as well. I noticed though that I do get timestamped latitude, longitude and altitude values so shouldn’t it be possible to “simply” calculate this, right? Right?

An Auto Flight System for Elite?

This was when I dived into the rabbit hole of calculating airspeed and heading on planetary objects using a spherical coordinate system and while I didn’t nail it exactly how Elite does it the result is close enough. The game provides the required data to go crazy here – most important the radius of the current object. In theory I could start writing some primitive AFS (Auto Flight System) routines now, which I’m totally going to explore at some point in the future just because 🤓

Checking my maths – yes, altitude is added to the mix so airspeed is mostly correct as long as no rapid course changes are made.

Conclusion

After spending way too much time with this and the Pythagorean theorem (Yes mum, a game made me do maths. MATHS! 🤯) I settled with some calculations and data for my current ship to the right and targeted ship data on the left. This is sort of tricky because many game events update different parts of the data so timestamps have to be kept in mind and a game specific parsing strategy is required. See the last part of the demonstration video here to get an idea how this looks.

Originally posted at https://simpit.dev/systems/afs/

The MFD (Multi-function display) is salvaged from an old laptop. It is not running GameGlass, like so many others SimPits out there do. Mostly because I’m not a fan of touchscreens or vendor lock-in. There is also the little detail that GameGlass is simply not available for my operating system and does not know about all the Space Pew Pew I usually do.

When I was evaluating what to use to program mine I was caught between the difficult choice to learn yet another fancy framework, like Raylib, that would do OpenGL ES 2.0 without X11 on the Raspberry Pi, or OpenFrameworks, or simply go with something I knew already.

In the end I just threw the might of my CoffeeLake at it and went with React since most of the data was already available via Node-RED over Websockets anyway. Also… Arwes is just so cool (alpha version or not) 🤩 and I had some experience with it thanks to my Streaming Overlay that I also wrote with Arwes. Connecting it to Node-RED was just a matter of installing Socket.IO to transport the messages. I rewrote the whole thing for version 2 though because the code for version 1 was a very hacky mess and the older Arwes version was deprecated. The core functionality is still the same though.

Originally posted at https://simpit.dev/version-2/mfd-software/

The last step in the construction was wiring everything up. That’s roughly ~250 connectors crimped and I usually remove the isolation with my thumbnail, which is a bad habit 🤪 I purchased crimping pliers just for this and I can totally recommend using such pliers. Used some leftovers from the frame construction to create two rails where everything else was screwed on. The black parts are 3.5" to 2.5" harddisk adapters I had laying around.

Next was connecting the LCD and see if everything survived the transplantation from version 1. The LCD is very bright on the backside, as you can see. The current version is still missing it’s planned glare shield that will also protect my other displays from the glare of the backside. That’s still to be done though.

After that came some rewriting of the custom joystick source code for the Arduino Mega. Many new buttons wanted to be read. I also removed the original buttons for the LCD controller and connected my own instead. Somewhere during connecting everything I noticed that I made an calculation error and a few buttons could not be connected because I was running out of free pins. So I’ll have to rewire some of the buttons into a button matrix (or use an IO expander - not yet sure what’s best for this).

The blinken lights were next. After that it was time to fix the wobbling. My “temporary” stand was no longer temporary and it was time to add some stabilizing bars. Convincingly this added exactly the space I was missing to fix the LCD controller board to the SimPit. Didn’t really plan this but with this I had all my connectors on the right side (my PC is also on my right).

Not too shabby considering I was winging it at this point.

Originally posted at https://simpit.dev/version-2/wiring/

Every cockpit needs blinken lights. My status indicators were realized with a Neopixel. That’s a string of RGB LED wich indidivually addressable LED. This way only a single PIN is needed to configure all lights. It has to be a pin that can do pulse-width modulation (PWM) though so choices are limited.

There are various protocols for this. Mine consists of WS2811 modules where plenty of examples exist on the internet.

A dedicated connection is used for power and in theory all LED can be driven from that but in reality we have to keep ampere in mind so things don’t go up in flames. The string is also dead should one module break for good. Not really suited for a real *craft but hey, this is a toy and each string comes with plenty of leftoversreplacement parts 🙃

I went for this specific Neopixel because it came with the “classic” LED design. The diffusor is 12mm in diameter and the LED did fit almost perfect in their former hexagonal housings. For version 2 I got some fancy fittings that look absolutely stunning but were designed for old lamps with filaments. So fix this I had to saw the endings off.

After that I had an almost perfect fit for the LEDs. Almost, because the fitting is exactly 12mm in diameter on the inside as well but each LED has 3 tiny hooks to hold a LED in place when stuffed through a 12mm hole. A cutting knife made short work of that though.

I also prepared a small triangular panel for the landing gear. It has no housing yet and is supposed to go into the lower part of the frame but that part doesn’t exist yet.

The LEDs are controlled by Node-RED that does all the plumbing in the end. A custom Rust daemon talks via Serial to the Arduino Mega and listens via Websocket for changes from Node-RED and translates the buttons pushed to a virtual joystick device. The Arduino Mega reads changes for the status indicators and adjusts the LEDs as needed.

Originally posted at https://simpit.dev/version-2/blinken-lights/

This Arduino Mega proved itself in version 1 already. I got it thinking I’d never run out of free pins on that. I was wrong. It’s also not a HID but a Serial device. I know that it’s bootloader can be replaced with the HoodLoader2 but I really don’t mind [any more]. There are probably cheaper clones as well but… would you just look at this beauty!

The communication is managed by a Rust daemon. I got the idea and the initial source code for this from github.com/gwilymk/arduino-joystick by Gwilym Kuiper who describes the idea in great detail in his article about Virtual Joystick on Linux. I wrote about this in more detail on my blog as well.

Windows user may either use the mentioned HoodLoader2 or adapt and work with e.g. vJoySerialFeeder but that’s really out of the scope of this article.

My extended source allowing for more buttons and rotary encoders is available at github.com/bekopharm/arduino-joystick. The snapshot there may be not up-to-date though. I’m tweaking this a lot and didn’t push any change for a while.

Originally posted at  https://simpit.dev/version-2/buttons-controller/

It was time to raid our local hardware store where I got a bunch of pine wood for model building purposes. 13x13x1000mm, 19x29x1000mm to be precise - simply because it looked right to me and was available. I built the whole frame with those two sizes. My STL was not exact enough so I had to make stuff up on the go. It was a pretty straight forward process though.

The outer frame is glued but mostly held together by staples. I know what you’re thinking. Heck even my dad told me this would never hold. Hear me out though: First of all I was going to have most of the burden on the inner frame, that is also a lot thicker, and distribute the burden mostly over the covering panels that would be screwed on the top later. Yes, this was flimsy but it held up until everything was screwed together - even for the following photo:

Now things were coming together. The inner panel would hold a shiton of buttons and the LCD later. I can tell you that drilling all the precise holes was no fun whatsoever! I also had to get a new drill for this because I had none with the required size.

Getting this right was important because most of my buttons would not be able to be fastened with their own screw from the backside. The material is simply to deep for the short length of the screw threads. So every button would have to sit snug in it’s fitting. This worked fine for most holes but some needed encouragement to not wobble around by applying some sealing tape that I usually use for water pipe fittings. It’s not stupid if it works 😛

I also can not stress enough how important the cardboard mock-up was. A lot of stuff had to be shifted around slightly for a better fit. The outer frame may be thin but does still introduce an off limits area. In some cases I had to bend the pins of a switch or button to make it possible. Cardboard is very forgiving when it comes to such corrections.

The panels were realized with two layers of thin compressed wood glued together. I only have a shitty jigsaw so I had to rasp the borders into oblivion in the end. A step drill was also a tremendous help because a lot of the parts - again - to not have enough screw thread to be fastened otherwise. This is especially true for the rotary encoders where I found none with a longer shaft so far and have yet to find a way to make these longer. Sadly the advertised products in my mailbox promising to help with enlargement are of no help here 🤡

I’m going to replace the wooden panels with a backlit variant made of acryl glass eventually. The idea is to replace the panels 1:1 with the exact same construction method of two layers sandwiched together.

Next was the backplate that would add a lot of stability to both frames. It connects the inner and the outer frame with screws of various length. The lower support area for the LCD is also already on the picture. I considered adding a little more depth for the wiring of the buttons. Some would be sitting on the LCD corners. I opted to leave it at the depth it is and bend pins again later simply because it would look better this way. I’m also going to add an inner bezel for the LCD frame at a later point.

At this point I was in need of a “temporary” stand to work on this more comfortable. This temporary stand was kinda incorporated into the final construction later. I’m going to eventually build a full cockpit around this but for now it’s just sitting on my table. It got additional stabilizer bars later so it wouldn’t wobble on each button press any more. The 17.3" LCD is really a tight fit here and I’m glad that everything worked out so good. I was totally winging it at this point because my STL did not go into too much detail on the backside.

Everything visible was painted in the end. There is not much to say about this. Colours are anthracite-gray and black. The colors don’t really shine, like the picture may imply. The coat of paint was simply not dry yet.

I waited another day for the paint to dry and assembled all parts for the long and dull wiring process. Yes, there are still some empty spaces. For some I’m still waiting for additional buttons to be delivered and for some I’m simply uncertain what to put there. Some gaming sessions should reveal what’s missing. I also didn’t build the lower panel yet because this part would be in the way when put on a table. I’ll probably design a temporary button box on the side for the elements that I was going to put there.

Originally posted at https://simpit.dev/version-2/frame/

The 3D design was followed by months of doing nothing 😩 until I realized that this would go nowhere without starting. So I found myself sitting down each evening and work on some mock-ups. Even if it was only for one or two hours. At some point would my kids show up and ask questions or hand me tools. Who would have guessed.

It payed off that I went with mock-ups first. Even with a rough 3D model I run into several small issues that had to be corrected.

For the Mock-Up I had to export my 3D model somehow first. After messing with various online converters, that all failed to produce a usable result from exported OBJ files I eventually found out that Wings3D has an export to STL built in. Man did I feel stupid. From there I imported the STL into Inkscape and added various A4 papers to the scene to print everything and tape it together. This was the first time that I got an actual idea of the dimensions and wondered what I did get myself into.

Originally posted at https://simpit.dev/version-2/mock-up/