GT7 is compatible with motion rig ?

[Stoobert]

I absolutely love following this thread! Is this being discussed more frequently somewhere? It seems to have slowed down from some of the early posters

Not that I am aware of. I think a few of the interested people are now satisfied that there is data presentable on a phone / rig / wheel display, a few more are still interested in the unsolved fields, and people like myself who love to push what we can do with the data.

 

[tarnheld]

Not that I am aware of. I think a few of the interested people are now satisfied that there is data presentable on a phone / rig / wheel display, a few more are still interested in the unsolved fields, and people like myself who love to push what we can do with the data.

Solving the timing riddle is also key to get to something like g-forces. You have to have an accurate timing to actually tackle these. Since acceleration is veclocity change over time, there is no point to calculate these without knowing what time elapsed between packets or without adressing the velocity discrepancies. So you are doing a great job here.

 

[DRIFT4EVA]

I am simply an "average Joe" I have nothing to do with coding, it is all completely over my head. I climb onto my GT Omega Art rig, with my G29, fire up GT7 and drive.

You are the unsung heroes. Cracking codes, solving puzzles, and adding whole new dimensions to complex theories. This is absolutely phenomenal stuff. Thank you

Just a couple of observations I've made simply from reading each comment. I could be completely wrong so please be gentle 😂

1) My understanding is that this information is one way only, however through the various tools etc you are able to manipulate this data by changing values. Could this lead to an expanded use of button boxes?

2) remarks made about the GT series going to PC MAY be out of the box thinking. It may not be either. PD has big goals and big ambitions that a console can generally not handle. I put it to you. What if we go really far out of the box and consider maybe they could be trying to produce their own console?

3) could all of this data discovered be strictly for GT SOPHY?

Thank you again. I have now downloaded Sim Dashboard and this has already added to my idea of the GT experience

Bravo!

 

[tarnheld]

You are the unsung heroes.

1) My understanding is that this information is one way only, however through the various tools etc you are able to manipulate this data by changing values. Could this lead to an expanded use of button boxes?

AFAIK there is no way to input data into GT7 other than through the controllers/wheels, and the interface discussed here is really just output only. PD might primarily target motion rig vendors with this interface, we'll see...

3) could all of this data discovered be strictly for GT SOPHY?

I don't think they use this interface to as training input to Sophy -- it is lacking info about the other race cars and it's lacking the knowledge of the race surroundings like walls or the race track centerline. There is a preprint of the Sophy article where the authors go into detail of the AI interface and it seems like a massively beefed up version of the interface for telemetry. In the paper they said that they had access to all race cars, and they had range finders that tell them the distance to the nearest object ahead and sideways of the car and points on the race track centerline to reconstruct the track curvature. All of this is not available in the telemetry interface. But i guess it would be neccesary to give the AI a sense of it's surroundings.

 

[Nenkai]

Sophy uses a different service thats available in retail builds but only accessible with an server account flag.

This thing is as old as GT6, a decade old.

 

[Bornhall]

2) remarks made about the GT series going to PC MAY be out of the box thinking. It may not be either. PD has big goals and big ambitions that a console can generally not handle. I put it to you. What if we go really far out of the box and consider maybe they could be trying to produce their own console?

Slightly off-topic in this thread maybe, and you pose multiple questions, but here's my take on it:

a) GT going to PC is a big unknown, for sure. I think this is a possibility that is mainly for Sony to ponder. Possibly also after evaluating the competition as well as how well other games (God of War, Spider-Man, Horizon et al) sells on the PC side.

b) PD has historically never really been on anything other than console, and they for sure have big ambitions and goals. But I would stick my neck out and claim that what they have done has (for the majority of the time) been within what the console (at the time) could handle. With PD it's more of a "will they" or "when will they" deliver on their goals. Besides, hardware-wise, there's not that much of a difference between a console and a PC these days, bar the operating system and mid-range components (CPU and GPU) that are somewhat locked-in at the time of console release.

