Guillemot Force Feedback Wheel Problems ?

I have recently purchased one of the new Guillemot Ferrari Force Feedback racing wheels. I first noticed playing Rally Championship 2000 that I had much less control in a straight line than with my previous wheels, and that I tended to zig-zag on straight road. I found this to be the same in other driving games such as TOCA2. I used DXTweak to remove the deadzone (which I thought was causing the problem) however this had no effect. I have done some testing using DXTweak and other games and have found that the steering problem seems to be caused by a lag between the input (my movement) to the output (down the USB port) of the steering wheel, i.e. as you turn left or right from any stationary wheel position it takes time for this to be registered as movement, in fact it is possible to move the wheel very slowly and for it to take ages for the movement to be registered. This is obviously not good in a racing game, as it prevents the fine control necessary to get fast times. This does not appear to be a problem with the guillemot driver - as it does exactly the same using the thrustmaster force gt driver. The problem appears to be introduced by the wheel electronics which are probably trying to smooth the output from the potentiometer. Is anyone else experiencing this problem?

Wow, look at all those words, this guy must be some sort of clever***! My Ferrari wheel has done absolutely nothing wrong since I bought it over a week ago now. Andi. PS Yes it's me Tim.

Tim, I mentioned this the other day, have you tried the Iforce reference drivers? The standard TM drivers are not brilliant. A comment from elsewhere in this news group: I've been using the reference drivers with my TM Force GT since TOCA2. As you know, Santa has my Guillemot wheel so I can't comment about it yet. From the above, I would be very upset to lose split axis. Andi. PS Sorry about the sarcastic post just now. I'd be very interested in any solution you come up with. Gave up on the P3 733 can't get hold of one, I have the 677 on order with supporting 820 M/B and PC133 memory.

'ere, where's my first post gone!! Andi. > Tim, > I mentioned this the other day, have you tried the Iforce reference drivers?

Quoted text (14 lines)

> The standard TM drivers are not brilliant. > A comment from elsewhere in this news group: > >Hi > >You can download The I-FORCE reference drivers , supports "split axis" > >(throttle and brake on separate axis) , > > I use them with my "Guillemot Race Leader FF" , > >http://www.force-feedback.com/iforce/main.html > >P.Ivar > I've been using the reference drivers with my TM Force GT since TOCA2. As > you know, Santa has my Guillemot wheel so I can't comment about it yet.

From

Quoted text (34 lines)

> the above, I would be very upset to lose split axis. > Andi. > PS Sorry about the sarcastic post just now. I'd be very interested in any > solution you come up with. > Gave up on the P3 733 can't get hold of one, I have the 677 on order with > supporting 820 M/B and PC133 memory. > > I have recently purchased one of the new Guillemot Ferrari Force > > Feedback racing wheels. I first noticed playing Rally Championship 2000 > > that I had much less control in a straight line than with my previous > > wheels, and that I tended to zig-zag on straight road. I found this to > > be the same in other driving games such as TOCA2. I used DXTweak to > > remove the deadzone (which I thought was causing the problem) however > > this had no effect. I have done some testing using DXTweak and other > > games and have found that the steering problem seems to be caused by a > > lag between the input (my movement) to the output (down the USB port) of > > the steering wheel, i.e. as you turn left or right from any stationary > > wheel position it takes time for this to be registered as movement, in > > fact it is possible to move the wheel very slowly and for it to take > > ages for the movement to be registered. This is obviously not good in a > > racing game, as it prevents the fine control necessary to get fast > > times. > > This does not appear to be a problem with the guillemot driver - as it > > does exactly the same using the thrustmaster force gt driver. The > > problem appears to be introduced by the wheel electronics which are > > probably trying to smooth the output from the potentiometer. > > Is anyone else experiencing this problem?

I do not have the Guillemot Wheel in my hands yet, but what you describe is VERY familiar to me. In fact I can say with 90% certainty I know what the problem is (only 90% because I haven't had the chance to determine the positioning resolution of the wheel yet). The problem is "Overshoot" in the positioning resolution. This anomaly occurs VERY noticeably when you cut into the positioning resolution too far to combat mechanical jitter that occurs in the axis. This algorithm to cut into the positioning resolution is in the firmware of the USB chip itself (programmed by the controller manufacturers individually), and using other drivers will not solve it. Here's what's happening in this anomaly; You have to understand first that you are trying to translate say: 270 degrees of turn into the game. However if you have cut into the positioning resolution too much (Guillemots WingLeader USB Joystick is HORRIBLE for this...... positioning resolution of 19!), you do not have enough positioning resolution to translate every degree of turn. e.g. You have a positioning resolution of 50 that must translate 270 degrees of turn..... leaving you with only every fifth degree of turn that can be translated and reported. The way they "hide" this is by registering a change in position whenever the axis is deflected even slightly past the center (Microsoft was BRUTAL for this). The problem is that you move the wheel perhaps a degree, and it jumps 5 degrees of turn over (you don't have a high enough positioning resolution to interpret 2,3,or 4th degree of turn). So it makes the change..... but it "overshoots" the actual position bye 4 degrees. This is why when you turn the wheel slowly through the 2nd, 3rd, 4th, and 5th degree of turn..... nothing changes (the wheel position is just catching up to the jump to the 5th degree). When you turn to the 6th degree of turn..... the position will jump to the 10th degree of turn, and so on. The end result in the experience is that you will have slow responses from the controller, because the wheel is constantly trying to "catch-up" to the jumps in positioning resolution. I have had direct talks with the Head of R/D at Guillemot in person regarding this issue, and they seem to think that you guys wouldn't notice it..... I am VERY pleased to see that you have, because PDPI have a solution for it (USB) that is going to take this industry by storm. No details to be released yet..... but it's going to BLOW every other controller manufacturer away by a WIDE margin, BANK on it :) Cheers, Shumi

Shumi, why would he have this problem with that wheel and others not have the problem with the same wheel? Doesn't the Guillemot Ferrari wheel use pots instead of optical like the MS FF wheel uses? Should the rest of us who are getting this wheel expect the same problem? Thanks bud Slot

As stated in my post... I do not have the wheel to test yet, so it is impossible for me to make an assessment 100%. However, the anomaly is present in Guillemot's WingLeader Joystick (for the reasons mentioned in my above post), and is concurrent with meetings held between myself and Guillemot R/D on the very subject. The fact that you do not notice it, is perhaps subjective as well. In fact... Guillemot are banking on it in their WingLeader joystick (and perhaps the FF Wheel if they have cut into the positioning resolution too far). As far as Pots or Optical..... makes no difference really... except that optics are more precise, but that brings along more inherit mechanical jitter, causing an increase of cutting into the positioning resolution being required, which leaves us with MORE of the positioning resolution being hacked, and a less precise controller overall. This is apparent in the MSFF wheel, and BRUTAL in the Precision Pro USB joystick (25 positioning resolution). The best way to determine the anomaly is to do what the above gentleman turn the wheel very slowly (degree by degree), and watch the positional target. It will jump over as soon as you move the wheel..... but watch how much further you have to turn it to make it move again.... Again... I do not have the wheel yet, so it may very well be something else.... it just sounds very familiar is all... and from the same company. Cheers, Shumi

