Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

DIY arduino steering wheel to fanatec wheelbase #12

Closed
lshachar opened this issue May 19, 2019 · 42 comments
Closed

DIY arduino steering wheel to fanatec wheelbase #12

lshachar opened this issue May 19, 2019 · 42 comments

Comments

@lshachar
Copy link

lshachar commented May 19, 2019 •
edited
Loading

Hi!
I have exactly the opposite problem that this project solves..
I recently bought a broken fanatec CSW V2.0 wheelbase and fixed it, (so it seems)
but, I don't have a fanatec steering wheel, and I planned on making my own.
I now get positional information from the wheel in fanatec's game driver, but in order to get force feedback I believe I need to have a steering wheel attached.
the plan is to use an arduino to communicate over SPI with the base, to fake a steering wheel.
once that is working, I'd also want to send the 'recalibrate center position' message over SPI, to recenter the wheelbase, as is usually needed after firmware upgrade of the base. (I don't know if this is a special recalibration message, or just an SPI message of the two buttons being pressed at the same time)
(last thing would be to have buttons working!)

I am definitely going to have a lot of problems writing this code by myself.. I might not be skilled enough. it sure seems like quite a lot of code that is needed for this project to work!
Any information would be greatly appreciated. IE, about the SPI communication protocol. Any chance that I can simply fake a wheel by resending the same message over SPI..? (fingers crossed)
How does the recalibration function work?
Anyone ever attempted anything like this?

thanks so much :)
-Shachar
@lshachar
Copy link
Author

lshachar commented May 21, 2019 •
edited
Loading

so far I didn't get very far at all..
I have my arduino connected to the CSW V2.0 wheelbase on SPI.
The SPI message I get through the MOSI line is

0 0 0 9A A5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9A A5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9A A5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9A A5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9A A5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9A A5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9A A5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9A 0

(hex)

