MoTeC Telemetry in AMS2

First of all you have to know that the SharedMemory API provides only one temperature.
UDP API provides all three.
Further only one application can receive the UDP packets on one system.
That means if you start two tools on one system the same time only one of them receives the UDP data.
If you mean SecondMonitor, it uses mainly SharedMemory, but for tire Temps it uses additionally UDP.
But if RST is already running the same time, then SecondMonitor is maybe not receiving the UDP packets.
If you need both tools the same time, then RST have to run on another system in the same network.

 

Look at this, donate-ware and very good

Telemetry Application Version 10 for AMS2

 

Well... It is hard to understand what kind of trouble you all have.
Here I run AMS2 with CrewChief, SimHub, RST, SecondMonitor, all at a time or even all together whitout any issue.

 

If you run RST and SecondMonitor the same time on the same system, do you really get inner, mid and outer Tire Temps in SecondMonitor and all Data in RST?
IMO that can not be possible, because under Windows only one application can receive data on a UDP port.
If two applications listen to the same UDP port, only one can receive the data.

 

I don't understand what your problem is with inner, mid, outer tire temp.
With RST, you don't get the temperature itself but you get temp. difference caused by camber and pressure. With these two parameters you can setup your camber and pressure.
And of course, don't think that you can solve both with one change of setup. If you change camber, it will have an effect on middle temp / pressure, so you have to do step after step

 

Yes, I do have IMO temps on all apps at the same time even though SimHub shows much cold M tyre temp than the others apps.

I really don't know how UDP works, I must admit.
Fact is ALL telemetry data are full received running those apps at the same time in just one pc.
If data come through UDP, Shared Memory or something else it doesn't matter to me since they are available for analysis.

 

I don't have a problem with interpreting the data. But that was not the question IMO.
I only want to say, that it is not possible to receive UDP data on the same Windows system on the same UDP port at the same time with multiple applications.
This is the cause why tools like SimHub or Telemetry Application (mentioned some posts above) have a feature to forward the UDP data to another UDP port.
SimHub uses default SharedMemory, but in the newer version UDP is supported, too.
And there is the same advice about multiple applications and UDP:


With SharedMemory this is no problem. It is accessable by multiple application the same time.

 

Could you please explain why you need more than one telemtry app?
I recommend to use one and work with that. You won't be faster the more telemetry apps you use
This is only a mass of data waste. Telemetry only shows values of sensors it doesn't tell you how you will be faster or which setup change was good or not. This is your interpretation of the data. At last every telemetry app shows the same.

 

Because not every tool is used for car setup work.
Crew Chief is an audio spotter.
SimHub supports web-based Dashes, in game Overlays, Buttkicker, custom FFB motors, custom monitors, Arduino boards for controlling LEDs for example, etc.
RST has the focus on setup work.
Telemetry has the focus improving your driving skills.
SecondMonitor has a great Overview what happens during Race.
All these tools work with the UDP and/or SharedMemory API.
And then there are also tools for controlling motion rigs.

 

Oh my goodness!
That's too much for me or I'm too old
I use my experience, so I don't need all these tools and I'm fast enough.

 

Or you can be a lot faster and don't know.

 

@viper4r i'm using Second screen only, i didn't know about the UDP...

So i activated UDP in frequency 1, and my game is very slow now, unplayable... any help?

I'm gonna try other channels

 

Thx @viper4r, worked on frequency 9 with a little bit of stuttering, but it's manageable for practicing.

 

I think the frequeny setting is:
UDP off
UDP 1 60/sec (16ms)
UDP 2 50/sec (20ms)
UDP 3 40/sec (25ms)
UDP 4 30/sec (32ms)
UDP 5 20/sec (50ms)
UDP 6 15/sec (66ms)
UDP 7 10/sec (100ms)
UDP 8 05/sec (200ms)
UDP 9 01/sec (1000ms)

1 means 60 UDP packets per second
9 means 1 UDP packet per second

I have it currently on 5.

I am wondering why your gaming system has a problem with a higher setting, what are your system specs, CPU, GPU?

The most problems with higher frequency are related to wifi routers/repeaters, because they cannot handle the high broadcast traffic load. I have the same problem.

 

i'm using cable connection...

My system specs are:

i5 4690
16gb DDR3 1666mhz
GTX 970 4gb
SSD 480gb

I can run rFactor2 with medium graphics and 30 AI cars without stuttering.

Next time i will try with resource monitor open, to analyse CPU/GPU usage.

 

@viper4r it's working fine now in frequency 6, maybe was an external app inteference. thx for your help.

 

A lot of home routers will see the UDP broadcast traffic as noise and send resets back to the host sending the broadcast packets. Then your PC has to handle the resets and still try to continue to send more packets which can cause your game to stutter depending on how the PC is able to cope with the resets from the router.

The ways to work around this is by lowering the frequency of the UDP and/or buying a higher grade router.

 

That's incorrect. I wrote my own telemetry app for PCars2 that used UDP but needed to play nicely with another app that also used UDP. It was written in Qt but for the windows platform. Opening the socket with:

socket->bind(5606,QAbstractSocket::ShareAddress)

Allows you to receive UDP data on the socket even if another application is connected to the same port. If the other application is not written to use the share address feature then it needs to be started first, but if the apps use it then they can be started in any order.

 

Ok, thanks for the Info. Then it depends on the application and the dev has to consider this use case, because sharing the port is probably not default.
In my case SecondMonitor and RST were not working together for the UDP part.
SecondMonitor uses SharedMemory, but for the inner,outer, mid tire temps UDP.
If I started RST and SecondMonitor the same time, SecondMonitor did not show the tire temps for example.

EDIT:
I tested RST and SecondMonitor and further Telemetry (from Iko Rein) together again.
All use UDP and all receive the data on the same system and the same UDP port 5606.

For RST and SecondMonitor I am 100% sure, that there was the described problem in the past. Maybe they changed the socket handling in an update like you described @NuScorpii.

 

deleted