This topic is now archived and is closed to further replies.

USB+Fanatec interface for Logitech G25 Pedals+Shifter Proto

49 posts in this topic

Hi all

Here's another prototype circuit I'm working on. It will allow both the

Logitech G25/27 Shifter+Pedals to be used as a standalone USB device

for PC or be connected and fully compatible with a Fanatec wheel.

I know there are similar devices around but I'm learning how to engineer

these things. ;) Once the basic interface is completed I'll add some

LED readouts for the gears and pedal % inputs. The circuit is completed

for the pedals and I'm close to completing the firmware to enable them.

Then I'll hookup the shifter and work on the protocol conversion to allow

it to work with the fanatec. A similar circuit could also be used to allow

the fanatec clubsport pedals and shifter be connected to the Logitech

wheel running different firmware, which might be handy for those who

like using consoles.




Share this post

Link to post
Share on other sites

I had a small win this afternoon and have managed to program this device to read all the

pedal inputs by a series of calls to the analog to digital converter (ADC) module of the PIC18F.

There is still some fine tuning and performance considerations to check relating to how

the voltage levels are sampled by the ADC but the basics are working.

I was thinking about other features I could add to it. One thing that might be worthwhile

is something to help in the situation where the potentiometers are wearing out and starting to

spike, so I could add a kind of filter to smooth out the noise so they are usable a while longer.

Any thoughts ?


Share this post

Link to post
Share on other sites

You want a software filter on the chip or analog?

Software is simple enough but takes processing cycles. The minimum update rate of USB leaves you some room to play, but not a massive amount. Sample each pedal as many times as possible and average the results, throw out the highs and lows. It works pretty well, but it's not perfect. Analog is superior in this respect at these speeds. Even more superior is a combination of the two.

I actually make and sell an analog filter that was designed to defeat these issues with the Fanatec pedals. You can see them here: I'm in the middle of adapting this to work with the Logitech pedals as well.

I'm also basically done creating a 12bit USB board that can be placed in the CSR non-elite pedals, I just haven't released it yet. It's not necessary specific to those pedals though, you could use it with any pedals. The device uses a combination of software and hardware filters and is quite steady.

I would be more curious to see what you find out about the Clubsport pedals to be honest...

Share this post

Link to post
Share on other sites

Hi MrB

I was considering oversampling and averaging, maybe figure out some algorithm to

discard the spiking values. The clubsport pedals use serial bus to communicate with

fanatec wheel. It would'nt be too difficult to trace the dataflow and figure out

the protocol structure. I'm busy looking at some of the performance characteristics

of this ADC in the 18F. For starters I'm thinking it would be better to hookup a

multichannel ADC device from Maxim to sample/convert all the pedals at the same time.

The resistor network I currently use on the interface to the pedals does not present the

full 5v range to the ADC so I was wondering about setting the Vref+ pin to the correct level.

I would think you lose resolution not setting the range it samples over properly.

Ultimately someone needs to engineer a clubsport update for the logitech pedals

so they use optical encoders or magnetic discplacement sensors. Alloy pedals

with race/bearings etc. I think thats where I'm heading with all this.

The filtering is just temporary fix. If I gather enough momentum then I might

considering producing some products too. I have about 6 month window to create something

worthwhile. ;)

Hey great job with the PF1 MrB nicely engineered. ;)

Share this post

Link to post
Share on other sites

I've done some testing with the MCP3204 from Microchip. Interfacing it is a simple task. The chip uses SAR (successive approximation) and is quite fast at 100k samples/sec. I've also just done this directly with one of the 18F chips. I haven't really made up my mind which is better. The cost is relatively the same whether you go with a cheaper USB enabled PIC and the seperate ADC, or the PIC with USB and 12 bit ADC.