this message comes in every 5 seconds. it looks as if 0xA5 is the initialization byte, 0x9A is the termination byte, and the wheelbase tries communicating 7 consecutive times in every burst.
(However, I'm not 100% sure that I have the correct SPI settings, so I'm not not sure if this is the message that I'm supposed to get!)
One thing that I know, by reading the getFirstByte function in fanatec.cpp (of this project): one can send nothing but 0x00 and an actual fanatec rim should still respond properly.
Also by reading getFirstByte, it seems that if I only sent 0xE0 bytes from the arduino to another arduino that would be running this project, this project would accept the arduino as a CSL_WHEEL. I wonder if this also applies to an actual wheelbase.

  • so, I tried constantly sending either 0xE0 / 0xD2 / 0xA5 bytes, did not work ("fake rim byte")
  • I tried sending 0x00 bytes, with a "fake rim byte" sent as a respond after the first 0x00 sent from the wheelbase (right after 0xA5 byte) - did not work. (see the code that I'm showing here.)
  • I tried changing the CPOL bit to 1, on the SPCR byte, but I still get the same exact message (the one described above) from the wheelbase. I think that the other SPI settings are correct (are they?)
  • what if 0x9A and 0xA5 don't mean what I think they mean? maybe the base is trying to send some actual information? I tried sending a "fake rim byte" every 32 bytes received from the wheelbase - regardless of the information - did not work.

I could really use some clues and hints right now! please! :)

  • PS, if this helps anyone - I believe that the wheelbase looks for a connection between pins 3 & 5 (both are marked as GND pins in the schematics on this project page) or SPI communication is off. (I assume this is a test that a physical rim is actually connected) (that is not to say, that this project said otherwise. just saying that my experience showed it was important to do so.)

I cannot seem to attach the code as preview code, so here it is:
spi_attempt.ino.txt

@darknao
Copy link
Owner

darknao commented May 21, 2019

Hi,
First, thanks for your interest in this project. I unfortunately don't have much time those days (months?) to work on this project, so I'll not be able to answer all your questions anytime soon.

You should probably, if not already, take a look on the wheel emulator you can find in dev-tool : t3_wheel_emu.ino
You'll need a Teensy 3.x for that (teensy LC is NOT supported). This firmware is really basic (buttons are not implemented) but will unlock the force feedback on your wheelbase.
If you need more info on the protocol, you should also take a look to the comments in cap.py.

@lshachar
Copy link
Author

lshachar commented May 29, 2019 •
edited
Loading

Hi!
I'm glad I'm not the only one who's interested in this!
I postponed my response so far because I didn't think this was really going to be of much interest to anyone... And also I don't have anything working yet.
So first, Darknao, Thanks so much for replying so quickly! Your answer was great and it totally pointed me in the right way!
Devactive, most arduinos are 8/16mhz, and they can only communicate over spi slave at clock/4, or 4 mhz, which is too slow for the wheelbase. I don't have a fast enough scope, but I did some tests and I won't be surprised if the clk rate was about or over 16mhz. (first thing I did was to rework my arduino code to send the 33 byte array, that is in the wheel emulator program that Darknao wrote for teensy 3.x. But found out that arduino wasn't up for the task.-too slow. )
I then proceeded to try to program my rpi 2 b+ as a spi slave device. I quickly found out that rpi does not have spi slave abilities!
:( Some of the spi chip pins are not connected by design, so no options there.
-I then dug out an esp8266 board (a wemos r1 board) and tried to give it a go. The esp8266 runs at 80 mhz and is able to run as spi master at 80 mhz, or as spi slave at 20 mhz. I think teensy 3.2 is the same (for slave) so in theory, the esp8266 should work. Also, there is a code example to run it as spi slave. (esp8266 can either run arduino code or Lua scripts, I went the arduino way. )
Thing is... That the arduino code does not work properly. The spi slave does not send out data correctly. And, that's where I'm at right now. Trying to figure that out. It's kind of hard because esp8266 documentation is a lot worse than genuine arduino boards, I don't understand the registers and interrupts on it, and I'm by no means a great programmer. so there's still work there.
Which leads me to this; Devactive, if you just want ffb working, easiest way is to use the teensy sketch that Darknao made. I became a little obsessed with getting spi slave working on one of the boards I already have. But there's a chance that I'll give up and just get a teensy, and add the buttons code (etc) to it.

@darknao
Copy link
Owner

darknao commented May 29, 2019

Don't know about the CSW, but the CSL base clock the SPI bus just below 500kHz, so most boards should be able to handle that. You only have around 1.2ms between each frame, so you'll have to keep things fast enough if you want to handle inputs and stuff.

The first thing to find is a board capable of running the spi bus in slave mode, with hardware interrupt on the Slave Select pin (and this pin must be available on your board). There is like 4us between the SS falling edge and the first clock tick so I don't think you'll be able to handle that with software SS.

Then, come one of the most hardest part here : dealing with EMI issues.
The SPI bus coming from the wheel base is REALLY sensitive, and your breakout board will act like a crazy antenna. You'll need to get a strong ground, and try to filter all spi lines until you get a clean transmission. A scope (or logic analyzer) is a must have for this part, and some board are worst than others.
Teensy are not bad, but I got some arduino nano that was totally garbage in that matter. I also got good result with a pro micro (but this one will need some hardware modification to get the SS pin available).
So far (but I didn't test much boards), I didn't found any board totally immune to this issue.

@lshachar
Copy link
Author

Then, come one of the most hardest part here : dealing with EMI issues.
The SPI bus coming from the wheel base is REALLY sensitive, and your breakout board will act like a crazy antenna.

uh, wow! It's possible that I wasn't reading actual data on the clk / ss line at all, but noise, which was in the Mhz range!
(I wouldn't think that the CSL clock frequency is a lot different to CSW, if at all).

Also, bare in mind that the SPI bus on the fanatec is 3.3V. many arduinos use 5V. I might have burnt the MISO line on my wheelbase, by having it connected to 5V (before testing the line voltage) :|
also, the false readings that I got on the input lines (clk / ss / mosi) could be because I didn't level shift from 3.3V to 5V. (arduino digital input pins go high at 3V, but hey I don't really trust my work anymore)

@lshachar
Copy link
Author

lshachar commented Jun 1, 2019 •
edited
Loading

Success! :D
I have the code up and running, and I have the wheelbase firmware believing a wheel is attached.

Darknao: using a scope I found out that the wheelbase is using CPHA. (data is sampled on the transition from high to low (trailing edge) (CPHA = 1))
in your code (raw_capture.ino and fanatec.cpp) you are not using CPHA. at least for CSW this seems wrong.
clock falling

Soon enough I will implement the buttons and stuff. and maybe switch to a board that natively runs on 3.3V for simplicity.
The ATmega328P SPI buffer is only 1 byte. that is why the interrupt routine always has to feed the next byte to MISO buffer. That may prove to be problematic when trying to read digital pins and send out buttons values.

The code is explained with quite a few comments. It will print out some debug information to the serial port, (which is not helpful once the user has a proper connection with the wheelbase)

Important: If anyone is attempting this! Arduino uno runs and outputs 5V. the CSW wheelbase SPI lines are using 3.3V. you might damage the wheelbase (mostly the MISO line) without a level shifter. I have an arduino Uno connected to the CSW wheelbase, through a level shifter.
Also, the code might not work without a level shifter - as the arduino might not recognize the 3.3V from the wheelbase as HIGH. (although it should, over 3V).
in order to get this working, you need the CS line connected to digital pin 2 on the arduino uno*, at least until I will change the interrupt routine (to use pin 10, the actual CS line)

arduino D2 to CS on wheelbase*
arduino D13 (SCK) to SCK on wheelbase*
arduino D12 (MISO) to MISO on wheelbase*
arduino D11 (MOSI) to MOSI on wheelbase*
arduino Gnd to Gnd on wheelbase

If you're using an actual level shifter (as you should), you will need to connect both 5V from arduino and 3.3V from wheelbase to the level shifter.

  • =through a level shifter!

good luck!

arduino uno wheel emulator.ino.txt

@lshachar
Copy link
Author

lshachar commented Jun 10, 2019 via email

@lshachar
Copy link
Author

lshachar commented Jun 10, 2019 via email •
edited
Loading

@delfinski
Copy link

Success! :D
I have the code up and running, and I have the wheelbase firmware believing a wheel is attached.

Darknao: using a scope I found out that the wheelbase is using CPHA. (data is sampled on the transition from high to low (trailing edge) (CPHA = 1))
in your code (raw_capture.ino and fanatec.cpp) you are not using CPHA. at least for CSW this seems wrong.
clock falling

Soon enough I will implement the buttons and stuff. and maybe switch to a board that natively runs on 3.3V for simplicity.
The ATmega328P SPI buffer is only 1 byte. that is why the interrupt routine always has to feed the next byte to MISO buffer. That may prove to be problematic when trying to read digital pins and send out buttons values.

The code is explained with quite a few comments. It will print out some debug information to the serial port, (which is not helpful once the user has a proper connection with the wheelbase)

Important: If anyone is attempting this! Arduino uno runs and outputs 5V. the CSW wheelbase SPI lines are using 3.3V. you might damage the wheelbase (mostly the MISO line) without a level shifter. I have an arduino Uno connected to the CSW wheelbase, through a level shifter.
Also, the code might not work without a level shifter - as the arduino might not recognize the 3.3V from the wheelbase as HIGH. (although it should, over 3V).
in order to get this working, you need the CS line connected to digital pin 2 on the arduino uno*, at least until I will change the interrupt routine (to use pin 10, the actual CS line)

arduino D2 to CS on wheelbase*
arduino D13 (SCK) to SCK on wheelbase*
arduino D12 (MISO) to MISO on wheelbase*
arduino D11 (MOSI) to MOSI on wheelbase*
arduino Gnd to Gnd on wheelbase

If you're using an actual level shifter (as you should), you will need to connect both 5V from arduino and 3.3V from wheelbase to the level shifter.

  • =through a level shifter!

good luck!

arduino uno wheel emulator.ino.txt

First thank you for your work!
Can you show with link this level shifter and if it possible to do dawing for all wiring, sorry but as newbies we will be more confident if it is shown...noone will have benefit if we burn our bases:)
I have Xbox rim and if you know way to read it with Arduino UNO I can do it:)

@lshachar
Copy link
Author

I have Xbox rim and if you know way to read it with Arduino UNO I can do it:)
That's great! which rim?
If you use /dev-tools/raw-capture.ino, you could read spi data coming from the wheel. You should be connecting the arduino as a SPI Master (Miso and Mosi - emphasis on the M for master), and the wheel will be slave. CS is digital pin 10.
SPI communication should still be at 3.3V level.
once you have working communication, you should press a single button (such as the left shift pedal) and save one spi packet to a text file; keep doing that for each button on the steering wheel, this way you will map all the buttons on the steering wheel, and I could implement it in my future code.

I'm using a level shifter like this one

@delfinski
Copy link

I have Xbox rim and if you know way to read it with Arduino UNO I can do it:)
That's great! which rim?
If you use /dev-tools/raw-capture.ino, you could read spi data coming from the wheel. You should be connecting the arduino as a SPI Master (Miso and Mosi - emphasis on the M for master), and the wheel will be slave. CS is digital pin 10.
SPI communication should still be at 3.3V level.
once you have working communication, you should press a single button (such as the left shift pedal) and save one spi packet to a text file; keep doing that for each button on the steering wheel, this way you will map all the buttons on the steering wheel, and I could implement it in my future code.

