RTT Linux client possible?
-
A quick follow-up:
The upcoming RTTServer/RTTClient v3.3 (which will be part of 4.35 U1) bumps the RTT_VERSION to 33U.
Before you ask, no, there will be no actual network message format changes, but that particular datum is used for other purposes as well and hence will be bumped with each major & minor version (however not micro & patch).
-
FYI, I’ve added some missing info about RakNetDefineOverrides.h at compile time to the post above, as well as UDP multicast info.
-
I finally managed to create an initial proof of concept of what I described previously in this thread.
This is an RTT Client running natively on a Raspberry PI 4 directly connected to the official RTT-Server.There are still some stability issues but at least it shows that what I was thinking of is possible in general…
-
I finally managed to create an initial proof of concept of what I described previously in this thread.
This is an RTT Client running natively on a Raspberry PI 4 directly connected to the official RTT-Server.There are still some stability issues but at least it shows that what I was thinking of is possible in general…
I have a couple of pi4. be happy to beta test it if you want. Let see if the pi can handle two monitors full of instruments
Sent from my SM-G960U using Tapatalk
-
Sure, appreciate your help. I just have to polish things just a little bit and get rid of the hardcoded IP address and so on so that it can be used in different environments. I’ll try to get this done this weekend…
But to make things clear: Initially, it was intended to extract the RTT stuff like MFDs, HUD, DED PFL, and RWR only. Currently, only the MFDs are working which is what I intended to use it for exclusively.
It’s not meant to be PI port of YAME. There are no plans (and time ;-)) to include this functionality - if that is what you meant with “full of instruments”. -
Yeah. I know some instruments are generated manually by the tools like tame and made. and some are extracted from shared texture.
Sent from my SM-G960U using Tapatalk
-
Here is an initial version that might be used to some extend in-flight. At the moment only left and right MFD is supported even if the config implies more.
There is still a problem in the ARM version where the display freezing after a couple of minutes if you stay to long in screens that require large data transmissions like TGP, A/G radar and thelike.
The windows version should work out of the box. There is a small readme that describes the system-requirements. I tested it only with the rPI 4 mentioned in the readme with a single screen.
If everything works as designed you should see something like that:Would be nice if you could update me with some test experiences from maybe different setups like rPI 3 oder rPI 4 dual screen.
-
There is still a problem in the ARM version where the display freezing after a couple of minutes if you stay to long in screens that require large data transmissions like TGP, A/G radar and thelike.
Are you sure it’s an ARM problem and not the current BMS Bug freezing / not rendering Textures to SharedTexMemory
-
yes, I’m pretty sure the problem I described is “self made” because this specific problem didn’t occur in the windows version yet, but tbh. while testing the windows version was running 5 to 10 minutes max. so I could be wrong.
-
yes, I’m pretty sure the problem I described is “self made” because this specific problem didn’t occur in the windows version yet, but tbh. while testing the windows version was running 5 to 10 minutes max. so I could be wrong.
A good repro case is using the TR_BMS_12_HARM Training mission in KTO. With that training mission running I could repro the BMS internal SharedMemory Freeze at no longer than 2 minutes
-
thanks, I’ll give it a try…
-
I’m now using my RPi Client to export the RWR. No problems with freezes since the Update.
I also created a DED for my pit reading the new multicast data available since U1, so this is completely self-contained. Only a USB connection for power supply.
-
Care to explain that?
@gofrm:…reading the new multicast data available since U1, so this is completely self-contained. Only a USB connection for power supply.
-
a few posts above, dunc describes a new functionality of the RTT server: sending the shared-memory data via UDP multicast into the local network.
So I created a microcontroller-based (arduino-like) device that is reading this data from the network without requiring any kind of host/controller-application running other than the RTT server shipped with BMS.
It is a little bit off topic regarding your original question about exporting the RTT with linux but its a logical step forward if you have the goal to power your pit with non-windows (in my case linux-bases, credit-card sized, more or less inexpensive hardware) finally having the sim running on windows plus only one network cable plugged into you pit. -
@gofrm said in RTT Linux client possible?:
a few posts above, dunc describes a new functionality of the RTT server: sending the shared-memory data via UDP multicast into the local network.
So I created a microcontroller-based (arduino-like) device that is reading this data from the network without requiring any kind of host/controller-application running other than the RTT server shipped with BMS.
It is a little bit off topic regarding your original question about exporting the RTT with linux but its a logical step forward if you have the goal to power your pit with non-windows (in my case linux-bases, credit-card sized, more or less inexpensive hardware) finally having the sim running on windows plus only one network cable plugged into you pit.That’s a great feature!
So, I have two Raspberry Pi’s with displays and I want to test RPi Client but I’m a complete newb to Linux.
@gofrm could you give me a step by step on how to install it and configure it (and BMS)?
-
-
-
@gofrm should the BmsExtractor you developed for Raspberry Pi work with the newest RTTServer v4.3? I got Client configured and connecting to the server, but MFD’s are always blank. When running the RTTClient shipped with BMS 4.37 on Windows machine, everything works normally.
p.s Thank you for the great idea of D1 Mini based DED. My cockpit instruments have become so much more reliable after getting rid of USB connections and relying on UDP multicasting packets. Are you using u8g2 to drive the SSD1322 panel, and if so, do you happen to have a working font for the DED?