Thanks for your reply Schumi, What you say seems to make perfect sense to me. I knew that the output from the potentiometer is not what you are really getting as no jitter occurs when calibrating with the new wheel, which was always the case with my old analogue only wheel. Obviously this is the trade-off they feel necessary, but in my experience and opinion it makes for a less than perfect steering device. Out of interest is the Logitech FF any better??

Quoted text (45 lines)

> As stated in my post... I do not have the wheel to test yet, so it is > impossible for me to make an assessment 100%. However, the anomaly is > present in Guillemot's WingLeader Joystick (for the reasons mentioned in my > above post), and is concurrent with meetings held between myself and > Guillemot R/D on the very subject. > The fact that you do not notice it, is perhaps subjective as well. In > fact... Guillemot are banking on it in their WingLeader joystick (and > perhaps the FF Wheel if they have cut into the positioning resolution too > far). > As far as Pots or Optical..... makes no difference really... except that > optics are more precise, but that brings along more inherit mechanical > jitter, causing an increase of cutting into the positioning resolution being > required, which leaves us with MORE of the positioning resolution being > hacked, and a less precise controller overall. This is apparent in the MSFF > wheel, and BRUTAL in the Precision Pro USB joystick (25 positioning > resolution). > The best way to determine the anomaly is to do what the above gentleman > turn the wheel very slowly (degree by degree), and watch the positional > target. It will jump over as soon as you move the wheel..... but watch how > much further you have to turn it to make it move again.... > Again... I do not have the wheel yet, so it may very well be something > else.... it just sounds very familiar is all... and from the same company. > Cheers, > Shumi > > Shumi, why would he have this problem with that wheel and others not have > > the problem with the same wheel? Doesn't the Guillemot Ferrari wheel use > > pots instead of optical like the MS FF wheel uses? Should the rest of us > who > > are getting this wheel expect the same problem? > > Thanks bud > > Slot

Shumi, Maybe we should get a petition going, you can put me down for a start, and I know Tim Haynes will also support a move that way (I work with him). If you haven't done this already maybe we should focus the petition on 'simracings' forum. I was testing my old Thrustmaster Force GT last night and yes I go wandering down straights zig zaging somewhat. I assumed it was just knackered. Regards. Andi. > I do not have the Guillemot Wheel in my hands yet, but what you describe is > VERY familiar to me. In fact I can say with 90% certainty I know what the > problem is (only 90% because I haven't had the chance to determine the > positioning resolution of the wheel yet). > The problem is "Overshoot" in the positioning resolution. This anomaly > occurs VERY noticeably when you cut into the positioning resolution too far

Quoted text (7 lines)

> to combat mechanical jitter that occurs in the axis. This algorithm to cut > into the positioning resolution is in the firmware of the USB chip itself > (programmed by the controller manufacturers individually), and using other > drivers will not solve it. Here's what's happening in this anomaly; > You have to understand first that you are trying to translate say: 270 > degrees of turn into the game. However if you have cut into the

positioning > resolution too much (Guillemots WingLeader USB Joystick is HORRIBLE for > this...... positioning resolution of 19!), you do not have enough > positioning resolution to translate every degree of turn. e.g. You have a > positioning resolution of 50 that must translate 270 degrees of turn..... > leaving you with only every fifth degree of turn that can be translated and > reported. The way they "hide" this is by registering a change in position > whenever the axis is deflected even slightly past the center (Microsoft was > BRUTAL for this). The problem is that you move the wheel perhaps a degree, > and it jumps 5 degrees of turn over (you don't have a high enough > positioning resolution to interpret 2,3,or 4th degree of turn). So it makes > the change..... but it "overshoots" the actual position bye 4 degrees. This > is why when you turn the wheel slowly through the 2nd, 3rd, 4th, and 5th > degree of turn..... nothing changes (the wheel position is just catching up > to the jump to the 5th degree). When you turn to the 6th degree of turn..... > the position will jump to the 10th degree of turn, and so on. The end result > in the experience is that you will have slow responses from the controller,

Quoted text (39 lines)

> because the wheel is constantly trying to "catch-up" to the jumps in > positioning resolution. > I have had direct talks with the Head of R/D at Guillemot in person > regarding this issue, and they seem to think that you guys wouldn't notice > it..... I am VERY pleased to see that you have, because PDPI have a > solution for it (USB) that is going to take this industry by storm. No > details to be released yet..... but it's going to BLOW every other > controller manufacturer away by a WIDE margin, BANK on it :) > Cheers, > Shumi > > I have recently purchased one of the new Guillemot Ferrari Force > > Feedback racing wheels. I first noticed playing Rally Championship 2000 > > that I had much less control in a straight line than with my previous > > wheels, and that I tended to zig-zag on straight road. I found this to > > be the same in other driving games such as TOCA2. I used DXTweak to > > remove the deadzone (which I thought was causing the problem) however > > this had no effect. I have done some testing using DXTweak and other > > games and have found that the steering problem seems to be caused by a > > lag between the input (my movement) to the output (down the USB port) of > > the steering wheel, i.e. as you turn left or right from any stationary > > wheel position it takes time for this to be registered as movement, in > > fact it is possible to move the wheel very slowly and for it to take > > ages for the movement to be registered. This is obviously not good in a > > racing game, as it prevents the fine control necessary to get fast > > times. > > This does not appear to be a problem with the guillemot driver - as it > > does exactly the same using the thrustmaster force gt driver. The > > problem appears to be introduced by the wheel electronics which are > > probably trying to smooth the output from the potentiometer. > > Is anyone else experiencing this problem?

Shumi : have you tried Directx 7a yet? It is supposed to have improved control of force feedback effects. I am downloading it right now from http://www.microsoft.com/directx/homeuser/downloads/default.asp . I'd be interested in hearing if this fixes the problems you identified. David > I do not have the Guillemot Wheel in my hands yet, but what you describe is > VERY familiar to me. In fact I can say with 90% certainty I know what the > problem is (only 90% because I haven't had the chance to determine the > positioning resolution of the wheel yet). > The problem is "Overshoot" in the positioning resolution. This anomaly > occurs VERY noticeably when you cut into the positioning resolution too far

Quoted text (7 lines)

> to combat mechanical jitter that occurs in the axis. This algorithm to cut > into the positioning resolution is in the firmware of the USB chip itself > (programmed by the controller manufacturers individually), and using other > drivers will not solve it. Here's what's happening in this anomaly; > You have to understand first that you are trying to translate say: 270 > degrees of turn into the game. However if you have cut into the