I'm using a level shifter like this one

I think my skills are not that good to do that...first gotta suply this level shifter, but do I need it for reading a rim? You said it is needed to preven base to burn out...but for rim do I risk to burn the rim?;)
My Xbox rim is CSL P1 Elite...

@lshachar
Copy link
Author

Although it is possible to put a voltage divider on any arduino output pin, (In case the arduino is master, these would be: MISO, MOSI, CLK, and CS. In case the arduino is slave, it's only the MISO pin), but it will only take a small wiring mistake, or the wrong code (pull an arduino pin that was supposed to be input to 5V - by mistake). I have accidentally connected 5v from my arduino to my wheelbase on the SPI interface, and nothing burned, but I don't recommend you to do that. get a level shifter. :|
you could also use a 3.3V arduino with the wheel_emu sketch. the 3.3V arduino pro mini would work. However they run on 8mhz and might prove too slow as SPI slave devices (to be tested)

@lshachar
Copy link
Author

I believe Fanatec made the design themselves. There is a metal pin in the steering wheel (not pogo pins), and a metal receptacle in the base. I guess with a bit of searching we could find suitable pins. I'm going to create a printable part, that you can stick some pins through yourself with a bit of heat. I'm going to use nails as a simple alternative (not the best in terms of conductivity)

@lshachar
Copy link
Author

my code is here
I plan to have schematics and a lot of work on the code there.
Thank you Darknao, again!

@delfinski
Copy link

Guys, need some help - Teensy board is very hard to be found around me, so is there any option some of the ardiuno boards to be used for Steering wheel to USB convertion?

@lshachar
Copy link
Author

lshachar commented Jun 19, 2019 via email

@delfinski
Copy link

delfinski commented Jun 19, 2019 •
edited
Loading

I saw ppl use Pro Micro for Thrustmaster rims USB covertion..
Here is the info from btClubSportWheel:
This firmware has been developed and tested on a Teensy 3.1 and Teensy LC but should work with any other compatible hardware.
The only requirement so far, is at least 1 SPI connectivity available.
So, the pro micro have this 1SPI covered?
and as this info is shown like only requirement that means that no extra code change is needed, at least from what I understand..

@lshachar
Copy link
Author

lshachar commented Jun 19, 2019 via email

@delfinski
Copy link

So, uploading this code to Pro Micro and ofcourse use its pins coresponding to those on Teensy - will not work ?
As I cant code that means it is a lost cause for me!;)