c) I'm pretty confident saying that PD, as a subsidiary of Sony, will not produce a console of their own.

Your other two points were answered, so I won't reiterate what tarnheld already said.

 

[poumpoum]

Hello !

I thought I had made some progress , but looks like I'm in a dead-end now. I focus on motion rig with roll/pitch/yaw/heave/sway/surge like @ashupp and used code from @Bornhall and @gt7coder for the packet structure, and of course based on @Nenkai work. I generated CSV from the decoded packet and tried to make some graphs to understand and figure values I needed. But I'm lost now.
What puzzles me is that for exemple I see positive and negative values for all velocity axes whereas I have always moved forward so I expected at least one of the three values to be always positive.
I was also unable to recreate the track aspect as some of you do, by plotting X,Y on a graph. This makes me think I have an issue with my code.... but values seem to move nicely without jumps.
Do you guys have the same behavior with the raw data ? Any idea of what I have missed ?

Packet format I used is this one, and seems accurate as values are moving smoothly withtou errors.
class GTDataPacket: def __init__(self, data): ## Format string that allows unpack to process the data bytestream: gt_format = '<ifffffffffffffffccccfffffffffffihhiiihhhhhhBBBcffffffffffffffffffffffffffffffffffffi' (self.magic, #int32 self.position_x, #single self.position_y, #single self.position_z, #single self.velocity_x, #single self.velocity_y, #single self.velocity_z, #single self.rotation_x, #single self.rotation_y, #single self.rotation_z, #single self.northorientation, #single self.angularvelocity_x, #single self.angularvelocity_y, #single self.angularvelocity_z, #single self.body_height, #single self.rpm, #single self.iv1, #char self.iv2, #char self.iv3, #char self.iv4, #char self.fuel_level, #single self.fuel_capacity, #single self.speed, #single self.boost, #single self.oil_pressure_bar, #single self.water_temperature, #single self.oil_temperature, #single self.tire_temp_FL, #single self.tire_temp_FR, #single self.tire_temp_RL, #single self.tire_temp_RR, #single self.pkt_id, #int32 self.current_lap, #int16 self.total_laps, #int16 self.best_lap_time, #int32 self.last_lap_time, #int32 self.day_progression_ms, #int32 self.pre_race_start_position, #int16 self.pre_race_num_cars, #int16 self.min_alert_rpm, #int16 self.max_alert_rpm, #int16 self.calculated_max_speed, #int16 self.flags, #int16 self.suggestedgear_gear, #byte self.throttle, #byte self.brake, #byte self.padding_byte1, #byte self.road_plane_x, #single self.road_plane_y, #single self.road_plane_z, #single self.road_plane_dist, #single self.tire_rps_FL, #single self.tire_rps_FR, #single self.tire_rps_RL, #single self.tire_rps_RR, #single self.tire_radius_FL, #single self.tire_radius_FR, #single self.tire_radius_RL, #single self.tire_radius_RR, #single self.susp_height_FL, #single self.susp_height_FR, #single self.susp_height_RL, #single self.susp_height_RR, #single self.unknown_single1, #byte self.unknown_single2, #byte self.unknown_single3, #byte self.unknown_single4, #byte self.unknown_single5, #byte self.unknown_single6, #byte self.unknown_single7, #byte self.unknown_single8, #byte self.clutch_pedal, #single self.clutch_engagement, #single self.rpm_clutch_gearbox, #single self.transmission_top_speed, #single self.gear_ratio1, #single self.gear_ratio2, #single self.gear_ratio3, #single self.gear_ratio4, #single self.gear_ratio5, #single self.gear_ratio6, #single self.gear_ratio7, #single self.gear_ratio8, #single self.car_code, #int32 ) = unpack(gt_format, data)

The full code is here just in case: https://github.com/vthinsel/GT7Proxy



View attachment 1182372
EDIT: I think I found the issue for the map: the Z axis is not what I used to play with other games such as PCars, but once axis are swapped, the map gets displayed fine. But I'm still puzzled about velocity axes behavior. Orientation looks almost fine (Y axis being used for yaw)

