Custom G27 controller programming

[sesselpupser]

Here's some info, finally...

So I've been having a play around with Wireshark, basically hammering buttons and jiggling axes while it sits there logging away, as well as playing a few seconds of Assetto Corsa (which garnered 12,000 reports). Here's what I've found with regards to interrupt transfers from the G27 to PC.

The 'leftover data', i.e. data that concerns the actual inputs, looks like this when the wheel is idle:
08 00 00 e8 7f ff ff ff 73 78 9c.

And from what I've gathered so far:
08 00 00 is button states, but I'm not sure why one bit is held high. I haven't tested all of the buttons yet, in fact I've only really done the ones on the wheel.
e8 7f is the encoder counter.
ff ff ff are the pedals, accelerator, gas and clutch from left to right. They all drop to zero, of course.
73 78 is the shifter position, the first byte is the x value and 78 is y, x ranges from 2a to a4 and y ranges from ea to 03. That's interesting because I really thought the microcontroller was doing that conversion, but it's really taken straight from the ADC.
9c is unclear, but I know it changes to dc when the reverse button in the shifter is held down which means it's going from 1001 1100 to 1101 1100, so the second bit is the reverse button.

Annoyingly, there's a tiny bit of jitter in the shifter x and y values which makes the wheel spit out tons of transfers when nothing is happening, so it might be worth modifying the shifter with a switch to add some capacitance to smooth that out or just ground it completely while testing... Who knows if or when I'll get time to do that, though?

I can't make much noise now but that's some decent testing for now, not a big breakthrough but it's interesting and useful to have written down all the same.

 

[sesselpupser]

Now I'm looking at two logs I made of the initial enumeration of the G27. At first the device is seen as a Logitech Driving Force at 3.6.0 (if I understand the addressing correctly that means it's the 3rd port of the root hub, 6th device connected to it, 0th endpoint - the control endpoint), then there are a few interrupt transfers whose data structure doesn't match my previous post, then a new device at 3.7.0 enumerates as a Logitech G27 racing wheel - @Outspacer, you were right, good call!

So now I have a different descriptor, here's a link to it on Pastebin (since I'm using Wireshark on a work PC but I'm using my phone to post this): Pastebin.com/A2UrAMMu

I'm not sure if it has been parsed correctly but I'll have a look at it to see if it matches the data structure from my last post.

 

[Outspacer]

Ah-ha! That's more like it. Seems to match, at least on the bits that align with bytes. The wheel encoder is only 14 bits of that e8 7f, for example - I think it's LSB first, so the first 2 bits are the low bits of the '8', and part of the preceding 22 bits worth of buttons. The high bit in the first byte must be the 'null' state of the d-pad. The last byte is curious, defined as 1 bit then 7 bits - I wonder if one of the bits changes if the shifter is unplugged?

 

[sesselpupser]

Here's my interpretation of it:

The thing I'm not clear on is that there are only eight buttons on the shifter and eight on the wheel, so where are the other six? And why are three of them held high? I'd expect anything not used to be held low, especially since the G25 shifter I looked at had pull down resistors everywhere.

Now I have a ridiculous urge to buy another G27, strip it and make a portable development unit for it so I can test on the go! It's not going to happen, though... But it would amuse me, especially because I've always wanted to make a Tomy Turnin' Turbo-based sim rig.

 

[Outspacer]

I think (not entirely sure) that the bits get used from the other end... so the e8 gets split like this 1110 10/00, and the 9c as 1001 110/0, making the button bits 0 as you'd expect. The encoder taken as 7FE8 >> 2 is dead centre of its range, which is nice confirmation.

The excess buttons could just be padding to keep it (mostly) byte aligned. The HID spec allows for specific padding to be defined, but of course it makes the descriptor larger, and there's not much point if you already have a size=1 item you can increase the count on.

Turnin' Turbo with an arduino and maybe a couple of extra sensors could possibly pretend to be a G27....... nope, don't get me hooked into your crazy But thinking about that, makes me wonder if some of those extra bits are for things like endstop sensors (most likely in the S1C7 at the end).

 

[sesselpupser]

I think (not entirely sure) that the bits get used from the other end... so the e8 gets split like this 1110 10/00, and the 9c as 1001 110/0, making the button bits 0 as you'd expect. The encoder taken as 7FE8 >> 2 is dead centre of its range, which is nice confirmation.

I think you're right, I should be able to verify that with the logs I've saved, which I will do ASAP.

Edit: The raw data has the IRP ID 'backwards' (raw: 80 98 47 0c 80 fa ff ff, IRP ID: fffffa800c479880) so it follows that the rest is probably also backwards. What I really need to do is test the d-pad, but what you said about the one high bit in that leading 08 being the null position is probably correct since there's a logical maximum of 7 there - 000 to 111 would cover that range, with the last bit being a null flag... Maybe?

