Forum Navigation
Please or Register to create posts and topics.

Jet45 and FSUIPC Offsets Discussion

(Original thread started on 09-11-09 by Douglas D.)

I have been reading the manual for the new Jet45 software and see that it interfaces using off sets. I need to confess that I have successfully avoided learning anything about off sets while sim building so far. All the interfacing I have done has been either GoFlight or CH or in the case of the Reality XP set up, by assigning a keyboard letter in the con fig file and sending the key stroke from a BU0836 controller via FSUIPC.

 

Can anyone tell me if you can use Leo's BU0836 joystick controller to sent to off sets via WideFS / FSUIPC or do I need anything else. and how do you do this?

 

(Posted by Vince C. on 09-11-09)

Unfortunately it seems that no direct keystrokes mapping has been added in the initial stage to the software nor direct game controller support. This means that you can't act trough a BU0836X or any other generic I/O interface and neither a keyboard, as is. Though I just hope that Jason will add that feature in one of the next updates there are for sure a few solutions.

 

First is buying a dedicated hardware for flightsim that let you play with offsets and FSUIPC, like Opencockpit mastercard+USBcard, or FDS, or others. The second is using a key to mouse scripting software to map keys position on the gauge to mouse clicks. Zero cost, but a bit a dirty solution and that I don't think it will work in any situation. The last (and probably if Jason won't support our requests it will be my choice) is to write a small application based on Simconnect or the FSUIPC's SDK that will catch the output from my own I/O interfacing board (both direct joystick buttons or keystroke mappings) and will convert them to offsets for the SIM. As the BU0836X is seen by Windows as a generic HID compliant device I think that a single piece of software can be written to map mine, your and any other device that can be enumerated by the system.

 

Those considerations are mostly for situations were the LJ45 AAS is networked and not installed on the main FSX PC. In this last case FSUIPC will be able to direct map your joystick inputs to offsets (though with some limitations), so it's easier to bypass the missing features.

 

Though it's a bit a pity that a software built with the final user in mind is lacking this easy to implement feature, the AAS suite looks anyway like a great piece of work and should deserve consideration from all the builders here in the hangar and other aircraft too. It's the natural complement to our projects. And as it's just the initial release we can't but expect more from such a good start.

 

(Posted by Scott Wegner on 09-11-09)

First and foremost, you cannot possibly hope to build a Learjet WITHOUT using offsets. Almost all of the lower panel functions and the FGC functions need to be done via FSUIPC. FSUIPC and its offsets are the holy grail of sim building and one cannot avoid them if you want to build as realistic as possible sim. The offsets are not difficult to learn and any of us would be more than willing to help out those that are new to working with FSUIPC and offsets.

 

Second, unless you have a VERY VERY VERY powerful PC as your FSX/FS9 PC you will most likely run the gauges off networked PCs and it really doesn't make a lot of sense to put your interface cards on the network PCs. That adds a whole different layer of complexity and is not worth one minute of effort as far as I can see. Your interface cards will likely all be on your main PC. In this case, you MUST use FSUIPC offsets. This is the same with PM, Sim-Avionics, Flight Deck Software and any other good sim building software designed for making home simulators. The Jet45 software was built with offsets in mind per our requests to make it easier to interface. Not harder. In this case I have to disagree with Vince.

 

As for the BU0836 cards and others....they will work fine. They are seen as a joystick with lots of buttons. You simply go into FSUIPC and assign a joystick button to an offset. Easy and clean as that. I have the BU0836X card and have begun testing some of the functionality so I will report back soon. I have also used Hagstrom and Open Cockpits.

 

In short, the software is designed to work with these and no other programs need to be written or anything else. The only case where you would have a problem is trying to put you interface cards on the networked PCs rather than the main PC in which case you just opened a can of worms for nothing.

 

Sorry to be long winded but wanted to make sure everyone understands how this stuff works and why it works the way it does (just like all of the other industry leading packages).

 