Would love to ear more about that cause it could lead me into buying actuators or not !

 

[vthinsel]

So get your bank account ready

I'm pretty happy with the current feelings. What is missing is the third axis with traction loss. With all tire metrics and speed I can imagine there is something smart to do. I also need to package it a bit better to include the pyhton proxy as part of the package.
Keep in mind this is XSim beta 3 (I didnt make the plugin for XSim 2), but version 3 is due soon. If I got it right, XSim is not the only platform that has GT7 support now, so you have no excuse to not have actuators yet .

 

[magnuus]

So I added some analysis data and visualization to my fork of gt7telemetry. After each lap a browser window opens with the latest comparison of two or more laps. Work in progress.

...

Can someone please make a guide to setup this one? I would love to try it out, but currently I am really struggling with the Salsa20 module. I have a lot to learn...

 

[CodeRedR51]

Sorry if this has been discussed as I'm not keeping tabs on this thread. But, anyone using sim dashboard that can tell me what the optimal tire temp range is? Where should I set the sliders? Thanks!

 

[Bornhall]

Can someone please make a guide to setup this one? I would love to try it out, but currently I am really struggling with the Salsa20 module. I have a lot to learn...

Can't see your install command in the screenshot, and I am by no means a Python expert, but most likely culprit is that you may have multiple Python installations/versions on your system. Meaning, the module may well be installed, but the pip (or pip3 more likely) command is not "in" the same installation as the python3 command. I know Python can be a bit fiddly with this, so you may have a bit of work on your hands to clean it up.

Also, take a peek at the first half or so here: https://realpython.com/lessons/why-cant-python-find-my-modules/

Disclaimer: I haven't really touched Windows in 15 years or so, so your mileage may vary, but on *nix and macOS conflicting installations is not uncommon. You may have better luck getting help from Windows Pythonistas on this.

 

[jajaballard]

Hello, like the way this progesses.
Would it be possible with one of the provided solutoions to collect and store the data in a format that is fitting for "MOTEC i2 Data Analysis" tool, like it is working in ACC (PC) ? https://www.motec.com.au/i2/i2downloads/

This would be absolutly great!

 

[Bornhall]

Would it be possible with one of the provided solutoions to collect and store the data in a format that is fitting for "MOTEC i2 Data Analysis" tool

Depending on what data you're after and how the i2 Data format is defined, yes, very likely.

It would however require someone to have knowledge of the format itself (I have no idea if it is an open format or proprietary/licensed) to output something that can be used. Myself, I have neither the knowledge nor the time at the moment.

But the short answer is; YES

The slightly longer answer is; WITH TIME AND EFFORT, YES

 

[snimat]

Can someone please make a guide to setup this one? I would love to try it out, but currently I am really struggling with the Salsa20 module. I have a lot to learn...

View attachment 1183982

You have to install the dependencies, one of those is salsa20. I have written something about it in the README.

How to run​

1. pip3 install -r requirements.txt
   1. to install Python dependencies (once)
2. python3 gt7telemetry.py <CONSOLE IP ADDRESS>

 

[snimat]

I have now updated my fork of Bornhalls script to a stand-alone live dashboard: https://github.com/snipem/gt7dashboard

Features​

...

• Speed/Distance Graph for Last Lap, Best Lap and Median Lap.
  • Median Lap is calculated by the median of all recent laps
• Throttle/Distance Graph
• Braking/Distance Graph
• Coasting/Distance Graph
• Race Line Graph
• Table of Speed Peaks and Valleys. Compared between best and last lap
• Additional data for tuning such as Max Speed and Min Body Height
• List off all recent laps with additional metrics, measured in percentage * 1000 for better visiuals
• Ability to Save current laps and reset all laps
• Additional "Race view" with only the laps

The dashboard is up to be changed as soon as I learn new stuff about race telemetry and data analysis.

 

[temp]