positioning > resolution too much (Guillemots WingLeader USB Joystick is HORRIBLE for > this...... positioning resolution of 19!), you do not have enough > positioning resolution to translate every degree of turn. e.g. You have a > positioning resolution of 50 that must translate 270 degrees of turn..... > leaving you with only every fifth degree of turn that can be translated and > reported. The way they "hide" this is by registering a change in position > whenever the axis is deflected even slightly past the center (Microsoft was > BRUTAL for this). The problem is that you move the wheel perhaps a degree, > and it jumps 5 degrees of turn over (you don't have a high enough > positioning resolution to interpret 2,3,or 4th degree of turn). So it makes > the change..... but it "overshoots" the actual position bye 4 degrees. This > is why when you turn the wheel slowly through the 2nd, 3rd, 4th, and 5th > degree of turn..... nothing changes (the wheel position is just catching up > to the jump to the 5th degree). When you turn to the 6th degree of turn..... > the position will jump to the 10th degree of turn, and so on. The end result > in the experience is that you will have slow responses from the controller,

Quoted text (39 lines)

> because the wheel is constantly trying to "catch-up" to the jumps in > positioning resolution. > I have had direct talks with the Head of R/D at Guillemot in person > regarding this issue, and they seem to think that you guys wouldn't notice > it..... I am VERY pleased to see that you have, because PDPI have a > solution for it (USB) that is going to take this industry by storm. No > details to be released yet..... but it's going to BLOW every other > controller manufacturer away by a WIDE margin, BANK on it :) > Cheers, > Shumi > > I have recently purchased one of the new Guillemot Ferrari Force > > Feedback racing wheels. I first noticed playing Rally Championship 2000 > > that I had much less control in a straight line than with my previous > > wheels, and that I tended to zig-zag on straight road. I found this to > > be the same in other driving games such as TOCA2. I used DXTweak to > > remove the deadzone (which I thought was causing the problem) however > > this had no effect. I have done some testing using DXTweak and other > > games and have found that the steering problem seems to be caused by a > > lag between the input (my movement) to the output (down the USB port) of > > the steering wheel, i.e. as you turn left or right from any stationary > > wheel position it takes time for this to be registered as movement, in > > fact it is possible to move the wheel very slowly and for it to take > > ages for the movement to be registered. This is obviously not good in a > > racing game, as it prevents the fine control necessary to get fast > > times. > > This does not appear to be a problem with the guillemot driver - as it > > does exactly the same using the thrustmaster force gt driver. The > > problem appears to be introduced by the wheel electronics which are > > probably trying to smooth the output from the potentiometer. > > Is anyone else experiencing this problem?

My Ferrari wheel seems to give about 5 little clicks to a movement of the crosshairs in the Controller setup panel in Win98. I just loaded DirectX 7a and its the same. But, I don't have any problems going in a straight line. Slot

DirectX has nothing to do with this anomaly and cannot fix it. The problem lies in the positioning algorithm in the USB chip itself. You can't solve it with software, since it is in the Firmware (like a BIOS)... you are stuck with it (if it's happening to you). The only way to solve lies with the controller manufacturer. The program the firmware, and they govern the positioning resolution. Some companies feel that making an aesthetically pleasing wheel is enough. I think otherwise... I want precision and performance, which is why I still use analog wheels with the PDPI L4 gamecard for my steering devices (still 2X the precision of any USB wheel out there today). Cheers, Shumi

Quoted text (13 lines)

> Shumi : have you tried Directx 7a yet? It is supposed to have improved > control of force feedback effects. I am downloading it right now from > http://www.microsoft.com/directx/homeuser/downloads/default.asp . I'd be > interested in hearing if this fixes the problems you identified. > David > > I do not have the Guillemot Wheel in my hands yet, but what you describe > is > > VERY familiar to me. In fact I can say with 90% certainty I know what

the

Quoted text (7 lines)