(Posted by Vince C. on 09-11-09)

There a billion situations where there's the need to put the logic on an extra PC and not the FSX one. That is why all the major brands of sim I/O cards have modules to make their cards running in network, else it wouldn't have been any need to even program them.

 

It's true that suites like PM or Sim-Avionics only have offsets to drive the gauges part but this doesn't mean that they are good because miss the poor and simple keystrokes. I guess that it was a major commercial choice to tell people: "Hey this is for PRO! and you pay for that..." Leaving to the user more choices to interface can't be bad at all. I didn't mean keystrokes INSTEAD of offsets or mouse clicks but have all of them working and leave to the user the choice should be the way. This would give much much more freedom to the customer to interface it the way he likes without being limited by the software itself.

 

(Posted by Eric Tomlin on 09-11-09)

Hi guys, thanks for the dialogue, that's a good start to discussing the software and its capabilities. Scott, thank you for catching this one! I agree whole heatedly with everything you said and I'm sure Jason appreciates the effort expended to correct a lot of misunderstandings.

 

Vince, you are right in that it would be *nice* to have the option to use keyboard strokes, but again that is a very archaic way of doing it IMHO. At one time there were keyboard presses assigned to some functions but I think they were eventually removed for various reasons. Jason would have to elaborate here.

 

In the end, Douglas you should jump feet first into using offsets. As Scott said, it's very easy to use them once you learn how to use the software your interface hardware uses. Typically it shouldn't take more than a few times assigning an offset to a piece of hardware to understand how to make it work. Nearly everything, if not everything, in Jason's software uses the FSUIPC 'bit' option and is super simple to assign.

 

(Posted by Jason Hite on 09-11-09)

Vince, I have struggled with the keyboard option ever since development began. I have been looking at the option for keyboard encoders and have seriously considered creating an application whereby the user can use the BU0836 card to interface the software. I much prefer this method over "bloating" the software with keyboard logic. It is true however that it is very simple to capture keystrokes in the software (I already do this for a few functions) the difficulty I had was how does the user configure this and does it complicate the use of the software? My answer to this was simple, yes it does add a layer of complexity and adds risk of the user being able to do something that the software won't agree with.

 

The nice thing about using the offsets is that you can have nearly identical installations of the software on multiple computers. The only real difference is one line in the .ini files. Keyboard logic would require that each installation has specific keystrokes on whatever PC it was installed on. Several others may also be using software on the client machines that interfaces with the keyboard so now you have to be concerned with which window is active so you don't send unintended keystrokes to another application.

 

With this in mind, I plan to pursue an interface driver for the BU0836 board and possibly others such as the PoKeys55T so that users don't feel like they need to be a pro or use an expensive interface option.

 

(Posted by Vince C. on 09-11-09)

Thanks Jason for the plain answer. A simple software that actually sends the right offsets to FSUIPC when getting input from a card. External software is just okay and I think that it's even better, because it can be installed on any PC, even one that doesn't have L45 AAS neither FSX on it.

 

Example: You want to use a card that has far more inputs that the ones needed by L45 AAS and you want to use it to drive other widgets too, but don't want to overload the PCs with avionics and visuals installed on them. PoKeys55T for example if using matrix feature it has, can support up to 96 keys + 5 axis (not bad for a card big as a matches box), so It's nice to use the extra free slots (L45 AAS should use approximately 93 with EFIS and XFR) for other applications.

 

(Posted by Douglas D. on 09-12-09)

