Pete Dowson

Ahwe come full circle! If you just strip out the relevant parts of your log: 6343 Monitor IPC:0800 (U32) = 0x0 6343 Monitor IPC:07FC (U32) = 0x0 72734 WRITE0 0800, 4 bytes: 01 00 00 00 72750 Monitor IPC:0800 (U32) = 0x1 72859 WRITE0 07FC, 4 bytes: 01 00 00 00 72890 Monitor IPC:07FC (U32) = 0x1 76593 WRITE0 0800, 4 bytes: 00 00 00 00 76703 WRITE0 07FC, 4 bytes: 00 00 00 00 then we see, it is that interlock problem I mentioned right at the beginning. it is NOT that whatever you write is sets it to 1. It is the problem that setting GS requires LOC as well, and the IPC interface is not able to switch both together, as I said. Individually the switching certainly works. It is actually a matter of timing, take a look at this (FSUIPC 3.03 + FS2004): 450765 Monitor IPC:07FC (S32) = 0 450765 Monitor IPC:0800 (S32) = 0 452531 WRITEex 0800, 4 bytes: 01 00 00 00 452531 WRITEex 07FC, 4 bytes: 01 00 00 00 452593 Monitor IPC:07FC (S32) = 1 452593 Monitor IPC:0800 (S32) = 1 454359 WRITEex 0800, 4 bytes: 00 00 00 00 454359 WRITEex 07FC, 4 bytes: 00 00 00 00 454421 Monitor IPC:07FC (S32) = 0 454421 Monitor IPC:0800 (S32) = 0 Here each pair of reads/writes are done together, in one FSUIPC_Process. I think changing them both in one FS frame defeats the interlock well, but otherwise each interlocks the other. It is certainly a matter of timing, not a logic change. If the only way to be sure is to make sure the changes are done together, then I think that will be the only solution. I'll add a note to that effect to the programming guide. All the programs i have here do change them in one FSUIPC_Process call, so they work consistently. Hence the earlier confusion. Otherwise I may need to add some strange logic or memory of previous writes, and I'd rather not really. There might be other effects which I don't foresee. After some other testing, I find that, yes, it it EXACTLY the same in FS2002 with FSUIPC 2.975, setting 800, then 7FC, then clearing 800 and clearing 7FC. If these pairs are done quickly enough, it works, if not it doesn't. It is just the double interlock. The timing is slightly different in FSUIPC 3 compared to FSUIPC 2.9xx. Your program is just coincidentally with timings set to be between one and the other. Make the changes more slowly and it will fail in both, make them faster and it will work in both. My advice therefore is to change them both in the same FSUIPC_Process call. This ensures that they get processed in the same FS frame. I shall add a note to this effect in the SDK. Thanks, Pete

Yes, but I need you to apply to my email address, as mentioned in the Announcements. petedowson@btconnect.com. I have a system established there for doing it, you see. I can't really do it here without making a lot more work for myself. Thanks! Pete

I have no idea, but I cannot help find out if you persist in not cross-checking things, and not even providing log files to show what you mean. All the tests I can do here show it is working the same. There is no change in any of the code in FSUIPC for FS2002 in the areas concerned with A/P in any case, and the conversion to the FS2004 A/P is working fine in all respects according to all my tests, and is confirmed by using FSInterrogate.. I am quite prepared to help, and most certainly to correct anything that is wrong, but if you take this attitude and refuse to go into any more details, or to do any cross checking, I'm sorry, but it just isn't going to get any further, now, is it? What else do you expect? Please be reasonable. Regards, Pete

Has he? I didn't think that was the case. Where has he said this, please? You think I need something extra to do, to while away all these hours I'm twiddling my fingers from boredom? :lol: I wish! Sorry ... Pete