> > problem is (only 90% because I haven't had the chance to determine the > > positioning resolution of the wheel yet). > > The problem is "Overshoot" in the positioning resolution. This anomaly > > occurs VERY noticeably when you cut into the positioning resolution too > far > > to combat mechanical jitter that occurs in the axis. This algorithm to

cut > > into the positioning resolution is in the firmware of the USB chip itself > > (programmed by the controller manufacturers individually), and using other

Quoted text (8 lines)

> > drivers will not solve it. Here's what's happening in this anomaly; > > You have to understand first that you are trying to translate say: 270 > > degrees of turn into the game. However if you have cut into the > positioning > > resolution too much (Guillemots WingLeader USB Joystick is HORRIBLE for > > this...... positioning resolution of 19!), you do not have enough > > positioning resolution to translate every degree of turn. e.g. You have

a > > positioning resolution of 50 that must translate 270 degrees of turn..... > > leaving you with only every fifth degree of turn that can be translated > and > > reported. The way they "hide" this is by registering a change in position > > whenever the axis is deflected even slightly past the center (Microsoft > was > > BRUTAL for this). The problem is that you move the wheel perhaps a degree,

Quoted text (19 lines)

> > and it jumps 5 degrees of turn over (you don't have a high enough > > positioning resolution to interpret 2,3,or 4th degree of turn). So it > makes > > the change..... but it "overshoots" the actual position bye 4 degrees. > This > > is why when you turn the wheel slowly through the 2nd, 3rd, 4th, and 5th > > degree of turn..... nothing changes (the wheel position is just catching > up > > to the jump to the 5th degree). When you turn to the 6th degree of > turn..... > > the position will jump to the 10th degree of turn, and so on. The end > result > > in the experience is that you will have slow responses from the > controller, > > because the wheel is constantly trying to "catch-up" to the jumps in > > positioning resolution. > > I have had direct talks with the Head of R/D at Guillemot in person > > regarding this issue, and they seem to think that you guys wouldn't

notice

Quoted text (14 lines)

> > it..... I am VERY pleased to see that you have, because PDPI have a > > solution for it (USB) that is going to take this industry by storm. No > > details to be released yet..... but it's going to BLOW every other > > controller manufacturer away by a WIDE margin, BANK on it :) > > Cheers, > > Shumi > > > I have recently purchased one of the new Guillemot Ferrari Force > > > Feedback racing wheels. I first noticed playing Rally Championship

2000 > > > that I had much less control in a straight line than with my previous > > > wheels, and that I tended to zig-zag on straight road. I found this to > > > be the same in other driving games such as TOCA2. I used DXTweak to > > > remove the deadzone (which I thought was causing the problem) however > > > this had no effect. I have done some testing using DXTweak and other > > > games and have found that the steering problem seems to be caused by a > > > lag between the input (my movement) to the output (down the USB port) of > > > the steering wheel, i.e. as you turn left or right from any stationary > > > wheel position it takes time for this to be registered as movement, in > > > fact it is possible to move the wheel very slowly and for it to take > > > ages for the movement to be registered. This is obviously not good in a

Quoted text (9 lines)

> > > racing game, as it prevents the fine control necessary to get fast > > > times. > > > This does not appear to be a problem with the guillemot driver - as it > > > does exactly the same using the thrustmaster force gt driver. The > > > problem appears to be introduced by the wheel electronics which are > > > probably trying to smooth the output from the potentiometer. > > > Is anyone else experiencing this problem?

Doing more than starting a petition..... we are making a wheel for y'all that will kick ass over current USB implementations. We will be EXPONENTIALLY more precise than the closest compare-sake, and the performance will be lightning fast. The company is PDPI, and we have done for USB what we did for the gameport. We approached many of the major wheel manufacturers with licensing opportunities for our technology, and the fact that it would cost literally $1.00 more than their current implementations seemed to turn them off (even though they would save that buck in R/D). They ALL admitted that our technology was substantially superior, but they couldn't justify the price since they didn't feel you guys would notice the pathetic positioning resolutions currently employed. Let it be known that PDPI (me particularly) have been listening to you guys on RAS, and other forums, and we are paying very close attention to what you want. We will be launching controllers that you yourselves have asked for, and basically built for us with feedback on this NG. We WILL NOT ignore the customer, and we will accept all suggestions/recommendations, as well as providing unprecedented support for the individual and Sim Racing as a whole (throughout all the genres). So the way we see it... they dropped the ball repeatedly and we decided to enter the controller market and build the best controllers available at a very reasonable price, because you guys are asking for it.... You should start to see some of our controllers on store shelves by Q2 2000. A lot of development is still under wraps since we have made further advancements in the FF area that should also increase performance there 2 fold. Please don't ask me details yet. I will be announcing some REALLY big things in the coming month(s). Cheers, Jason "Shumi" Murray Director of Marketing & Business Development PDPI 2591 East Lee Street Simi Valley, CA 93065 > Shumi, > Maybe we should get a petition going, you can put me down for a start, and I > know Tim Haynes will also support a move that way (I work with him). If you > haven't done this already maybe we should focus the petition on 'simracings' > forum. > I was testing my old Thrustmaster Force GT last night and yes I go wandering

Quoted text (12 lines)

> down straights zig zaging somewhat. I assumed it was just knackered. > Regards. > Andi. > > I do not have the Guillemot Wheel in my hands yet, but what you describe > is > > VERY familiar to me. In fact I can say with 90% certainty I know what

the

Quoted text (7 lines)

> > problem is (only 90% because I haven't had the chance to determine the > > positioning resolution of the wheel yet). > > The problem is "Overshoot" in the positioning resolution. This anomaly > > occurs VERY noticeably when you cut into the positioning resolution too > far > > to combat mechanical jitter that occurs in the axis. This algorithm to

cut > > into the positioning resolution is in the firmware of the USB chip itself > > (programmed by the controller manufacturers individually), and using other

Quoted text (8 lines)

> > drivers will not solve it. Here's what's happening in this anomaly; > > You have to understand first that you are trying to translate say: 270 > > degrees of turn into the game. However if you have cut into the > positioning > > resolution too much (Guillemots WingLeader USB Joystick is HORRIBLE for > > this...... positioning resolution of 19!), you do not have enough > > positioning resolution to translate every degree of turn. e.g. You have

a > > positioning resolution of 50 that must translate 270 degrees of turn..... > > leaving you with only every fifth degree of turn that can be translated > and > > reported. The way they "hide" this is by registering a change in position > > whenever the axis is deflected even slightly past the center (Microsoft > was > > BRUTAL for this). The problem is that you move the wheel perhaps a degree,

Quoted text (19 lines)

> > and it jumps 5 degrees of turn over (you don't have a high enough > > positioning resolution to interpret 2,3,or 4th degree of turn). So it > makes > > the change..... but it "overshoots" the actual position bye 4 degrees. > This > > is why when you turn the wheel slowly through the 2nd, 3rd, 4th, and 5th > > degree of turn..... nothing changes (the wheel position is just catching > up > > to the jump to the 5th degree). When you turn to the 6th degree of > turn..... > > the position will jump to the 10th degree of turn, and so on. The end > result > > in the experience is that you will have slow responses from the > controller, > > because the wheel is constantly trying to "catch-up" to the jumps in > > positioning resolution. > > I have had direct talks with the Head of R/D at Guillemot in person > > regarding this issue, and they seem to think that you guys wouldn't

notice

Quoted text (14 lines)

> > it..... I am VERY pleased to see that you have, because PDPI have a > > solution for it (USB) that is going to take this industry by storm. No > > details to be released yet..... but it's going to BLOW every other > > controller manufacturer away by a WIDE margin, BANK on it :) > > Cheers, > > Shumi > > > I have recently purchased one of the new Guillemot Ferrari Force > > > Feedback racing wheels. I first noticed playing Rally Championship

2000 > > > that I had much less control in a straight line than with my previous > > > wheels, and that I tended to zig-zag on straight road. I found this to > > > be the same in other driving games such as TOCA2. I used DXTweak to > > > remove the deadzone (which I thought was causing the problem) however > > > this had no effect. I have done some testing using DXTweak and other > > > games and have found that the steering problem seems to be caused by a > > > lag between the input (my movement) to the output (down the USB port) of > > > the steering wheel, i.e. as you turn left or right from any stationary > > > wheel position it takes time for this to be registered as movement, in > > > fact it is possible to move the wheel very slowly and for it to take > > > ages for the movement to be registered. This is obviously not good in a

Quoted text (9 lines)

> > > racing game, as it prevents the fine control necessary to get fast > > > times. > > > This does not appear to be a problem with the guillemot driver - as it > > > does exactly the same using the thrustmaster force gt driver. The > > > problem appears to be introduced by the wheel electronics which are > > > probably trying to smooth the output from the potentiometer. > > > Is anyone else experiencing this problem?

From any stationary position I have to move the wheel 15-20 "notches" of the motor before any movement is registered. If you are only having to move it 5 notches then this would explain why you probably don't notice it as much. I am wondering if I have a very early version of the wheel as mine has only one clamp underneath. The Guillemot UK web page shows a model having 2 clamps underneath - could I have an early model that exhibits a few "bugs" which they have ironed out a bit in later models? Tim. > My Ferrari wheel seems to give about 5 little clicks to a movement of the > crosshairs in the Controller setup panel in Win98. I just loaded DirectX 7a > and its the same. But, I don't have any problems going in a straight line. > Slot

Currently..... the Logitech is the most precise USB controller (wheel). They have a positioning resolution just below 128 on each axis, which is a bit better than any other wheel that I have tested. It's not precise.... but it's the best you'll get in a USB implementation. You can just compare it to a positioning resolution of 256 on all axis with an analogue wheel, and the PDPI L4 card. That will give you something to compare it to... Cheers, Shumi > Thanks for your reply Schumi, > What you say seems to make perfect sense to me. I knew that the output from the > potentiometer is not what you are really getting as no jitter occurs when > calibrating with the new wheel, which was always the case with my old analogue > only wheel. Obviously this is the trade-off they feel necessary, but in my

Quoted text (10 lines)

> experience and opinion it makes for a less than perfect steering device. > Out of interest is the Logitech FF any better?? > > As stated in my post... I do not have the wheel to test yet, so it is > > impossible for me to make an assessment 100%. However, the anomaly is > > present in Guillemot's WingLeader Joystick (for the reasons mentioned in

my > > above post), and is concurrent with meetings held between myself and > > Guillemot R/D on the very subject. > > The fact that you do not notice it, is perhaps subjective as well. In > > fact... Guillemot are banking on it in their WingLeader joystick (and > > perhaps the FF Wheel if they have cut into the positioning resolution too > > far). > > As far as Pots or Optical..... makes no difference really... except that > > optics are more precise, but that brings along more inherit mechanical > > jitter, causing an increase of cutting into the positioning resolution being > > required, which leaves us with MORE of the positioning resolution being > > hacked, and a less precise controller overall. This is apparent in the MSFF

Quoted text (8 lines)

> > wheel, and BRUTAL in the Precision Pro USB joystick (25 positioning > > resolution). > > The best way to determine the anomaly is to do what the above gentleman > > turn the wheel very slowly (degree by degree), and watch the positional > > target. It will jump over as soon as you move the wheel..... but watch

how > > much further you have to turn it to make it move again.... > > Again... I do not have the wheel yet, so it may very well be something > > else.... it just sounds very familiar is all... and from the same company.

Quoted text (8 lines)

> > Cheers, > > Shumi > > > Shumi, why would he have this problem with that wheel and others not

have > > > the problem with the same wheel? Doesn't the Guillemot Ferrari wheel use > > > pots instead of optical like the MS FF wheel uses? Should the rest of us > > who > > > are getting this wheel expect the same problem? > > > Thanks bud > > > Slot

Be careful..... some may have adjusted the Deadzone in the wheel through the dinput.dll tweaker (Deadzone Utility). The dinput.dll will affect the deadzone in the wheel, and gives Windows a "place to start". The more important thing to look at is: After it moved the first time..... see how much more you have to turn the wheel to make it hop over again. This will give you a better idea of the precision. Cheers, Shumi > From any stationary position I have to move the wheel 15-20 "notches" of the > motor before any movement is registered. If you are only having to move it 5 > notches then this would explain why you probably don't notice it as much. > I am wondering if I have a very early version of the wheel as mine has only one > clamp underneath. The Guillemot UK web page shows a model having 2 clamps > underneath - could I have an early model that exhibits a few "bugs" which they

Quoted text (8 lines)

> have ironed out a bit in later models? > Tim. > > My Ferrari wheel seems to give about 5 little clicks to a movement of

the > > crosshairs in the Controller setup panel in Win98. I just loaded DirectX 7a > > and its the same. But, I don't have any problems going in a straight line. > > Slot

Daaaamn :)! Need any beta testers ;)? That does it - I'm waiting until 2000 to finally plunk down the cash for FF. I've been watching the FF wheel reviews and developments, and it's been looking like nothing would equal the precision of a good standard wheel. I would have a PDPI card too, if it weren't for my MS digital joysticks. The SB Live gameport seems to be the next best thing, though. Could you guys finally be the replacement for the late, great Thrustmaster? (this is coming from someone who bought a T1 wheel back in the ICR1 days, and steadily upgraded to T2 and then Nascar Pro) And another thing - be sure to add a gearshift! Who wants to shift in GPL with a button ;)? Keep us posted! Kendt In article <h3T64.57396$[email hidden]>, "Shumi" <[email hidden]> wrote: > Doing more than starting a petition..... we are making a wheel for y'all > that will kick ass over current USB implementations. We will be > EXPONENTIALLY more precise than the closest compare-sake, and the > performance will be lightning fast. The company is PDPI, and we have done > for USB what we did for the gameport. > We approached many of the major wheel manufacturers with licensing > opportunities for our technology, and the fact that it would cost literally > $1.00 more than their current implementations seemed to turn them off (even > though they would save that buck in R/D). They ALL admitted that our > technology was substantially superior, but they couldn't justify the price > since they didn't feel you guys would notice the pathetic positioning > resolutions currently employed. > Let it be known that PDPI (me particularly) have been listening to you guys > on RAS, and other forums, and we are paying very close attention to what you > want. We will be launching controllers that you yourselves have asked for, > and basically built for us with feedback on this NG. We WILL NOT ignore the > customer, and we will accept all suggestions/recommendations, as well as > providing unprecedented support for the individual and Sim Racing as a whole > (throughout all the genres). > So the way we see it... they dropped the ball repeatedly and we decided to > enter the controller market and build the best controllers available at a > very reasonable price, because you guys are asking for it.... > You should start to see some of our controllers on store shelves by Q2 2000. > A lot of development is still under wraps since we have made further > advancements in the FF area that should also increase performance there 2 > fold. > Please don't ask me details yet. I will be announcing some REALLY big things

