What's new

doozer

Unobtanium
Professional
Joined
Jan 12, 2018
Messages
219
Reaction score
126
Location
Brisbane, Australia
Hi All,

I'm currently converting my Chihiro Outrun 2 SP single chassis to use the Lindbergh system.
My Chihiro seems to be slowly dying. The usual capacitor and CPU/GPU heatsink fixes don't seem to have helped. So rather than replace the Chihiro I though I would install a Lindbergh system.
Everything should in theory work as-is, with the exception of the Force Feedback Board. The Chihiro talks MIDI to the board I have, whereas the Lindbergh wants to speak RS232/RS422 with the 838-14592-91 board.

I have tried to find a 838-14592-91 board, but haven't been successful.

This got me to wondering if it would be possible to make some sort of adapter/conversion board based on an Arduino that would allow a Lindbergh to connect to a MIDI system.
So with a weekend with not much on, I started doing some research.

The Outrun cabinet wiring diagrams were a big help and allowed me to quickly zero in on which connections would be of use. The ones I am interested in are CN2 on the 838-14174 DRIVER BD MIDI.
CN2 has 5 wires connected: shield/gnd, TXD,TXD_R,RXD, and RXD_R.
Figuring this was a good place to start I connected my logic analyzer to those 4 pins and captured the cabinet booting until the game loaded. This includes the self test where it asks you to stand clear and it rotates the steering wheel full right.

As luck would have it, my analyzer already knew how to decode the MIDI protocol. So I ran the software just to see what would happen.
The first group of data that caught my eye, was the Chihiro repeatedly sending the packet:
FD 00 00 7D
Which was answered by the FFB board with:
0x44

So I went digging into the Midi protocol spec and quickly discovered that 0xFD is a system message that's undocumented and should be ignored. Great.

Fast forward a few hours and I had the basics of an Arduino with a Midi interface shield wired up to my Chihiro so it could capture (via passthrough) any commands sent from the Chihiro to the FFB.
This led me to my first eureka moment. Sega have added a CRC to the usual 3 byte midi protocol.
Fantastic, this means I could now determine if the data I was capturing was legit.

Here's a sample of the output:

Code:
> [202040] FF 00 00 7F [OK]
> [202100] 81 30 7F 4E [OK]
> [202115] 81 30 7F 4E [OK]
> [202130] 81 30 7F 4E [OK]
> [202144] FC 00 20 5C [OK]
> [202160] FD 00 00 7D [OK]
> [202175] FD 00 00 7D [OK]
> [202189] FD 00 00 7D [OK]
The first field is the time in milliseconds, then the 4 bytes and an OK if the crc checks out.
Notice that the FD 00 00 7D matches what i saw in the logic analyzer.

The Midi spec says the first byte is the command. And that command 0xFF means reset. Stands to reason the first thing the Chihiro would do is tell the board to reinitialize.
The FD 00 00 7D seems to be an "are you there?" type of message. I suspect if the FFB doesn't answer then you'll get an error.

But there's a lot of other stuff in there that doesn't make sense yet.

Next thing I did was bring up the game service menu. This allows you to test the feedback board.
One of the tests you can do is turn the wheel left/right or stop the motor.
You better believe I logged that test real quick.

Full right
80 01 01 00
84 00 60 64
Full left
84 01 20 25
Stop
80 00 00 00

My guess is 80 01 01 00 means turn the motor on, then 84 xx xx xx is a position.
And 80 00 00 00 turns the motor off again.

How does all of this help?
My hope is that the Lindbergh is sending the same commands over RS232 and all I need to do is convert them to Midi. However, I doubt things will be that simple.
More likely I will need to capture the RS232 command, convert it to a similar Midi command and send it to the FFB. Get the response back and then send an appropriate response to the Lindbergh.
Many times per second. I fear my Arduino Uno won't be up to the task. This might be the excuse I've been looking for to try out one of the new Arduino Due boards.

I've attached the full dump of the one way comms to the FFB. Its not 2-way yet because I need to hand build a second Midi interface and I wanted to prove this was even slightly possible before proceeding.

If anyone has a 838-14592-91 board and is able to log the RS232 comms (or is willing to loan/sell it to me so I can log it) please speak up.

I'll post more as I discover it.

Matt.
 

Attachments

  • ffb_logic.PNG
    ffb_logic.PNG
    211 KB · Views: 2,018
  • chihiro_ffb_midi.txt
    48.4 KB · Views: 556
  • logic_capture.jpg
    logic_capture.jpg
    641.2 KB · Views: 688
  • ffb.jpg
    ffb.jpg
    815.2 KB · Views: 823
