PHYSICS MoTeC telemetry and dedicated ACC workspace

Seems to be around 12% is what people shoot for. I don't quiet understand the reason why yet it is that number but of all the videos on Motec and Dampers I've watch 12% is usually the target

 

You can't think that way, changing the bin size, changing the time filter or motion ratio in the graph properties will change the % time spent in each bin.



So you can only compare values with same static properties, from one workbook to the other, from one personal visual preference to another you'll get different results.

You need to train yourself to get your own habits and references, feel when you have good grip and these would be your target values for a particular car. Or get the telemetry file from one fast driver and compare it with your telemetry in your workbook.

I've addressed a bit this topic in previous posts
https://www.assettocorsa.net/forum/...ated-acc-workspace.55103/page-20#post-1118132
https://www.assettocorsa.net/forum/...ated-acc-workspace.55103/page-20#post-1118137

 

same problem, it doesn't work

 

I think you might be making a mistake somewhere. Try selecting a different lap maybe.

 

Is there a way of telling when the car is bottoming out? I can't find a rake setting.

 

An easy way is generally to look at vertical G's but we dont have that channel either...

What you can look is the max value you get on SUS_TRAVEL_XX the absolute max is either full stroke on your damper (metal to metal scenario) or bottoming out if the suspension geometry allows long enough damper stroke before bottoming out.

You can create a useful (imo) indicator in your SUS_TRAVEL_XX time distance graph to see when the bumpstops are engaged by doing these maths per wheel :

stat_min(choose('BUMPSTOPUP_RIDE_LF' [..]>0,'BUMPSTOPUP_RIDE_LF' [..]*'SUS_TRAVEL_LF' [mm],invalid()))

That will result in the XX Bumpstop Ride (1) you see below wich is the suspension position when the bumpstop is starting to be compressed. Aristotelis said in a stream that the bumpstop rates are forces at 10mm bumpstop compression

Due to NDA's the ride height isn't given in the channels, you know the static ride height / static rake from the setup screen, but you don't have telemetry channels for it.

You could though with a bit of tinkering build approximations with maths channels but it's rather advanced MoteC use for the rake calculation to be usefull in ACC (to simple maths makes it unusable from track to track, session to session or ride height change during a test session... you get irrelevant numbers) but that is definitely possible, you just need a huge amount of discipline to get valuable readings.

 

Ride height channels are available.



Edit: Oh wait, not with the default workspace it seems. I'm using Nils Naujoks workspace + I added brake temperature channel.
https://mega.nz/#!hI8ghCoK!69gaKB9ZRVOZKR5xjxyBMP_wU-ihfL4GOberrvkaMIU

 

Done by Maths expressions, not in the channels and that's what I call difficult and the need of being disciplined as you would need to adjust the formulas each time... and looking at old sessions you'd be lost by what were the wheelrates, the static ride height...

Here is is Math expression in Nils workbook for LF
51-'SUS_TRAVEL_LF' [mm]+21.83

You'd need to replace the 51 by your static front ride height of the setup screen and the 21.83 by the suspension travel when car is static and not on the jacks...
The static suspension travel would change each time you change the wheelrates, and it won't tell you the whole story anyway as it is an estimate for your laps as your fuel consumption will change your overall weight

You can try to capture the static position by Maths expressions, but you still need to respect a few steps to get right values and it is still a lot of work. You can call setup sheets where you enter your static ride heights, but that will still need you to be very disciplined and it's really advanced MoteC use.

 

Ah damn, thought it was the proper ride height... now feels like I'm using RST again xD

 

Rewrite the math channel so that it looks up the setup sheet and not the "constant"

Problem solved

I've written about this whole setup sheet deal before.

Sent from my SM-G975W using Tapatalk

 

Kunos right..? Because we can not do this, Aris has already mentioned ride heights are off the table.. See here:- https://www.assettocorsa.net/forum/...cated-acc-workspace.55103/page-2#post-1026774

 

I know I talk about it too in my previous answer, and I do it, but my point is:
- it's advanced MoteC use,
- it's no longer "ok lets just read the values" as you need to make inputs on the values you changed in the setup and it is still source of mistakes,
- you'll enter the static ride height in the setup sheet but you still have to enter the static suspension position that is different per wheelrate.

I wanted to warn people that it's not because you find "ride height" in a workbook, that:
1) the value is correct,
2) it wouldn't need to adjust values here and there everytime you do a setup change on the ride height and/or wheelrates or look at another car telemetry.

So problem is solvable but it shifts to something else to handle anyway.

 

The motec setup sheet, not the Kunos.

Stop expecting the company who gives you the cars to give you anything .

For that part they got this bang on lmao.

Sent from my SM-G975W using Tapatalk

 

@Borbor - Gotcha man, excel "Motec" setup sheet under tools.. Nice one

 

If it was as easy as Nils' math channel, we would've implemented this in RST long time ago already.
His method is a good start but his formula is missing some vital data that's hard to come by and it's cumbersome to use if you don't use the Motec setup sheet, as @Borbor already pointed out.
We're working on a more accurate solution for our app but there's still lots of testing to be done.

 

Coming from other sims I'm missing some base signals. Do understand that not every signal can be provided but would appreciate if we could get the following signals in addition:

- fuel consumption [l/min]
- engine map currently used
- disc brake wear (At least when arriving in pits:, although wear =f(t) would be preferable)

Furthermore it would be helpful if:
A) driver name and at least name of used setup will be added. Values of setup would be preferred
B) have an option which allows to configure that one file per outing will be generated. Sometimes different number of laps is being done and ACC splits them weird into files

 

Just keep in mind that accuracy in statistics/ Histogramms very rarely increases with a decreasing database size?

 

Some hope. Please see Aris response to these requests here:- https://www.assettocorsa.net/forum/...cated-acc-workspace.55103/page-2#post-1026774

Brake wear was not implemented at the time however it would be interesting to see his response now.. Maybe if you pester him it could be possible..

 

Can they monitor brake wear in real time in real life? I guess one could measure the distance the brake pistons move out over time

 

No but as already suggested as we are lonely sim racers and not a whole team looking at everything, some stuff like tyre wear, break wear, track temp, report on the tyre sets used in the race, etc... could be fed in telemetry as constant when going to the pits (iRacing is indicating tyre wear in the pits e.g.)