I figured the Clubsports were using some serial protocol for communication. (I don't have a set to mess with) This would be why they will not work with my filters. My filters just filter it into a static voltage lol :) This makes me wonder though, why the heck did they leave the resolution at 8bit when connected to the wheel? oh well.

As for the voltage levels, I talked about that pretty extensively in another thread here, though I'd need to go find it. The Fanatec wheel auto-calibrates each pedal after it's been bound to the host machine. In software it's taking whatever the "max" position set for the pedal when it's pressed and making this the new max range. Unfortunately, this also means that resolution is SEVERELY impacted until full travel is reached and even then it's not the full 8 bits as it's typically only using about half the range as you can see here:


I have overcome this with a load cell brake I am about the release. ;) The brake is made to be usable with any wheel. Sorry I can't post a shot of it yet here, but rest assured it works quite well and I use it every day. :) The other pedals are too follow... I have to finish up the first one, first, instead of getting ahead of myself and disappointing folks.

Your efforts with regard to all of this is much appreciated by myself and the community. I have a lot of these types of conversations at another site "behind closed doors" It's nice to see another racer interested and involved in such things.

Share this post

Link to post
Share on other sites

I'm using the MPLAB ide v8.76 with C18 (free one). Problem with the free C18 compiler that after

its evaluation period terminates it does'nt optmise code as well and things like the bootloaders

Microchip provide dont fit in the chip memory anymore. Also using MPASM on occasion for assembly.

I think Fanatec engineers might have gone with 8bits as its probably what Logitech use. Either way

they only allocate 8bits for each pedal within the USB report descriptor.

Both the Logitech buttonboard in the shifter and the Fanatec button board in the wheel use very similar

circuitry to read the button matrix and pipe the data out on a serial bus. I was a little more impressed

with the compactness of the G25 mainboard, planning to take closer look at it soonish.


Share this post

Link to post
Share on other sites

Well that's the problem with using 8 bits though... The Fanatec wheel is using it's auto-calibration of the pedals to always map the range being used on the pedals to the 8 bits. This is great in theory, but doesn't actually work. Sure, the wheel puts out numbers between 0 and 255, but there's gaps in that range. I wonder if the Logitech pedals are using a different range for their ADC. I believe their voltage goes UP as you press the pedal, as opposed to the Fantec which goes down. That's simpler to deal with usually when defining VREF. Let me know on the Logitech voltage direction... I haven't tested mine and I've been curious.

Does the 18F chip you are using have a - VREF setting? (which chip is it btw) If so, that's what you need to use with the Fanatec wheel. Set the +VREF at 5V and the -VREF at maybe, 2V. This leaves some room as not all the pedals move the same distance. You can only go within like 2.5v of the positive rail I think, but it should be close enough to almost double the actual pedal resolution.

Share this post

Link to post
Share on other sites

I'm using an 18F2550 , yes it has both VREF+ and VREF-, theres quite a few things to consider to make

the ADC perform. I have a bit of reading ahead of me to understand it better.

I checked the voltage on the 9-way D plug for the G25 pedals and they're all high 5v going low when you press the pedal.


Share this post

Link to post
Share on other sites

Thus far regarding the performance of my circuit I've determined that I have the following

- 10bit resolution for ADC

- USB allocates 8bit values to each pedal axis

- 12 Mhz input frequency, MCU frequency 48Mhz (PIC18F configured to use HSPLL)

- Aquisition time (SAR needs enough time for holding capacitor to charge up)


TC= -(CHOLD)(RIC+RSS+RS)ln(1/2048)


TC=-(25 pF)(1k+2k+16k)ln(0.0004883) us = 3.62 us

TACQ = 0.2us + TC + 0 = 3.82 us

TAMP=0.2 us amplifier settling time

TC = holding capacitor charging time

TCOFF = temperature coefficient (neglect for less than 25C)

RIC=1k Interconnect resistance of ADC

RSS=2k Sampling switch resistance

RS= 12k to 16k max Resistance at the source (this effects offset voltage of ADC output)

- Conversion time (time required to obtain the digital result after analog input disconnected)

The A/D conversion time per bit is defined as TAD.