Last edited:
Lovely work!
I think you should try to ping @winteriscoming on this one. I'm sure he'll be able to help. If not I can lend you a Lindbergh ffb pcs to help you make progress. Many people.will be very happy if you manage to make such an adapter, although winter was working on a similar thing. Dunno where this stands now.
 
Very interesting. Most of us (like me) just changed Naomi/Chihiro FFB board to Lindbergh/RingEdge one. But if we could still use our original FFB, it would be amazing !
 
Everything I know is posted here.

This includes everything I know about the midi protocol and driving it with an arduino. Also documented is my discovery that the Lindbergh uses basically the same protocol where I was getting feedback by using the arduino to just pass the communication back and forth between the midi board and the Lindbergh, converting from midi to RS-232. I got the impression that something extra was needed because the force feedback was very weak and the commands I expected that set the power were not being issued. I haven't gotten to the point of wiring up the RS-422 force-feedback to monitor the communication, but it is on my list of projects. I suspect that the RS-422 board simply initializes with a default power that is higher than that of the midi board, but that is just a guess until I get to the point of testing.
 
Everything I know is posted here.

This includes everything I know about the midi protocol and driving it with an arduino. Also documented is my discovery that the Lindbergh uses basically the same protocol where I was getting feedback by using the arduino to just pass the communication back and forth between the midi board and the Lindbergh, converting from midi to RS-232. I got the impression that something extra was needed because the force feedback was very weak and the commands I expected that set the power were not being issued. I haven't gotten to the point of wiring up the RS-422 force-feedback to monitor the communication, but it is on my list of projects. I suspect that the RS-422 board simply initializes with a default power that is higher than that of the midi board, but that is just a guess until I get to the point of testing.
Wow that's some fantastic information there!
Good to know I was on the right track.
My goal for now is to get the Lindbergh Outrun working on my Chihiro cabinet, so i'll be building essentially a rs232/midi passthrough device.
 
Everything I know is posted here.

This includes everything I know about the midi protocol and driving it with an arduino. Also documented is my discovery that the Lindbergh uses basically the same protocol where I was getting feedback by using the arduino to just pass the communication back and forth between the midi board and the Lindbergh, converting from midi to RS-232. I got the impression that something extra was needed because the force feedback was very weak and the commands I expected that set the power were not being issued. I haven't gotten to the point of wiring up the RS-422 force-feedback to monitor the communication, but it is on my list of projects. I suspect that the RS-422 board simply initializes with a default power that is higher than that of the midi board, but that is just a guess until I get to the point of testing.
Wow that's some fantastic information there!Good to know I was on the right track.
My goal for now is to get the Lindbergh Outrun working on my Chihiro cabinet, so i'll be building essentially a rs232/midi passthrough device.
We look forward to it!!!
 
You probably shouldn't focus 2 much on the midi protocol. The only thing it has in common with midi is the baudrate and the fact they use high speed opto couplers to connect the 2 devices. Details of these can be found in the midi specification. The aztech microcontrollers on the chihiro baseboard likely have a maximum baudrate of 115200 on their serial port, unless their interface is set to midi. Sega could use the higher baudrate for a faster respons time and likely used midi due to that.
 
Quick update: over the weekend I got my multi-boot installed. I selected Outrun and it complained the JVS board was not responding.
So I connected the JVS board and as expected the game now complains the driver board is missing (FFB).

So I connected my laptop to the Lindbergh COM1 port at 38400 baud and could see it sending a reset/init command:

FF 00 00 7F

This is great news as it looks like the protocols are very similar... if not identical.
I'll post the results once I get my RS232 -> Midi interface working.
 
Quick update: over the weekend I got my multi-boot installed. I selected Outrun and it complained the JVS board was not responding.
So I connected the JVS board and as expected the game now complains the driver board is missing (FFB).

So I connected my laptop to the Lindbergh COM1 port at 38400 baud and could see it sending a reset/init command:

FF 00 00 7F

This is great news as it looks like the protocols are very similar... if not identical.
I'll post the results once I get my RS232 -> Midi interface working.
I'm not sure what all options there are for the Lindbergh Outrun, but when I was originally messing with my translator, I couldn't get it to boot without a FFB error, even when I was giving replies back to the game.
 
I wasn't getting anywhere with my investigation (I was getting bad CRC values a lot), so I decided to log the raw data coming out of the Lindbergh COM1 port using my laptop. I'm glad I did, as my Arduino was throwing away bytes it considered to be errors.
Turns out the Lindbergh is sending 7 byte packets, not 4 like the Chihiro does.
A quick tweak to my code captured the following:

Code:
> [137570] FF 00 00 7D 00 00 02 [OK]
> [152657] 80 01 01 7D 00 00 7D [OK]
> [152660] 84 00 60 7D 00 00 19 [OK]
> [169441] 80 01 01 7D 00 00 7D [OK]
> [169444] 84 01 20 7D 00 00 58 [OK]
> [232947] FF 00 00 7D 00 00 02 [OK]
> [242144] FD 00 00 00 01 01 7D [OK]
> [242148] FD 00 00 04 00 60 19 [OK]
> [248539] FD 00 00 00 01 01 7D [OK]
> [248542] FD 00 00 04 01 20 58 [OK]
> [328664] FF 00 00 7D 00 00 02 [OK]
The same CRC routine as used by Chihiro works for byte 7, so I know the packet is valid.
Interestingly, the first 4 bytes look like valid MIDI packets, however the CRC (byte 4) is slightly wrong.
For example: FF 00 00 7D should be FF 00 00 7F.
Hmmm.

The output above is from using the Outrun test mode to check the Driver board. This has an extra option over the Chihiro one, in that you can select a "handle" to be either left or right.
I vaguely recall that the DX layout supports dual drivers with 2 steering wheels. I suspect that is what is going on.
It seems that byte 5 is the destination steering wheel (0 = left, 1 = right).
Not sure what byte 6 is for yet.

But what I'm thinking is I can strip off the first 3 bytes, recalculate the correct CRC and pass it on to the MIDI FFB board and see where I end up.
 
I don't think the 2 wheels are the problem. If I remember well, the Dx cab use a special PCB that swap to first or second wheel, I suspect the game don't see the 2 wheels at the same time.
 
I don't think the 2 wheels are the problem. If I remember well, the Dx cab use a special PCB that swap to first or second wheel, I suspect the game don't see the 2 wheels at the same time.
Then the mystery deepens :)
 
I wonder if the 838-14597 [Motor Switcher Board] sits between the Lindbergh and the FFB board. I suspect it probably intercepts the 7 byte packet and steers it to the correct wheel and strips it back to a 4 byte MIDI packet.

http://tms-designs.com/theshed/default.asp?stockid=2609

Pity I can't find a wiring diagram to prove it. The scanned copy of the owner's manual I have is unreadable.
 
Maybe contact Andy geezer from tms and see if he can provide a better scan or PDF.
 
If there is data for 2 steering wheels, wouldn't it make sense for the first 3 bytes to be the command for one wheel en the following 3 for the other one?
The final byte should be the checksum. Without knowing what the lindbergh expects back from it's ffb board, it's hard to analyse things any further.
 
If there is data for 2 steering wheels, wouldn't it make sense for the first 3 bytes to be the command for one wheel en the following 3 for the other one?
That's kind of how I'm reading it:
Byte 1: Command for both
Bytes 2-3: Data for command to wheel 1
Byte 4: Checksum?
Bytes 5-6: Data for command to wheel 2
Byte 7: Checksum


Without knowing what the lindbergh expects back from it's ffb board, it's hard to analyse things any further.
This one would be kind of tricky to guess. How does the game know it got a reply back from each wheel? Maybe double up an OK reply?

It isn't clear to me what the stock setup is (i.e. what's in place to drive 2 wheels... is it 2 boards or a dedicated board that has the capacity to drive 2 wheels?), but this appears to be an issue that is unique to OR2SP on the Lindbergh as the other Lindbergh games with FFB would boot for me and had a protocol that nearly matched what I expected for the MIDI version, as in it accepted the same replies.
 
Some good suggestions, but I don't think the data supports this. The CRC values just don't work.

At Darksoft's urging, I reached out to Andy last night and traded a couple of emails. Andy made the comment that I didn't need the 838-14597 [Motor Switcher Board] on a single Outrun setup.
He said to change the cabinet type in the game assignments from SDX to Standard (he also mentioned that putting it in Upright mode means you don't need the FFB at all).
As soon as I did this, the COM from the Lindbergh returned to the familiar 4 byte MIDI format with a valid CRC in byte 4.
ie.
FF 00 00 7F

This leads me to conclude that the 7 byte packet most likely includes actuator positioning information that the Motor Switcher Board consumes before passing the MIDI packet on to the FFB board.
For now I'm going to concentrate on the "Standard" mode.
 
Very interesting. Saddly Andy sells 838-14597 for a large amount (too expensive for me), cause I'd like to test transforming my twins to kind of SDX.
 
Last edited:
Back
Top