DOCS ACC Shared Memory Documentation

Please make this thread a sticky one, and please update docs to v1.1

 

So I have a shared mem program called dash-pi , I have 2 pads I use with it and it works with rf2, AC and a few others ...Tonight I left the pads on after racing AC and when I fired up ACC its all working !! ?? lol tire ware, tac ,gas, break, clutch ,wheel movement ..its all there ! what a pleasant surprise ! I did not load anything for it ..it must use the same that AC uses >?? IDK ..... I hope it still works again tomorrow ! lol

 

Has some example about how to use this with C#? or is not possible? only with c++?

 

It is possible with C#, use it with C# as well.
Was thinking of releasing a standalone Shared Mem reader in C# for quite a time but have no time found.
The code I use currently is a mess to read, no comments.


Gesendet von meinem HMA-L29 mit Tapatalk

 

Could you give me just the tip about how to use in C#? I'm noob and learning C# yet.

 

Yes my DashPanelServer program is C#.
You want to look into an area called Marshaling for consuming unmanaged structures in managed code:
https://docs.microsoft.com/en-us/dotnet/framework/interop/marshaling-classes-structures-and-unions

 

The RST software is in C# as well, RacingSimTools.com, like @Berno mentioned you want to look into marshaling. You can define a struct, and it will handle the parsing of the binary stream for you. Much handier than other languages where you need to parse the binary yourself!

 

First, big thank you for making the Shared Memory example + documentation available.

I have been adapting my Telemetry tool for ACC.

As many of my users are using the Telemetry tool on a spare Mac/Win/Linux laptop , I needed something which sends the data over network. I took the shared memory example and made it to send the different packets over UDP, so the data can be received over the network.

I seems to work quite well in normal use, but I found one issue in my testing.

I don't know if the issue is in the Shared Memory implementation or in ACC. This happens with the latest new 1.2 version, didn't test this with the previous version(s).

When doing a custom race with 2 qualifications and/or 2 races, the graphics package (or memory) gets messed up, when the 1st quali/race ends.

You can test this easily with the provided Shared Memory example like this:
1) Select custom race, enable 2nd quali,
1.1.) You can press keys 1, 2 or 3 in the SharedMemoryExample, you get the data
2) Start driving in the first quali
2.1.) If you press they keys 1, 2 or 3 in the SharedMemoryExample, it all works
3) Drive the first quali to the end, press exit
--> Now if you press in the SharedMemoryExample key 2, the example hangs.
Even if you close the "handing SharedMemoryExample" and restart it, the app still hangs, when you press key 2 in the SharedMemoryExample.

Should this be reported as a bug or what is the right way to solve this?

Cheers.

 

@Iko Rein
Did a quick test and I can confirm your findings.

 

And it is now fixed in 1.2.2. Great stuff.

Cheers.

 

I am writing my own integration between ACC's Shared Memory and an Arduino board with my own dot-matrix display for TC, ABS, and several LEDs for TC, ABS and redline rpms.
How often should I poll the shared memory for rpm changes?
Is it updated at the rate of the Physics and Graphics engine?

 

I poll 'em with 100 Hz

 

There are more physics updates than graphic updates in shared memory.

I wrote a simple wrapper, which takes the shared memory packets and sends them via UDP to an ip address. I only send the packets, if the packetId has changed. I actually have 2 different options, either sending all packets (i.e. many physics per one graphics) or only send the latest packets, when graphics packetId has changed. My need was in creating the distance/time based telemetry graphs + race history data, so for me it was sufficient to take the data per one graphics packet as there are plenty of those too. But for a real-time RPM etc, your need is bit different, so getting the data, when physics packetId has changed is most likely the best option.

I haven't done very detailed analysis on the rate the packetId changes, but in the loop by default the tool sleeps 5ms per loop to keep the tool behaving nicely.

Cheers.

 