Quoted text (16 lines)

> in the coming month(s). > Cheers, > Jason "Shumi" Murray > Director of Marketing & Business Development > PDPI > 2591 East Lee Street > Simi Valley, CA 93065 > [email hidden] > Andi Cole <[email hidden]> wrote in message > news:83fpgk$o8i$[email hidden]... > > Shumi, > > Maybe we should get a petition going, you can put me down for a

start, and > I > > know Tim Haynes will also support a move that way (I work with him). If

Quoted text (8 lines)

> you > > haven't done this already maybe we should focus the petition on > 'simracings' > > forum. > > I was testing my old Thrustmaster Force GT last night and yes I go > wandering > > down straights zig zaging somewhat. I assumed it was just

knackered.

Quoted text (7 lines)

> > Regards. > > Andi. > > Shumi <[email hidden]> wrote in message > > news:Off64.50424$[email hidden]... > > > I do not have the Guillemot Wheel in my hands yet, but what you

describe > > is > > > VERY familiar to me. In fact I can say with 90% certainty I know what > the > > > problem is (only 90% because I haven't had the chance to determine the > > > positioning resolution of the wheel yet). > > > The problem is "Overshoot" in the positioning resolution. This anomaly > > > occurs VERY noticeably when you cut into the positioning resolution too > > far > > > to combat mechanical jitter that occurs in the axis. This algorithm to > cut > > > into the positioning resolution is in the firmware of the USB chip > itself > > > (programmed by the controller manufacturers individually), and using > other > > > drivers will not solve it. Here's what's happening in this anomaly; > > > You have to understand first that you are trying to translate say: 270 > > > degrees of turn into the game. However if you have cut into the > > positioning > > > resolution too much (Guillemots WingLeader USB Joystick is HORRIBLE for > > > this...... positioning resolution of 19!), you do not have enough > > > positioning resolution to translate every degree of turn. e.g. You have > a > > > positioning resolution of 50 that must translate 270 degrees of > turn..... > > > leaving you with only every fifth degree of turn that can be translated > > and > > > reported. The way they "hide" this is by registering a change in > position > > > whenever the axis is deflected even slightly past the center (Microsoft > > was > > > BRUTAL for this). The problem is that you move the wheel perhaps a > degree, > > > and it jumps 5 degrees of turn over (you don't have a high enough > > > positioning resolution to interpret 2,3,or 4th degree of turn). So it > > makes > > > the change..... but it "overshoots" the actual position bye 4 degrees. > > This > > > is why when you turn the wheel slowly through the 2nd, 3rd, 4th, and 5th > > > degree of turn..... nothing changes (the wheel position is just catching > > up > > > to the jump to the 5th degree). When you turn to the 6th degree of > > turn..... > > > the position will jump to the 10th degree of turn, and so on. The end > > result > > > in the experience is that you will have slow responses from the > > controller, > > > because the wheel is constantly trying to "catch-up" to the jumps in > > > positioning resolution. > > > I have had direct talks with the Head of R/D at Guillemot in person > > > regarding this issue, and they seem to think that you guys wouldn't > notice > > > it..... I am VERY pleased to see that you have, because PDPI have a > > > solution for it (USB) that is going to take this industry by storm. No