I am sorry, this simply is not true. Please try it using FSInterrogate and prove it to yourself. It is working fine, and has done for a long time. I don't know what you have wrong in your program, but please re-check it more thoroughly. These offsets are written to by programs driving PFC and Aerosoft MCP devices, and probably many others, and they work now in FS2002 and FS2004 just as they have for several years. Please re-check. Do some tests with FSInterrogate. If you think there's some sort of incorrect interlocking going on, then fine, let's investigate. But merely stating that YOUR program gets these results without any substantiation and no cross-checking on your part does not help I'm afraid. If you like, please use the IPC read/write logging facilities in FSUIPC, and show my the part of the log which proves your point, or show me the part of your program and I'll try to see the error in it. Meanwhile I cannot hold up the release of FSUIPC 3.04, which does correct some genuine errors and omissions, any longer. Regards, Pete

Is it Radar Contact you mean? I will assume it is ... Certainly Radar Contact has been accredited, and I know JD has incorporated the access key for FSUIPC 3. Maybe the "latest version" isn't the real latest, which is probably still in Beta. Sorry. You'd need to check in the RC support forum I think Anyway, if that is the case then, at least under FS2002, it won't need FSUIPC 3, your previous one would do. It is FS2004 which is the need for FSUIPC 3. Yes. All FSUIPC compatible programs should work (as far as their FSUIPC interface is concerned) when you have registered. Only accredited ones work if you haven't. The other pages contain the User facilities which is what you are really paying for when you register. You'll see them all then. You get all the User facilities if you register, including the "magic battery" option (as I like to call it! :) ). Regards, Pete

Not exactly FSUIPC's doing. The original FS98 weather interface only supported setting universal or global weather, as did the "Advanced Weather Interface" I provided to take advantage of the weather additions in FS2000. FSUIPC has never been able to directly set specific local weather stations before, even though there were most certainly local weather facilities in both FS2000 and FS2002. All that is added for FS2004 is an interface which allows external programs to set weather at specific weather stations (and read it too). This is in addition to the other two methods, and it is called the "New Weaher Interface" (NWI). (How's that for imaginitive naming? :lol: ) FSUIPC has never provided any smoothing of anything for local weather. That's not changed. FS itself does that. The weather at any point in FS (especially FS2004) is an interpolation of the weather from a number of nearby weather stations -- it is not just one, then the other! Your "abrubt wind changes" will certainly occur if you "go from one station to another" abrubtly, using the Go To Airport menu, for example. But it certainly shouldn't if you fly there, as FS is interpolating the weather all the way along the route. Why not load up FS2004, get it to download the weather for you, and try it? All the NWI provides is the opportunity for external programs to supply the same facilities. Why should Microsoft exclude 3rd party programs from being able to provide the same locally variable weather as they do through their arrangements with Jeppesen? If you don't like the new localised weather capabilities of FS2004, then you don't need to use them. The old methods still work. They are just not as good in my opinion. Let's move forward, not back, eh? Regards, Pete

Menu "PFC", Select the Avionics Buttons page. There you see the list of those buttons on the Avionics stack which can be re-programmed in PFC.DLL. There are 6 situated at the bottom of the stack and 6 in the GPS area. Make sure you have "List all FS ctrls" checked, then use one of the drop downs to find the GPS controls you can assign. When you register your FSUIPC you will be able to do likewise with almost ANY button or knob on the PFC devices. For that you go to FSUIPC's Buttons page. Pete

Hmmm. I don't knowI've never taken any steps specifically. Perhaps it's to do with BIOS settings? I do have one PC which never switches itself off, it only ever goes to a point where Windows says "it is now safe to switch your PC off". Does your rogue PC switch off properly when you tell XP to do so directly, via the Start menu? Because as far as I know it should do exactly the same when WideClient issues the instruction to Windows too. If it doesn't, then possibly there's some driver or other background task not terminating correctly? Pete