Thank you. Yes my needs are slightly different. I am more interested in a real-time response to data changes, but luckily the device is only for output.
I have experience with serial master-slave protocols: in my youth I played with broadcast frame accurate equipment and controlled devices using the Louth (VDCP) protocol over RS-422.
What I will do is measure how fast the my Arduino UNO and the dot-matrix display library are.
Like you, I am not interested in packet loss, and I don't need acks from the Arduino.
But I do know that despite what it says, the serial buffer can fill up quite quickly, and when that happens things go a bit wrong, so I will need to establish a way to re-sync the packets.
I also want to see how much processing I can push out to the Arduino: knowing the car, the Arduino could do BrakeBalance adjustment, and RPM redline % calculations.
It's early days, it's a pet project, and I will learn a thing or two. Will keep you posted on developments.

To make matters even more complicated, I currently don't have access to my simrig while developing this, so I have to come up with my own test bench:
- run the game and capture changes to the shared memory at a poll rate of 5ms.
- dump it in a file (playbook)
- when at the dev station, replay the shared memory playbook as if I were at the simrig
- test!

The Arduino UNO will be the master, and request data at the rate that it can handle; I can even put some logic then to ensure the buffer is not filling up too quickly.

 

SHAMELESS PLUG ALERT

I have finally got most of the functionality working in my project and I am currently running everything at the slowest update speed (testing the lower limit of what’s reasonable such as serial communication speed and display update speed) and I’m happy to say updating everything at 25 updates per second seems very acceptable to me. I could process data much faster (above 100 updates per second) but i would need to test if it’s actually noticeable.

this is a video I took today.
https://1drv.ms/v/s!AvkRpNN0V2R-gukMHee24brDN9wwTw

 

Nice!
It may be my brain messing with me, but it looks as though your rev lights respond more rapidly than the on-screen HUD

 

Thanks!

that is unfortunately only a matter of configuration. In the code if you look for optrpm and shiftrpm. Those are arbitrary numbers that must be entered for each car. I chose numbers for the Bentley based on what I see when capturing a live video from the game, but they might need to be fine tuned!
For reference the numbers I currently have are 6000 for the optimum rpm, and 7250 for the shift rpm. The only number I can see in the shared memory is the max rpm which for the Bentley is fixed at 7500.
I will populate those numbers for all the cars but if you can share those numbers with me please go ahead I’ll add you to the CREDITS file in GitHub!

 

With the news about ACC coming to console can we ask if UDP telemetry will be coming to consoles and if this time it could be a closer match to the shared memory?
Was a great shame how limited the UDP was for AC console users.

 

@Fernando Barbarossa, @Lord Kunos, @Aristotelis

Is it possible to do something with these inconsistencies in the shared memory output?

Lap: 3 | Last Sector Time: 59157 | Sector Index: 2 | Last Lap Time: 98406 | Current Lap Time: 101346
Lap: 3 | Last Sector Time: 59157 | Sector Index: 2 | Last Lap Time: 98406 | Current Lap Time: 101361
Lap: 3 | Last Sector Time: 0 | Sector Index: 0 | Last Lap Time: 98406 | Current Lap Time: 3
Lap: 3 | Last Sector Time: 0 | Sector Index: 0 | Last Lap Time: 98406 | Current Lap Time: 18
Lap: 4 | Last Sector Time: 0 | Sector Index: 0 | Last Lap Time: 101394 | Current Lap Time: 36
Lap: 4 | Last Sector Time: 0 | Sector Index: 0 | Last Lap Time: 101394 | Current Lap Time: 51

The transition between laps produces inconsistent data. For some samples the lap number is not incremented (3 -> 4), but sector index is already reset to starting sector (2 -> 0). Also current lap time timer and last sector time is already reset while still reporting same (current) lap (3). With these inconsistencies it is very hard to detect and generate some crucial events.

Also after crossing S/F line Last Sector time is reset to 0, instead of providing time for the last sector of the previous lap. Is it intended and are we supposed to calculate last sector times ourselves?

One more thing. Would it be possible to generate for each session a GUID? It would make detecting a new session trivial.

Thank you!

 

the spline position is also reset back to zero some time before or after the lap counter increments (can be either, IIRC). It's the same for each opponent too. I think this unsynchronized data might just be the way the game works and I don't think it's likely to change