@lshachar
Copy link
Author

lshachar commented Aug 19, 2019 •
edited
Loading

Hi!

I plan to have schematics and a lot of work on the code there.

apparently... I lied... I have not been working on it quite at all, really. :0
(small update: I did change to arduino nano, from uno, with no issues. it works with the CSW wheelbase.)

I have no idea what's causing the delay in pressing the buttons!! I just updated the 'beepEverySecond' branch to operate with the buffer (that I previously created for the SPI communications;)
(which means, if you compile that branch, a button is automatically pressed or released once every second. Without the buffer, an SPI packet may be sent with an incorrect CRC8 value.
the buffer is suppose to solve that problem. However, I'm still getting the delay!! :|
I wonder if Darknao's documentation of the interface is accurate. I can't see how I can check that, since I don't have one of Fanatec's actual racing wheels.
I also wonder if I check that the communication is working properly with my slow and basic osciloscope.

I don't think that changing the interrupt to a different pin would have any effect.

By blades - do you mean paddle shifters? - I have mine hooked up to a different arduino (nano) so that I can use them while playing. the rj12 socket should be working fine, but I think you need to set up the paddle shifters using the on-wheel LCD display. in other words, you need to figure out my serial monitor interface, in order to enter the menu system on the wheelbase and bind the paddles. (* I remember you have to bind buttons for Fanatec's H shifter; I just assume you need to go in a similar route for the other peripherals. (might be wrong there)

@delfinski
Copy link

The paddles conected to rj on the back work plug n play, no need of setup;) If you do some custom ones you just need correct wiring for the 2 switches...you need to know which wire from the rj for what is used;) but it is simple nothing complicated there!

@lshachar
Copy link
Author