Quoted text (11 lines)

> > > details to be released yet..... but it's going to BLOW every other > > > controller manufacturer away by a WIDE margin, BANK on it :) > > > Cheers, > > > Shumi > > > Tim Haynes <[email hidden]> wrote in message > > > news:[email hidden]... > > > > I have recently purchased one of the new Guillemot Ferrari Force > > > > Feedback racing wheels. I first noticed playing Rally

Championship > 2000 > > > > that I had much less control in a straight line than with my previous > > > > wheels, and that I tended to zig-zag on straight road. I found this > to > > > > be the same in other driving games such as TOCA2. I used DXTweak to > > > > remove the deadzone (which I thought was causing the problem) however > > > > this had no effect. I have done some testing using DXTweak and other > > > > games and have found that the steering problem seems to be caused by a > > > > lag between the input (my movement) to the output (down the USB port) > of > > > > the steering wheel, i.e. as you turn left or right from any stationary > > > > wheel position it takes time for this to be registered as movement, in > > > > fact it is possible to move the wheel very slowly and for it to take > > > > ages for the movement to be registered. This is obviously not good in > a > > > > racing game, as it prevents the fine control necessary to get fast > > > > times. > > > > This does not appear to be a problem with the guillemot driver - as it > > > > does exactly the same using the thrustmaster force gt driver. The > > > > problem appears to be introduced by the wheel electronics which are > > > > probably trying to smooth the output from the potentiometer. > > > > Is anyone else experiencing this problem? Sent via Deja.com http://www.deja.com/ Before you buy.

Shumi, what's a deadzone utility? Guillemot software is pretty sparse. My wheel was pulling to the right. Not at first, but after some use. It got pretty bad. There is no included software to set this up. The iForce Lite included would let me make an adjustment, but there's no way of putting it in the games or using it for a default setup when you turn on the wheel. I finally just took the cover off the wheel and adjusted the trim. The pot is in plain site when the cover is removed. It works great now. Now, if only I could get the configuration utility to let me assign the stick shift in SCGT. I set it up for , and . but SCGT doesn't see it. Actually, I thought it did when I first set it up, but it doesn't now. I've uninstalled and reinstalled the software a few times, but no luck. Slot > Be careful..... some may have adjusted the Deadzone in the wheel through the

Quoted text (23 lines)

> dinput.dll tweaker (Deadzone Utility). > The dinput.dll will affect the deadzone in the wheel, and gives Windows a > "place to start". > The more important thing to look at is: > After it moved the first time..... see how much more you have to turn the > wheel to make it hop over again. This will give you a better idea of the > precision. > Cheers, > Shumi > > From any stationary position I have to move the wheel 15-20 "notches" of > the > > motor before any movement is registered. If you are only having to move > it 5 > > notches then this would explain why you probably don't notice it as

much. > > I am wondering if I have a very early version of the wheel as mine has > only one > > clamp underneath. The Guillemot UK web page shows a model having 2 clamps > > underneath - could I have an early model that exhibits a few "bugs" which

Quoted text (11 lines)

> they > > have ironed out a bit in later models? > > Tim. > > > My Ferrari wheel seems to give about 5 little clicks to a movement of > the > > > crosshairs in the Controller setup panel in Win98. I just loaded

DirectX > 7a > > > and its the same. But, I don't have any problems going in a straight > line. > > > Slot

Shumi, Do you think there will be an improvement if we used the serial port on the Ferrari Wheel rather than USB? Andi. > DirectX has nothing to do with this anomaly and cannot fix it. The problem > lies in the positioning algorithm in the USB chip itself. You can't solve it > with software, since it is in the Firmware (like a BIOS)... you are stuck > with it (if it's happening to you). > The only way to solve lies with the controller manufacturer. The program the > firmware, and they govern the positioning resolution. > Some companies feel that making an aesthetically pleasing wheel is enough. I

Quoted text (22 lines)

> think otherwise... I want precision and performance, which is why I still > use analog wheels with the PDPI L4 gamecard for my steering devices (still > 2X the precision of any USB wheel out there today). > Cheers, > Shumi > > Shumi : have you tried Directx 7a yet? It is supposed to have improved > > control of force feedback effects. I am downloading it right now from > > http://www.microsoft.com/directx/homeuser/downloads/default.asp . I'd be > > interested in hearing if this fixes the problems you identified. > > David > > > I do not have the Guillemot Wheel in my hands yet, but what you

describe

Quoted text (8 lines)

