Correct. For all intents and purposes you can think of the ethernet there being just transparent transition to more reliable connection.
1 Like
Mika, while you are here, was always wondering what was a rationale for making wheel hub mount non standard bolt pattern instead of traditional 70 or 50mm one.
That effectively rendered all shaft extensions and quick releases incompatible with SC2 base until some 3rd party adapters were developed.
What I meant was âpowered onâ, the startup if you will.
And to be precise, I was wondering what lock-in you were discussing that upcoming changes would introduce. Itâs very confusing, to me at least.
The first point was a lock-in, and I can see how people owning pedals that can only connect to this accessory port would be affected - but I donât understand where a new lock-in happens.
The wireless protocol likewise WAS a form of lock-in.
This is not a lock-in, what is anyone being locked into by connecting the wheelbase to Link and then PC?
Also, Iâm not sure why this is a âping-pongâ conversation to you, I merely asked you where exactly you see the lock-in. To be fair, I donât know what exactly your opinion is in this, so I canât even tell you whether I agree or disagree with it, but I will leave it at that.
The concept was material cost optimization- the conical shaft clamp solution which tightens against the shaft and pulges outside towards the hub was the elegant design idea that we wanted to keep, so the wheel base side QR part was designed to fit that without having unneeded excess materials.
We are talking 3 holes in slightly different places, not additional adapter supplied by GD.
The wedge shape was designed with some actual design loads analysis and starting point was that we wanted to use the conical shaft clamp this way, which gave us an outer diameter. The the angles on the QR were optimized to work with the projected loads with minimal deflections. That in combination with material optimization left good places for the three holes pretty much exactly as they are.
We could have used larger diameter for the hub, but that would be extra cost, extra shipping weight, extra CO2. Or we could have used a smaller / custom shaft clamp, with likely extra cost and some months of time delay for the whole project.
The wheel base is a plug&play unit, we donât exactly have to support 3rd party mods that would be quite easily made by DIY scene or other people in short time. And that consideration was true, adapters were brought to market pretty soon by 3rd parties.
Got it, thanks for explanation Mika.
Not that I agree with the motivation as a customer I might have different perspective as you essentially unloaded that extra cost on customer and 3rd parties.
I think the way we did it unloaded the cost to those customers who actually want to customize. Which is really a small minority.
You canât really say that itâs a âminorityâ considering how many use shaft extensions and prefer 3rd party QRs. Again, another example of creating a problem (locking into vendor solution) by not following universally adopted standards and protocols.
then you can say that for all other wheel base manufacturers as well.
You didnât answer my previous question about the vendor lock-in?
Like Logitech and Thrustmaster? Yes, they have their toy wheels linked to their ecosystem, always had.
SC2 is a successor of SC1 and OSW, with big enough base of customers already using standard wheel rims with standard extension shafts and QR solution utilizing industry standard bolt patterns.
Sorry, we have tried to save cost on material is not good enough excuse for the customer when he cannot fit his standard wheel extension or QR directly.
I had to pay ~$80 with shipping for Ascher plate and wait a month because it was sold out and backordered, must be that âminorityâ users cleaning the stock.
Now BT, why not standard BT protocol that could have worked with any system, any wheelbase, anything really. Why it has to be locked to SC2?
Link dongle is afterthought ugly kludge really, solution to the problem that could have been avoided in the first place, and itâs not free either.
This is classical definition of Vendor Lock-In forcing into proprietary solution by avoiding already well established industry wide standards
In economics, vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products, unable to use another vendor without substantial switching costs.
The use of open standards and alternative options makes systems tolerant of change, so that decisions can be postponed until more information is available or unforeseen events are addressed. Vendor lock-in does the opposite: it makes it difficult to move from one solution to another.
You didnât answer the specific question.
Read response above, it should have your answer. And if not, read again.
Please answer this question @Andrew_WOT
How does the Simucube Link with the ActivePedal actually lock you in Simucube as the vendor of any of your other hardware?
And how does for example a Fanatec sequental shifter, that is connected to the PC with Fanatecâs USB converter, lock user into using Fanatec as the vendor for any other peripherals?
etcâŚ
Fanatec was always a walled garden, including their shifter that requires that stupid bulky always losing FW converter. If this is what you are using as an open standard example, you have picked the wrong role model.
1 Like
I chose another manufacturer which is rather popular. I can switch to some other example if you wish. But you still didnât answer the question.
I donât understand your out of context question. I donât have AP pedals, never will, why you even brings them into conversation.
What I see that you push another home made standard and forcing all peripheral from you (including wheelbase and wheels) using it, instead of standard USB protocol compatible with anything and everything.
And by judging by the history you are not good at sticking with your own standards long term, abandoning them for the next new and shiny thing.
Because the same architecture is going to be on our next wheel base, which is what the thread is about. And this exact same architecture is something that you claim is vendor lock-in, but you donât seem to be able to come up with practical answer on how.
Standard USB is available, only the actual devices are connected with Ethernet.
Are you saying that you would be happy with something like this?
1 Like
At least from my perspective, for what it is worth, having Ethernet communication (a standard also used in many industrial areas) from the devices like wheels, pedals, even button boxes and steering wheels, back to a network switch and onto Ethernet to USB-C HID device, is actually a wonderful way to maximise bandwidth, link devices and have the benefit of reduced EMI issues when dealing with dd bases, active pedals and also motion equipment.
If the aim is to separate the HID from each and every individual device now have a âCentralâ HID, communicating via USB-C to the PC, and via Ethernet to downstream devices, or even Ethernet switch, it is a very good technology. I had similar ideas already some years ago, it is a natural and logical progression and helping to reduce EMI-related issues.
As we have experienced over many years, grounding is a big issue in most setups, and ground-loop issues are prevalent everywhere, especially when no standards are followed. So using Ethernet twisted pair carriers will significantly help with signal integrity.
One thing to note, in industrial controls, we use Ethernet networks to run as operation and control-room layers in a few instances - often, we will have UI to process devices on one layer, and then process control to IO devices on a seperate set of switches - standard Ethernet TCP/IP on former, proprietary protocol on the latter.
But sometimes, due to cost-reasons and smaller installations, we can combine both UI/Multicast/Unicast, as well as proprietary IO communications on one layer. So I can see a time where someone will make an open HID /USB-C device, which has this basic Ethernet interface, and all peripherals will connect via a simple dumb network switch, back to open HID.
You will even be able to have Simucube HID connect to letâs say, a 24-port switch, and then an open HID also connect to it, with a multitude of vendors peripherals connected to the same switch, for example, SC3, AP, as well as a shifter from someone else. So in a way, it will become the de facto distribution /connection standard in sim world after 5 years or so, imho.
Just my simplistic pov, anyway.
2 Likes
With all future talk. Iâm ready for the SC3!