PC Raildriver

campinge give me a DM, let's get you under NDA and on the beta programme, then you can access everything and help with feedback to make sure it runs the best it can, it's also easier to talk directly with the dev team and get answers to technical questions.

The variation on the notch setup, as i've seen it, is that there is some variation in whether "input" or "output" positions define the notch.

For those unaware - TSW has two lever position representations. The "input" is usually 0 to 1 and just matches the minimum and maximum extents. The "output" is range-mapped to something that makes more sense, and might map it to say -1 to 4 - if you have one step below zero, then four steps above it. But this input/output difference can be confusing, and the way notches are defined using an inconsistent (as far as I know ) mix of the two, doesn't help matters at all.

In one loco - i think it's the 350, the *fixed* notches are defined with one, and the *continuous* positions are defined in another. Move on to test a different loco and now its all done on the inputs and another loco its another mix. I think ultimately it's down to the loco author who simply sets the notches up the way they feel most comfortable for the configuration they're trying to achieve.

I have some code that is trying to make sense of it - my goal is to have a set of vibration motors which I'll attach to the TSC-X throttle handles, then as you move the throttle to a new "notch", it'll buzz the motor - giving you direct haptic feedback. My code is far from finished though, but happy to share notes - this is a personal project, nothing official.

I've also been trying to make it work without any configuration needed - so it scans what controls are on the loco once it detects a new loco, and based on which ones it finds, i've got some rules set up so it can say "oh hey this is a two handle BR era loco, set it up like this" or "this is a german sbahn style pbc - set it up like this". Basics of this are working quite nicely but only on a limited configuration thus far, I want to get this notching stuff sorted before I spend more time anywhere else.

Matt.

 

No changes to raildriver yet, hoping to get the jitter fix into the next patch.

Matt.

 

Those are going to need something else I think, not sure if the current interface can support controls that adjust themselves - but will add to the list of things to look for a solution to, several affected by it.

Matt.

 

Yeah I found there was a change made when the API went in which removed something inadvertently (simple logic mistake).

Because the raildriver has very noisy potentiometers on the input levers, when you read values from it you dont get a single value even if the lever stays still - you get a bunch of wavering values in around the one you actually want. Which is what gives you the jitter. Depending on how well your potentiometers are doing, depends on how much jitter you experience in the raw data.

Before TSW5 we had some code in there that required the lever to have moved more than a small amount before it would accept the new input as valid - which then smooths it out, at the cost of reducing the resolution of the lever a little.

The change that went in flipped the logic on a surrounding test and that meant it no longer did the jitter removal for RailDriver. I've had that flipped back and in my tests it's much better (even on my 23 year old OG Rail Driver). I got beta team to test the change too, and they've reported positively.

It's a core change that affects input reading of any lever from the raildriver, and is not train specific, so all trains are behaving better.

Matt.

 

I'll give it a try later on and see how it is.

Matt.