Jump to content
The simFlight Network Forums
Sign in to follow this  
Wizball

Strange value from one offset

Recommended Posts

Hi.. I have made an logic on PMSystems for automaticly disconnects autobrake when using the toe brake.

For that I have used this offsets for detecting the toe brake use.

0C00 1

Right toe brake control: 0 – 200, proportional braking with timed decay

0C01 1

Left toe brake control: 0 –200, proportional braking with timed decay

When monitoring the two offsets I got normal values from 0C01 (left toe brake) , 0-200 as described. But from the 0C00 (right toe brake) I got some very strange values. I dont remeber the values right now (at job) but it is not between the 0-200. And the right toe brake also "infect" the values for the left toe brake. Is it a bug ? :)

Using FS2004 with FSUIPC 3.71

Well.. hope you understand. :)

Best Regards

Tom Stian Bjerk

Share this post


Link to post
Share on other sites

For that I have used this offsets for detecting the toe brake use.

0C00 1

Right toe brake control: 0 – 200, proportional braking with timed decay

0C01 1

Left toe brake control: 0 –200, proportional braking with timed decay

These are control inputs (not read-outs) for the application of brakes with a pressure-decay release, as opposed to proportional brake inputs directly (eg from analogue toe brakes on pedals). The function dates back to FS95/FS98 and has been retained in FSUIPC all this time because it is used by some drivers for toe brakes, such as those for the Aerosoft GA28R cockpit.

When monitoring the two offsets I got normal values from 0C01 (left toe brake) , 0-200 as described. But from the 0C00 (right toe brake) I got some very strange values. I dont remeber the values right now (at job) but it is not between the 0-200. And the right toe brake also "infect" the values for the left toe brake. Is it a bug ? :)

Sorry, I don't know anything about "strange values" getting into these locations -- show me some logs with the values Monitored (see FSUIPC Logging facilities) if you want me to check, but I think you are monitoring entirely the wrong thing to determine brake usage. It may only work because of the way your toe brakes are connected and driving FS.

The braking indicator at 0BCA is more reliable, but the offset especially added for your precise need is the one at offset 32F9.

Regards

Pete

Share this post


Link to post
Share on other sites

Although not related to FSUIPC directly, but if it helps any finding out why:

The XML variables BRAKE LEFT POSITION and BRAKE RIGHT POSITION had the the same problem (= the read values being dependant on eachother).

But that was in FS2002 ONLY (OK in FS9 or FSX), and then ONLY when those two variables were read in the same XML gauge.

Maybe this is a simular problem as yours.

Regards, Rob Barendregt

Share this post


Link to post
Share on other sites

Now I tried the both 0BCA and 32F9 offset..

The Autobrake is trigging the 0BCA offset, so can not use that one.

But the 32F9 is working almost fine :) .. The only problem is that the offset is only trigging when my toe brakes are "on the move" If I hold the brakes steady at 50%, the offset is "0". PMsystems can have some problem to get the time to read the offset if I dont push the brakes "slowly".

Best Regards

Tom Stian Bjerk

Share this post


Link to post
Share on other sites

The Autobrake is trigging the 0BCA offset, so can not use that one.

Yes, that's why the 32F9 offset was added.

But the 32F9 is working almost fine :) .. The only problem is that the offset is only trigging when my toe brakes are "on the move" If I hold the brakes steady at 50%, the offset is "0".

Yes, as documented. It also isn't held on if the brakes are decreasing.

PMsystems can have some problem to get the time to read the offset if I dont push the brakes "slowly".

Well, it is held for a whole second (enough for at least 30 normal WideFS transfers and at least that number of Logic loops in pmSystems), so it shouldn't be a problem even if you simply "blip" the brakes. That was the whole reason for the 1 second hold. Have you got a very slow (i.e. high) pmSystems cycle time set?

Regards

Pete

Share this post


Link to post
Share on other sites

My PM-system may be a littlebit slow.. the logic cycle is set to 50ms .. And the hardware is a P4.. So I dont know why it is so slow.. PMsystems is not a CPU friendly software ..

Share this post


Link to post
Share on other sites
My PM-system may be a littlebit slow.. the logic cycle is set to 50ms .. And the hardware is a P4.. So I dont know why it is so slow.. PMsystems is not a CPU friendly software ..

Well, even at 50 you should be getting 20 reads per second. What's the FS frame rate?

I have pmSystems running at 20mSecs I think, both cycle times. And the same PC also runs ActiveSky, Radar contact, FS RealTime, AI Smooth and pmSounds, all via wideFS.

Regards

Pete

Share this post


Link to post
Share on other sites

I have locked my framerate to 25 FPS. And also usaly have 25 FPS in Fs2004..

My computer that is running PMSystems is a P4 1.4 GHz with 256MB RAM.

The videocard is a Geforce 2 card. But I dont think that should slow down the performance to pmsystem!?

Best Regards

Tom Stian Bjerk

Share this post


Link to post
Share on other sites

My computer that is running PMSystems is a P4 1.4 GHz with 256MB RAM.

The videocard is a Geforce 2 card. But I dont think that should slow down the performance to pmsystem!?

No idea, but why not speed up pmSystems by reducing your cycle time of 50 down to say 20 mSecs and see if it helps? It is already running slower than FS if it is set to 50 mSecs! It would certainly be better running faster!

Regards

Pete

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.