ADC requires 11 TAD per 10bit conversion, it must be as short as possible but greater than

the minimum required TAD. ( docs assume min req TAD = 0.8 us)

A minimum wait of 3 TAD is required before the next acquisition starts.

Initially I chose 20 TAD and 64TOSC for the acquisition/conversion timing just to test things but now

I want to determine the best possible sampling rate given that the system clock FOSC=48Mhz

and my calculated TACQ=3.82 us ( I had some help with the next part, take the red pill ;) )

Calculating the conversion timing settings:

FOSC=48Mhz gives TOSC=1/48Mhz ~= 0.02083 us

TADmin/0.02083= 0.8/0.02083 ~= 38.4

thus for the TAD to be longer than the min I need at least 38.4TOSC

So we need to choose the next highest available setting 64TOSC (ADCON2 bits 2-0) or 750Khz

Calculating the acquisition timing settings:

64TOSC = 64x0.02083 us ~= 1.33 us

then TACQ/1.33 =3.82/1.33 ~= 2.865 TAD acquisition time

So we choose the next highest available 4 TAD (ADCON2 bits 5-3)


- LSb = Vref+/2^10 = 5/2^10 = 4.88mV per bit (ideal scenario)

- ADC input pin sees voltage range of 0 to 2.2V (in my circuit)

So this means I'm using around 450 out of the possible 1024 steps

for sampling this 2.2v range. Which is about double the possible

range of values that is sent to the computer over USB.

It takes TACQ+(11TAD)+3TAD = 3.82+(11x1.33)+(3x1.33) = 22.44 micro seconds to sample and convert

each pedal axis in sequence including acquisition delays and then additional time to prepare and send

the data over USB. So Total time to sample and convert 3 inputs is 67.32 microseconds, with a max

sample rate of approx 45k samples/sec.

Now my head is aching ;) We will neglect all the other errors for the moment

but the offset error due to the input resistance of the pedals is significant in

my circuit and it needs to be subtracted from the final sampled result. This is

my first attempt to crunch the numbers on this ADC so if you see any obvious

mistakes please post a fix. Its also worth noting that these potentiometer type

pedal systems are likely susceptible to thermal changes so keep them cool ;)

Ignoring for the moment:

- Accuracy ??

- Differential non linearity ??

- SNR (on inputs) ??


Share this post

Link to post
Share on other sites

My inner geek just loves the Microchip datasheets. It makes me feel smart to read them sometimes and dumb other times. :) Information overload!

I didn't check your calculations on the ADC conversion, but it does look about right to me. For the purposes of this they aren't absolutely critical but it's certainly good to go through them so you know what the circuit is doing, how many samples you can read before you need to update the USB, etc. What you have sounds just about right though. However, now you need to do another calculation to figure out how large of a sample size you can get and still update the USB quickly enough that it's silky smooth. So if you can sample each ADC input at 192k samples/sec, you need to think about how often you will be sending this data to the PC. I believe USB "talks" about every 1ms, just to maintain it's connection, but you don't need to be sending data this quickly. Concentrate on how often new data is sent to the computer instead, as that is what the user "sees." For now, lets go with a 60 samples/sec update rate on the computer.

You have 3 pedals, they can sample at 192,000 samples/sec., you need to get the process done 60 times per second with room to send the data as well. (I'm gonna leave the last part out for now)

So, we do 1000/60 to get our update rate which is once every 16.6666 ms.

Divide this by 3 because we have to do it 3 times, so 5.5555 ms per pedal.

192,000/1000 gives us our samples/ms which is 192.

5.5555 * 192 = 1066 samples per pedal for an update rate of 60 hz. Note: Don't get this backwards, it's not necessary to sample at 1066 samples to get 60 hz... It's the max samples you could take and maintain a 60hz update. (and doing nothing else lol)

That's entirely theoretical though because you're going to quickly hit the speed cap of USB full speed and it's not taking into account doing ANYTHING but the ADC. :( This is why I said I was going to leave that part out as it depends on your HID descriptor size. Bulk transfer can help get around this, but the Microchip USB stack didn't previously support this. In the circuit I was working on I was able to easily hit 64 samples per pedal and not run into bottlenecks. This provides very steady results, especially when combined with an analog filter.

I hope that helps some :) Though you probably already thought of it :)