On the console? There are no switches or knobs really usable on the Cirrus II for a GPS. Don't you mean the Avionics stack? Anyway, please be a little patient! FS2004 only came out last week. I had it a couple of weeks before that, but even so it's a near miracle that as much works as it does. I have a lot of work to do still just to catch up and complete FS2002 compatibility items. When I've done all that, and hopefully it will be this side of Christmas, I shall start looking at some of the new things in FS2004. Meanwhile, you can of course program all the programmable buttons on the Cirrus and Avionics stack within the PFC options -- if you enble "all FS controls" to be listed you'll see the new GPS controls listed in the drop down (they start "GPS ..."). And of course you can program almost any button switch and knob on the Cirrus and the Avionics Stack through FSUIPC, assuming you have registered it. Again, you'll find all the GPS controls somewhere in the list of assignable FS controls -- look for "GPS ...". No, none at all. You should get excellent calibration for all the default FS2004 aircraft by simply copying over your previous PFC.INI. None of that is changed in the least. It works well here. Possibly some of the aircraft now behave slightly differerntly and you need to get used to them? Regards, Pete

Sorry, now you have me confused. All I will try to do is make it all operate exactly alike both on FS2002 and FS2004. If I don't do this there are lots of applications which will break. If you are saying that it works exactly as it does on FS2002 already, then that is how it should be, isn't it? I've not changed FS2002 behavior in FSUIPC 3. Please clarify. Make a list of all possibilities or state / read /write / result for both FS2002 and FS2004. Please verify all this with FSInterrogate -- I don't want to spend a lot of time on this if it is just a little problem in your program. Note that I don't think FS has a mode for GS without LOC. You han have LOC on its own, LOC + GS or LOC + B/C, but I don't think there's a mode with GS only. Perhaps that is what is confusing the issue? If you set GS or BC then LOC willl have to be 1 too I think. All FSUIPC is doing when you WRITE is send the appropriate controls to FS. When you read you are seeing the indicators as they are. FSUIPC offsets do not operate like memory, that is but an illusion. Okay? Please let me know what you find now, with this understanding ... Pete

Right. I've managed to look at both these things now. On checking back I see that the mapping of offset 132C to the GPS/NAV switch was done just after 3.03 went out. It is fixed here and will be okay in 3.04, due soon. The second question is more difficult. It looks like FS2004 is interlocking the GS and Localiser switches. You seem to be able to set them separately, but they have to be cleared together, which is not so easy through the IPC interface because each of the locations invokes a different action. I'll try to work out a solution to this and incorporate it into version 3.04. Thanks for the feedback! As for the SDKhmm. I'll get to start on it soon I hope. Pete

If you want to use the facilities in FSUIPC, yes. If you only want to access values through the IPC interface, first you must make sure to use the Internal Modules mthod, noty the external method. Then you need an access key for your gauge. If you apply to me on petedowson@btconnect.com I can send you the documentation. Well, a week ago I was saying last weeked, so it would be rash of me to say this next weekend, as too many questions are coming up and I have too much to do. The current SDK is okay for now, if you want details of the New Weather Interface and Registration, write to me at the email address I just gave. There isn't much else extra for FS2004 yet in any case. I'll start looking for more goodies later, when I have a little time. Regards, Pete

Actually, further on this, in FS2004 it looks like Microsoft have added access to most of the GPS values, including for instance: GPS_GROUND_SPEED GPS_GROUND_HEADING GPS_GROUND_TRACK so, it is going to be possible for me to expose these, and other GPS things, in the IPC interface. However, I do not have time to do this yet. I am still catching up with FS2002 compatibility and cannot go searching for new data yet. So, please remind me in about a month, and I'll see what I can do. Okay? Of course, I cannot guarantee that they will always be updated. They may only be operative when one of the FS GPS devices is configured into the current panel. Regards, Pete

Not that I know of. You'd either need to compute it from TAS and ambient wind, or more accurately from the changes in the Latitude/Longitude position. Much as in a real airliner I would think (from the IRS). Regards, Pete

