F1 AOPA Cardinal-COM/NAV2 freq swap problem w/FSUIPC v4.1.5.

[BC]

Pete,

Strange snag. I have downloaded and installed the AOPA Cardinal for FSX and the bottom line is that NAV2 does not work with FSUIPC installed.

I can change the *frequency* in the standby window, but when I hit the button to toggle the frequency to active, it toggles NAV1 instead.

I'm using FSX SP1 with FSUIPC v4.1.5.6 and PFC 4.3.0.0

FYI, I am using the Cirrus II console without the avionics.

I have confirmed FSUIPC's involvement by removing the .dll and it's .ini file and running FSX, where the COM/NAV2 radios swap as advertised. Putting FSUIPC back in the modules folder and COM/NAV2 swaps COM/NAV1 when toggled.

Every other airplane I have (stock and a few add-ons) work swell. It's only the Flight 1 stuff. I have posted on their site but have not received a response yet (it's been about a week).

Any ideas?

BC

[Pete Dowson]

I can change the *frequency* in the standby window, but when I hit the button to toggle the frequency to active, it toggles NAV1 instead.

I have confirmed FSUIPC's involvement by removing the .dll and it's .ini file and running FSX, where the COM/NAV2 radios swap as advertised. Putting FSUIPC back in the modules folder and COM/NAV2 swaps COM/NAV1 when toggled.

Every other airplane I have (stock and a few add-ons) work swell. It's only the Flight 1 stuff. I have posted on their site but have not received a response yet (it's been about a week).

Any ideas?

None at all. FSUIPC doesn't have anything to do with these values, and the "swap" action is normally all accomplished by FS itself, other programs don't come into it. So it sounds as if the Flight1 aircraft are using FSUIPC for something and have some errors in the offsets they are using. Are these aircraft transposed for FSX or newly written specifically for FSX? If the latter it surprises me that they are using FSUIPC at all.

Can you do some logging for me so I can see what is going on? For now please remove the PFCFSX.DLL from the Modules folder (else the logging from its actions will swamp the rest). Also, please disable or temproarily remove any other add-ons which may be using FSUIPC, for the same reason.

Then go into FSUIPC's Logging tab, enable logging for these options:

IPC Write

Button and key operations

Events (non-axis)

and also, on the Right-Hand side of the Logging tab, set these 4 locations for monitoring:

0350 as type U32, in hex

311E as type U32, in hex

034E as type U16, in hex

311A as type U32, in hex

and check the "Normal Log" option below.

Reproduce the problem (do an obvious Frequency change, different frequencies each time, for COM1, COM2, NAV1, NAV2), then close FSX, ZIP up the FSUIPC4 Log and INI file, and send to petedowson@btconnect.com.

I am going on holiday next Thursday and plan to make one more FSUIPC release (4.16) before than, so if you could be quick about this, if there is anything I can do I will do it beforehand.

Regards

Pete

[Pete Dowson]

I have downloaded and installed the AOPA Cardinal for FSX

You mentioned this is a Flight1 aircraft? I can't find it anywhere on their website -- I wanted to check whether it was indeed an FSUIPC user etc. The only Cardinal they have is the Dreamfleet one, which I think is an FS2002 aircraft updated for FS2004, not a specific FSX one by any means. Is that it? Where does AOPA come in -- I can't find any mentioning AOPA.

I've searched several other websites and can't find any other Cardinal for sale. Is this the actual name it is listed under? I did find a freeware Cardinal on FlightSim.com, here:

Name: c177rgbh.zip Size: 4,821,487 Date: 07-21-2007 Downloads: 1861

FSX Cessna 177RG Cardinal. A Gmax FSX/SDK retractable landing gear version of Cessna's 177 Cardinal proposed replacement for the 172. At 200 hp and considerably more aerodynamic than the 172, it was truly a standout airplane in its own right. This model is based on the real C177RG in which the author received his complex endorsement. Includes full function VC with accurately modified gauges. Model, textures and flight dynamics by Brett Henderson.

I'm downloading it now to check its radio stack.

[LATER]

No, that one is okay -- and it doesn't use FSUIPC in any case.

Regards

Pete

[BC]

Howdy Pete,

Some background I should have included last night. Sorry for the omission.

The AOPA Cardinal is a special deal that Flight 1 does every year for AOPA members. AOPA (The Aircraft Owners and Pilots Association) restores/rebuilds an aircraft every year and gives it away to one of the members in a sweepstakes. See: http://www.aopa.org/sweeps/ for details. For information about the F1 Cardinal, see: http://www.aopa.org/sweeps/fly/. You have to be a member to download it.

Anyhow, Flight1 did a Commander and a Cherokee 6 for FS2004 and have now done the Cardinal for FSX.

The Cardinal is supposed to be a brand new model, fully FSX compliant and as far as I know, they do not make use of FSUIPC. That would be evident to me as there are no problems with the airplane when FSUIPC is not involved. The airplane is not supposed to be a rebuild of the DF Cardinal.

A gazillion years ago, I did some gauge design for the sim just for fun and for the life of me, I don't know how someone could mess up the frequency swap. I mean, it's a pretty basic function, right? What code could someone insert into the programming that would cause it do work normally without FSUIPC in this instance, but react completely different when FSUIPC is present?

I know that you are extremely busy Pete, so don't go nutz over this. I was sort of hoping that there was a simple snip that I could place in the FSUIPC.INI file to sort this out. Evidently, it gets a little more complicated.

I'll get the info you need into a log file and paste it here if it's small enough.

Thanks and Regards,

Bill (BC)

[BC]

Pete,

As you already knew, the log file is too big for here. I've zipped up both the log and ini files (as instructed) and they should be whizzing through cyberspace to you right now.