Share this post

Link to post
Share on other sites

Thanks for the feedback MrB very appreciated. I've made some corrections to my

previous post I think its getting closer to being more accurate. The timing

calculations for setting up the ADC is bending my head a bit. I know it will probably

work fine with the slowest config but I like to run it flat out. I'll be testing my

new calculations later today. Hooking up the shifter next ;)

Share this post

Link to post
Share on other sites

Well it appears that my calculations were ok. I've used the GT3RSV2 report descriptor in

my firmware temporarily so the driver loads up on the PC with the nice bar graphs.

I've tried sorting an autocalibrate feature so it maps the sample range to an 8bit value

which is not quite working properly yet but enough so I can see that each of the pedals inputs

are being sampled ok at the higher data rate which is great.

I'm using an interrupt driven bulk transfer process for the USB so it handles all the housework

itself and only sends data when something has changed on the inputs so its not continually

flooding the USB with data and also place excess load on the PC. So all I do is run the PIC18F

flat out in a loop to poll the ADC and buttons, I keep the last state of all the buttons and

sampled data and compare to the newly gathered set and if there is a change I place it in the

outbound USB data buffer which causes an interrupt bulk transfer to the PC. So when you thrash

the pedals and buttons driving it just goes as fast as it can handle the data. I'm yet to build in

error handling and compensation for the data range returned by the ADC. Who would have

thought engineering pedals was so friggn tricky. 8)

Share this post

Link to post
Share on other sites

ok things are looking good so far. The data returned by the ADC for each

pedal is around the 50 to 450 range the +50 offset is a result of the input

resistance of the pedal circuitry causing the ADC to skew the values.

We need to scale and translate that data range so we have something

that fits in 8bits giving us values 0-255 required by the USB protocol &

fanatec PC drivers I'm currently using. This is the function I used to translate

and scale the ADC data f(x) = (b-a)(x-min)/(max-min) + a



min=least value returned by ADC

max=max value returned by ADC

x=current data sampled

Oh the reason why my auto calibrate was failing previously was due to limitations doing floating point

arithmetic and mixing integers within the calculations. It appears C18 has its limits. So if you keep

all your data types FLOAT all is good.

This all works fine but there are some errors seen when the pedal is not being pressed

due to inconsistent readings from the potentiometer as a result of the slop in the gearing

the pedal moves to turn it. So I need to add a little deadzone to account for that.

Other than that its working well to this point and I'm ready to hookup the G25 shifter ;)

Share this post

Link to post
Share on other sites

Hey MrB do you realise that the filter you have developed for the Fanatec pedals

could be used to filter their shifters as well as the Logitech one.

Another method for filtering I was considering is just discarding values when compared

to the previous sampled value are just way off and physically impossible for the driver

to move the pedal that fast. It might be possible to also log the pedal position where the

pot is going bad and then oversample it to try get a good value or just ignore and hold

the previous value or even interpolate where the data is heading and guess a value.

I've finished wiring up the Logitech shifter to my circuit and its working ok electrically.

I've started working on the firmware now to read the x, y coordinates for each gear.

After that works I'll try interfacing the G25 button board and sort the reverse button.

I found an LCD display in my recycle bin from an old DEC server I trashed years ago so I'll figure out

how that works and get the thing to display gears and pedal position data.

The logitech pedals will work fine on the Fanatec as its just a direct connect and same for the

shifter but you lose the button board and reverse gear unless some serious hacking is done.

I think just having the Logitech H-shifter forward gears will be ok, its still better than the

Fanatec H-shifter IMO. You could just assign reverse to a wheel button. What do you think ?

Share this post