great, that could have saved me my last race at SimRacingSystem when my shifter became buggy

@lshachar
Copy link
Author

lshachar commented Aug 19, 2019 via email

@lshachar
Copy link
Author

lshachar commented Aug 19, 2019 •
edited
Loading

Are you sure the whole problem is not with the button bouncing?

Yes... are you listening? 🙃 check out my beepeverysecond branch, hook in a buzzer, and see for yourself.

Maybe the problem is interference.

Intererence could be the problem, but it doesn't make sense as the problem will be the same both for button press and button release.
secondly, when there is an interference issue, you get a lot of bad crc8 packets (on the arduino, from the wheelbase)
When you don't have interference issues, there are no bad crc8 packets coming in, at all.
(However, this is true for the base -> arduino direction, and it says nothing about the arduino -> base direction, which we don't have any way to truely test. (since fanatec does not give us any debugging information on their devices)

@lshachar
Copy link
Author

The paddles conected to rj on the back work plug n play, no need of setup;) If you do some custom ones you just need correct wiring for the 2 switches...you need to know which wire from the rj for what is used;) but it is simple nothing complicated there!

do you have / can you make a wiring schematic? couldn't find one online

@MatMenzies
Copy link

Hi Ishachar, Delfinski,
I'd like to try and contribute here as I would also like to use non-Fanatec wheels on my base. Or at the very least assist others succeed.
At the moment I have only my CS V1 base and a new Formula wheel, and no time. Next year I will have much more time, but I cant really do much until after December. I am happy to test code, I can dabble and adjust, but I'm not skilled up on SPI.
I am expert in electronics and have some basic test gear, scope / PSU's etc, sounds very similar to you Ishachar. I'll be happy to reproduce hardware to test and make and send for others if required.

One thing I might suggest, is if you can get the positin and FFB working, forget using the fanatec base for buttons / shifters / pedals etc, and go with the OSH software on STM32 boards. I've done a number of these now for myself and others to make custom wheels & pedals controllers, they are quite versatile: https://opensimhardware.wordpress.com/pedal-button-controller/
(I'm sure you've probably seen it, I'm just adding my 2c :-)
Looking forward to contributing.

@delfinski
Copy link

I dont really see reason to use external devices for pedals, as all decent fanatec pedals are USB also...but event they wasnt - Why to avoid the base plug?
For buttons etc - there are alot other easier to use solutions outhere, I really dont see this solution practical...too many components , to achieve something already made posible easier!:)

@MatMenzies
Copy link

I dont really see reason to use external devices for pedals, as all decent fanatec pedals are USB also...but event they wasnt - Why to avoid the base plug?
For buttons etc - there are alot other easier to use solutions outhere, I really dont see this solution practical...too many components , to achieve something already made posible easier!:)

Hi Delfinski,
The latter part of this thread appears to focus on an issue getting buttons to work properly, my suggestion was just that, a suggestion that there is an easy USB solution with huge versatility if the fanatec buttons are a blocker.
Sure, nicer to have the buttons on the wheel connected through the base, maybe easier DIY solutions for buttons and pedal controllers, but for me it was very easy and far better than any other system I have used (many button / encoder options and very good loadcell / pot resolution with good supporting software and doco). Just having input, my suggestion has validity here.

Just out of curiosity, whats the resolution of the fanatec pedals? (how many steps in game calibration?)

@delfinski
Copy link

You can easy find that info on Fanatec website for USB mode on the pedals which is build in...and ofcourse everyone can do suggestions and input here - just saying that your solution is not the best posible, if you dig deeper you will find that buttons and rotaries can be connected even to single cheap nano board... here the topic is for more complicated thing - to trick fanatec base to accept arduino powered rim..... the buttons to usb is piece of cake;)

@lshachar
Copy link
Author

lshachar commented Sep 15, 2019 •
edited
Loading

Hi MatMenzies!

if you can get the positin and FFB working

Yeah, it's working since the time I uploaded the code to github. I have no idea what causes the buttons delay, but otherwise, for position + ffb + entering the wheel menu and changing settings / calibrating the wheel center etc - everything works fine.

@Jonbakhol
Copy link

Jonbakhol commented Sep 17, 2019 •
edited
Loading

Hi Guys,
Reading this topic with great curiousity.
Will this also work with an Fanatec V1?

Than I'll get a second hand Fanatec and give it a shot.

Thanks for now

Bakhol

@lshachar
Copy link
Author

