Category: SimPit

A place for my simulation cockpit shenanigans

Posted on
by

Finally replaced the old display with a new touch display in my VF-1 inspired home cockpit panel.

The old display was salvaged from a laptop years ago and while it was working fine it also has a very bad viewing angle. I also got really tired of it’s glaring reflections so I experimented with an anti glare foil. This reduced the reflections a lot (worth every cent) but couldn’t help with the bad viewing angle, of course. I now had an idea how this could look though so I decided to buy into a replacement kit.

The new display is the N173HCE-E31, a 17.3" with a resolution of 1920x1080. The touch controller registeres as a USB HID pointer/mouse by ILITEK and is basically sitting on top of the display. The kit included a PCB, that was advertised as VS-RTD2556HC-V2 controller by VSDISPLAY but came without any data sheet and I have no idea who really made this.

Thing is this PCB runs very hot and the noted input voltage isn’t explicitly stated. An attached image suggested to use an USB PD power supply without 20V so I was looking for it’s datasheet to check if I was just holding it wrong. Picture me surprised but VSDISPLAY does not list this particular configuration in it’s datasheets. I contacted them via mail and they confirmed that this is not theirs. Theirs is apparently also strictly 5V/12V so that matches the picture I get.

Mine is equipped with the IC RTD2556VD that does not match the list of supported ICs. Theirs has 2556TE_R20.1 printed on the PCB. Mine has 2555TF_R30.1 printed on. It’s like 99% similar but differently routed. It also mentions E470791 JPX-D which seems to point to the PCB manufacturer Dongguan Jingweixin Circuit Co Ltd but that is where my GoogleFu left me. I did also find the very same pictures on other offers, each stating a completely different controller model 🤷

Anyway. I tried different configurations and while it works with 5V at ~2A I feel way more comfortable with 12V at ~0.8A on full brightness + blue color. I also attached a passive cooling block I had laying around and slapped a fan on top. Now it’s only “comfortable” warm to the touch after running for an hour.

Sadly I do not have any device with DP ALT providing more than 5V and the PCB will always switch down to 5V the moment the USB-C dedicated for the display signal is used as well, even when a proper USB PD power supply is attached on it’s dedicated power connector. I could only keep it at 12V with my VITURE USB-C XR charging adapter, which can indeed provide 12V and more via USB-C while still allowing DP-ALT + USB2. There went my plans to only have a single cable for all, DP, PD and the USB2 lanes for the ILITEK pointer, because I really do not want to block this adapter all the time.

So now I have a dedicaded USB PD power supply at 12V connected, a HDMI connection for the display and an additional USB2 for the touchpanel pointer – and on top of that the little fan, that I simply connected to the micro USB2 socket on the PCB to provide it with 5V.

This also means that my Linux PC can not know that both, touch panel pointer and display, belong together. As a result all touch panel inputs were all over the place and not limited to a single display. Apparently KDE has an option in it’s graphical settings where this can be easily configured. Gnome does not [yet?] have such an option in it’s graphical settings. There is however a way to enforce the mapping of the touch panel in Gnome too! And while the real manufacturer for the controller of the new display is still a mystery to me I found the following snippet in my monitor configuration $HOME/.config/monitors.xml after plugging the controller in:

<monitorspec>
    <connector>HDMI-2</connector>
    <vendor>RTK</vendor>
    <product>0x2555</product>
    <serial>0x20230705</serial>
</monitorspec>

The touch panel is, according to lsusb, connected as ID 222a:0001 ILI Technology Corp. Multi-Touch Screen. Armed with that knowledge I can limit it’s input with gsettings to this specific display:

gsettings set org.gnome.desktop.peripherals.touchscreen:/org/gnome/desktop/peripherals/touchscreens/222a:0001/ output "['RTK', '0x2555', '0x20230705']"

Works like a charm but what a mess. I still wish I had a data sheet for this so if you know more kindly drop me a comment!

