BU0836X, Encoders and FSUIPC

[eossim]

Greetings,

I am using a BU0836X with a Rotary encoder CTS 288 (288T232R161A2) to drive FS2004 VOR OBI.

The problem is that it is extremely slow as it seems to miss a lot of pulses.

I have configured the card with the Leo Bodnar's encoder config utility using different pulse delay without

sinificant improvement. I have edited the fsuipc.ini file to trigger the VOR OBI several times per detected pulse.

Altough it is much faster, precision is lost of course.

Have someone experienced something similar ? Any hint to solve this ?

Thanks for help.

Cedric

[Pete Dowson]

I am using a BU0836X with a Rotary encoder CTS 288 (288T232R161A2) to drive FS2004 VOR OBI.

The problem is that it is extremely slow as it seems to miss a lot of pulses.

What is it sending? Keypresses or Button toggles? How are you programming it? Keypresses or controls?

Some information might help me help you.

Regards

Pete

[boruca]

Hi Pete:

I have the same problem. Im use de Realty XP Gauches and these software has a config file for key assignements. Then, I use for my knobs (encoders CTS) the Keypresses programming. The encoder respond very slow. I cannot use the Button troggles because I dont have RealtyXP commands inside FSuipc. Please help me.

Gracias.

Tracy

[Pete Dowson]

I have the same problem.

And I still have no information to work with.

Pete

[boruca]

For example:

I have in the RealtyXP config file (RXPFLT.INI):

(Keypress)

VOR1_INC=SHIFT+CTRL+F1

VOR1_DEC=SHIFT+CTRL+F2

and in FSUIPC Options and settings (Button and switches) I use the option "Select for key press" and press my fisical button for this:

Press key to be sent when you press thiis button: SHIFT+CTRL+F1

and

Press key to be sent when you release thiis button: SHIFT+CTRL+F1

Tracy

[Pete Dowson]

For example:

I have in the RealtyXP config file (RXPFLT.INI):

(Keypress)

VOR1_INC=SHIFT+CTRL+F1

VOR1_DEC=SHIFT+CTRL+F2

and in FSUIPC Options and settings (Button and switches) I use the option "Select for key press" and press my fisical button for this:

Press key to be sent when you press thiis button: SHIFT+CTRL+F1

and

Press key to be sent when you release thiis button: SHIFT+CTRL+F1

Why? Do the encoders send on/off pulses? If so, how fast? If you want a faster scan rate in FSUIPC you'd need to adjust its polling interval -- "PollInterval" in the relevant [buttons] sections of the INI file. The default is 25 (mSecs) which is 40 polls per second. Here's the relevant paragraph quoted from the FSUIPC Advanced User's guide:

A polling rate of 40 per second is more than adequate for all normal button programming. It is only when you come to the more advanced uses that you may want to change this. Rotary switches, for instance, may give pulses so fast that some are missed at such a rate.

Of course, the Windows keypress queue is also a bottleneck. When you use the SHFT+CTRL+F1 press on the keyboard and hold the key down, does it go fast enough for your liking? I don't think you will get it a lot faster -- maybe a little.

Pete

[boruca]

Thanks Pete, I go to make the changes in the INI file.

Tracy

[boruca]

Hi Pete:

I resolve the problem. You are correct respect to keypress speed in Win. Its fast for me. I modify the fsuipc.ini with this:

REPEAT=75,0 and

POLLINTERVAL=15

The encoders speed is fast and I test other values to optimice.

Thanks.

Tracy.

[Bob Church]

Hi Pete,

They usually send (at the hardware level) to sets of pulses, about the same deal as a mouse actually. The pulse trains come out shifted half of one pulse width relative to each other so they can determine direction. They're usually called "bi-phase" encoder. Treating them as a mouse might work out. Sending character isn't very usefull generally. Better to use a low res encoder and not try to move it very quickly.

The problem with them is generally that the pulse need to hold at the FS level for one frame and users tend to spin them rapidly, . Otherwise they get missed. If they have any resolution at all, you have to turn them slowly so that each transition on either of the pulse trains holds until FS queries DX (and so HIDClass) for buttons and axes which as you know only happens once per frame. The advantage is that if they'll work, the can spin forever, just like the mouse rather than having a rotation angle like a pot would, but it's difficult because people tend to just spin the things as fast as they can.