BC

[BC]

Pete,

Looking through the log file I sent to you, there is a recurring theme:

(0x00000000) COM_RADIO

481106 *** EVENT: Cntrl= 66514 (0x000103d2), Param= 0 (0x00000000) ATC_MENU_CLOSE

481107 *** EVENT: Cntrl= 65581 (0x0001002d), Param= 0 (0x00000000) FREQUENCY_SWAP

481107 *** EVENT: Cntrl= 66372 (0x00010344), Param= 0 (0x00000000) COM_STBY_RADIO_SWAP

481166 SimRead: 034E="COM ACTIVE FREQUENCY:1"

INT32: 8592 (0x00002190)

481166 SimRead: 311A="COM STANDBY FREQUENCY:1"

INT32: 10293 (0x00002835)

481166 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0

I am not doing ANYTHING with ATC here, so where is that "ATC_MENU_CLOSE" coming from? All I did was change the frequencies and toggle the swap button.

BC

[Pete Dowson]

The Cardinal is supposed to be a brand new model, fully FSX compliant and as far as I know

From the logs you sent me it looks very much like it is actually an FS2002 model. They may have updated the graphics and animations for FSX, but it seems all the gauges are very old indeed -- at least the radio ones.

I'll get the info you need into a log file and paste it here if it's small enough.

Received the Logs by email. Thanks. These controls:

452688 *** EVENT: Cntrl= 65585 (0x00010031), Param= 0 (0x00000000) NAV_RADIO

481106 *** EVENT: Cntrl= 65582 (0x0001002e), Param= 0 (0x00000000) COM_RADIO

481107 *** EVENT: Cntrl= 65581 (0x0001002d), Param= 0 (0x00000000) FREQUENCY_SWAP

are all non-specific -- they work on the last radio selected, 1 or 2. these controls:

452751 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2

and

357234 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_1

are supposed to select the appropriate radio first.

The sorts of things this cockpit is doing here are rather archaic -- there have been proper NAV1/NAV2 and COM1/COM2 controls around since FS2004 was released and there were better ways of doing this even in FS2002. I'm now pretty certain this aircraft's radio stack is a very old design.

The "SELECT_n" controls are processed by FSUIPC because these are the 1, 2, 3, 4 keys used for things like selecting engines, and Pushback direction, and FSUIPC tries to ensure they are associated with the last relevant control -- it allows, for instance, a view left or right whilst pushing back, before pressing the 1 or 2 for direction.

FSUIPC certainly doesn't stop the SELECT_2 actions going through, but it is likely that, because I am intercepting them, the order of controls being sent by your panel is getting changed. Here's an example:

379478 *** EVENT: Cntrl= 65582 (0x0001002e), Param= 0 (0x00000000) COM_RADIO

379478 *** EVENT: Cntrl= 66514 (0x000103d2), Param= 0 (0x00000000) ATC_MENU_CLOSE

379478 *** EVENT: Cntrl= 65581 (0x0001002d), Param= 0 (0x00000000) FREQUENCY_SWAP

379478 *** EVENT: Cntrl= 66372 (0x00010344), Param= 0 (0x00000000) COM_STBY_RADIO_SWAP

379569 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2

That last SELECT_2 was probably issued just after COM_RADIO. I don't understand why it is issuing both a FREQUENCY_SWAP and a COM_STBY_RADIO_SWAP -- probably only one of them actually works.

I cannot do the same as I do for Engine, Exit and Pushback -- i.e. keep back the first command for a short time, waiting for the SELECT, as this would then occur AFTER the "SWAP" control, but I will experiment with either allowing the SELECT to go through even though I am saving a copy for later too (I am a bit worried about such double actions), or, more likely probably, intercepting and forwarding the SWAP controls as well. If it is only the SWAP control which is being affected here that should be okay.

It is interesting that this hasn't come up before. It would happen on FSUIPC3 too, except that on that ALL controls are intercepted and processed, so the order isn't being changed.

Regards

Pete

[BC]

Howdy Pete!

I've posted an update to the F1 forum regarding the conflicting commands. It should be noted that if the ATC window is actually open, clicking the COM/NAV2 swap does in fact close the ATC window.

I see what you mean about the archaic coding. You are right, the non-specific stuff went out with the DODO.

I wonder how the F1 guys will respond. Seems a lot easier if they just update their code. I have a feeling that won't happen, but we can hope, right?

Thanks again Pete, I'll buy you a fine pint at the next Squadron party!

BC

[Pete Dowson]

I've posted an update to the F1 forum regarding the conflicting commands. It should be noted that if the ATC window is actually open, clicking the COM/NAV2 swap does in fact close the ATC window.

Yes, the control is in the same sequence. I expect that is because, otherwise, the SELECT_ controls will actually seelct an ATC option from that window.

I wonder how the F1 guys will respond. Seems a lot easier if they just update their code. I have a feeling that won't happen, but we can hope, right?

Rightbut on the other hand I do try to maintain compatibility with FSUIPC. That's been part of its main purpose, after all.

I've made one of the changes I suggested -- adding the radio select and swap controls to the list of those I intercept, so that at least they should be kept together. The ATC close thing will occur first then, in fact. I'll post it to you by email (after I've checked that I've not broken anything else) for you to test. Even if it works, I'd like to see the same logs please.

Regards

Pete

[BC]

Pete,

Got the update and it works swell!

Perfect!

I've forwarded the latest log and ini file for your perusal.

Thanks again,

BC

[Pete Dowson]

I've forwarded the latest log and ini file for your perusal.

Yep, that looks perfect. Thanks!

This version, or one very like it, will be released as a new User version in the coming week, probably Monday/Tues. It will be 4.16. Please update to that when it's posted.

Regards

Pete