@snimat This looks fantastic. Thank you for sharing it. However, the dashboard remains empty, even though I'm able to get the data through @Bornhall script.

Perhaps there are env vars that I'm missing but this is what I'm getting in the shell.

2022-08-17 20:04:37,104 Starting Bokeh server version 2.4.3 (running on Tornado 6.2) 2022-08-17 20:04:37,106 User authentication hooks NOT provided (default user enabled) 2022-08-17 20:04:37,107 Bokeh app running at: http://localhost:5006/gt7dashboard 2022-08-17 20:04:37,107 Starting Bokeh server with process id: 26585 /opt/homebrew/lib/python3.9/site-packages/bokeh/models/plots.py:815: UserWarning: You are attempting to set `plot.legend.click_policy` on a plot that has zero legends added, this will have no effect. Before legend properties can be set, you must add a Legend explicitly, or call a glyph method with a legend parameter set. warnings.warn(_LEGEND_EMPTY_WARNING % attr) 2022-08-17 20:04:45,860 W-1005 (FIXED_SIZING_MODE): 'fixed' sizing mode requires width and height to be set: Button(id='1616', ...) 2022-08-17 20:04:45,860 W-1005 (FIXED_SIZING_MODE): 'fixed' sizing mode requires width and height to be set: Button(id='1617', ...) 2022-08-17 20:04:45,860 W-1005 (FIXED_SIZING_MODE): 'fixed' sizing mode requires width and height to be set: Column(id='1632', ...) 2022-08-17 20:04:45,860 W-1005 (FIXED_SIZING_MODE): 'fixed' sizing mode requires width and height to be set: Row(id='1630', ...) 2022-08-17 20:04:45,860 W-1005 (FIXED_SIZING_MODE): 'fixed' sizing mode requires width and height to be set: Row(id='1631', ...) 2022-08-17 20:04:45,860 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "speed" [renderer: GlyphRenderer(id='1262', ...)] 2022-08-17 20:04:45,860 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "throttle" [renderer: GlyphRenderer(id='1376', ...)] 2022-08-17 20:04:45,860 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "brake" [renderer: GlyphRenderer(id='1299', ...)] 2022-08-17 20:04:45,860 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "raceline_z", key "y" value "raceline_x" [renderer: GlyphRenderer(id='1584', ...)] 2022-08-17 20:04:45,860 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "throttle" [renderer: GlyphRenderer(id='1280', ...)] 2022-08-17 20:04:45,860 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "speed" [renderer: GlyphRenderer(id='1357', ...)] 2022-08-17 20:04:45,860 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "coast" [renderer: GlyphRenderer(id='1416', ...)] 2022-08-17 20:04:45,860 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "brake" [renderer: GlyphRenderer(id='1501', ...)] 2022-08-17 20:04:45,861 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "coast" [renderer: GlyphRenderer(id='1523', ...)] 2022-08-17 20:04:45,861 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "speed" [renderer: GlyphRenderer(id='1458', ...)] 2022-08-17 20:04:45,861 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "coast" [renderer: GlyphRenderer(id='1318', ...)] 2022-08-17 20:04:45,861 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "raceline_z", key "y" value "raceline_x" [renderer: GlyphRenderer(id='1601', ...)] 2022-08-17 20:04:45,861 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "throttle" [renderer: GlyphRenderer(id='1479', ...)] 2022-08-17 20:04:45,861 E-1001 (BAD_COLUMN_NAME): Glyph refers to nonexistent column name. This could either be due to a misspelling or typo, or due to an expected column being missing. : key "x" value "distance", key "y" value "brake" [renderer: GlyphRenderer(id='1396', ...)] 2022-08-17 20:04:46,003 WebSocket connection opened 2022-08-17 20:04:46,003 ServerConnection created

Edit: Nevermind. It actually works for me. The chart updates after every lap. For some reason, I was expecting the chart to update in real time which is not how it works.

 

[F1Bernardo]