> > is > > > VERY familiar to me. In fact I can say with 90% certainty I know what > the > > > problem is (only 90% because I haven't had the chance to determine the > > > positioning resolution of the wheel yet). > > > The problem is "Overshoot" in the positioning resolution. This anomaly > > > occurs VERY noticeably when you cut into the positioning resolution

too

Quoted text (13 lines)

> > far > > > to combat mechanical jitter that occurs in the axis. This algorithm to > cut > > > into the positioning resolution is in the firmware of the USB chip > itself > > > (programmed by the controller manufacturers individually), and using > other > > > drivers will not solve it. Here's what's happening in this anomaly; > > > You have to understand first that you are trying to translate say: 270 > > > degrees of turn into the game. However if you have cut into the > > positioning > > > resolution too much (Guillemots WingLeader USB Joystick is HORRIBLE

for > > > this...... positioning resolution of 19!), you do not have enough > > > positioning resolution to translate every degree of turn. e.g. You have > a > > > positioning resolution of 50 that must translate 270 degrees of > turn..... > > > leaving you with only every fifth degree of turn that can be translated > > and > > > reported. The way they "hide" this is by registering a change in > position > > > whenever the axis is deflected even slightly past the center (Microsoft

Quoted text (9 lines)

> > was > > > BRUTAL for this). The problem is that you move the wheel perhaps a > degree, > > > and it jumps 5 degrees of turn over (you don't have a high enough > > > positioning resolution to interpret 2,3,or 4th degree of turn). So it > > makes > > > the change..... but it "overshoots" the actual position bye 4 degrees. > > This > > > is why when you turn the wheel slowly through the 2nd, 3rd, 4th, and

5th > > > degree of turn..... nothing changes (the wheel position is just catching

Quoted text (29 lines)

> > up > > > to the jump to the 5th degree). When you turn to the 6th degree of > > turn..... > > > the position will jump to the 10th degree of turn, and so on. The end > > result > > > in the experience is that you will have slow responses from the > > controller, > > > because the wheel is constantly trying to "catch-up" to the jumps in > > > positioning resolution. > > > I have had direct talks with the Head of R/D at Guillemot in person > > > regarding this issue, and they seem to think that you guys wouldn't > notice > > > it..... I am VERY pleased to see that you have, because PDPI have a > > > solution for it (USB) that is going to take this industry by storm. No > > > details to be released yet..... but it's going to BLOW every other > > > controller manufacturer away by a WIDE margin, BANK on it :) > > > Cheers, > > > Shumi > > > > I have recently purchased one of the new Guillemot Ferrari Force > > > > Feedback racing wheels. I first noticed playing Rally Championship > 2000 > > > > that I had much less control in a straight line than with my

previous > > > > wheels, and that I tended to zig-zag on straight road. I found this > to > > > > be the same in other driving games such as TOCA2. I used DXTweak to > > > > remove the deadzone (which I thought was causing the problem) however > > > > this had no effect. I have done some testing using DXTweak and other > > > > games and have found that the steering problem seems to be caused by a > > > > lag between the input (my movement) to the output (down the USB port) > of > > > > the steering wheel, i.e. as you turn left or right from any stationary > > > > wheel position it takes time for this to be registered as movement, in > > > > fact it is possible to move the wheel very slowly and for it to take > > > > ages for the movement to be registered. This is obviously not good in > a > > > > racing game, as it prevents the fine control necessary to get fast > > > > times. > > > > This does not appear to be a problem with the guillemot driver - as it > > > > does exactly the same using the thrustmaster force gt driver. The > > > > problem appears to be introduced by the wheel electronics which are > > > > probably trying to smooth the output from the potentiometer. > > > > Is anyone else experiencing this problem?

Andi, the serial and USB ports seem to behave the same. Nonetheless, the wheel is smooth and feels quite accurate throughout its turning arc. Although lock to lock of the wheel is about 220 degrees, only 180 is usuable. After that the arc is dead space. Slot

Quoted text (11 lines)

>Shumi, >Do you think there will be an improvement if we used the serial port on the >Ferrari Wheel rather than USB? >Andi. >> DirectX has nothing to do with this anomaly and cannot fix it. The

problem

Quoted text (10 lines)

>> lies in the positioning algorithm in the USB chip itself. You can't solve >it >> with software, since it is in the Firmware (like a BIOS)... you are stuck >> with it (if it's happening to you). >> The only way to solve lies with the controller manufacturer. The program >the >> firmware, and they govern the positioning resolution. >> Some companies feel that making an aesthetically pleasing wheel is

enough. >I >> think otherwise... I want precision and performance, which is why I still >> use analog wheels with the PDPI L4 gamecard for my steering devices (still

Quoted text (12 lines)

>> 2X the precision of any USB wheel out there today). >> Cheers, >> Shumi >> > Shumi : have you tried Directx 7a yet? It is supposed to have improved >> > control of force feedback effects. I am downloading it right now from >> > http://www.microsoft.com/directx/homeuser/downloads/default.asp . I'd

be

Quoted text (13 lines)

>> > interested in hearing if this fixes the problems you identified. >> > David >> > > I do not have the Guillemot Wheel in my hands yet, but what you >describe >> > is >> > > VERY familiar to me. In fact I can say with 90% certainty I know what >> the >> > > problem is (only 90% because I haven't had the chance to determine

the >> > > positioning resolution of the wheel yet). >> > > The problem is "Overshoot" in the positioning resolution. This anomaly >> > > occurs VERY noticeably when you cut into the positioning resolution >too >> > far >> > > to combat mechanical jitter that occurs in the axis. This algorithm to

Quoted text (8 lines)

>> cut >> > > into the positioning resolution is in the firmware of the USB chip >> itself >> > > (programmed by the controller manufacturers individually), and using >> other >> > > drivers will not solve it. Here's what's happening in this anomaly; >> > > You have to understand first that you are trying to translate say:

270

Quoted text (24 lines)