Thank you for your detailed replies. I seem to have started a bit of a debate here. I agree that it is time that I learned how offsets work. I have to admit that I have spent so much time building the CNC and learning to make panels that I haven't spent much time with the sim on, so I haven't look to close at the other parts of FSUIPC. I remembered a post over at MC `offset for dummies HERE  As soon as I can get the software running I will give it a go.

 

(Posted by Vince C. on 09-12-09)

Douglas, the debate was about if the Jet45 AAS suite should have used keystrokes instead of offset, but this is only because it's a standalone suite and makes all the work for the user. No matter that to make the cockpit lit and act in the real way you'll need to learn about offsets and you'll have to choose at least one of the available interfacing platforms (Opencockpits, FSbus, InterfaceIT etc..) that will allow you to use script programming trough offsets.

 

It's not that hard though and watching buttons light and toggles act the way you want will reward you for the short time needed to learn how things work.

 

(Posted by Douglas D. on 09-14-09)

Okay, I have had a go at setting this up with no success, so rather than spend all night on it I will ask for some help:

Douglas3

 

I am still trying to work out how to set up buttons to work with off sets. I have pressed the momentary button which is connected to my Leo Bodnar card. FSUIPC has detected this a Joy3 button 0. I have entered the off set in the box for EFIS 1 in jet45

 

I want to toggle the Ih/pa switch which is bit 0. Can anyone tell me what I enter in the parameter box? and confirm what should be in the control sent when button pushed box?

 

(Posted by Jason Hite on 09-14-09)

I recommend using FSInterrogate to see if your button is truly toggling the bit or not. See the FSI2 Manual in the FSUIPC SDK. This is a VERY useful program for "seeing" what your hardware is actually doing in FSUIPC. It can be run on the server, or a client with WideFS running. Based on the picture you attached, everything looks okay.

 

I also wanted to make sure that you are not attempting to toggle the In/hPa display on the FS panel. This offset will only toggle the display on the Jet45 PFD.

 

SOLVED:

I did some testing tonight and I have the solution. If you want to hook up hardware for the EFIS, you cannot have the EFIS running. Setup FSUIPC Buttons + Switches with "offset Byte Togglebits" and bit 0 should actually be "x01" in the Parameter field. The EFIS software writes to the 73FE offsets, and it controls what is in that offset and it cannot be overridden by hardware.

 

So in summary:

1. Don't have the Jet45 EFIS running.

2. Use Offset Byte Togglebits

3. Bit 0 in Jet45 offsets is "x01" in FSUIPC Buttons+Switches settings.

 

(Posted by Douglas D. on 09-14-09)

I have had success with this but for some reason not exactly as above.

 

1. Yes turn off the EFIS mini panel.

2. Offset Byte Togglebits would not work, but Offset Word Togglebits did work.

3. x01 did not work, but `Parameter x0001` did work.

 

I have also got the ARC/ROSE button to work using this and parameter x0006 and the FMS/NAV mode to toggle with x0008.

 

I am not sure this is how it is supposed to work or if using 'Offset Word Togglebits' will cause any other problems but the key thing here for me is that you can use these interfaces with the software. Please chip in if you can explain what the Parameter numbers for 0 to 7 are.

 

(Posted by Mark L. on 09-15-09)

I'm new at with IOCards and SIOC stuff and I think I have this right as using IOConsole, I can see everything toggling correctly. I did see the previous posts and I unloaded AAS EFIS, but I still don't see the switch changing positions in the cockpit on the dash or any indication anywhere that the Bearing 1 mode has changed. Not familiar with 'togglebits', but changebit is what I used and seems to work sort of. The code below is what I have (only listed the one) for example. Any ideas as to what I'm missing? (Inputs 19-22 configured for this rotary switch and coded accordingly)

 

Var 3000, name EFIS1, Link FSUIPC_INOUT, Offset $73FE, Length 1 // Offset EFIS 1

Var 3001, name EFIS2, Link FSUIPC_INOUT, Offset $73FF, Length 1 // Offset EFIS 2

Var 3010, name EFIS1_B1FMS_SW, Link IOCARD_SW, Input 19 Type I // FMS Bearing 1

{&EFIS1 = CHANGEBIT 5 ,&EFIS1_B1FMS_SW}

 

I should clarify that other switches and LED's I have are working thus ruling out whether I have the core of it configured correctly or not.

 

(Posted by Jason Hite on 09-16-09)

Mark, sorry about the delay in getting back to you on this. You should only see changes on the PFD on the side of that EFIS. For instance, changing the bearing selector on the Captain side EFIS should change the pointer source on the Captain side PFD, and expect the opposite for the Co-Pilot side. Once again, the only offset for the EFIS that you should see on the FS panel is for FMS/Nav mode. The other EFIS offsets are only for the Jet45 PFD displays. Here are how the parameters map from FSUIPC Button + Switch to the Jet45 offsets:

 

FSUIPC Parameter Jet45 Offset Bit

x01 Bit 0

x02 Bit 1

x03 Bit 2

x04 Bit 3

x05 Bit 4

x06 Bit 5

x07 Bit 6

x08 Bit 7

 

You should be able to use the Byte type in FSUIPC Buttons + Switches. A BYTE is 8 bits, hence x00. Each digit represents 4 bits so x00 is 8 bits. A WORD on the other hand is 16 bits or x0000 (4x4, 4 digits with 4 bits each). The offsets are broken up into BYTES so you may end up with problems when you use the WORD type.

 

Looking at your screen shot that you posted I notice the following things:

1. On the first line setting 73FE to 0x0100 does nothing because 73FE bits are only in the lower two digits. This is why you must use the BYTE type instead of WORD.

2. For 73FE you have set to 0xA0 which means you have bits 5 and 7 of the Jet45 offsets set, that means you are commanding bearing 1 to display both FMS AND NAV at the same time. Of course this is not possible.

3. For 73FF, you are toggling on and off the first bit (bit 0 in the Jet45 offset). This is simply saying that you don't want bearing 1 pointer to show. Hope that helps some, if not let us know.

 

(Posted by Eric Tomlin on 09-17-09)

Mark, also see pages 9-2 and 9-3 in the User Guide. This explains that depending on what EFIS mode you are in (NAV or FMS) determines then what you will see when you move the bearing selector to the different bearing modes. For example, You are flying in FMS mode and have NAV hold selected on the FGC. The aircraft is flying along the route and you want to monitor a VOR station. You can tune NAV2 to freq. 123.45 and on bearing pointer 2, you will see your bearing 2 indicator pointing to that VOR if in range. However, even if you have an ILS or other Vor tuned to NAV1, you wont see it on bearing 1 IF you are in FMS mode, because FMS mode via the EFIS forces your bearing 1 to display a magenta pointer to the next waypoint in your flightplan. If you are 'on route' then naturally the FMS bearing pointer will point straight up toward the next waypoint.

 

If you just took off from the runway and you have to make a left turn to join your loaded flight plan, then you are likely in NAV EFIS mode and have the ILS showing in the event of having to return to the field. Once you are up in the air and turn toward the first waypoint you can switch from NAV to FMS mode via the EFIS controller and then select FMS on the bearing 1. If you then selected NAV mode on the EFIS, your bearing 1 will either go blank (if you are out of range of the VOR or if one is not tuned at all) or will then point to the station tuned. If taking off, you likely have the ILS for that runway tuned and are in NAV EFIS mode with NAV selected on the bearing selectors too.

 

One more thing too that is very important regarding offsets and the EFIS component is that you CANNOT run the JET45 EFIS.exe AND have your hardware interfaced/using the EFIS offset at the same time. The EFIS.exe is simply there for the users who have no hardware to handle EFIS functions and need something to click on. EFIS functions are still available even without the EFIS.exe running, but it's just a visual component and will cause offset issues if it's running while you are using hardware to control EFIS functions.

 

(Posted by Mark L. on 09-17-09)

Well I'm familiar with bits and bytes, I'm not familiar with the FS-Interrogate and picking up SIOC pretty well. Jason, I'm not trying to connect and use this via the FSUIPC control panel. So the parameters don't mean much to me.

 

Per the documentation, the EFIS offsets are at 73FE and 73FF with a length of 1.  This should mean 1 byte or 8 bits each.  Bits are usually displayed / read / set, numbered what ever you want to call it,right to left.

 

Bit position 7 6 5 4 3 2 1 0

Value 128 64 32 16 8 4 2 0

logic state 1 1 1 1 1 1 1 1

 

So I would expect to see/set For FMS Mode, Bearing 1- FMS.

Bits 3 and 5 so: 0 0 1 0 1 0 0 0 or 48 hex or 40 decimal for FMS Mode, Bearing 1 - NAV

Bits 7 and 3 1 0 0 0 1 0 0 0 or 88 hex or 136 decimal

Setting of other bits for the other items would obviously change the hex and decimal values.

 

Using SIOC programming to change these via the inputs card, I link a variable to the declared offset address which allows me to read/write to this area. Next, I can 'toggle' bits of this 1 byte by using the CHANGEBIT command by specifying the bit position, hence CHANGEBIT 7, &EFIS1 This toggles the state of that bit from 1 to 0 or 0 to 1.

 

Not sure what was going on before, but I have verified that I can see the same values whether set by the EFIS app or by my switch.

 

What's bugging me now using just the AAS EFIS, I cannot get anything to change. The Rose To Arc mode, or displaying the Bearing 2 pointer. So I think I need to get this part figured out first. In FS, if I make changes, say Bearing2 is Nav, it displays the pointer, but I don't get the same results with the EFIS Controls / PFD.

 

I'd like the Jet45 AAS version to show me its working correctly now first. I might not have something set right yet. I noticed I can't tune the radios either from the graphical i/f knob. It kind of stutters and flutters and I might make it move a digit or 2, so there's a couple of things going on that have to be addressed.

 

(Posted by Jason Hite on 09-17-09)

Mark, I found an issue in the software whereby you have to have a frequency tuned for the bearing pointers to show up. I'm not sure if this is how the real avionics behave or not but please have a valid frequency tuned when you get around trying it again. I will be sure to update this in the next release coming very soon. I just tested this with my OpenCockpits hardware and it is working.

 

There is a value in the RMU .ini file that will help you tune frequencies better. There is a parameter called

 

[COM_WRITE_TO_SIM]

 

Setting this to a 1 tells the RMU not to read the COM/NAV/ADF/ATC frequencies from FS. Instead it expects that all radio tuning will be done through either the graphical interface of the Jet45 RMU or hardware talking with the RMU bits.

 

If you set this to 0, then the RMU will act merely as a display of the above radio frequencies and tuning is expected to be done through the standard FSUIPC radio offsets or through the graphic panel in FS.

 

(Posted by Eric Tomlin on 09-17-09)

Jason, the bearing POINTER wont show up unless there is an active frequency tuned. If it did, it'd be pointing 'somewhere' which would be a wrong direction since it wasn't active, so you have it programmed correctly as far as I can see. The same for the source identifier section to the left of the HSI; it's blank if there's no active info being received. Back in the day when the bearing pointers were mechanical, they would simply point to the 9 o'clock position when 'dead'.

 

(Posted by Mark L. on 09-17-09)

I got the panels to display using the AAS EFIS panels! Now I can go back to the OpenCockpits IOcards and get that running I hope. Oh, The RMU tuners are working just fine now, thanks Jason!

 

Okay, now I think I have it working via my OC boards/SIOC. I only have 1 rotary switch currently, so I hard coded some values for EFIS2 and things seem to be working. I'll do some more testing to confirm I have it 100%, but it looks good.

 

(Posted by Eric Tomlin on 09-17-09)

Yes, I just confirmed the issue of not having the EFIS component executed if you want to use hardware vs. mouse clicking. I love it when hardware works perfect! That's why I like my FDS SYS3 card- very simple to figure out. I'm sure SIOC is awesome, but it looks very daunting.

 

(Posted by Jason Hite on 09-17-09)

Good stuff, I love it when a plan comes together. Thanks Mark for sticking it out, what dedication!