Setting up RTT multicast
-
Multicast.txt says:
“Hence, this document assumes that you know what UDP multicast is, what valid IP
address ranges you can use, how not to flood your network, how to receive
multicast packages with your custom client applications.”What about those that don’t know how to set it up? Any pointers?
-
@Nikolas_A that doc seems geared toward developers, who might wish to consume the data, over the local network on other devices … but I honestly don’t know if any such software exists. it’s not for the normal RTTClient. what software are you trying to setup?
-
@airtex2019 no, it’s geared towards pit builders.
Check this thread:
https://forum.falcon-bms.com/topic/19572/rtt-linux-client-possible?_=1671546419967You can read the data with a microcontroller and drive instruments or panels , without the need for a second PC or interface software. Check the standalone DED that @gofrm built.
-
-
It’s been almost two years since I first started developing the RTT linux/R-PI client. I continued development a couple of weeks ago and since I noticed there is some discussion in this and the original threat I thought I give a quick update and clarify the RTT / Multicast confusion.
When we talk about Multicast we are only talking about the simple shared mem data without the actual RTT images like MFDs, RWR, HUD, and so on. This simple data can be consumed by simple Arduino-like microcontrollers to implement things like my DED, my new FuelFlow-, and EngineGauge-Panel, or any other instrument that displays simple values or lights LEDs. For the RTT images to be received and displayed on a screen, you need at least an R-PI running Linux and this is not covered by the documentation found in Tools/RTTRemote/MULTICAST.txt or is otherwise documented officially AFAIK. For both types of clients, you should be familiar with networking and developing C/C++ (or another programming language) to some degree. So I would say the documentation is geared toward pit builders who happen to be developers as well.
At the moment my software is able to display all RTT-exported images running on multiple R-PI 4s / CM4s displaying one exported image each on individually connected small screens from 4" to 10" depending on the image type.
I also started creating some yame-like clients to create and display instruments on screen that are not available as RTT-image. The first one here is the EHSI which I “painted” entirely by myself. A couple of others will hopefully follow soon but I don’t have the time and desire to create all the needed assets. I had a look at the instrument images located in the BMS DDS files but it would still be a lot of work to adapt them and use them in my software and there might also be some legal issues as well if I wanted to distribute the software at some point. - Any help here would be appreciated.
I will try to assemble a couple of images and videos from what I currently use in my pit the next days and will post it here: https://forum.falcon-bms.com/topic/19572/rtt-linux-client-possible?_=1671546419967
-
@gofrm I know the difference, that’s why I started a new thread. I wan to read shared memory data with a Teensy as my main I/O interface.
Any pointers on how to set things up would be greatly appreciated!
-
@Nikolas_A I’ll try to help but it would be great if you would get a little bit more specific about which kind of pointers you need. I can provide you with the basic source code I use to read the data but in one of your previous posts, you stated that you are not a developer. Unfortunately, my software is not yet on an let’s say “MobyFlight” level with a nice UI where you can configure your inputs and flash the config onto the controller. Everything is still quite hardcoded at the moment, specifically designed for the instrument the controller is intended to drive.
However, here is the basic receiver code running on the Arduino Platform using an ESP8266 Wemos with WiFi-chip. I use PlatformIO for development, Teensy is also supported. I hope that helps…#include <ESP8266WiFi.h> #include <WiFiUdp.h> #include "flightData.h" char ssid[] = "your ssid"; char pwd[] = "your pwd"; WiFiUDP Udp; IPAddress ipAddr(224, 0, 0, 44); unsigned int port = 45000; byte msgbuf[3000]; int respCnt = 0; enum SMEM_DATA : byte { F4 = 0U, //FalconSharedMemoryArea (FlightData) BMS, //FalconSharedMemoryArea2 (FlightData2) OSB, //FalconSharedOsbMemoryArea (OSBData) IVIBE, //FalconIntellivibeSharedMemoryArea (IntellivibeData) DATA_NUM }; void setup(void) { Serial.begin(115200); WiFi.begin(ssid, pwd); while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); } Serial.println(""); Serial.print("Connected to "); Serial.println(ssid); Serial.print("IP address: "); Serial.println(WiFi.localIP()); digitalWrite(LED_BUILTIN, HIGH); int res = Udp.beginMulticast(WiFi.localIP(), ipAddr, port); Serial.print("Res: "); Serial.println(res); } void loop() { char newLine[26]; int numBytes = Udp.parsePacket(); if (numBytes) { Udp.read(msgbuf, numBytes); //detect package type (see SMEM_DATA enum) unsigned char dataNo = msgbuf[8]; if (dataNo == F4) { // cast packet-data to flightdata.h struct, skip header (+9) auto *data = (FlightData *) (msgbuf + 9); // do something with the data // some examples (see flightdata.h) float a = data->rpm; float b = data->oilPressure; float c = data->fuelFlow; float d = data->internalFuel; Serial.print("int. fuel: "); Serial.println(d); } } }```
-
Thanks for the example.
@gofrm said in Setting up RTT multicast:
@Nikolas_A I’ll try to help but it would be great if you would get a little bit more specific about which kind of pointers you need.
To take things from the start, first post: valid IP address ranges, how not to flood the network.
I’ve done some Arduino programming, I think I can get somewhere with the help from your example, but I don’t now much about LAN settings. I haven’t even made MFD extraction to work (on a Windows laptop, I haven’t tried your Linux client yet).
-
@Nikolas_A
Just take the IP and port settings that are predefined in the RTTServer.ini and also in my code. It worked out of the box for me in my LAN. -
This post is deleted! -
@gofrm ok, I’m trying to make it work with the NativeEthernet library on the Teensy. I’m making some newbie mistake because I get an “expected primary-expression before ‘.’ token” on line 44
#include <SPI.h> #include <NativeEthernet.h> #include <NativeEthernetUdp.h> // Enter a MAC address and IP address for your controller below. // The IP address will be dependent on your local network: byte mac[] = {0x04, 0xE9, 0xE5, 0x0C, 0xC6, 0x40}; IPAddress ip(192, 168, 1, 113); EthernetServer port(44000); #include "flightData.h" byte msgbuf[3000]; int respCnt = 0; enum SMEM_DATA : byte { F4 = 0U, //FalconSharedMemoryArea (FlightData) BMS, //FalconSharedMemoryArea2 (FlightData2) OSB, //FalconSharedOsbMemoryArea (OSBData) IVIBE, //FalconIntellivibeSharedMemoryArea (IntellivibeData) DATA_NUM }; void setup(void) { Serial.begin(115200); Ethernet.begin(mac, ip); while (Ethernet.linkStatus() == LinkOFF) { delay(500); Serial.print("."); } Serial.println(""); Serial.print("IP address: "); Serial.println(Ethernet.localIP()); digitalWrite(LED_BUILTIN, HIGH); int res = EthernetUDP.beginMulticast(ip, port); Serial.print("Res: "); Serial.println(res); } void loop() { char newLine[26]; int numBytes = EthernetUDP.parsePacket(); if (numBytes) { EthernetUDP.read(msgbuf, numBytes); //detect package type (see SMEM_DATA enum) unsigned char dataNo = msgbuf[8]; if (dataNo == F4) { // cast packet-data to flightdata.h struct, skip header (+9) auto *data = (FlightData *) (msgbuf + 9); // do something with the data // some examples (see flightdata.h) float a = data->rpm; float b = data->oilPressure; float c = data->fuelFlow; float d = data->internalFuel; Serial.print("int. fuel: "); Serial.println(d); } } }
-
@Nikolas_A You are using the wrong port and IP address here. The port and IP address you are using tells me that you (accidentally) trying to connect to the “main” RTT server, which is not multicast nor is the protocol/data format compatible with the receiver code I provided.
If you want to communicate with the “main” RTT Server (which also sends shared mem data alongside the RTT images) you would first have to make yourself familiar with the RakNet protocol BMS uses.
Assuming that you have a standard LAN setup at home, as I said, just use the values already provided in the server config and in my code. You don’t have to change anything here.
in RTTServer.config the multicast settings start at line 33. the multicast server transmits on port 45000 by default while the “main” RTT server uses 44000. Both protocols are sent from this single RTTServer64.exe.
the main server config:
HOST = 0.0.0.0 PORT = 44000
the multicast server config:
MULTICAST_HOST_v4 = 224.0.0.44 MULTICAST_PORT = 45000
for multicast you need to set the same values in your client.
-
@Nikolas_A I didn’t test the code but what seems a little bit weird is that you are creating an EthernetServer called “port” on line 9 that listens on port 44000 and then using that server instance “port” in line 44 to provide the port number for the multicast client.
Simply put the port number directly as the second parameter or better create a simple uint16_t or int on line 9:
int port = 44000;
taking my previous post into account, use 45000.
see also https://github.com/arduino-libraries/Ethernet/blob/master/src/EthernetUdp.cpp line 182 for expected parameters / types of the EthernetUdp.beginMulticast() - method.
-
@gofrm thanks, I’ll try these and report back. I new the IP settings where wrong but since I had compile errors I wanted to get those out of the way first…
-
I did that, still getting the same error… Some obvious syntax error is staring me in the face…
@gofrm said in Setting up RTT multicast:
Simply put the port number directly as the second parameter or better create a simple uint16_t or int on line 9:
int port = 44000;
taking my previous post into account, use 45000.
-
You are trying to access the EthernetUDP methods in a static way. You should create an instance of the EthernetUDP class first:
EthernetUDP udp;
and then
int res = udp.beginMulticast(ip, port); . . . int numBytes = udp.parsePacket(); . . . udp.read(msgbuf, numBytes);
see also: https://www.arduino.cc/reference/en/libraries/ethernet/ethernetudp.begin/
I know, it’s not exactly the library you are using but it seems to have a similar API.I didn’t test the code. but it compiles without errors.
-
Alright! It compiles. Now to set the IPs. I put the defaults back in but it doesn’t work. The MFDs extract locally, so from the BMS config I’m ok
-
@Nikolas_A
What exactly doesn’t work?
Does it fail to connect?
Are you sure your router supports multicast? Maybe it has to be enabled there as well.
Do you have any output on your serial monitor?
Did you enable multicast your server config? - While the values should be ok, it’s off by default and has to be enabled by uncommenting the relevant lines. -
@gofrm said in Setting up RTT multicast:
Does it fail to connect?
Do you have any output on your serial monitor?Yes, the Teensy reports it’s IP and Res:1 on the serial monitor, the MFD client shows Xs in the MFD frames
Are you sure your router supports multicast? Maybe it has to be enabled there as well.
I see Multicast: IGMPv2 in the settings. Supports v1 and v2 also.
Did you enable multicast your server config? - While the values should be ok, it’s off by default and has to be enabled by uncommenting the relevant lines.
Yes. Also the set g_bExportRTTTextures 1 line was missing, I added it.
I’ve opened the ports both on the sim pc and the one I’m running the client on -
@Nikolas_A
As the RTTclient for the MFDs is running locally as you stated earlier and would use the other protocol if they were on an other machine, they don’t prove anything in regard to your multicast problem.
Running locally, they would show the X and later the in-game output (if g_bExportRTTTextures =1) even if the server is not running.But setting g_bExportRTTTextures to 1 also makes no difference in your case as multicast does not transmit the RTT textures either way.
could you please post your multicast related config from your server.ini?
-
@gofrm I know they are different, but I believe the problem is common, router settings, port setting etc. I’d be surprised if one worked and the other didn’t.
The sim PC is on a switch btw, not directly on the router, could this matter?
MULTICAST_HOST_v4 = 244.0.0.44 #MULTICAST_HOST_v6 = ff12::44 MULTICAST_PORT = 45000 # By default, UDP multicast TTL is 1, i.e. packets are not routed outside your # subnet. If - and only if - you have good reason to route multicast into other # subnets, you might want to adjust the TTL according to your needs. MULTICAST_TTL = 1 # Which BMS shared memory data areas should be be sent via multicast? # Set 0 to disable, 1 to enable. If all are 0, multicast is disabled. MULTICAST_F4 = 1 MULTICAST_BMS = 1 MULTICAST_OSB = 1 MULTICAST_IVIBE = 1