For those of us with iOS devices that were desperately searching for dash apps that support GT (Sport and 7), DashPanel has just released a version with it. It's cross platform and works on other games as well... and the dev is very cool (not me, not affiliated by the way)

Check it out:

https://apps.apple.com/br/app/dashpanel/id1441894380

I recall @Nuschel01 asking about this, so ... tagging you

 

[Nuschel01]

Thanks @F1Bernardo this was the App I was hoping to see support it actually

 

[Stoobert]

I have now updated my fork of Bornhalls script to a stand-alone live dashboard: https://github.com/snipem/gt7dashboard

• Speed/Distance Graph for Last Lap, Best Lap and Median Lap.
  • Median Lap is calculated by the median of all recent laps
• Throttle/Distance Graph
• Braking/Distance Graph
• Coasting/Distance Graph
• Race Line Graph
• Table of Speed Peaks and Valleys. Compared between best and last lap
• Additional data for tuning such as Max Speed and Min Body Height
• List off all recent laps with additional metrics, measured in percentage * 1000 for better visiuals
• Ability to Save current laps and reset all laps
• Additional "Race view" with only the laps

The dashboard is up to be changed as soon as I learn new stuff about race telemetry and data analysis.

This certainly looks a lot easier than Plotly / Dash that I have been using recently.

 

[Skinny McLean]

Hello, like the way this progesses.
Would it be possible with one of the provided solutoions to collect and store the data in a format that is fitting for "MOTEC i2 Data Analysis" tool, like it is working in ACC (PC) ? https://www.motec.com.au/i2/i2downloads/

This would be absolutly great!

Yes and no. Of course it's possible to log and export the data (provided you know the data format,) but we simply don't have access to as many channels as in ACC - e.g. not even the steering angle is exposed by this interface, so such a tool is going to be more of a toy/curiosity than a proper setup/driver development aid. Also, the sample rate is quite low (60 Hz.)

That being said, I've adapted the telemetry tool I made for Raceroom (called R2M) to work with GTS and GT7 (I don't have a PS3, so can't test it on GT6.) I hope to finish it when I have more spare time (and the weather cools substantially!) As it stands, it needs a little fine-tuning (e.g. what channels are useful) and a GUI.

But, again, with the lack of channels we're used to have in the other sims, I'm not sure this is going to be much of a help to anybody at all.