Link to post
Share on other sites

The pedals are working great. I have the firmware reading the shifter axis

data and have just finished hooking up an I2C bus LCD display/button board,

which I'll use to display gear selection and percentages for how far each pedal

is pressed. I have to write all the functions to drive the display which will take

a little longer to sort. Its fairly old and I was lucky to found some datasheets on it.

Then I'll have to program the gear detection, calibration routines and some io

routines to talk to the G25 shifter button board.

Here is what its looking like. Its getting close to completion, theres only

the fanatec ports to hookup and the data feed from the G25 Shifter

button board to connect.


Share this post

Link to post
Share on other sites

Sorting out the signalling for the LCD display forced me to understand

precisely what the instruction cycle TCY rate is. So when I went back

to check the clock rate of the 18F MCU I discovered I had configured

it for full speed USB operation 48Mhz and also the core clock of 48Mhz.

USB forces design constraints on the clock you select depending on

your decision to employ low or high speed USB operation for the PIC18F2550.

HSPLL_HS tells the chip to use the external oscilator and enable the PLL,

which then allows you to clock the MCU with configurable frequencies from the PLL.

With an input frequency of 12Mhz this is divided by PLLDIV and fed

into the internal PLL circuitry which puts out 96Mhz. This is then

divided by USBDIV to produce 48Mhz required for full speed USB operation.

So this then leads me to realize I've made some more errors with my ADC

calculations based around 12Mhz instead of 48Mhz . I'll recalculate and

edit my previous post.





This is a nice intro on how Phase Lock Loops work by a couple of amazing engineers.

Share this post

Link to post
Share on other sites

This is my initial testing of the LCD display


This is the layout I'm planning to use to display the

gear selection, clutch ,brake and accelerator percentages.

This display would not be the final type used i'll likely go for some nice round

LED dials or something. I could also store the telemetry data on SD card

for later analysis. It would be nice if the console sims gave easy access to the

telemetry like most PC titles do.


Some more coding ahead to make the display update in realtime as the

pedals and gears are moved.


Share this post

Link to post
Share on other sites

I've written a driver for the I2C LCD and completed the programming to decode the gear selection.

The display now updates in realtime showing the percentage each pedal is pressed as well

as the selected gear. The pedals autocalibrate after one complete press of each pedal and I've

builtin a reasonable deadzone to account for thermal drift and mechanical slack. I've wired up the G25

shifter button board and am just about to write a driver to access all the button data. Heres a short video of a recent test I completed showing the operation of the circuit with the G25 pedals and shifter connected

via USB to a PC Laptop. I'm currently using the Fanatec report descriptor for USB initialisation so

it loads up their driver to process the inputs on the PC side. Its fairly easy to make it emulate any

manufacturer pedal type.


Share this post

Link to post
Share on other sites

Well I have the G25 shifter button data clocking into the PIC18F ok. Just need to tidy up the code

and figure out the matching bits within the USB protocol that fanatec use.

I noticed that the G25 has an 1k SPI Serial CMOS 25c01 EEPROM inside, does anyone know

whats stored in it? When you turn on your G25/27 Wheel with everything connected

the flashing power led on the shifter indicates that the EEPROM chip is being accessed.

The G25 has a couple of 74HC165D 8bit shift registers to latch all the button data in,

you just do a parallel load followed by 16 serial reads to get the lot. I'll test out the

Microchip SPI lib and extract all the data from the eeprom for look ;)

The final step is to connect up the Fanatec ports. The challenge I face is to keep the

LCD working whilst the circuit is interfaced to the fanatec wheel.

G25 Shifter Pinout:

Colour Dplug Description

Black 1,9 +5V

Red 5 SPI input

Orange 4 Axis X

Green 8 Axis Y

Yellow 3 !CS & !PL

Purple 7 Clock

Grey 2 Data

Black 6 GND

Share this post

Link to post
Share on other sites

I was wondering if anyone here has figured out how the force feedback (FFB) protocol