Hope you doing well!

Best regards,

- Bob

The Stickworks

http://www.stickworks.com

[Pete Dowson]

They usually send (at the hardware level) to sets of pulses, about the same deal as a mouse actually. The pulse trains come out shifted half of one pulse width relative to each other so they can determine direction. They're usually called "bi-phase" encoder.

I know of such encoders, but I've never seen any. I assume the Leo Bodnar card is doing the decoding -- though there are ways of doing it in FSUIPC's INI file using flags. There's an example in the Advanced User's guide.

All of the encoders I've ever used are simple to connect and program, without a special decoding circuit. They have common and two other connections which provide the "button pressed" pulse for each direction. Those are a doddle to program of course.

And, yes, it is always much more efficient to program them direct to FS controls rather than keypresses, but unfortunately some add-ons only accept keypresses for some tasks (like, presumably, the RealityXP gauge add-ons). Not the regular FS OBI adjustments though, the controls are fine for that.

Regards

Pete

[boruca]

Hi All:

The encoders work fine with mi suggestion, however this solution resoults partial. I explain:

The encoder accuracy in VOR and ADF gauges is not very thin and jumps, its fast but not accurate. It's a bit hard to pick a exact value because encoder operation.

I am trying another option in search of better accuracy while maintaining speed with the ALPS EC 11 encoder. This encoder is a rotary unit, like CTS encoders, but the difference is in the operation. ALPS encoder has only 3 position (like a selector) ON (pulse) - NONE -ON (pulse). You may operate the encoder with one movement to left or right to obtein the pulses. and when you release de knob, the encoder self-return to NONE position in the center. The encoder turnrs like a CTS encoder but not complety, its a single turn to left or right. Visit this link for more info of EC11 encoder http://www.alps.com/WebObjects/catal.../EC11/EC11.PDF

Good luck

Tracy - boruca (Sorry, my english its not so good)

[Masterploxis]

Hello,

thanks to Peter and AK Mongo for pushing this issue.

I take the same approach using LUA to get 4 buttons out of the encoder turns.

I have two questions:

The result in hidscanner.log is for the BU Card is:

Device at "\\?\hid#vid_1dd2&pid_1001#6&9f26302&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"

Vendor=1DD2, Product=1001 (Version 1.35)

Manufacturer= Leo Bodnar

Product= BU0836X Interface

Serial Number= B17910

The hiddemo.lua starts with:

Vendor=1DD2, Product=1001 (Version 1.35)

Product= BU0836X Interface

Device = 0 -- Multiple devices of the same name need increasing Device numbers.

-- Logging on or off (to see when numbers you are getting)

Logging = true

The hiddemo.log gives me the following error:

********* LUA: "HidDemo" Log [from FSUIPC version 4.703] *********

687684 System time = 28/05/2011 20:43:41, Simulator time = 05:41:56 (03:41Z)

687684 LUA: beginning "F:\FSX\Modules\HidDemo.lua"

687684 *** LUA Error: F:\FSX\Modules\HidDemo.lua:14: malformed number near '1DD2'

687684 LUA: ended "F:\FSX\Modules\HidDemo.lua"

687684 System time = 28/05/2011 20:43:41, Simulator time = 05:41:56 (03:41Z)

********* LUA execution terminated: Log Closed *********

Any suggestion why LUA doe not like the vendor name ???

AK Mongo:

Maybe i can get faster results with your help.

To which inputs on the BU Card is your encoder connected ?

I connected mine to 31 & 32 which is shown in USB game controller programm. When i turn the encoder it gives me signals on ccw 31 & cw 32 as it should.

The result in fsuipc looks different. There it sais ccw 30 & cw 31 ?? Which value did you use in your lua file ? The game controller vaöue or the fsuipc value. Anyway - i tried to edit the lua file for 30 / 31 and also for 31 / 32 with the same result - no additional buttons show up in fsuipc when i turn the encoder fast.

Any idea ?

Cheeres from Germany

Andy

[AK Mongo]

AK Mongo:

Maybe i can get faster results with your help.

To which inputs on the BU Card is your encoder connected ? I only have 1 encoder hooked up. It is connected to the Bodnar card on inputs 31 and 32.

