combination key presses in FSUIPC

[ozbeowulf]

I'm working on a new sim console and trying to use DPDT switches for combination keys such as CTRL + E or SHIFT + F7. The obvious problem is that simultaneous presses of CTRL and E keys will not reliably produce CTRL + E. So far, experimention with R/C circuits to induce the needed 10 or 20 millisecond delay between the CTRL & the E (for example) has not been fruitful.

FSUIPC button programming allows such combinations for a single button press by staggering the combination keys, but I cannot find a way to do the same thing with a key press (as opposed to a button press). Am I missing something in the User's Guide and Advance Guide?

Many thanks for any help you can offer. Btw, many thanks also for FSUIPC. I used earlier versions and purchased Ver3 in a heartbeat when it came out.

Glenn Duncan

Townsville, Qld

Australia

[Pete Dowson]

I'm working on a new sim console and trying to use DPDT switches for combination keys such as CTRL + E or SHIFT + F7. The obvious problem is that simultaneous presses of CTRL and E keys will not reliably produce CTRL + E. So far, experimention with R/C circuits to induce the needed 10 or 20 millisecond delay between the CTRL & the E (for example) has not been fruitful.

Sorry, I don't understand much of that. Where do R/C circuits come into it please?

Almost everyone who programs key presses in FSUIPC's Buttons page will be using a combination of Ctrl, Shift, Tab, Win and/or Menu with a normal graphic or cursor or function key -- this is normal because most if not all single key presses are already used.

FSUIPC button programming allows such combinations for a single button press by staggering the combination keys

Erstaggering? No. For all windows applications, if you want CTRL+E, say, you hold CTRL first then press E. That's how you program FSUIPC in the Buttons page. But the key sequences it then generates aren't specifically staggered. It is simply a sequence of windows messages -- CTRL key down, E key down, E key up, CTRL key up.

but I cannot find a way to do the same thing with a key press (as opposed to a button press). Am I missing something in the User's Guide and Advance Guide?

I am really bewildered as to what you are looking for. Just program the keypresses in the Buttons page. Why do you specifically need the documentation for that? Go the Buttons tab, operate your button, select Key Press programming instead of controls, press your key combination, see it recorded, then confirm and OK your way out. Isn't that simple? If not, what am I missing?

Regards,

Pete

[ozbeowulf]

Sorry if I didn't make myself clear.

The R/C circuits I mentioned were Resistance/Capacitance circuits. I want to introduce a small time delay for one pole of a double-pole/double-throw switch to emulate the sequence, for example, CTRL, then E.

Since I have not yet been successful, I wondered if the proper sequencing could be introduced using FSUIPC. Apparently, only through Button Programming, which doesn't help me. Too few buttons are available.

I'll try a different approach. Thanks for your time.

Glenn

[Pete Dowson]

The R/C circuits I mentioned were Resistance/Capacitance circuits. I want to introduce a small time delay for one pole of a double-pole/double-throw switch to emulate the sequence, for example, CTRL, then E.

But why not simply program the button action to give your CTRL+E?

Since I have not yet been successful, I wondered if the proper sequencing could be introduced using FSUIPC. Apparently, only through Button Programming, which doesn't help me.

I'm sorry, I'm lost again. If you are not wanting keystrokes to result from button operations, which is one of FSUIPC's button programming facilities, what is it you are wanting to do? We seem to be going in circles, don't we?

Too few buttons are available.

In what way? You have too few in your hardware? You can use conditionals and flags in FSUIPC to multiply them, you know. In the extreme you can make n buttons operate 2^n different actions, even separately for each aircraft model and even with differences for things like on the ground/airborne, engines running, flaps extended, etc etc. There's almost no limit -- but for much of that flexibility I'm afraid you have to resort to INI editing rather than simple entries into the dialogue.

I'll try a different approach. Thanks for your time.

Well, I'm sure I could help if I understood what you wanted, if it isn't what seems obvious from your questions.

Regards,

Pete

[Bob Church]

Hi Glenn,

PMJI, it sounds like what you've got a keystroke generator of some sort and that you're trying to program CTL-E on the "Keys" tab in FSUIPC to send an FS command rather than to program a joystick button on the "Buttons" tab to send CTL-E, and that the RC circuit is an attempt to delay the closure of the "E" circuit so that the "CTL" circuit closes first. Yes?

If so, what are you using to send the keystrokes? If it's electronic, chances are the R in the RC circuit is just setting up a divider circuit, there's a good chance that the signal input isn't getting to ground (or the positive rail depending on how it's set up). Maybe going way down with the R value to get it closer to the rail, and then way up with the C value to hold the time delay would do it, but without knowing what the input circuit looks like it's just a shot in the dark.

Best regards,

- Bob

The StickWorks

http://www.stickworks.com

