[perpetualKid]

If someone wants to test current state of the changes as mentioned above, attached is a binary package.


This is based on ORMG 3.7, so make sure the prerequisites as mentioned here are installed. Should work both for 64 and 32 bit, default to the OS architecture.


Known issues:
- expects the RD calibration file (ModernCalibration.rdm) in the exe-folder. This is a temporary issue and change to the original version, but since I expect to remove these external calibration and move into settings/options anyway, didn't want to spent time fixing Path-settings


Currently working on button customization, and I'll backport the code changes to ORTS (other than the changes for 64bit which there is not possible in original ORTS currently) only once done, or if someone else wants to take on such job.

Let me know any feedback or bug reports.

//edit on Feb 3rd - removed the binary package as a newer version is available further down the thread.

[perpetualKid]

dforrest, on 30 December 2018 - 12:46 PM, said:

I have had a RailDriver for many years but find that its support for steam locomotives, the only thing I seriously drive, is very limited.

since I'm not driving steam engines, I don't really know what's missing. Imagine we get customizable blue buttons (and maybe the left hand side buttons as well), would the levers need to be mapped/used differently also?

[James Ross]

perpetualKid, on 25 December 2018 - 11:11 AM, said:

Unfortunately didn't got it working in the first trial, but I discovered the Raildriver support in ORTS is bound to an older 32bit driver implementation from PI Engineering. Good news though, PI is supporting 64bit in newer versions of their API. However there are some changes in the PI API which require couple updates to the OR code for Raildriver to get the new version to work. Furthermore, they way it's implemented, may cause some challenges supporting both a 32bit and 64bit at the same time. I'm looking to implement this in a 64bit version of OR MG at least, but potentially backport to the official (32bit) version as well - if there is interest at all...

If there are changes we can safely make to the official version that will enable 64bit to work in the future, I'd be happy to take them ahead of enabling 64bit support. I suspect we'll keep things 32bit with MonoGame initially, just to reduce the number of large changes at once, but it does depend on how things are affected by 64bit.

perpetualKid, on 25 December 2018 - 11:11 AM, said:

So while getting into the code, wondering how many folks are using Raildriver with ORTS, if there's larger interest in other changes.
I searched the forums and there seem few sporadic messages on Raildriver only, and indicating missing features like programmable key mappings or different keys mappings for OR camera views.


What's on folks mind, do we need any updates for Raildriver in OR? No commitment or timelines yet ;)

Being able to customise the buttons on the RailDriver, at least, would be fantastic; the other inputs I'm less sure need it, but if there's a calibration step needed for proper functioning I'm okay with us including that too.

[perpetualKid]

finally got some time to complete work on the RailDriver implementation I started few weeks ago.

this includes:
- a new tab page on Options Dialog in Menu to customize Raildriver. The tab page will only show if an RD is connected
- on the page, RD buttons can be customized in a similar way as keyboard settings. Known limitation - each functionality can only have one unique button assigned. This means the horn and e-stop dual way switches can be assigned to different settings only, but not the same on either direction. In default config however, both switches still can be used in both ways for the same functionality.
- RailDriver calibration is now part of the options dialog. Calibration is fully integrated in ORTS, so there is no need for separate calibration program and calibration files. Therefore an initial calibration needs to be run in ORTS. While Calibration runs, a guidance dialog will be shown as in the screenshot, showing which lever to move in position to get a measurement, before moving to next.
- I found some Trello card voting for options to reverse lever handling, and use full throttle range for trains not using dynamic brake. This can be configured separately now.

- both 32 and 64bit versions working
- fixed the BailOff issue
- more precise input reading
This is currently based on Monogame implementation, and as before, requires .NET 4.7.1, DirectX runtime, and OAL installed as mentioned here


//removed attachment for newer version further down the thread

[R H Steele]

http://www.elvastower.com/forums/public/style_emoticons/default/sign_thank_you.gifhttp://www.elvastower.com/forums/public/style_emoticons/default/sign_rockon.gif Your time and effort are very much appreciated. http://www.elvastower.com/forums/public/style_emoticons/default/cool3.gif http://www.elvastower.com/forums/public/style_emoticons/default/hi.gif

[R H Steele]

I'm not sure RD is calibrating correctly on my system...The Raildriver does not indicate it is turned on, the speed window is dark during calibration.
Options\Raildriver\Run Calibration

Downloaded Program.zip, installed - indication that ICSharpCode.SharpZipLib.dll was required - it was missing - copied over from version 1.3 monogame.
Made sure Net Framework (latest version 4.7.2) was installed, OpenAL was already installed, and since I'm running Win7 Pro 64bit, I believe DirectX runtime is also installed.
What did I miss??

[perpetualKid]

R H Steele, on 04 February 2019 - 03:58 PM, said:

I'm not sure RD is calibrating correctly on my system...The Raildriver does not indicate it is turned on, the speed window is dark during calibration.
Options\Raildriver\Run Calibration

Downloaded Program.zip, installed - indication that ICSharpCode.SharpZipLib.dll was required - it was missing - copied over from version 1.3 monogame.
Made sure Net Framework (latest version 4.7.2) was installed, OpenAL was already installed, and since I'm running Win7 Pro 64bit, I believe DirectX runtime is also installed.
What did I miss??

as long the Raildriver tab page appears, the unit is correctly identified and used.
I didn't think of any indication on the Raildriver itself, but if's a good point and I'll add some output on the speed window

As for ICSharpCode.SharpZipLib.dll, that should no longer be needed, but I realize there was some old code in the launcher (OpenRails.exe) checking for dependencies, which is cleaned up for next version: Instead of OpenRails.exe you could just start Menu.exe, or as you did copy an older version, or create an empty file called
ICSharpCode.SharpZipLib.dll ….