The excess buttons could just be padding to keep it (mostly) byte aligned. The HID spec allows for specific padding to be defined, but of course it makes the descriptor larger, and there's not much point if you already have a size=1 item you can increase the count on.

This makes sense, I was expecting to see padding so this possibility didn't seem too obvious. This is one area that I'd hope a proper map of the controller PCB would shed some light on, because maybe there are some digital inputs that aren't buttons, or maybe there are some input pins that are grounded to give a stable low state. Maybe there's neither and it's just done in software.

Turnin' Turbo with an arduino and maybe a couple of extra sensors could possibly pretend to be a G27....... nope, don't get me hooked into your crazy But thinking about that, makes me wonder if some of those extra bits are for things like endstop sensors (most likely in the S1C7 at the end).

The G27 doesn't have any endpoint sensors, the endpoints are set during calibration. The wheel turns clockwise until it hits the mechanical endstop, then the motor reverses direction until it hits the other end and then I guess it divides the total by two and uses that as the centre. You can stop the wheel manually during the calibration to confuse the hell out of it, but it'll usually just refuse to calibrate. Also if it manages to turn beyond the calibrated range it apparently crashes the wheel until you re-enumerate it.

And what's wrong with my crazy? It's the good kind! I think.

Anyway, I moved into a new flat yesterday and the next three weeks are busy - two funerals, a wedding, a job interview and properly moving out of the other flat I'm leaving - so I doubt I'll get time to do much tinkering for a while.

 

[Outspacer]

I think you're right, I should be able to verify that with the logs I've saved, which I will do ASAP.

Edit: The raw data has the IRP ID 'backwards' (raw: 80 98 47 0c 80 fa ff ff, IRP ID: fffffa800c479880) so it follows that the rest is probably also backwards. What I really need to do is test the d-pad, but what you said about the one high bit in that leading 08 being the null position is probably correct since there's a logical maximum of 7 there - 000 to 111 would cover that range, with the last bit being a null flag... Maybe?

Almost definitely. Although in practice it's probably always 8 as the null value, I suspect the spec says any out of range value is considered null.

The order of bytes wasn't in question, it's the order of bits - e.g. d-pad is first and seems to occupy the low nibble of the first byte, not the high.

This makes sense, I was expecting to see padding so this possibility didn't seem too obvious. This is one area that I'd hope a proper map of the controller PCB would shed some light on, because maybe there are some digital inputs that aren't buttons, or maybe there are some input pins that are grounded to give a stable low state. Maybe there's neither and it's just done in software.

I reckon the only way to work out which bits are which buttons is to sniff the packets anyway. You might see afterwards that, say, 8 buttons are in a byte that corresponds directly to a CPU port, but you couldn't know that without sniffing.

The G27 doesn't have any endpoint sensors, the endpoints are set during calibration. The wheel turns clockwise until it hits the mechanical endstop, then the motor reverses direction until it hits the other end and then I guess it divides the total by two and uses that as the centre. You can stop the wheel manually during the calibration to confuse the hell out of it, but it'll usually just refuse to calibrate. Also if it manages to turn beyond the calibrated range it apparently crashes the wheel until you re-enumerate it.

