[simpits-tech] EPIC Q's and programming for Falcon4

[Mark Doran]

> Unless you can read the current state of the sim and then go in and
change
> it, you are stuck with performing a preflight checklist and setting
each
> switch or rotary into the correct position before launching the game.

[Mark Doran] That's what I was afraid of :-)
 
> There has been some talk about interface methods (F4 glass, memreader,
> etc)
> and EPIC. However, there has not been published any work so far on
> standardization.

[Mark Doran] This is sort of orthogonal to what I wanted to ask.
However, I was planning to work with the memreader that Martin Schmitt
has put together since that gives you access to the shared memory values
right into EPIC code.

However, as far as I can see, that only give you access to lamp output
bits, values to drive gauges or motion control, and display data for
DED/PFL/RWR.  What it doesn't get you is any kind of ability to read the
position of a knob somewhere in the cockpit.  That's what you'd need to
sync I expect.
 
> That may change and I would be interested in hearing any proposals to
> date.

[Mark Doran] I've certainly lobbied with G2 to look at this issue.  I
don't think we'll see anything on this from F4UT since it would require
source code edits.  I could certainly make such changes if I had access
to the code or describe a workable plan to do it for someone else that
does.  Not holding my breath on that though.
 
> I have started a rough Excel file for a switch matrix of all the
switches
> on
> the F-16.  There are still a lot of empty holes, but I have outlined a
bus
> standard for the cockpit.  Where things have stopped, at the moment,
is
> the
> details that connect EPIC to F4.

[Mark Doran] Did you look at the excel sheet that I uploaded to this
site a while ago -- it has all the switches and dials in Falcon4 mapped
out by panel and a rough first cut at the number of poles per switch
required.
 
> That portion of the project requires deeper thought and how I might
> leverage
> existing avionic standards.

[Mark Doran] I guess I'm less concerned about "macro" bus level wiring.
The hardware side of our crew will figure out the wiring harness type
problems.  

What I wanted to ask more about is the interface between the hardware
switches/knobs and the EPL code.  For example on rotary switches (ones
that are not obviously best implemented with encoders like the HSI CRS
and HDG knobs that is), I can think of three wiring schemes:

First assumption, wherever possible use break before make knobs.  Easy
enough on AGT panels; some of the "real" ones don't work that way
though...a problem I haven't yet figured out and would like a solution
for (anyone??).  Anyhoo...

1) One throw per position wired up to one module/row/bit EPIC input.
This gets you distinct position indication and would work ok if the
keystroke map actually had a keystroke to match each unique position of
the knob.  Sadly I think none of the rotary switches in Falcon4 do have
such keymappings.

2) Wire each throw to one of three module/row/bit EPIC inputs
sequentially.  I.e. first switch position to bit 0, second position to
bit 1, third position to bit 2, fourth position to bit 0, first position
to bit 1, etc.  This works programmatically reasonably well when you
have keystroke bindings for the control that go one left and one right.
Aside from really fast knob spinning, you can know what position you
were at last when an "on" procedure is called by using a var to record
it.  Then if the var value is greater than where you are, press the
go-left-one key else press go-left-one.  Like this:

:fuel_sel_0{
  if (FuelSelLast == 1) {
    keypress(LSHIFT);
    keypress(CTRL);
    keyhit(F1);
    keyrelease(CTRL);
    keyrelease(LSHIFT);
  } else {
    keypress(LSHIFT);
    keypress(CTRL);
    keyhit(F2);
    keyrelease(CTRL);
    keyrelease(LSHIFT);
  }
  FuelSelLast = 0;
}

:fuel_sel_1{
  if (FuelSelLast == 2) {
    keypress(LSHIFT);
    keypress(CTRL);
    keyhit(F1);
    keyrelease(CTRL);
    keyrelease(LSHIFT);
  } else {
    keypress(LSHIFT);
    keypress(CTRL);
    keyhit(F2);
    keyrelease(CTRL);
    keyrelease(LSHIFT);
  }
  FuelSelLast = 1;
}

:fuel_sel_2{
  if (FuelSelLast == 0) {
    keypress(LSHIFT);
    keypress(CTRL);
    keyhit(F1);
    keyrelease(CTRL);
    keyrelease(LSHIFT);
  } else {
    keypress(LSHIFT);
    keypress(CTRL);
    keyhit(F2);
    keyrelease(CTRL);
    keyrelease(LSHIFT);
  }
  FuelSelLast = 2;
}

This works pretty well with a SLOWSCAN row and you will have to turn the
knob fast to get it out of sync with the sim once it is set initially.
Right now I use a combination of pre-game checklist and then mouse
clicks when in game to sync.  Not very satisfactory but if there's no
better ideas on offer I guess we're stuck with just that.

I'm a little concerned that having to go "round the horn" when
implementing click-left-one for knobs like the HSI mode that has only a
go-left-one keystroke ("i") that inputing three I's ina row isn't going
to go fast enough to keep up with you physically turning that know two
spaces left (i.e. send three i's on the first click and then three more
on the second).  Haven't tested that yet.

Using this tactic has the advantage that it uses less EPIC data bits for
a given knob with more than three positions compared to wiring one bit
per throw.

3) Binary coded position wiring using a diode matrix.  Doing this gives
you ability to determine directly the position of the physical switch in
the EPL code without remembering where you were of necessity.  This also
has the advantage of being efficient in using EPIC data bits less
quickly too, again compared to a data bit per throw.  It's much harder
to wire up though since you have to make the diode matrix (likely near
the back of the knob at the panel).  It's well future proofed though
since you can cope with single keystroke per knob, up/down keystrokes or
the hoped for event of discrete key presses per knob position.

For two position toggle switches and pushbuttons, I am thinking of just
a single EPIC databit input.

For three position toggle switches I am thinking of two databits (on, on
and both off -- center -- being the three positions to program for in
EPL).

Between these types of  knobs and switches that takes care of most of
the cockpit.  Just about all that's left are the pots and that whacky
transducer in the TQS.

If you have already planned this stuff out -- how close does this match
your chosen approach -- is there a smarter way to go at this??

> Your input is welcome.

[Mark Doran] Not sure if this is helpful or not -- you know I was look
for input rather than to give it -- but as you can see I'm happy to
pitch in if what raw thinking I've put into this so far is useful :-)

I guess I was hoping there were folks ahead of me on this interesting
road we travel -- perhaps not :-)

Cheers,

Mark.