I connected mine to 31 & 32 which is shown in USB game controller programm. When i turn the encoder it gives me signals on ccw 31 & cw 32 as it should.

The result in fsuipc looks different. There it sais ccw 30 & cw 31 ?? Which value did you use in your lua file ? Pete built the Lua file and I have not modified it in any way, other than adjusting the poll rate and boundary time as Pete suggested. Did you create the ipcready.lua file in your modules folder that Pete created?

Reid

[Pete Dowson]

Device at "\\?\hid#vid_1dd2&pid_1001#6&9f26302&0&0000#{4d1e55b2- f16f-11cf-88cb-001111000030}"

Vendor=1DD2, Product=1001 (Version 1.35)

...

Vendor=1DD2, Product=1001 (Version 1.35)

Product= BU0836X Interface

Device = 0 -- Multiple devices of the same name need increasing Device numbers.

...

687684 *** LUA Error: F:\FSX\Modules\HidDemo.lua:14: malformed number near '1DD2'

...

Any suggestion why LUA doe not like the vendor name ???

As it says, 1DD2 is not a good decimal number. As the documentation says, you either need to give the details as strings:

Vendor="1DD2"

Product="1001"

or as the hexadecimal VID and PID from the line before:

Vendor=0x1dd2

Product=0x1001

Also you have the Product variable twice. Not sure if Lua accepts multiple assignments separated by ,

Regards

Pete

[Filipe Bessa]

Hi Guys,

Appreciate if someone could help me on this. I'm doing some tests with Leo Bodnar's controller BU0836X with a rotary 288V232R161B2. I'm trying to work out with increasing (clockwise) and decreasing (counter-clockwise) degress. I was able to connect and configure the VOR using the option "Press the key(s) to be sent when you press this button" on FSUIPC. Got that working, but only increasing degrees. I couldn't figure out how to configure it to rotate counter-clockwise and get the degrees turning to the other way around (decreasing). Basically it will increase if I turn the rotary to either directions.

I connected the wires on the board on 28 and 29 (both). I ran the utility from Leo and it is set up to 1:1 and 48ms.

Any idea where am I slipping on?

I'm starting the sim now, so not much understanding on this stuff yet. Planning a C172 panel, with PM GA (LED 23 emulating). Got the Cessna yoke, rudder and trim.. from Saitek.. :)

Appreciate the help.

Cheers

Filipe

[Pete Dowson]

I'm doing some tests with Leo Bodnar's controller BU0836X with a rotary 288V232R161B2. I'm trying to work out with increasing (clockwise) and decreasing (counter-clockwise) degress. I was able to connect and configure the VOR using the option "Press the key(s) to be sent when you press this button" on FSUIPC.

Why use keypress assignments when there are perfectly good FS controls for such standard functions? You only need to assign to keypresses when driving add-ons which don't recognise FS controls! A list of FS controls is installed for you in the FSUIPC documents folder, and you can use FSUIPC's event logging to determine exactly which control corresponds to which function when you use it. Using keypresses is very inefficient, especially with something which is going to be repetively pressed and released like a rotary.

Got that working, but only increasing degrees. I couldn't figure out how to configure it to rotate counter-clockwise and get the degrees turning to the other way around (decreasing). Basically it will increase if I turn the rotary to either directions.

The rotary should be sending a different button one way to the other, so you simply need to assign one to the INCRement control and the other to the DECRement control.

Note that with most rotary controls you get "button pressed" and "button released" alternately on each click, so if you want the change to happen on each click you need to assign both press and release to the same control. But please do change to using controls, not keypresses -- the latter will simply choke in Windows' message lists and result in delayed actions in the gauges. You get at least 5 times as many messages going through per click using keys than the one needed for a control.

Regards

Pete

[Filipe Bessa]

Hi Pete,

Thanks for all your comments.

In fact I have tried the FSUIPC for the commands in the FS as well, it also worked.

Actually what I was doing wrong is that turning clockwise the rotary was alternating between 28 and 29 button, so I could never use the INC and DEC this way. It was also happening counter-clockwise. This happened because of the "stupid person - ME" connected things wrong on the board.

I could not get the command to be repeated turning to one side. So now, with things connected correctly, I get 29 clockwise and 28 counter-clockwise.

I'll play more with this, but will probably bother you a bit more soon. :)