Ah, I see. Well, there still might be other used bits in that last group of 7 (wondering why there's 4 set bits in there).

And what's wrong with my crazy? It's the good kind! I think.

Absolutely nothing! It is good. I wrote that after I caught myself searching for Turnin' Turbo on ebay

Anyway, I moved into a new flat yesterday and the next three weeks are busy - two funerals, a wedding, a job interview and properly moving out of the other flat I'm leaving - so I doubt I'll get time to do much tinkering for a while.

Wow, that's a mixed bag Good luck in the interview

 

[sesselpupser]

Wow, that's a mixed bag Good luck in the interview

Thanks!

Although I can't do anything with the wheel for now to test the buttons and such, I do have a few logs to look over. One thing I haven't touched on yet is the output frames from the host to the device.

Frankly, the tools at my disposal aren't going to make this easy; the only log I have that contains output frames is over 12,000 entries long for only 40 seconds of captured gameplay - mainly because of the potentiometer jitter from the shifter that results in a ton of useless frames.

Anyway, as far as I can tell there are four different types of output frame: something resembling an idle state, the force feedback state, what appears to be a counter and something else that I can't work out.

Anyway, so the four basic data types I've seen are:

f8 12 00 00 00 00 00 - this is what I think could be an idle state because there's a long string of them before anything else starts happening, but the third byte does change so I'm not sure what that's about. I've seen the third byte appear as 01, 03, 07, 0f and 1f, I've searched the entire log and there were no other possible values for this. It could be the LED data because these would look like 0000 0001 to 0001 1111, maybe I didn't get to the highest end of the LED scale in those 40 seconds.

Edit: this is a bit odd, because the first frame where the third byte isn't 00 shows it as 03, so if it is the shift light then it would've started at the second step. In addition, the bulk of the frames after that point show the value toggling between 1f and 00, which could be the LEDs blinking to indicate that I should shift up, but that would mean I had been redlining the car for the majority of the 40 seconds the log covers, which I guess is possible but I can't remember if I did or not. I'll investigate the timing of the toggle to see if it's a long enough delay to feasibly relate to the shift light blink frequency. Another thing - when the value reaches 1f it seems to repeat a few times before the toggling starts.

11 08 xx 80 00 00 00 - this is by far the most common output and the 'xx' is a constantly changing byte with no pattern and what looks like the full 256 possible states. None of the other bytes change.

21 0c xx 00 xx 00 01 - this looks like a counter. The bytes marked 'xx' are always identical, they start at 0e and count down to 00 (with one frame for each value between the two), then that particular data shape stops appearing, so there's only 15 of these. Sadly the timing is irregular so it's impossible to say what this is keeping count of (the intervals between these frames ranges from 24ms to 104ms).

13 00 00 00 00 00 00 - this is the last type I've seen, it occurred once after 7.25 seconds and didn't show up again until 31.69 seconds, then it occurred a further nine times. Again, the timings are very irregular (between 80 and 912ms) so it's unclear what this could be, I thought perhaps it could be LED data and I never got the LEDs higher than the first step, which perhaps it could still be.

One thing is for sure, I need to test all sorts of different scenarios; games with FFB disabled but LEDs enabled, turning the wheel on the spot, etc. to see what frames I get back from various games.


Edit: Because I'm not quite dedicated enough to sift through 12,000 frames, I've written lists of the occurrences of the f812, 210c and 1300 frames so I can then delete them from a log then check the remaining frames for anything that doesn't start with 1108 to see if there are any other data types I've missed.

 

[sesselpupser]

Here's something new:

Having done all I can think to do with the logs I've got from the G27, I've turned my attention to working out how to write a HID descriptor into a USB device. To that end, I took my Leonardo, uploaded a simple library example HID gamepad program to it, ran Wireshark while it enumerated then went looking in the relevant library for something that resembled the HID descriptor (might be worth noting that Wireshark never managed to grab the descriptor - it treated it as a payload of a different type of communication but I recognised the "0501" at the start). I found something that was identical, changed one value, re-uploaded the code and ran Wireshark again to confirm the value had changed, and it had.

Given that this library makes the Leonardo into a composite device, as it has to to retain the ability to program the device again, I need to look around and find out how exactly it does this. I feel like doing this with Arduino is too convoluted since I'm going to end up (probably) stripping out everything that makes it an Arduino, but it's a useful starting point at least. I wonder, if I'm able to make a composite Arduino/G27 device, will the Logitech drivers recognise the G27 component?

 

[sesselpupser]

As I often do, I've sidetracked myself on this project by buying a Namco JogCon. I read in another thread that early Logitech wheels used the protocol introduced by the JogCon so now I want to bring it back as a USB controller based on the G27 protocol if possible, it should work with a small controller like a Pololu A-Star 32u4. Might be fun! I've made no progress on the G27 itself because work has been hectic on the busy days and I've taken the last three quiet days off for funerals and the interview (in which I mentioned my G27 reverse engineering project as an example of a project I'm proud of).

I think the next step is to work out the HID library's source files to figure out how to reconfigure everything, which is annoying because that's all reading and no practical.

 

[sesselpupser]

In the past couple of days I've programmed my Arduino to have the same HID descriptor as the G27 but I haven't changed the VID and PID so it doesn't actually do anything, and I've taken a quick look at the PCB for the G27's wheel buttons, LEDs and paddle shifters.

I haven't mapped it properly yet because my multimeter is buried, but there's a 74165 for the buttons and a 74595 for the LEDs. Notably they're both 8-bit shift registers, the former is parallel in, serial out and the latter is the opposite, but there are ten LEDs in the wheel itself so it seems sensible to assume that three of the 595's outputs are floating and the other five are connected to pairs of LEDs, which is supported by the fact that the LEDs light in pairs from the outside to the inside. This also supports what I said about the 'f8 12' input frames - that the third byte's range from 01 to 1f was probably the LED data - so I think that's that confirmed, but I obviously have more to test.

Also on the board are two SOT23 components with '1AM' codes, that seems to point to MMBT3904LT1 transistors - basically just tiny 2N3904 small signal NPNs. I want to say these are probably LED drivers, but if they are, why are there only two and not five? I expect properly mapping the PCB will answer that question.