I think the ActiveSky documentation tells you the settings to make, doesn't it? Anyway, I think it best to leave everything to default initially and see how it goes. You can play with things like adding cirrus layers and putting limits on things like clouds and visibility later. See how it works for you as it stands, first. Pete

Oh, I don't doubt that. It will be encrypted too, because I think it has to be according to the licensing deal MS did with Jeppesen. I don't think they want their data used for anything else, that's why. You can switch that off. I don't know, but I think it only actually populates and progresses the nearer METAR stations, but whether it is limited by distance or by array size I don't know. That is where you have to use older (FS2002 and before) methods, using the global weather instead and changing that dynamically yourself. This is why I still included smoothing options for winds, pressure and visibility. Unfortunately the clouds may jump in and out though. I never found out how to get into the morphing part of WEATHER.DLL. Regards, Pete

In FS2002 there was a fixed set of METAR stations, listed in the ICAO lists in the files in the Weather folder. The downloaded file contained an index to the ICAO table. The latter, if you look at the binary file, contains 16 bytes per station, with ICAO, latitude, longitude and elevation for each station (the last three in 32-bit float format). Because stations come and go, I think the FS2004 system is a little more flexible, but it is possibly based on the same system. I think the index file may also sometimes be downloaded -- isn't it amongst the personalised data now, in Application Data or whatever? Sorry, but really haven't had time to investigate it. I only know of a way to inject one station at a time. I suppose you could have a routine which did this in a loop, working from a file, rather than using the IPC interface to pass the data, as it obviously is not suited to such large amounts of data. I'm not sure why this would be any advantage over creating a WX file and loading that with a FLT. What really is the application for this? Why not do as the other weather programs are doing and load stations around the aircraft, at progressively longer distances, till you've populated say 100 miles around, then just update that as you fly? Regards, Pete

I don't think it could "go crazy" within FSUIPC without something being changed. Was there a change from, say 3.00 or 3.01 or 3.02 to 3.03? I'll re-check them again here before I release 3.04, early this week -- look out for the update Monday or Tuesday. Pete

This is while you are on the ground? If so, it is almost undoubtedly because part of the early position is "arming" them for automatic deployment. If you are on the ground and arm them, they go to 100% This is a long-standing problem with FS I think. Try it in the air. It's a slider somewhere in FS assignments for axes. It adjusts the value caled "SCALE" in the CFG file. Pete

Sorry, I cannot make anything out of what you are saying except that you cannot calibrate your spoilers axis. You need to get it working in FS itself first. Don't use FSUIPC except to trim the "ends" -- "reset" the FSUIPC entry, go and set things correctly in FS first. Make sure the sensitivity isn't turned down too much. If you need help you need to be a little more explicit please. Pete

I've found the problem in running Flightdeck Companion. It's only applicable to Windows 2000. It seems there's a bug in one of the Windows routines I use which truncates the names of programs I'm asking about to 15 characters. In FDC's case this stops me recognising the correct name to check the access key against. The bug was evidently fixed in Windows XP and it never found its way into Windows 98. I've worked out a way around it and will incorporate a fix in the next update to FSUIPC, version 3.04, early this week (hopefully Monday, but possibly Tuesday). Regards, Pete

One more thing. You have tried calibrating it in FS2004 without FSUIPC being involved, haven't you? In other words, reset the FSUIPC setting so that it isn't getting involved at all (even temporarily remove FSUIPC.DLL just to be absolutely sure it isn't doing anything), and just using the FS assignment? If it has the full range of flap settings, when calibrated there, then there really IS something going very funny in FSUIPC. Otherwise something else has changed it in FS. Let me know please. Pete

Have you simply tried copying over your previous FSUIPC.INI? There's no change in those facilities in FSUIPC 3. Pete

Hmm. I don't really understand much of that, I assume it is just a general reference. I have forwarded your comment to SimMarket. Please send other complaints or suggestions direct, it would be quicker. Regards, Pete