I have my RD set to output the RPM over multicast to a custom tcp server. The fist 4 bytes lines up with the target id of 37 (as expected) but when I take the ieee 754 floating point of the second 4 bytes, it comes up with a number no where near the RPM values.
Am I doing something wrong?
Hard to say for custom systems. Maybe you are sending the float value from big endian device to little endian device?
Thank you for the reply and all the help.
I was able to get it working. So now I have a custom c# program controlling the real dash software. Itās so awesome!
I just wish there was an easier way to do the animation and movements
Can you suggest how to improve that?
Hello Jani, Let me apologize for all of the text, just want to give you as much information as possible.
Iām having trouble with Multicast. I have it configured correctly and data is being sent to my custom program, but for some reason there are times when the pipe is flooded with values other than the IDs I set in the Multicast section. IDs in Multicast section are RPM, DUMMY 38, 39, 40, VSS1.
The unknown values or IDs are above 10 thousand (sometimes less than negative 10 thousand as well)
I have also removed all IDs from Multicast, so that nothing is sent, but I am still receiving the large IDs.
I am creating a log file to capture the IDs so I should have that for you soon.
Just wondering if this is expected behavior? For example do the large values represent a real dash error or exception?
These byte arrays are happening while using simulation mode. When I first connect its ID 1901. The ID afterwards has been different.
**
**
**
These are happening while connected to the obd portā¦ These are separated by an underscore ā_ā.
1901_1241513985_1543503873_301989889_-1862270975_-301989887_620756993_-1509949439_1828716545_2130706433_-1543503871_-620756991_587202561_889192449_-1241513983_-33554431_-654311423_-956301311_-335544319_-1577058303_-922746879_-2130706431_268435457_1207959553_922746881_1862270977_1509949441_-1828716543_
Hard to say. At a quick glance those may be Inputs from āMulticast Inputsā option. Do you have that enabled in Data Multicast settings?
Multicast inputs is not checked. Accepts inputs is checked
Now you have me thinking that my set up might be wrong.
Can 1 RD instance output multicast values and also receive inputs?
What I currently have is c# program connected to the RD instance on port 8005.
I am receiving and sending on that port between the c# program and RD instance.
Is this even allowed?
Yes, any instance can output multicast values and all but one (the sender) instance can receive inputs.
Well, you have put yourself into a deep end. What is it that you are trying to achieve with intercepting the multicasting data? Maybe there is a easier way to do what you are doing.
Oh maybe thatās my problem.
Because Im sending commands from my program to RD, but also need RD to send me values
My program tells RD to change gauges. While RD sends me gear (turns on reverse cam), rpm (turns computer off) and fuel consumption (custom mpg formula)
I think youād be better off to make your app to behave like a CAN device and then use the RealDash CAN protocol to communicate between your app and RealDash. You can configure the CAN XML so that RealDash will send a CAN frame with gear info.
Can you explain some more about this?
Iām having a hard time picturing it
Here is a full documentation to RealDash CAN protocol and XML description file:
RealDash-extras/RealDash-CAN at master Ā· janimm/RealDash-extras (github.com)
I think i found the problem. I have custom NAMES within my XML description file.
In the Units and Values Section, i was setting these names to DUMMY IDs.
The DUMMY IDs were set in Multicast to send to my custom program. I was receiveing the dummy IDs, but also receiving all of the NAMES as IDs.
Once i deleted the settings in the Units and Values section, and used the Names in the Multicast section, only the IDs in the multicast section are now being sent.
Either there is a bug or i am doing something different than the original workflow for RD. Either way, i think im the only one using it this way lol, so no need for alarm
1 Like