[ozbeowulf]

You got in one, Bob!

Specifically, I'm trying to get one operation by a DPDT switch (momentary, center-off) to perform a combination keystroke. CTRL + E is simply an example. A reliable method to do that would triple (approximately) the available commands accessible with single switch operations.

So far, after bread-boarding various combinations, the best results come with this R/C circuit on the side of the DPDT switch to be delayed.

(short side of keybord matrix)------vvvvv---|--| |---|--(long side of matrix)

|-vvvv-|

The resistors are both 1 K ohm and the cap is a 1000 ufd electrolytic. It delays the "e" signal to produce a CTRL + E on 80-90% of switch ops, but the remaining 10-20% of the time it either blanks (i.e. only the CTRL gets through) or only the E gets through. So... not good enough yet.

I've varied both the R and C elements of this simple circuit somewhat and results drop off, but I will experiment with the major decrease in R and increase in C you suggested.

Btw, I know a proper time delay circuit would involve using this sort of R/C circuit to switch a transistor or 555 IC on and off, but I need many circuits and would have to introduce a separate power supply to my small sim console. I live on a boat, so space is at a premium. I'd like to keep it small and simple, i.e. one console structure with no power needed beyond what the computer supplies via the hacked keyboard pcb.

Thanks for the reply and for grasping my earlier posts. I was barking up the wrong tree, I guess, but I thought I'd explore a software solution. There doesn't seem to be one, so I'm back to re-jigging the hardware.

Cheers,

Glenn

[ozbeowulf]

Whoops! When I posted the previous message, the different margins on the board messed up my admittedly primitive text-based circuit diagram. In plain language, the flow is from an input on the short side of the keyboard matrix through a 1 K ohm resistor to a 1000 ufd capacitor which is paralleled by a 1 K ohm resistor to an input on the long side of the keyboard matrix.

Glenn

[Bob Church]

Hi Glenn,

Ah. I don't know if you can really get it to work with a scanned keyboard matrix setup. I was thinking you were using something that accepted the button inputs individually, one of those little keyboard modules maybe. If I understand you correctly, you've got the second resistor and the capacitor in parallel across the switch. That will probably delay it a bit, but if the cap gets too large it's probably just going to act like the switch is closed. The strobe that goes to one side of the matrix is going to pass right through it.

Best regards,

- Bob

The StickWorks

http://www.stickworks.com

[ozbeowulf]

It's been an interesting morning....

A few years ago, I tested this idea with just a 330 ufd cap on the leg to be delayed and it worked. If it hadn't, I certainly wouldn't have gone to the trouble of building console loaded with DPDT switches. This morning, I sorted out the problem, I think.

I dug out a small keyboard emulator I built some time ago to use with the electronic charting system I have on board. I hacked a USB keyboard pcb for that emulator and I finally remembered why. I had found that the old DIN and current PS2 keyboards would only accept one cursor key at time, but I could move a map cursor diagonally using two cursor keys on the USB keyboard I used everyday. So I picked up an el cheapo USB keyboard back then and used it. And not only does it accept dual cursor inputs and respond with a diagonal movement, it also will take CTRL (or SHIFT) + L (for example) and produce a capital L. Don't know exactly why, but it acts like there is a logic circuit that differentiates between two simultaneous keypresses and sequences any CTRLs or SHIFTs first. I haven't tried TAB as a combo key yet, but I suspect it won't work. We'll see.

Anyway, I just picked up three more of those cheap Chinese keyboards (US$7.50 from a local discounter) and I'll use one of them. I can't imagine why I started this upgrade with the old keyboard pcb instead of newer gear. Brain fart, I guess. I'll probably put a lone cap into the circuit just for overkill, but so far I haven't been able to induce a failure, even without the cap. Many thanks for your advice.

This seems like a minor FS watershed to me. Who needs an EPIC card or FSBUS if we can get 240-odd single-switch keypresses from a down-market keyboard pcb and use that to take advantage of the wide variety of FSUIPC commands.

Gotta go fully map this pcb and get to work.

Cheers,

Glenn

[Bob Church]

The keyboard type would make a difference. PS2/AT keyboards sent one character at a time as serial data, so the keys had to line up in order. With USB, it just sends a report that contains generally as many as 6 keys as well as the Left and Right Shift, Alt, and Control states. USB keyboard don't autorepeat, either. The system phonies up an autorepeat but all the USB keyboard does is to send a report with the keys that are pressed. When you release a key, it sends another report that lists the keys that are still pressed, none if that's the case. Anyway, the USB keyboard drivers in Windows should deal with the simultaneous keys okay, though some sims, Falcon and LOMAC for example, will choke on them.

Anyway, if it works, that's all that matters. :)

Best regards,

- Bob

The StickWorks

http://www.stickworks.com