[perpetualKid]

just changed as per discussion above, during calibration run the RD unit will first show "CAL" for calibration, and afterwards the respective lever positions numeric values. Not that the values would mean anything, but at least you have some sign everything is working.
Same for the blue button customization, when a button is pressed while editing the assignment, the button's number code is displayed.

Also fixed the ziplib dependency check.

//removed attachment because of newer version further down the thread

[R H Steele]

RE: Calibrating RD

Every locomotive I've tried starts with 100% dynamics...anyone else??I found the dynamic brakes calibration a little confusing ( and I calibrated many times using Raildrivers calibration format) - but I'm going to assume I messed up the instructions...so going to go through it again.
Thanks again, perpetualkid, your efforts much appreciated.

[dforrest]

I am very interested in this and considering how I can setup a profile for user with British steam locomotives. I assume others have the same, or similar, ideas and wonder if there is any thought to publishing standard "profiles" for this (and other) uses. If there is, I would be very interested is assisting in the preparation of testing of them.

[R H Steele]

R H Steele, on 06 February 2019 - 07:20 PM, said:

RE: Calibrating RD

Every locomotive I've tried starts with 100% dynamics...anyone else??I found the dynamic brakes calibration a little confusing ( and I calibrated many times using Raildrivers calibration format) - but I'm going to assume I messed up the instructions...so going to go through it again.
Thanks again, perpetualkid, your efforts much appreciated.

It was me, not understanding the instructions. Now everything works, LOVE the fact that the bailout actually engages and disengages! My Auto Brake still is a little off, better than before, maybe I need to replace the unit.

[perpetualKid]

R H Steele, on 07 February 2019 - 10:49 AM, said:

It was me, not understanding the instructions. Now everything works, LOVE the fact that the bailout actually engages and disengages! My Auto Brake still is a little off, better than before, maybe I need to replace the unit.

let me guess, you did calibration in order Full Throttle - Dynamic Setup - Dynamic Brake, while the calibration indeed is going from Full Throttle - Dynamic Brake and back to Dynamic Setup-
I think the former is more intuitive, however I followed the same pattern as the original calibration from PI, which is the latter sequence.

If there are ideas for improvement on the process or guidance, I'm open to implement further changes.

[R H Steele]

perpetualKid, on 08 February 2019 - 08:07 AM, said:

let me guess, you did calibration in order Full Throttle - Dynamic Setup - Dynamic Brake, while the calibration indeed is going from Full Throttle - Dynamic Brake and back to Dynamic Setup-
I think the former is more intuitive, however I followed the same pattern as the original calibration from PI, which is the latter sequence.

If there are ideas for improvement on the process or guidance, I'm open to implement further changes.

I agree, the former is more intuitive, additionally shouldn't the "null" point ( Dynamic Brake Setup ) be set first and then Dynamic Brake....I'm in favor of changing it.Full Throttle - Dynamic Setup - Dynamic Brake
One other question, does this version of monogame permit the use of ReShade? I seem to be having difficulty in getting it working with this version, works fine with other monogame versions.
Thank you.

[EricF]

I believe PI Engineering uses the sequence Full Throttle > Full Dynamic Brake > Dynamic Brake Setup to calculate the full range of the control and then derive the center region between the extreme end values.

Some (possibly) interesting thoughts:

I've seen the Rail Driver's circuit board, and apparently the analog controls (and, interestingly, the rotary controls as well) are capacitive, not resistive or magnetic Hall-effect potentiometers.
Variable capacitor controls have a little bit of lag as they charge and discharge when varying their output. While the RailDriver's analog-to-digital conversion for USB output might smooth that a bit, I suspect it's important to sample the output of the controls fairly rapidly and average the samples to get a good "read" on control positioning. (Too few samples will result in a strong "rubber-band" feel, and vague, drifting physical positioning of the levers in relation to the expected throttle "notch" regions and brake position values.)

What that means for calibration is, when the user lets go of the control and clicks the calibration button, take multiple samples and average, and wait for a bit (in milliseconds) for the average to settle into a reasonable tolerance before taking the calilbration snapshot. It shouldn't take but a few milliseconds, but a good, stable average and high enough sample rate is key.

Likewise, when reading movement to determine where the control is in relation to throttle notch points and braking percentages, you have to account for "input lag" as the control moves, the capacitance catches up, and the output stabilizes. A fast enough sample rate will help with that.

Why did PI use variable capacitor controls instead of the more common resistive potentiometers or Hall-effect potentiometers? My guess is they wanted to duplicate some of the "input lag" that's inherent in real locomotive controls. Real locomotive controls are linked through electrical relays and pneumatic systems. There's always a bit of delay between actuating a control and getting a response. The capacitive controls provide a little bit of baseline delay.

The challenge is handling it correctly in the software. Slow sample rates (or worse, just taking the first value from a single sample) will give the rubber-band effect and vague control positions. Faster sample rates will account for the "sluggish" change rates of the capacitive controls and make for more predictable behavior. There will always be a baseline delay to account for in calibration and operation.

One of these days, I really need to publish the pictures I took of the insides of the RailDriver on my blog... It's kind of intriguing, if you like knowing how things work.

[jared2982]

Did some testing today and found a couple of issues. One- the sander will not turn off with the button on RD. I had to turn it off using the keyboard. The second issue is the horn. If I blow it with the RD pulling the switch down does nothing. Once I release the horn switch the horn starts to blow. Pulling the horn switch back down stops it until I release the switch and it starts blowing again. The only way to turn it off is to blow it using the keyboard. Everything else seemed to work just fine. The only thing I have is there needs to be a way to delete key assignments from the RD key map. If there is I could not find it.

Cheers