The last thing to fix was the already mentioned reflective glare. For this I went with a screen protector by BROTECT (that name still makes me laugh), that promises beside anti scratch also an anti glare effect without limiting the view angles (some foils do this to enhance privacy).

Attaching the foil was straight forward. The trick is to make sure that not a single dust particle is around during the process. To help with this I used an air humidifier to raise the humidity in the room before I even started. After that I removed the protective cover from the display and started slapping on the foil with the provided mounting card (yay, cardboard again). This was the very moment one of my curious cats decided to investigate my actions and jumped onto the table almost giving me a heart attack. The last thing I needed was cat hair all over the place and indeed after a lot of hissing I had to make good use of the also provided adhesive sticker to catch all dust particles in the last corner. Cats!

The end result is like night and day. I do no longer see any light sources or myself clearly reflected on the display. The touch panel is still accepting inputs just fine and the colours look very bright from any angle, especially with HDR enabled. This will also ease it’s cleaning because the cockpit panel is collecting dust like crazy due to the gradient of the panel. I usually use a vacuum cleaner for this and the foil will help a lot to avoid scratches.

Replacing the old display was also a task on it’s own. The old screws didn’t fit, of course, so I kinda had to build little adapters from leftover angle and wood pieces. Very ugly but good enough – this is just a toy after all 🤓

Ah yes and now that I have a touch panel I also have to rewrite my HUD app, of course 🙃

CC

This content is licensed under a Creative Commons Attribution 4.0 International license.

Posted on
by