>> > > degrees of turn into the game. However if you have cut into the >> > positioning >> > > resolution too much (Guillemots WingLeader USB Joystick is HORRIBLE >for >> > > this...... positioning resolution of 19!), you do not have enough >> > > positioning resolution to translate every degree of turn. e.g. You >have >> a >> > > positioning resolution of 50 that must translate 270 degrees of >> turn..... >> > > leaving you with only every fifth degree of turn that can be >translated >> > and >> > > reported. The way they "hide" this is by registering a change in >> position >> > > whenever the axis is deflected even slightly past the center >(Microsoft >> > was >> > > BRUTAL for this). The problem is that you move the wheel perhaps a >> degree, >> > > and it jumps 5 degrees of turn over (you don't have a high enough >> > > positioning resolution to interpret 2,3,or 4th degree of turn). So it >> > makes >> > > the change..... but it "overshoots" the actual position bye 4

degrees.

Quoted text (20 lines)

>> > This >> > > is why when you turn the wheel slowly through the 2nd, 3rd, 4th, and >5th >> > > degree of turn..... nothing changes (the wheel position is just >catching >> > up >> > > to the jump to the 5th degree). When you turn to the 6th degree of >> > turn..... >> > > the position will jump to the 10th degree of turn, and so on. The end >> > result >> > > in the experience is that you will have slow responses from the >> > controller, >> > > because the wheel is constantly trying to "catch-up" to the jumps in >> > > positioning resolution. >> > > I have had direct talks with the Head of R/D at Guillemot in person >> > > regarding this issue, and they seem to think that you guys wouldn't >> notice >> > > it..... I am VERY pleased to see that you have, because PDPI have a >> > > solution for it (USB) that is going to take this industry by storm.

No

Quoted text (16 lines)

>> > > details to be released yet..... but it's going to BLOW every other >> > > controller manufacturer away by a WIDE margin, BANK on it :) >> > > Cheers, >> > > Shumi >> > > > I have recently purchased one of the new Guillemot Ferrari Force >> > > > Feedback racing wheels. I first noticed playing Rally Championship >> 2000 >> > > > that I had much less control in a straight line than with my >previous >> > > > wheels, and that I tended to zig-zag on straight road. I found

this >> to >> > > > be the same in other driving games such as TOCA2. I used DXTweak to >> > > > remove the deadzone (which I thought was causing the problem) >however >> > > > this had no effect. I have done some testing using DXTweak and >other >> > > > games and have found that the steering problem seems to be caused by

Quoted text (9 lines)

>a >> > > > lag between the input (my movement) to the output (down the USB >port) >> of >> > > > the steering wheel, i.e. as you turn left or right from any >stationary >> > > > wheel position it takes time for this to be registered as movement, >in >> > > > fact it is possible to move the wheel very slowly and for it to

take

Quoted text (13 lines)

>> > > > ages for the movement to be registered. This is obviously not good >in >> a >> > > > racing game, as it prevents the fine control necessary to get fast >> > > > times. >> > > > This does not appear to be a problem with the guillemot driver - as >it >> > > > does exactly the same using the thrustmaster force gt driver. The >> > > > problem appears to be introduced by the wheel electronics which are >> > > > probably trying to smooth the output from the potentiometer. >> > > > Is anyone else experiencing this problem?

Andi, I thought the same thing initially and gave the serial port a try - no difference whatsoever. Tim.

Quoted text (153 lines)

> Shumi, > Do you think there will be an improvement if we used the serial port on the > Ferrari Wheel rather than USB? > Andi. > > DirectX has nothing to do with this anomaly and cannot fix it. The problem > > lies in the positioning algorithm in the USB chip itself. You can't solve > it > > with software, since it is in the Firmware (like a BIOS)... you are stuck > > with it (if it's happening to you). > > The only way to solve lies with the controller manufacturer. The program > the > > firmware, and they govern the positioning resolution. > > Some companies feel that making an aesthetically pleasing wheel is enough. > I > > think otherwise... I want precision and performance, which is why I still > > use analog wheels with the PDPI L4 gamecard for my steering devices (still > > 2X the precision of any USB wheel out there today). > > Cheers, > > Shumi > > > Shumi : have you tried Directx 7a yet? It is supposed to have improved > > > control of force feedback effects. I am downloading it right now from > > > http://www.microsoft.com/directx/homeuser/downloads/default.asp . I'd be > > > interested in hearing if this fixes the problems you identified. > > > David > > > > I do not have the Guillemot Wheel in my hands yet, but what you > describe > > > is > > > > VERY familiar to me. In fact I can say with 90% certainty I know what > > the > > > > problem is (only 90% because I haven't had the chance to determine the > > > > positioning resolution of the wheel yet). > > > > The problem is "Overshoot" in the positioning resolution. This anomaly > > > > occurs VERY noticeably when you cut into the positioning resolution > too > > > far > > > > to combat mechanical jitter that occurs in the axis. This algorithm to > > cut > > > > into the positioning resolution is in the firmware of the USB chip > > itself > > > > (programmed by the controller manufacturers individually), and using > > other > > > > drivers will not solve it. Here's what's happening in this anomaly; > > > > You have to understand first that you are trying to translate say: 270 > > > > degrees of turn into the game. However if you have cut into the > > > positioning > > > > resolution too much (Guillemots WingLeader USB Joystick is HORRIBLE > for > > > > this...... positioning resolution of 19!), you do not have enough > > > > positioning resolution to translate every degree of turn. e.g. You > have > > a > > > > positioning resolution of 50 that must translate 270 degrees of > > turn..... > > > > leaving you with only every fifth degree of turn that can be > translated > > > and > > > > reported. The way they "hide" this is by registering a change in > > position > > > > whenever the axis is deflected even slightly past the center > (Microsoft > > > was > > > > BRUTAL for this). The problem is that you move the wheel perhaps a > > degree, > > > > and it jumps 5 degrees of turn over (you don't have a high enough > > > > positioning resolution to interpret 2,3,or 4th degree of turn). So it > > > makes > > > > the change..... but it "overshoots" the actual position bye 4 degrees. > > > This > > > > is why when you turn the wheel slowly through the 2nd, 3rd, 4th, and > 5th > > > > degree of turn..... nothing changes (the wheel position is just > catching > > > up > > > > to the jump to the 5th degree). When you turn to the 6th degree of > > > turn..... > > > > the position will jump to the 10th degree of turn, and so on. The end > > > result > > > > in the experience is that you will have slow responses from the > > > controller, > > > > because the wheel is constantly trying to "catch-up" to the jumps in > > > > positioning resolution. > > > > I have had direct talks with the Head of R/D at Guillemot in person > > > > regarding this issue, and they seem to think that you guys wouldn't > > notice > > > > it..... I am VERY pleased to see that you have, because PDPI have a > > > > solution for it (USB) that is going to take this industry by storm. No > > > > details to be released yet..... but it's going to BLOW every other > > > > controller manufacturer away by a WIDE margin, BANK on it :) > > > > Cheers, > > > > Shumi > > > > > I have recently purchased one of the new Guillemot Ferrari Force > > > > > Feedback racing wheels. I first noticed playing Rally Championship > > 2000 > > > > > that I had much less control in a straight line than with my > previous > > > > > wheels, and that I tended to zig-zag on straight road. I found this > > to > > > > > be the same in other driving games such as TOCA2. I used DXTweak to > > > > > remove the deadzone (which I thought was causing the problem) > however > > > > > this had no effect. I have done some testing using DXTweak and > other > > > > > games and have found that the steering problem seems to be caused by > a > > > > > lag between the input (my movement) to the output (down the USB > port) > > of > > > > > the steering wheel, i.e. as you turn left or right from any > stationary > > > > > wheel position it takes time for this to be registered as movement, > in > > > > > fact it is possible to move the wheel very slowly and for it to take > > > > > ages for the movement to be registered. This is obviously not good > in > > a > > > > > racing game, as it prevents the fine control necessary to get fast > > > > > times. > > > > > This does not appear to be a problem with the guillemot driver - as > it > > > > > does exactly the same using the thrustmaster force gt driver. The > > > > > problem appears to be introduced by the wheel electronics which are > > > > > probably trying to smooth the output from the potentiometer. > > > > > Is anyone else experiencing this problem?