Thanks mate.

Filipe

[Filipe Bessa]

Hi Pete,

Yes, got that working now. I'm testing it with heading but as expected it is quite slow and sometimes it loses the pulse.

Went to the FSUIPC.ini to change the repeat and pollinterval, as per the tracking on this POST, but I can only see the repeat option. Maybe it is because of FSUIPC 4.6?

Sorry for the basic questions, as I mentioned, just started playing with that now.

Thanks,

Filipe

[Pete Dowson]

Yes, got that working now. I'm testing it with heading but as expected it is quite slow and sometimes it loses the pulse.

Are you still using keystroke assignments? If so, don't. That'll never improve.

Are you assigning to both press and release? If not it will be half speed in any case.

Went to the FSUIPC.ini to change the repeat and pollinterval, as per the tracking on this POST, but I can only see the repeat option.

The button repeat only applies when a button is held down, so it doesn't apply. The PollInterval parameter is an optional one for the [buttons] section. Please look in the Advanced Users guide. Use search on 'PollInterval'. However, don't reduce it too much -- the default of 25 mSecs is 40 times per second which should certainly be sufficient. i think FS's is 6 per second.

Pete

[Filipe Bessa]

Pete,

I'm using the FS Control option and assigned the Gyro Drift Inc on clockwise and Dec to counter-clockwise.

I went through some sections of the advanced user guides, specially on the pollinterval part. I have got the following on the IN, for buttons. I added the parameter manually.

[buttons]

ButtonRepeat=20,10

PollInterval=25

6=P0,28,C65878,0

8=P0,29,C65877,0

10=R0,27,K86,9

11=U0,27,K187,9

12=R0,26,K86,9

13=U0,26,K187,9

No improvements made, I still need to turn the rotary about 5 times to go through 1 degree. This I believe is due to the missing pulses, when I turn once it doesn't change, then twice then 3rd time it changes. I have CTS A connected to 29, C to 30 GND, and B to 30.

On the Leo's software I have 48 ms, and set to 1:2, also tried 1:1 and various pulses, but not much difference.

Edited November 25, 2011 by bessalf

[Pete Dowson]

I'm using the FS Control option and assigned the Gyro Drift Inc on clockwise and Dec to counter-clockwise.

I went through some sections of the advanced user guides, specially on the pollinterval part. I have got the following on the IN, for buttons. I added the parameter manually.

But you set it to 25 mSecs, which is the default value in any case, so why add it?

I have no idea what units FS does its Gyro Drift inc/dec in. Never used it (I fly airliners) -- so what happens to the dial with one use of the control? Internally the gyro drift amount is in 1/65536ths of a degree, so it certainly can't be one of those or it would take you forever to adjust by one degree. But equally it may not be a whole degree in any case. It might be a half?

No improvements made, I still need to turn the rotary about 5 times to go through 1 degree. On the Leo's software I have 48 ms, and set to 1:2, also tried 1:1 and various pulses, but not much difference.

Sorry, I've no idea what all the latter stuff means. You need to talk to Leo about that sort of thing. But when you say "5 times" do you mean 5 x 360 degree turns, or 5 "clicks"? Does it click?

I see you haven't even bothered to assign the button releases to the same controls, as I suggested, so it would take at least two clicks in any case.

Pete

[Filipe Bessa]

Hi Pete,

Sorry for the misunderstanding.

This is on a Cessna 172, the Gyro is for the DI.

You are correct, one turn (click) on the rotary gives me half degree (could be 1 degree?), however I realized not all of the turns is giving a command out. Sometimes I turn 3 times to get it to change, not sure why these missing pulses? The 5 times I mentioned is to turn the rotary 5 times (clicks) to get 1 degree changed.

Sorry, I mistyped that on the INI, in fact I wanted 15 for the pollinterval.

Yes, I also assigned the button releases as you suggested.

Looks like the main problem is the missing pulses. What would be the adequate pulse width with the 15 pollinterval set up? I haven't fully understood this. :(

Btw, to make sure the pollinterval parameter is working, I set it to zero so the tab buttons was disabled on FSUIPC.

Thanks,

Filipe

[Pete Dowson]

You are correct, one turn (click) on the rotary gives me half degree (could be 1 degree?), however I realized not all of the turns is giving a command out. Sometimes I turn 3 times to get it to change