So I dunno if you know what a (https://en.wikipedia.org/wiki/Vacuum_fluorescent_display) is but I’m a sucker for these – at least virtually.

Games like perfected the look and this is where I want to go with my HUD app for my / home cockpit too.

Screenshot from the game Rebel Galaxy Outlaw with it's very colourful cockpits full of VFD like displays.

The segment displays are heavily inspired by project (https://augmented-ui.com/) where I’ll borrow some more elements. Learned the neat fake scan lines from there too. And yes the 8 segment display works by shifting bits under the hood 🤓 This isn’t really needed for an app but I have plans to add some real segment displays eventually (I do have a whole box full with these!) so I wanted to know how to implement this anyway.

Video from an earlier stage in the development demos the scan line effect.

The bars are configured with parameters in size, count, percent, colours and thresholds 😁 I also added a random chance of 5% to shift the hue a little bit because just as in real life nothing is perfect.

A colourful button box surrounding a display that shows various data from the game running in the background stretched over several own displays for immersion.

And yes they are fully themed so switching the colour theme also affects the virtual VFDs.

I’m also going to replace the older horizontal bars, that look way too boring in comparison.

It’s still very early but I hope to get some rad animations going too. See https://www.hudsandguis.com/home/2022/retro-digital-dashboards to get an idea in which direction this is going 🤓

See the dedicated project page https://SimPit.dev for more details on this inspired panel.

Posted on
by

This uses my X4-SimPit extension for X4: Foundations, that sends ship telemetry via a socket to my node-red plumbing pipeline, which in turn forwards data to Websockets, SocketIO and MQTT. Various subscriber listen on the new messages to run blinken lights and my HUD app. I’m using the well known message format also used by Elite Dangerous so it’s compatible with that game as well.

Pick your poison: https://makertube.net/w/nUoG2ZPeAW1QhT3A2BXRrM / https://www.youtube.com/watch?v=wp1PkVhH9cc

Oh yeah… and on Linux PC 🤓

Let me know what you think!

X4-SimPit code (pending changes) is here: https://github.com/bekopharm/x4-simpit
The cockpit panel has a dedicated project page here: https://simpit.dev/

Posted on
by

https://makertube.net/w/bufv9BJv2vcXDb3KUaksB7 / https://www.youtube.com/watch?v=CpP7KS1fbrY

`@ozoned` interviewed me on my home cockpit on a live stream via his instance at https://stream.ozoned.net/. This is a more condensed version of the stream that is still just 1h shy. We’re going over almost every feature of my Primary Buffer Panel and I explain how everything works. I also decided to add various photos, slideshows or video snippets during the talk only sections so things don’t get too boring. Sometimes that even complements the talks 😄

Ever wondered how to start your own DIY / on? It’s easy. Just watch this stream 🤓

Dedicated project website: https://SimPit.dev

Check out the original recording if you want to see more or the full stream with more [dirty] details: https://video.firesidefedi.live/w/dTkHpUidsgANCUontrmCaZ

Edit: Updated links to latest location.

Posted on
by

So I started taking a closer look at the various panels I got with the old , which is a challenge in itself, since not everything has a handy badge telling me what it is. It’s also not like I’d have a clue in the first place. Figured out that this one apparently belonged into a but I don’t know the exact model yet. It was installed in the rear cockpit on the left side of the front panel and operated by the Weapon Systems Officer and is apparently no longer in use since ~1990. It’s safe to assume that this thing did see action and was closer to space than anything else I own.

Side view of the buttons array
Side view of the buttons array

Next was finding out how this thing is wired to see if I can convert it into a button box for PC gaming. The segment displays look pretty straight forward and I’ll definitely need some multiplexers to drive them but that has a low priority. The switches can easily be checked with a meter but thanks to @kranfahrer@mastodontech.de I was able to track down some wiring diagrams as well. Turns out these are not also very old but apparently rather pricey too? Someone mentioned an eBay offer for whopping 300 USD for a single button – which is insane to me 🤯

Backside of the Tornado WCP showing beautiful cable lacing.
Backside of the Tornado WCP showing beautiful cable lacing.

Speaking of wiring: The backplate may be missing but some of the original cable management is still in place. This is where we can see the rather beautiful cable lacing, which is used in avionics for bundling together wires with waxed nylon or linen cord in an environment with lots of shaking and vibrations. No I didn’t know this before and would probably have ignored it but A Hornet’s Nest just released a video about Cockpit Cable Management where he talks in detail about this technique. Great channel!

The lamp used in one of the buttons is not even LED yet
The lamp used in one of the buttons is not even LED yet

Another question was for what voltage the lamps are designed for. Each button comes with at least one lamp. This is a rather old fashioned and not a LED yet (and in fact LED replacements are rather expensive even). This specific one is the model OL387 rated for 28V DC and 40mA. Apparently this all is up to military spec MIL-S-22885 and bright enough to still be readable in sunlight and comes with high duty cycles before it needs replacements – so it will probably last a lifetime in my man cave 🤓

CC BY-SA

This content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International license.

Posted on
by

This video is how I gutted my already modified old Thrustmaster F-16 FLCS joystick of my ViperPit and made it work again with the help of an Arduino Pro Micro. This flight stick (and also the other peripherals) do belong in a museum but where’s the fun in that? I modified it and now it’s a generic USB joystick that works on any recent system. I focus mostly on the 5×5 button matrix since this is the hardest part to understand. In the end are a few minutes of playing X4 Foundations with it to give it a good test run. Now it just needs some oil for the creaking 😅

https://makertube.net/w/qrqqZLr2QvJFjCwyNzzAmp / https://www.youtube.com/watch?v=AYiPFDpHwmc

Oh boy oh boy it arrived. And what a friendly seller 👌 Kinda a shame that they gave up this hobby. Sold everything for an apple and an egg. It’s a loosely based on a F-16. Nothing of this is functional though. Yet.

Winter may come!

Man… the _feel_ of those lovely switches and dials alone ❤️

Posted on
by

I just set https://simpit.dev/ live.

Primary Buffer Panel – The On A PC For More Immersion In Pew Pew

A glorified joystick controller with an LCD (‘MFD’) and plenty of RGB.

Best viewed WITH an ad-blocker (thanks @stefan)

I’m kinda blind by now after hacking away on this page for days so I’d appreciate feedback.

Especially if something is broken.

Posted on
by

I hacked a mod for X4: Foundations to get ship telemetry and targeting data to my “Primary Buffer Panel” via a socket. This is a demonstration of my simulated cockpit made from cardboard on a budget usually used to play Elite Dangerous now also used for X4: Foundations. This is work in progress.

My DIY cockpit for X4: Foundations (on Linux PC)

In use:

  • A Linux PC
  • A DIY Headtracker
  • A DIY Joystick (My Primary Buffer Panel)
  • A X52 Pro HOTAS
  • An AMD RX6700XT
  • …a lot of plumbing in Node-Red xD

This is loosely based on the Python Pipe Server mod for X4 that is sadly Windows only using Named Pipes. I fixed that for Linux PC by side-loading the library LuaSocket and starting a socket server directly in X4. That’s right, the Python Server is simply not needed now and companion tools may directly connect to the socket. It’s a nice bonus that LuaSocket also allows a UDP or TCP server depending on how it is started. That was some piece of work though and I’m still wrapping things up to publish my code changes. I’m also still looking for testers so if you’re interested get in touch!

So you _still_ think you can’t space pew pew on Linux PC? Think again. I do it all the time: https://beko.famkos.net/2021/10/16/space-pew-pew-on-linux-pc/

CC BY-SA

This content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International license.

Posted on
by

A lot happened since my last update on the simpit – under it’s hood. Function wise it changed not so much so the older demonstration video is still better for a quick demo. I still assembled a new video from clips of the first evening with the new hardware:

Quick trip from Armstrong Orbital over to the huge crater on HIP 117029-4 and back

So what changed? I got rid of the CY-822A USB joystick controller that, while good, was also limiting. Especially in inputs and how they would react. The Raspberry Pi, that I used to drive the status indicators, is also gone. This is all replaced by one single Arduino Mega that is connected via serial over USB.

A custom joystick daemon written in Rust is listening for data from the and feeds back the flags of Elite Dangerous to drive the blinken lights. I also extended the source to add me some rotary encoders (with push button function) and I’m very happy with the result of this. That makes a whopping amount of 48 buttons and 6 axis (where 2 axis make one hat). And it feels _so good_ to have e.g. self destruct or eject cargo save under a protective cover now 😀

An enemy vessel exploded, the bounty is mine
That rocket was too close for comfort
Limping to a hangar after taking battle damage
Evading a firestorm from behind by moving sideways
Various screenshots from a gaming session of StarCitizen

The panel also got an external PSU with enough ampere to drive as many LED as I may imagine so I no longer abuse a phone charger for that or risk frying of the PCB / USB.

With all that in place I streamlined my pre-flight check-list quite a lot because way less hardware is involved and most of this is automated by now. It wasn’t all fun n giggles tho and while the new hard- and software “just worked” in e.g. it was that gave me a hard time to actually use most of the new buttons.

Getting all the precious buttons into Elite as well (okay, limited to 32 thanks to an old dinput library but who is counting at this point – will simply set the rest to keyboard macros instead)

Turns out it had no idea about the device and model identifiers reported by the joystick daemon and that the kernel assumed a gamepad based on declaring e.g. ButtonNorth via the more recent xinput system really didn’t help – because that limited the amount of read buttons via xinput severe! In the end I set it’s identifier to a “vJoy” device. That I found in the DeviceMappings.xml of Elite and since this could be basically anything I gave it a try (and removed all “offending” magic gamepad buttons from the code) and sure enough Elite started accepting the inputs as expected and from there it was smooth sailing – got even the hat working.

Oh and for everyone who is wondering what exactly they are seeing on the “MFD” when I’m playing Elite: That’s basically a Website using the FUI framework. Find a quick demo video here. Without the cardboard covering up parts of the screen it looks basically like this:

What the game shows
What the ARWES website shows as MFD

I also started doodles for a version 2 – now that I have an idea what I really want.

Plans for another based on a Valkyrie Cockpit

CC-BY-NC-SA

This content is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license.