Is there any plan to implement telemetry-based FFB alongside direct input FFB?
VNM implemented this in their software and it is awesome. It is likely that more and more manufacturers will introduce this.
We have that on idea list. However we need to do some research on how that could be added to the Simucube 2. We would like to benefit from the software API that is used on our ActivePedal and Simucube link products. However those are not built on the same limitations that are there on the Simucube 2 microcontroller, and some amount optimizations and other tricks will be required.
There is no timetable nor promises that we will get that done.
Any updates on this?
From a user perspective it sounds like great feature and doesn’t require any additional effort and cost for game developers(most sims already provide the telemetry) contrary to Trueforce or Full Force.
I recently watched another RaceBeyondMatter video on the topic and he still loves it:
Also apparently VRS is testing it for their wheelbases(even on the old one that has separate control box connected to the small Mige motor) : https://m.youtube.com/watch?v=nEIL4-Mv6Ug&t=44m32s
Just watched Simucube 3 release event and there was some talk it will have this feature, but I don’t know if it’ll be via available Simucube’s new open API or just use game’s existing telemetry like it’s in VNM ?
Also , the most important question for me - will it be implemented / work for SC2 too?
I am also anxious to know if telemetry will be available on the SC 2, my SC 2 is only a few years old and works very well, I do not want and can not change base.
If game would be able to do it, why wouldn’t they put it into their normal FFB signals.
but it will be both - our API does have possibility for e.g. iRacing LFE type signals, and we do additional effects based on their telemetry.
We have answered this several times before and also in Discord. Here’s my latest reply from today:
Simucube 2 is a completely different product architecture, developed in 2017-2019. Since then, we changed the architecture in both hardware (larger and faster microcontrollers), and in software, for ActivePedal and for Simucube 3, with none of the limitations that were on the Simucube 2 platform. We would very much like to import the work that enables telemetry reception on to the Simucube 2 and use exactly the same code base as-is. However, we don’t yet know if those software components fit into the Simucube 2 microcontroller’s memory, and if they fit, is there enough performance on it for operation.
After we have this information, we will evaluate how we proceed for the Simucube 2. But we cannot say or promise anything as none of this work has been done yet. Certainly no timetables can be given as of now
Additionally, there is a limitation on SC2 where the two microcontrols (USB side and the servo drive) communicate at a certain rate, that is much slower than the rate required for good LFE signals. So much more additional development and changes would be needed for SC2 to support that type of telemetry signaling.
Thanks for the update. I don’t follow Discord channel and couldn’t find the answer on this forum ( except your response on February here) .
Regarding the telemetry based FFB - correct me if I’m wrong, but my understanding was that things like Trueforce is just another layer of (certain frequency) signals basically can be added (and adjusted) for immersion and not necessarily what you would actually feel based on pure physics engine output . Essentially like cheap and simplified way of having butt kicker/bass shakers on a rig. I actually recently was thinking of getting them as people keep saying it’s really great for immersion , especially if you have couple of shakers and configured it correctly .
Anyway, I was surprised VNM managed to implement similar feature in their bases without the need of an API like Trueforce and just making use of the telemetry that’s already available in games. Also recently heard that Accuforce supposedly has it since long time, which is even more surprising for me, given it’s an old and not a high end wheelbase(hybrid stepper motor etc.) . But if Logitech already had Trueforce even in it’s cheap G29 wheels ( although, considered more as a gimmik, due to low speed and torque), then it’s not that surprising.
Regarding implementing it for SC2 - that’s a bummer. I thought the wheelbase CPU should fast enough , but didn’t think of memory and bandwidth limitations etc. Hopefully, eventually it will be implemented, but I understand it’s not a priority.
Thank you for your reply @Mika
I am also disappointed by this response.
I think that we ourselves are not ready to see the arrival of ffb by telemetry on SC2, moreover my SC 2 dates from 2021 there is no question of me changing it now, I will wait for the next evolution perhaps an SC 4 …
So you are disappointed that we will look into it? There is really no way for us to retrospectively design hardware back in 2018-2019. Things have moved on since then.
If it turns out that the same code base won’t work, then we will look into alternative (more lightweight) solution.
But we won’t have the business case to do another major rewrite of the Simucube 2 codebase.
Based on GD track record it’s quite possible as most important SC2 features eventually were added for SC1 owners. Also, remember e.g. how much RAM Windows 3.11 or even 95 needed ? Or how good Quake 3 looked in 1999 or then Crysis 1 with GPUs with 256MB VRAM? With proper optimisation you can achieve surprisingly good results, but it takes time. Hopefully it won’t be needed for SC2 or at least to much lesser extent.
But based on some design decisions that we see in SC3 (e.g. Fanatec like approach of locking in the expensive ecosystem - if you want wireless wheels of course), I’m not sure about that.
Telemetry based FFB is one of the main selling points as well, so wouldn’t be surprised if we never see it in SC2, personally not sure if it’s that critical for mainstream sims with even basic tactile setup.
Business is business though, and we’ve paid for product with the feature set as it was at the time of the release, manufacturer has no obligations to back port new functionality into older product.
That’s unfortunate but not unexpected judging by company’s track record employing proprietary standards just to abandon them in the next product iteration.
You’re right @Andrew_WOT
If I’m disappointed, it’s simply that I was hoping to see an evolution of the SC2 with the FFB telemetry, indeed we paid for the SC2 for what it was and I’m still just as satisfied with it, then there was a nice evolution of the TUNER software as well as the implementation of steering linearity, which is very good for certain vehicles. In the end, it’s not so bad if we never see an update for telemetry.
Ultimately it will be most probably a business decision made by management , whether it will be implemented for SC2. I’ve worked in a large company and had a few good ideas, especially at the beginning , but often hit a wall because management didn’t see enough business benefits vs time needed to implement it (I’m just an average software engineer).
Unfortunately that’s just how most companies work , if they don’t see much benefit for e.g. Q4 revenues then it won’t be a priority for sure. Welcome to the Capitalism
It’s like with new technologies like G-sync . First it required a hardware module form NVidia and you had to pay premium etc., then it turned out it’s possible to have open source implementations like FreeSync at much lower cost. It’s not always working as good and reliably(monitors don’t go through Nvidia certification etc.). It seems to me that things like the SC3 Link module follows similar philosophy.
Same with FSR4 etc. AMD could implement it for older architectures , but it would take some time. Let alone there are cases, were vendors artificially lock out old customers.
I think we saw new features added to SC2 only because it was the only active Simucube wheelbase product and features were introduced to attract new customers, existing one just automatically benefited from that.
Some stuff that was ported to SC1 perhaps only happened because good Samaritan Mika got bored and did it in his spare time.