not sure why these missing pulses? The 5 times I mentioned is to turn the rotary 5 times (clicks) to get 1 degree changed.

So now it is down to 3, which sounds reasonable for 1/2 degree per click. If the computer had nothing else to do but what the inputs it might not miss any at all, but we are talking about an ordinary user-level program sharing resources with a flight simluator which has other things to do as well. If you are fussy enough to demand one click per increment or decrement, and never more or less, you need to have a kernel-mode driver.

Looks like the main problem is the missing pulses.

Can you explain why this is a "problem"?

What would be the adequate pulse width with the 15 pollinterval set up? I haven't fully understood this. :(

Assuming there is nothing else for FS and FSUIPC to do, so it could actually certainly always read the USB status every 15 mSecs, then the pulse width (both high and low states) would need to be more than that to guarantee never to miss one. However, because quite often FSUIPC (or even FS) won't have the processor at the time, the only guarantee of never ever missing is N mSecs pulse width, where N is unknown but certainly pretty big. Possibly you could use your FS frame rate as a guide. If you are getting 100 fps all the time in FS then FSUIPC should theoretically have time to scan everything once every 15 mSecs. as specified. If a more usual 25 fps is the norm then maybe there will be some intervals of 40 mSecs or more when FSUIPC cannot deal with the change.

The actual scanning is actually in a higher priority thread. That isn't the problem, it is the sending of the resulting command to FS. That can't be done at anything faster than the frame rate. And FSUIPC will NOT queue these up, one per click, because 99% of folks use rotaries with visual feedback -- i.e. they read the dials as they are turning the knobs. That's normal practice, so I'm not sure why you are counting clicks instead. If FSUIPC queued pulses and sent batches of commands to FS, the feedback would be wrecked, folks would over-adjust and have to adjust back, and so on.

Btw, to make sure the pollinterval parameter is working, I set it to zero so the tab buttons was disabled on FSUIPC.

Yes, 0 is a special case meaning don't read any buttons at all.

Regards

Pete

[Filipe Bessa]

Hi Pete,

Thanks for all your inputs here, really appreciated.

Maybe I understood wrong what you mean about clicks, click to me is one turn on the rotary? I could see this missing pulse on the FSUIPC buttons screen, where it was taking up to 3 turns to change to the other button. Is this normal? I assumed not, so that's why I said "problem". Shouldn't it execute the command every time you turn the rotary? Ideally, right?

Yes, I'm turning and looking at the DI, so with the current setup it is taking some effort to change heading.

I was looking for 1 turn on the rotary, 1 degree on heading. Is this achievable?

One thing you mentioned about the frames, so it could potentially be my "problem" here.

As I mentioned, I'm on the initial state of my project, so I'm not using the pc I want yet (looking for hight frames), so instead, I'm emulating a VMware windows 7 image with FSX on it. For sure performance is really low and just confirmed now, it's 10fps. I'm spending some time with the hardware first so then I can move forward with more things on hands, but wasn't expecting this to "catch me". The idea is to have the rotary and switches (lights and stuff) to be working pretty good and then go to the real deal.

Sorry for the trouble.

Regards,

Filipe

[Pete Dowson]

Maybe I understood wrong what you mean about clicks, click to me is one turn on the rotary?

Er ... I kept asking you to confirm whether by a "turn" you actually meant a 360 degree twist of the knob or not. All of the rotary encoders I've ever used make a little 'click' (either audible or feelable or both) when turned a little, and each click either makes the contact (press) or unmakes it (release). One 360 degree turn may generate 10 - 30 clicks. The ones used on GoFlight devices generate about 24 per full 360 degree turn.

I could see this missing pulse on the FSUIPC buttons screen, where it was taking up to 3 turns to change to the other button. Is this normal? I assumed not, so that's why I said "problem". Shouldn't it execute the command every time you turn the rotary? Ideally, right?

I now cannot answer this until you explain your "turn".

For sure performance is really low and just confirmed now, it's 10fps. I'm spending some time with the hardware first so then I can move forward with more things on hands, but wasn't expecting this to "catch me".

At 10 fps you'd need a pulse width of over 100 mSecs, obviously. (1000 msecs / 10 frames = 100 mSecs per frame).

Pete