To give an example, I logged a couple of laps at Trial Mountain in a BMW sedan (the M30, IIRC,) and took some screenshots in Motec i2 (it's smart enough to draw the track based on the G forces):

Spoiler: Graph sheet

Spoiler: Engine RPM scatter sheet

Spoiler: Suspension Histograms sheet

Spoiler: Suspension sheet

Spoiler: Track Report sheet

Edit: I used a pad for these laps.

 

[Bornhall]

Yes and no. Of course it's possible to log and export the data (provided you know the data format,) but we simply don't have access to as many channels as in ACC

Right, completely forgot about the lack of channels when I replied, and as you say the steering angle is completely missing.

To give an example, I logged a couple of laps at Trial Mountain in a BMW sedan (the M30, IIRC,) and took some screenshots in Motec i2 (it's smart enough to draw the track based on the G forces):

About that, you say it can draw the track "based on the G forces" – how do you calculate that? AFAIK there is no channel for the G forces, or have I missed something the last week (I have been a bit out of the loop, to be fair)?

Overall, good job!

 

[tarnheld]

Would it be possible with one of the provided solutoions to collect and store the data in a format that is fitting for "MOTEC i2 Data Analysis"

There is some python code available on github to read and write MoTeC i2 logs:

GitHub - stevendaniluk/MotecLogGenerator: For generating MoTeC .ld files from external log sources

For generating MoTeC .ld files from external log sources - GitHub - stevendaniluk/MotecLogGenerator: For generating MoTeC .ld files from external log sources

github.com

With some work, this could be adapted to a GT telemetry to MoTeC log converter.
But as @Skinny McLean said, there is some crucial data missing to make it useable in general.

Motec i2 (it's smart enough to draw the track based on the G forces)

I would also be interested in the G forces, did you calculate them based on the GT7 telemetry or did MoTeC i2 calculated them based on the logs?

 

[Stoobert]

I did some experimentation with G-Forces a few weeks back just in the "forward" direction and the numbers came out pretty reasonable... Until you got tapped by another car at speeds as low as 10kph, which generated peak numbers in excess of 100g. But I was doing this rather crudely rather than summing the vectors for each direction to produce a proper value.

 

[nokazito]

I did some experimentation with G-Forces a few weeks back just in the "forward" direction and the numbers came out pretty reasonable... Until you got tapped by another car at speeds as low as 10kph, which generated peak numbers in excess of 100g. But I was doing this rather crudely rather than summing the vectors for each direction to produce a proper value.

curious about that, I noticed quite a similar pattern when gear-shifting and overreving, the numbers go nuts :-)=

 

[vthinsel]

G forces calculation requires some good math knowledge as there are some challenges: acceleration vector (known heave/sway/surge) can be calculated from local velocity. Unfortunately, the velocity available in the UDP telemetry is world velocity (explaining negative and positive values when moving at constant speed on a speed ring), not local. So it needs to be converted (using the rotation values), then projected against the axis. Once we have the local velocity vector, it is easy to compute the acceleration which is a variation of the velocity over time.
I'm currently working on it with some other guys in order to get accurate motion. I wish I had listened to my math teachers a bit more ....

 

[MCrisostomo]

I had test the game with Sim Dashboard app yesterday. You guys are awesome and i could see some informations on my phone screen that some times ago was possible only in PC simulators or some console games that exported UDP data. Thank you all guys envolved.

 

[Skinny McLean]

About that, you say it can draw the track "based on the G forces" – how do you calculate that?

I would also be interested in the G forces

The acceleration vector is the time derivative of the velocity vector.

Both vectors can be transformed from global to local space by multiplying with the rotation matrix obtained from the orientation quaternion found in the telemetry data. Divide the local acceleration vector by 9.8 to express it in Gs instead of m/s/s.

With trigonometry, the Euler angles (aka. pitch, yaw and roll) can also be found from the rotation matrix.

So, time to fetch your favorite linear algebra text-books, gentlemen!

 

[tarnheld]

the orientation quaternion found in the telemetry data

Ahh, so at 0x1C there are actually 4 floats, and 0x28 is belonging to those and they are quaternion coefficients? Then the half-angle interpretation of the first three makes sense all of a sudden! So the first three are the imaginary part and the last one is the real part?
Thanks for the hint! Will update the table when i have confirmed the coefficients and their relation to the global coordinate system.

The acceleration vector is the time derivative of the velocity vector.

The issue here is the time delta -- if you use the time progression in milliseconds you cannot use races with time progression factor that is unequal to one, and with time progression 0 you won't get any time progression. If you use external time measurements (measure time between arrival of packets) you will get inaccuracies. I came up with a timing solution based on the packet numbers and that the timing between them is almost-always-but-not-quite fixed to 1/60s. But it is quite involved and requires you to not miss some special packets. It doesn't work in some cases like standing starts. @Stoobert also found some velocity discrepancies with live vs. replays in the data so the time retrieval is sketchy and thus also deriving things from it like acceleration.

How do you get the time delta to differentiate from velocity to acceleration?

 

[Nenkai]

For those of us with iOS devices that were desperately searching for dash apps that support GT (Sport and 7), DashPanel has just released a version with it. It's cross platform and works on other games as well... and the dev is very cool (not me, not affiliated by the way)

Check it out:

https://apps.apple.com/br/app/dashpanel/id1441894380

I recall @Nuschel01 asking about this, so ... tagging you

Considering the effort that went in and the licenses between each repositories, I was surprised to find out that they sell access to certain fields and also a total lack of credits.
Make yourselves a favor and use SIM Dashboard instead.

 

[Nuschel01]

Make yourselves a favor and use SIM Dashboard instead.

Not available on iOS sadly.