works on any of the wheel technology thats currently available?

I was hoping the wheel did all the calculations from the sim telemetry to determine

how to drive the FFB motor but as far as I can tell its done inside the PC/Console

and it sends out commands to the wheel to control it. Some details on this is covered

in the USB HID specifications.


Share this post

Link to post
Share on other sites

I completed all the G25 shifter button decoding last night (except the seqential shift)

and translated the buttons to the equivalent set on the fanatec wheel. So the top

four map to the right spoke, the Dpad maps to the lower spoke and the four red buttons

map to the left spoke. I'll map the Logitech driver later so it can do both.

Also I have the reverse gear working. The G25 reverse and 6th gear positions are

about same so the G25 has a switch on the bottom of the stick that activates

when press the stick down and put it into reverse.

The one thing I do not like about the operation of the Fanatec shifter is the way it seperates

the reverse and first/second gears with a springy piece of foam. I prefer the more solid

feel of the G25 shifter to locate the gears. Slam the stick left then up/down for first/second

whereas the fanatec you hit the springy foam and risk selecting reverse or missing second.

I've started working on the SPI code to read the firmware in the G25 shifter and also

figuring out if I can keep the LCD display going when the circuit is connected to the

Fanatec wheel. The problem is I have to bypass the resistor network used on my circuit

and connect the pots directly to the PS/2 port for them to work. Also the gear shifter

is operating on 3V not 5V on the fanatec due to the different MCU it connects to.

So for the LCD to work I'll need to connect my 18F ADC ports to the input side of the

PS2 port which feeds the wheel without upsetting the voltage levels the wheel uses

but adjusting the levels so it functions ok with my ADC. I'm not sure what effect

it will have with multiple ADC sampling the same circuit.

Thus far I've added some jumpers to select between USB power and PS2 power, also

one for operating the gear shifter on 3V or 5V. Figure I'll just test it all works without

the LCD first then do some calculations to see if I can design a resistor network

that allows everything to work together. ;)

Share this post

Link to post
Share on other sites

Still working on the sequential shift code. Sorting a bug.

I've decided to add a menu feature to the circuit so you can tweak a few things.

Specifically the gear shift thresholds and the pedal deadzone thresholds and

also a reset button to force a recalibrate of the ADC.

So if you are doing a long race for some reason and the mechanics of the pedals change or the

ambient temperture causes some drift in the readings effecting the inputs then you can

just hit a button and it will auto recalibrate the pedal ranges again, no need to power cycle the wheel.

Also if your pedal pots have alot of slack in them you can adjust the deadzones so no annoying

pedal zero problems. Similarly on the gear shifter you can adjust where along the throw of the

stick it locks into gear, this allows some performance gains in shift speed.

I'll also put the pedal spike filter feature in a menu option so you can turn it on or off.


Share this post

Link to post
Share on other sites

I'm winning ;) Sorted out the sequential shift and tweaked all the gear thresholds manually

and testing it all out on the PC. Its working sweet. Its taken me about a year from knowing

zippo to re-engineering the architecture of a fanatec GT3RSV2 and creating a circuit

that lets the G25 shifter and pedals work on a PC standalone over USB with LCD readouts

for the gears and pedal percentages.

Next is the menus to allow manipulation of all the settings and save them in eeprom.

Followed by interfacing the whole thing to the PS2 ports on a Fanatec wheel and

keep the LCD working and hope this 18F MCU does'nt run out of memory ;)

I need the full blown version of the Microchip C18 compiler to optimise the code

better. The lite version is lagging me on the bootloaders too due to its optimisation

limitations, problem is the full version costs lots of $$$. If I resolve the LCD issues

the circuit will also allow the clubsport pedals to be connected to take advantage

of the display. I thought I'd keep the cheap LCD display when I build the final version

and add a port to allow extra dials to be connected ... nice big eyecandy ones ;)

Something like these ones

but cheaper.

Share this post

Link to post
Share on other sites