The other components are:
Fifteen 10k resistors (eight pull resistors for the switches, I don't know what the others do yet)
Four 75r resistors
One 220r resistor
Two 0r resistors
Three capacitors with no markings (why don't they ever have markings? But I think they're decouplers for the ICs and... Something else)
Ten LEDs
Two microswitches
Three locking headers (two 4-way, one 7-way).

The two 4-way headers are for the three buttons on either side of the wheel (three signals and ground, or Vcc, it's surprisingly hard to tell), the 7-way is probably Vcc, ground, clock, serial in, serial out, RCLK (I forget what it's called, the 595 input that pushes the register's data to the output pins?) and !PL (the 165's parallel load input). So... All pretty obvious assumptions so far!

Edit: I've now mapped the PCB and since it's such a slow work day today, I've even drawn a quick schematic for it:

... Except I've just noticed I've drawn the first eight resistors as pull ups rather than downs. And I've forgotten to include the paddle switches. Oops!

Also, for what it's worth it looks like the microswitches are Zippy SM series, they could be SM-P1 S-01 P 0-Z. The only parts I'm not certain about are the P1 (100mA rating, 5A is '05') and S, that's the code for standard force.

 

[sesselpupser]

So I ended up making an "Arduino as ISP" programmer out of an old Nano board with wonky headers, I had to cut the reset trace to the ICSP header, solder a 3x2 header on the bottom and a jumper from pin 10 to the reset pin on that header, but it's not bad. It's definitely a fake Nano because the LEDs are retina-searingly bright (and all the same colour) so I don't feel bad about modifying it for just this one purpose, either. Now I don't need to worry about breaking the Leonardo's programmability by changing the VID and PID because it's no longer being programmed directly, and I believe this means I don't need the bootloader so I think programs can occupy more space... But I don't know how to test that.

Edit: We have something kind of resembling lift-off! I programmed the Leo with the G27's VID, PID and HID descriptor, installed the G27 software on my work PC and it detects it as a G27. None of the inputs do anything yet, but it's promising!

Edit: My mistake, something has gone wrong which is preventing the IDE from using the correct HID descriptor and I don't know why. However, that does mean it seems like the driver software will respond to any HID descriptor, as long as the bits are in the right place. This should hopefully mean it's going to be easier than I thought to get this working, but who knows?

 

[sesselpupser]

I decided to pull the main PCB out of my wheel to get a closer look at the components on the board, to be honest I'm not convinced this is strictly necessary now that I've examined the USB data but - provided I can avoid the temptation to buy another G27 so I can desolder and test individual components - I figured there's no harm in having a look.

So far I've found lots of resistors and capacitors that are too small to have values printed on them, an extra MOSFET that the G25 didn't have, t04 and t06 transistors that appear to be SOT23 2N3904s and 2N3906 BJTs, A7 diodes which are the same BAV99 diodes as on the G25's board, but I've been too scared to take the board to work to analyse it properly so I haven't got a schematic for it.

I've just received the GT Omega wheel stand I ordered too... But I dug my multimeter out last night in preparation for some mapping, so hopefully I'll get time to do some before I reassemble the wheel.

 

[sesselpupser]

Wow, it's been longer than I thought. I've not forgotten about the project but it has been placed on the backest of back burners due to my new job which I'm still adjusting to - I've gone from 8am wake ups and 11pm bedtimes to 5.30am wake ups and bed at 9! Also the job gives me very little free time, my last was entirely dead two days a week. I'd also reassembled the wheel to take the GT Omega stand for a spin but it's in pieces again now, pending motivation to get probing which has been in short supply lately.

I'm still planning on mapping the PCB so I can make a schematic for it, I'm also still thinking about buying a second G27 purely to solder on test leads and all the rest of it but that's highly unlikely for obvious reasons. I do want to make a bed of nails test rig for the test points on the bottom of the board, though...

 

[PinealServo]

Hey, I just got a bunch of parts from a pair of G27 controllers that were used in a demo platform at work, but were no longer needed. I've assembled a complete wheel... except for the controller board. I guess one of them got trashed, and the other remains with the demo platform. So, this project to emulate a G27 controller from a cheap microcontroller development board is very interesting to me! Fortunately, the pedals and shifter I've got (both pairs!) are unmolested, and I think all the sensors, motors, and buttons in my wheel are intact.

I'm an embedded software engineer, so I started my research on the software side. From my understanding, the main portion of the controller is a straightforward USB HID game controller using the optical encoder on one of the motors to give wheel position information. The tricky stuff would be the force feedback implementation, but Logitech has released a document describing their force feedback descriptors!

The GIMX project has also done some reverse-engineering of the G27 USB descriptors that it uses when communicating with a PS3; hopefully it's largely the same as when communicating with a PC or other host.

There's also a project I found that used a STM32Discovery board to implement a USB force feedback controller; unfortunately for me it's a German-language forum and it also appears to have crashed since I was looking at it, but I think if you register you can grab the source code from a link there, assuming it's recovered from its crash when you read this.

My plan is to use an MSP430 USB Launchpad to do my initial prototyping, since I've got one handy and it's got a USB driver framework that supports the HID profile. I'll first get the "controller" bits connected and working, including quadrature decoding for the optical wheel position sensor, which should be fairly straightforward. Then it'll be time to decode the force feedback controls from the host and figure out how to map those into PWM outputs to an H-Bridge motor controller (the protocol description goes a long way, but there are still a lot of details left vague that would be a lot easier to figure out with some hardware to probe); designing the motor driver is a bit beyond my electronics experience right now, but hopefully I'll be able to find a reasonable design to start from somewhere.

Anyway, if you're still working on this, I'd be willing to switch over to an Atmega32U4 (the processor on the Leonardo) platform for my controller so we could share software; I haven't done much with Atmel controllers and this would be a good learning opportunity. I'm impressed with the work you've done so far figuring out how the hardware and software work, so I hope you do continue!

 

[sesselpupser]

@PinealServo oh wow, thanks! To be honest my job is sapping my enthusiasm for hobby projects - I fix stuff all day so coming home to do more electronics work is a bit offputting - but I will need a new lunchtime/after work project after I start then finish the Baby10 sequencer I've wanted to make for ages so I'll probably get back to it. As an added bonus I now work with some talented people with a broad array of skills (though microcontroller programming is kind of my thing so I probably won't get much help with it).

The other branch of my project was to build custom hardware for my custom controller to, er, control, I think that might be coming back to the fore because we have a mill and lathe at work so I can actually make components now (in theory). I was talking to a colleague about it today, actually, but that's a story for my other thread.

It's great to know I'm not the only person curious about the possibility though, thanks for the links!

 

[PinealServo]

I decoded the example force feedback reports via the Logitech documentation; you were pretty good on your guesses!

Normally, the first 4 bits select the "force slots" the command applies to, then the next 4 bits are the actual command, although 0xf8 is an "extended command" that doesn't apply to force slots. The next byte is either the type of force or some other param, and the rest are command/force specific parameters.

Anyway, so the four basic data types I've seen are:

f8 12 00 00 00 00 00 - this is what I think could be an idle state because there's a long string of them before anything else starts happening, but the third byte does change so I'm not sure what that's about. I've seen the third byte appear as 01, 03, 07, 0f and 1f, I've searched the entire log and there were no other possible values for this. It could be the LED data because these would look like 0000 0001 to 0001 1111, maybe I didn't get to the highest end of the LED scale in those 40 seconds.

Edit: this is a bit odd, because the first frame where the third byte isn't 00 shows it as 03, so if it is the shift light then it would've started at the second step. In addition, the bulk of the frames after that point show the value toggling between 1f and 00, which could be the LEDs blinking to indicate that I should shift up, but that would mean I had been redlining the car for the majority of the 40 seconds the log covers, which I guess is possible but I can't remember if I did or not. I'll investigate the timing of the toggle to see if it's a long enough delay to feasibly relate to the shift light blink frequency. Another thing - when the value reaches 1f it seems to repeat a few times before the toggling starts.

0xF8 is the command to access extended commands; these are used to switch identity and device configuration, including device LEDs. It so happens that 0x12 is the extended command to set the RPM LEDs. There are 10 LEDs that light in pairs, so the lower 5 bits of the 3rd byte are a bit-pattern corresponding to which LEDs should be lit.

11 08 xx 80 00 00 00 - this is by far the most common output and the 'xx' is a constantly changing byte with no pattern and what looks like the full 256 possible states. None of the other bytes change.

This is a normal force command; it applies to force slot 1 and corresponds to command 1, which is "load and run force slot". The next byte, 0x08, is the force command to load/run: Force "Variable", which can define a pair of ramping forces with a number of parameters. It only works on force slots 0 and 2, but only force slot 0 has its bit set in the first nibble, so only the parameters corresponding to force 0 will be interpreted. The next byte is the slot 0 starting force, followed by the slot 2 starting force, then the S0 step duration and size nibbles, then the S2 duration and size nibbles, and finally the S0 direction (0 = down, 1 = up) and S2 direction.

If the step size and duration (in "main loop interval" counts) were non-zero, this would define a force that gradually ramped down; with the zeros, I'm guessing it stays constant indefinitely until updated.

21 0c xx 00 xx 00 01 - this looks like a counter. The bytes marked 'xx' are always identical, they start at 0e and count down to 00 (with one frame for each value between the two), then that particular data shape stops appearing, so there's only 15 of these. Sadly the timing is irregular so it's impossible to say what this is keeping count of (the intervals between these frames ranges from 24ms to 104ms).

This is another normal force command applying to slot 1; again it's command 1 to load and run a force. The force command is 0x08, which is a high-resolution damping force. The parameters provide 4-bit linear-scaled spring constant values for left and right rotation, where 0 is the least force and 15 is the strongest force; the actual force value is device-dependent. There are some sign bits in the least significant bits of the two 0x00 bytes, and the final 0x01 is a "clip" parameter.

13 00 00 00 00 00 00 - this is the last type I've seen, it occurred once after 7.25 seconds and didn't show up again until 31.69 seconds, then it occurred a further nine times. Again, the timings are very irregular (between 80 and 912ms) so it's unclear what this could be, I thought perhaps it could be LED data and I never got the LEDs higher than the first step, which perhaps it could still be.

One thing is for sure, I need to test all sorts of different scenarios; games with FFB disabled but LEDs enabled, turning the wheel on the spot, etc. to see what frames I get back from various games.


Edit: Because I'm not quite dedicated enough to sift through 12,000 frames, I've written lists of the occurrences of the f812, 210c and 1300 frames so I can then delete them from a log then check the remaining frames for anything that doesn't start with 1108 to see if there are any other data types I've missed.

This is a normal force command applying to the force in slot 0. Command 0x03 is "cancel force", so it turns off whatever force is currently active in slot 0. This suggests that the "variable" force command with a 0 step duration remains indefinitely until updated or canceled, unless there was some other force that got put in slot 0 that needed to be canceled.

I'm pretty confident that I'll be able to light up the LEDs correctly based on the LED command, but figuring out what to do with motors based on the force commands could be a bit trickier. At least the commands seem to make sense, though!

 

[sesselpupser]

@PinealServo I've been casually skimming through the Logitech document over the past few days, it's very interesting with regards to explaining how the wheels work. For instance, it looks like every wheel since the Driving Force may have been loaded with profiles for every other wheel released up to that date (the 'change mode' section), the G27's LEDs have more states than it first appears - as in you can illuminate each pair of LEDs separately, or do every other pair, etc. - and the 'secret' on-the-fly wheel rotation limiter button combination could be replaced with a much finer method from 40 to 900 degrees.

I don't doubt that the project would've been completely stalled without this document, having seen the detail it goes into, so thank you again for linking it!

 

[PinealServo]

@neema_t I spent a little while poring over the hi-res photos of driver boards and the MCU datasheet that you linked earlier, trying to figure out how the MCU is connected to the motor driver. Only some of the pins are analog capable, and of those only two are PWM outputs. Unfortunately, most of the pictures aren't clear enough to follow traces, there aren't any of the G27 board clear enough to read the text on parts, and there's absolutely nothing showing the back-side of the board. But I was able to make a few guesses about how some of the pieces might be connected.

The really big resistor is a high-power, low resistance one. I am guessing that this is a shunt resistor to measure current, which feeds back into the PWM control somehow. As the current draw is directly related to force applied by the motor, it's a prime candidate for a feedback mechanism in the control loop, and at the very least it must be set up as a hard limit for for current draw to avoid burning out motors and MOSFETs. I somewhat less confident guess is that the G27's extra MOSFET chip and the other somewhat large resistor is related to the alternate drain path that opens as the current limit is reached. And finally, there's a dual comparator IC that could very well be part of the current limiter circuitry, although it's impossible to tell from the photos what it's really connected to. I am very curious about whether one of the MCU PWMs is hooked up to it or whether it's got fixed feedback, and I am also curious whether it's hooked to the motor control or possibly the analog lines from one of the peripherals.

There are a number of ICs available that are brushed DC motor controllers well-matched to the power range of the motors, which would eliminate *most* of the H-bridge motor control circuitry, assuming it's not doing something particularly tricky. Most of them are based around a primarily speed-oriented control loop, through, which is not really what you want for force feedback. Most have a hookup for a shunt resistor that'll give a fixed max current level to avoid burning out motors or exceeding the current rating of the chip, but I did find one that also provides a Vout pin that can be used via an ADC to get direct current level feedback into an MCU control loop, which I am thinking is going to be essential for good force feedback. But that could always be done externally if necessary.

Anyway, if you have any thoughts from the earlier work you did on examining the main control board, I'd be very interested in hearing them. Also, if you happened to take any hi-res photos of the back of the G27 control board, I'd love to look at those too. Not having one in hand makes it a little tricky to reverse-engineer it.

 

[sesselpupser]

@PinealServo I was actually going to take my G27 board to work so I can examine it during my lunch breaks, honestly I haven't looked at it in months so I can't really remember what I found before. I intend to trace it all out into a schematic eventually so that you, I and anyone else can take a look at it but finding time and enthusiasm to work more on electronics when that's what I do all day now is difficult! I'll get a photo of the other side of the board when I remove it from the wheel - annoyingly it had been on my table for months until yesterday, but now it's back in service. Great timing!

 

[PinealServo]

@neema_t No pressure from me; I know how the ebb and flow of hobby project motivation goes. Don't go disassembling your stuff just on my account! But when you get the itch to do it, I'd definitely like to know what you figure out. Meanwhile, there's plenty of stuff I can work on in this project still, and when I figure anything relevant out I'll throw it up here in the hopes of raising your interest level again.

 

[sesselpupser]

@PinealServo

I hope these images are ok, they're a bit distorted because I was photographing them through the lens of one of these lamps in an attempt to reduce the glare enough so that you can read the silkscreen.

Edit: R39 (the biggest one) is such a small value my multimeter can't measure it, it's supposedly 0.15 ohms, 5% tolerance. R28 (the other large one) is 340 ohms, 5%. The former is almost certainly a shunt but I'm not sure what the smaller one is for yet.

Some more component details (I know I've been over a few of these before but it was a while ago so I'm refreshing my own memory as much as anything else):
- U5 is a LM393L dual comparator IC.
- M3 and M1 are 4951GM ICs, M2 is a 9977GM IC.
- U6 and U7 are 74LVC1G08GV single AND gate ICs.
- Q5, Q8, Q10, Q11, Q14, Q15, Q16, Q17, Q18 and Q19, labeled t04, are very likely to be PMSS3904 NPN transistors according to this page.
- Q7, Q9, Q12 and Q13, labeled 't06' are probably PDTC124EU PNP transistors, I think? (Source, actually the same as before)
- D10, D11, D12 and D13 are very likely to be a series pair of BAV99 switching diodes. I can't tell if it's a SOT-323 or SOT-523 package, though, and if it's the latter it could be MMBD4448HTC diodes instead...? (Source)
- Q20 (next to M3) is labeled 702... There are a lot of 702s in this list! But it would appear likely that it's a 2N7002 N-channel MOSFET.
- Q6 (near the crystal) is apparently labeled 01, which would make it a FDG6301N N-channel MOSFET. (Source)
- D14 appears to be marked 50 with a sideways 4, which is either a zener or varactor diode. (Source)
- Sadly, both D6 and D9 are rotated so that most of the letters are obscured. I can only read 'E27A' from the end of the label. D5 reads 'KE27CA', again it's probable that that's not the whole label. This catalogue shows three TVS diodes that match these: P4KE27, P6KE27 and 1.5KE27, where 'A' denotes unipolar and 'CA' denotes bipolar. Edit: The G25 board photo on the first page shows one of the diodes starts 'P6...' so that's that mystery probably solved.
-D2 is almost a complete mystery, all I can make out is the top line of the label starts with 'SB' and the bottom row ends with a 9.
- D1 could be a 4148, it's the right size for a 4148 and in a glass case, I can only read 'PH' from the label and googling 'PH diode' brings up a 4148... Kind of a long shot, though. Edit: Having thought about it, it seems likely D1 is a Zener because the G25 image shows '12' on the same diode and it's in reverse bias - the anode is connected straight to the ground plane.

I think that's all the non-passives.

Oh and:
J1 - USB
J2 - Shifter
J3 - Optical encoder
J4 - Pedals
J7 - PSU input voltage
J8 - Left motor (when looking at the back of the wheel)
J9 - Right motor
J10 - Wheel buttons and LEDs.

 

[sesselpupser]

As I called in sick to work today (for legitimate reasons!), I've spent an hour this morning tracing out what I can of the 24V input jumper. I've traced it to one end - through three resistors, one transistor, one diode and three capacitors, but it branches off near the start and that route is up to four resistors, one cap, one diode, one transistor and one IC so far, and I can see another via so I'm not quite finished. I'll post up the HAD (hand-aided design) result when it's done, but at this rate I'm beginning to suspect the ENTIRE board is connected to this jumper.

Edit: I think I traced it all the way out, but I didn't do the other side of the MOSFET and the pencil drawing is terrible so I'll wait until it's more complete. I've spent a portion of today counting vias and test points using the photos I took, but I need better ones to get the alignments of the photos consistent so the vias line up. Then I should be able to map the board out quite a lot easier, and I'm not sure why I put this off for so long.

 

[sesselpupser]

So my attempts at mapping the PCB have pretty much failed so far because I keep getting confused, so I keep starting all over again. What I want to end up with is a series of circuits that start at a specific point, say a microcontroller or jumper pin, then end... Well, wherever they end. The problem is it's hard to keep track of which components I've already traced out so I end up testing some I've already done and I get sidetracked.

So to solve this I think I need to do it all photographically; take some master photos and use layers to show what connects to what, of course backing it up with multimeter testing. I also thought of having a spreadsheet of each labelled component, giving each pin a number (i.e. R45.1 would refer to the left or top pin of R45 depending on whether it's horizontal or vertical), making a grid reference system and then making a note of which other component pins each pin connects to, which is basically a lot like SPICE.

The result of that should be something I can turn into a complete schematic, but it'll take a while, so I think that's what I'll start on tonight if I can find the time.

 

[taoladuy24]

Hi guy. I have a logitech G25, it's not working now, can not calibration, steering wheel turn left and stop, not return. But, the H-Shifter, brake, some function, and clutch still working well. I was found some solutions for "logitech G25, G27 won't calibration": change encorder disc. But not solved for me. It has an analog encorder, i was check it by Volt, Ohm multimeter, it's well working (while turn steering wheel, the voltage level changed 0V~4.6V~0V~4.6V~...). So, i think encorder no problem. I was found ST72F651 pinout, and check all of VCC, VDD, GND pin, everything is OK. So, i think microcontroller not convert and tranfer data from encoder to PC, or some program, some function inside the microcontroller is error. I can order new one ST72F651, but i has not program to load into this IC. So, i think the motherboard must be replacement by new one.
Can i order only motherboard? And where? Pls tell me if you know

Sory for my bad english

 

[Kolyanovich]

Hi guy. I have a logitech G25, it's not working now, can not calibration, steering wheel turn left and stop, not return. But, the H-Shifter, brake, some function, and clutch still working well. I was found some solutions for "logitech G25, G27 won't calibration": change encorder disc. But not solved for me. It has an analog encorder, i was check it by Volt, Ohm multimeter, it's well working (while turn steering wheel, the voltage level changed 0V~4.6V~0V~4.6V~...). So, i think encorder no problem. I was found ST72F651 pinout, and check all of VCC, VDD, GND pin, everything is OK. So, i think microcontroller not convert and tranfer data from encoder to PC, or some program, some function inside the microcontroller is error. I can order new one ST72F651, but i has not program to load into this IC. So, i think the motherboard must be replacement by new one.
Can i order only motherboard? And where? Pls tell me if you know
I from Vietnam, Logitech G25/G27 is very very expensive (about 800USD)
Sory for my bad english

Hi, taoladuy24!
Encoder is an infrared LED, disk with holes and infrared sensor (black one with a four pins). Sensor has two phototransistors(or photodiodes) and amplifiers inside. When disk are rotating - holes in the disk passes a light to one or another or to both phototransistors. Order of the passing of the light defines direction of rotation. Every passed light pulse counted. Sensor, as I said above, has 4 pins: ground, power and two pins for the outputs of the phototransistors. So you need to check that both of output pins are changing when wheel is rotating.
P.S.: Sorry for my english.

 

[taoladuy24]

Hi, taoladuy24!
Encoder is an infrared LED, disk with holes and infrared sensor (black one with a four pins). Sensor has two phototransistors(or photodiodes) and amplifiers inside. When disk are rotating - holes in the disk passes a light to one or another or to both phototransistors. Order of the passing of the light defines direction of rotation. Every passed light pulse counted. Sensor, as I said above, has 4 pins: ground, power and two pins for the outputs of the phototransistors. So you need to check that both of output pins are changing when wheel is rotating.
P.S.: Sorry for my english.

Hi Kolyanovich!

Yeah, i know, the encoder has an infared led (i can see the infared light by smartphone camera). But, i don't know phototransistors has 2 output pins. I will recheck both. Thanks for your help!

 

[sesselpupser]

Well it's been a long time but I have basically no updates. Shocking, I know! I've just been working so much it's practically impossible for me to get anything done at home beyond eating and sleeping. I do still have ambitions to continue the project at some point, though, and I have a rough plan:

First, read up on how people modify the programming of the AVRs that do the USB to serial conversion on non-USB Arduino boards, because I want to use a Mega 2560. This is because the 32U4-based boards with native USB, the Leonardo and Micro, are impossible to program after you change the VID and PID (which is required to get the Logitech drivers to see the board as a G27) until you flash the Arduino bootloader on them, which isn't really the best way to get stuff done. So instead I'd like to reprogram the on-board USB handler on a non-USB board to present the board as a G27, while the real microcontroller on the board still thinks it's an Arduino. That would allow me to use a USB to serial converter to upload programs instead, which would speed the whole process up. It would, however, make it a bit harder for DIYers to complete the project... Then again, if they fail because they can't figure out how to flash their USB to serial MCUs, they're probably not cut out for the whole project anyway.

After that it should, in theory, be quite straightforward to get all the bits lined up properly, so then I can focus on the hardware. Again, I have some ideas of how to tackle that, I remember struggling before with mapping the PCB so I intend to approach it more sensibly with high resolution photos and a grid system - I kept getting lost before when counting transistors but there aren't even that many.

Then, when I know what needs to be made, I can use our PCB router at work to prototype some designs. The end goal is still to make an open-source G27 that will enable people to build or repair their own wheels that will work with the widely used, easily available, highly compatible Logitech software... The only problem is, by the time it's finished I imagine developers won't even be including G27 support in their games!

Edit: as an aside, the long term plan for after I've got a G27 replica working is to include some sort of wireless support - Xbee or Bluetooth specifically - so you don't have to use the shifter and pedal cables to connect them to the wheel. That'd be really useful for someone like me who can no longer have their wheel permanently mounted on their desk.

 

[mrbasher]

I think you should take a look at the code being used by the GIMX project for the G27 side and getting the USB side all worked out. Then for the actual FFB stuff on the wheel, you should be able to adapt the stuff used in the open sim wheel project. Armed with the info from both, I bet you could knock it out without too much hassle. Lots of learning involved, but that's half the fun!

 

[sesselpupser]

@mrbasher I actually completely forgot about GIMX... Good call!