yes.

@Jonbakhol
Copy link

Jonbakhol commented Sep 27, 2019 •
edited
Loading

Thanks Ishachar,

At this moment I got an Fanatec Elite Base running Version 475 (if I'm right, this shows up on the display of the wheel delivered with it))
And an Teensy 3.2. I uploaded the t3_wheel_emu.ino
Soldered:

PLUG---------Teensy
1-------------------11
2-------------------12
3------------------GND
8---------------------10
6----------------13
4----------------VIN
5----------------GND
7----------------3v3

But at this point nothing happens.
Can you see if I did something wrong. Or did I missed something?

Thanks for now

Bakhol

@Jonbakhol
Copy link

Jonbakhol commented Oct 3, 2019 •
edited
Loading

@lshachar

Above teensy works on my second base CSW V1. So that's sorted.
Now I want to send commands to the base for the settings, and I think I need the arduino nano to do that. Is below wiring correct..
Many thanks

image

@lshachar
Copy link
Author

lshachar commented Oct 5, 2019 •
edited
Loading

@Jonbakhol,

  1. You didn't tag me, you've tagged someone else. (lshachar / ishachar)
  2. Please, for you or anyone else with future issues: open new issues on my own project's github page
  3. Your schematic was almost correct except for one error. Pin number 4 on Fanatec's round plug should go to 5V on the arduino, instead of VIN.
    This means you are supplying the arduino with 5V from the wheelbase.
    suppying 5v to VIN, as in your schematic, means that the voltage regulator has only 5v on its entrance, which is not enough for it to work. (Needs 7-12V). this should explain your difficulties.
    The 5V pin on the arduino board is the output of its voltage regulator. It's fine to connect a stable 5V source to there (such as the wheelbase).
    (your connection between the HV side of the logic shifter to 5V is correct)

Please note
When you connect a USB cable to your computer, you are connecting the +5V power supply on your USB socket (your computer PSU), to the +5V power supply of your wheelbase.
I've done this, and have not had issues with that, but this should be avoided...
One of these supplies will have a slightly higher voltage than the other, and it will push current through the other supply. (similar to connecting two batteries in parallel. The charged battery will try to charge the drained battery.)
So, it is better if you disconnected the 4 pin from VIN before you connected the arduino to the computer. or better:
a. Modify a micro USB cable, cut off the 5V wire.
or b. Cut the 5V trace coming from the USB connector on the arduino nano.

schamtics arduino nano-level shifter-fanatec round plug

@Vanterkraft
Copy link

image
Can you tell me how to connect pins 11 and 13 with USB famale on the universal hub? I don't have it and I have no one to ask to check it out. I want to use the project Arduino_Fanatec_wheel and make your steering wheel with USB display, but did not want to use a USB cable

@Pistolidas
Copy link

Hello All,

Has enyone been able to get either the Teensy 3.2 or the Arduino Nano working on a Fanatec CLS Elite V1?
I tried both, but no succes. :(

Regards,

Pistolidas

@lshachar
Copy link
Author

lshachar commented Nov 16, 2019 •
edited
Loading

As I already asked,
Please, for you or anyone else with future issues: open new issues on my own project's github page

Darknao, I would thank you if you clicked 'lock conversation' on this issue. (I'm thinking that closing it may get people to miss it completely)

@Pistolidas Pistolidas mentioned this issue Dec 27, 2019
Open
@sabifa
Copy link

sabifa commented Feb 10, 2020

image
Can you tell me how to connect pins 11 and 13 with USB famale on the universal hub? I don't have it and I have no one to ask to check it out. I want to use the project Arduino_Fanatec_wheel and make your steering wheel with USB display, but did not want to use a USB cable

Did you find anything out regarding the Data Lines for another USB device?

@lshachar
Copy link
Author

As I already asked,
Please, for you or anyone else with future issues: open new issues on my own project's github page

Darknao, I would thank you if you clicked 'lock conversation' on this issue. (I'm thinking that closing it may get people to miss it completely)

@lshachar
Copy link
Author

As I already asked,
Please, for you or anyone else with future issues: open new issues on my own project's github page

Darknao, I would thank you if you clicked 'lock conversation' on this issue. (I'm thinking that closing it may get people to miss it completely)

Repository owner locked as off-topic and limited conversation to collaborators Mar 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@darknao @lshachar @sabifa @Jonbakhol @Pistolidas @delfinski @Vanterkraft @MatMenzies and others