Pete Dowson

Hmm, so they are still maintaining it but not selling it? That's weird. And, as you imply, referring you to an internet flight planner for moving map purposes is a bit dense. Pete

Yes, I think so. I think your unit, like all three of my Garmins (Etrex Vista, GPSMap 60CXi and iQue 3600), has no facility to run with an external GPS supplying the positional data. The NMEA type inputs will be for other things, not positional. Your GPS likes to act as a GPS, not as a Moving Map. Regards, Pete

Well, unless it was due to something you changed in FS or FSUIPC, I can't see how it could be anything else but a hardware problem. Maybe something's gone awry in the pedals themselves, or the connection via USB? Software doesn't normally suddenly change of its own volition. If it worked yesterday and isn't changed it should work today. Regards, Pete

You should need to "try" to "find" anything! Doesn't the motion driver you have got come with any instructions at all? Surely you need to know how to connect your platform to the PC and set it up with the driver? It seems that if you don't understand it you should ask the supplier. I'm afraid I simply cannot support other folk's programs, most especially ones I have never heard of. All you need to know about FSUIPC is that you put it into the Modules folder in your FS installation. that's it. The rest is up to whatever program you are trying to use. If it is a program with no access license for FSUIPC you may need to purchase an FSUIPC user registration. Regards Pete

None of the settings in the user facilities of FSUIPC will affect such a connection. It should all be handled by your driver, the program which interfaces to FSUIPC. In other words, there are no user-serviceable parts! Pete

Hmmm. That's not a very encouraging start, now, is it? I'm Pete, okay? Seems everyone with CH pedals has problems with them. Sorry, I have read your message in details and I have absolutely no idea what is going on. You need to get them working in FS first, which plainly they are not. I really think you need to talk to CH or someone who understands their pedals -- try Bob "Sticky" Church at http://www.ch-hangar.com Regards Pete

Offset 3850 is in Degrees Rankine. Your dial is in degrees Fahrenheit / 100. Your reading of 15.8 is 1580F. 2007R = (2007-459)F = 1548F Looking at the dial I'm surprised you can read as accurate as 15.8 and, that, plus the time delay between it changing and FSInterrogate displaying it, I would say 3058 was spot on. It will be the same value that the gauge is using -- it is just converting it to Fahrenheit. Rankine is the same as Fahrenheit except measured from absolute zero as 0 R instead of from 32 F as freezing point of water at standard pressure. Pete

Sorry, I don't know anything about any motion platforms, nor Classic Flight. I don't understand what you are asking nor why you are asking me. I have no connection with either of these things. Pete

Did you take into account that the units are different? I think the above are in degrees Rankine and Centrigrade, respectively, not Fahrenheit. Era barber pole is a limit. You won't be able to move one of those, it'll be pre-calculated. And I don't know any mechanical type of ASI which shows TAS. What you're moving is probably just a bug, a reminder. It's to save sticking little bits of paper on the dial. Pete

Ah .. with pmSystems you have to have everything else right too. Evidently you haven't. Do you have the handbook for the aircraft? That's what I use. Please post questions about pmsystems to the PM webgroup site. There are folks there who will help. it sounds like you need to learn more about the overhead. ;-) Regards, Pete

Sounds like you have something else also assigned to the mixture levers. Check the assignments in FS. Pete

No idea. Sorry, but you really do have to actually both develop AND debug your own programs. I can't do that for you too. There are enough tools around to help -- FSInterrogate to compare values with, and the full logging features in FSUIPC. Have you tried using any of those? Also, I would really have thought that Delphi came with a debugger. Doesn't it? Regards, Pete

FSUIPC doesn't have its own list (except for the special additions and the PM stuff). The main list of FS controls is grabbed directly from FS's "CONTROLS.DLL" for the drop-down. I've just checked, and there's "Trim Down" and "Trim Up" listed in the drop down -- i.e. without the "Elev" in front. Strange, I thought. So I dug into the codeand I found that the actual internal names in FS for these used to be "Numpad 7" and "Numpad 1" -- i.e. they were named after the default keys which you used for them. This must have been back in FS98 and FS2000 days. Looks like I deliberately check for the two control numbers and replace these rather inappropriate names by "Trim down" and "Trim Up". Odd no one has mentioned this before in all these years! Anyway, in the very next version of FSUIPC I will re-name them "Elev Trim Dn" and "Elev Trim Up". Okay? ;-) Thanks, Pete

Oh, right -- so it isn't that you've been USING it and had problems, you thought you were taking precautions because of some out of date information? Sorry to have misunderstood then. Good flying! Pete

The only reason that could be is that their users (including you?) are using pirated keys. The only change after 3.40 was better checks against fraudulent keys. If you have registered FSUIPC and you think you paid for it and have a genuine key, AND you are not using a version of FSUIPC older than 3.53, let me know and we'll sort it out. Otherwise, just delete your FSUIPC.KEY file and try again with version 3.70. If the authors of FSHotSFX think there is a problem after 3.40, why is it they've never ever written to me to sort it out? 3.40 was replaced 21 months ago! I'm sure that if they'd had problems for the last 21 months someone would have contacted me. :x In fact, I know for sure that it works properly with later releases, because when I changed the classification of landing AI traffic in 3.45 it affected the reverse sounds that program produced, and I changed it again for the program immediately after (by 3.47 for sure), and it worked fine again. Pete

That's because the read and write calls merely add the request to a queue in your memory. They never leave your program. Only the Process call does anything -- that takes a while because it has to get windows to switch to the FS process, pass the data built up to FSUIPC, wait for the reply, then switch back. NEVER do a Process after each read. The whole point of splitting the specification of what you want to read and write from the actual doing of it was for efficiency. You'll not only slow your program down, but you'll slow FS as well. Ideally ALL of the things you want to read and write in each cycle of your program should be built up and sent in one Process call. The cycle is best if it is timed to be either the same as one FS frame, or a multiple of it (if you don't need things so urgently). If you get, say, 20 fps consistently from FS (set the limiter to something suitable) then sending a Process every 50 mSecs (or every 100, 150 etc) is best. The only exception to saving everything up for one Process is for those cases where what you write needs to be decided upon from what you read. Then you may need to read something, do some calcs, and write something. Even then it would be more efficient to spread that over two of the above cycles, so "Read --- Write & Read --- Write & Read --- etc. Oh, there is one other exception but it isn't likely to arise. That's when the total data size adds to more than the max size for one Process call -- around 30000 bytes. Don't get anywhere near that. Pete

Yes. I have a heavy investment in PFC hardware -- I'm not about to chuck it all away, am I? ;-) Pete

Hmmm. I always thought they did nothing at all. Maybe I never tried them in FS2004. Thanks for the feedback! Pete

Unfortunately it is impossible from what you supply to actually extract what your problem really is. You don't say. The only two clues are these: and Now the latter is completely nothing to do with me. If someone else's program crashes, then it must be sorted out by the author or publisher. Nothing in any of my programs can force another to crash -- that is all within that program's control. It is an error. The former case, duplicate copies of FSUIPC running, can occur in several ways: 1. Having more than one copy of FSUIPC.DLL in the modules folder. For this to occur one of them must have been renamed. NEVER rename any of the DLLs and leave them in the Modules folder. The FSUIPC files which are found in the Modules folder should be: FSUIPC.DLL, FSUIPC.KEY, FSUIPC.INI, FSUIPC.LOG. 2. Some folks have reported that modules placed in the main FS folder also get loaded, so check there too. Personally I've never been able to verify this. 3. Some add-ons cause FS to stay running in the background even after you close it down and it looks as if it has gone completely. When this happens, and you load FS again, FSUIPC detects the other version still running and you again get the 'duplicate' error. It is impossible for FSUIPC to run twice on the same PC, because of the interface for applications. Hence the report. To check for this error, next time you get "duplicate" use the Windows task manager (Ctrl-Alt-Del) to look at the Process list (not the Applications). If there is one (or more) copies of the FS EXE (FS9.EXE for FS2004) listed, that's your problem. forcibly close it from the Task Manager and try again. In future please tell me the VERSION of FSUIPC you are using, and maybe even show me the text in the FSUIPC.LOG file. Regards, Pete

Good to hear. Thank you. Seems like Joaquim , the thread originator, must have been supplied with FliteStar 9.16 instead. Maybe a mixup at the Jeppesen end. They've got my update orders wrong on occasion. Regards, Pete

I don't know those. Are they owned by Project Magenta, pmSystems perhaps? Sorry, I don't know the term 'knitter'. Is that some sort of rotary switch? Sorry, no. Having 1 for decreasing and 2 for increasing seems very odd. If this is programmed in pmSystems, then why not re-program it to accept the values you want? Anyway, I think, if you are talking about pmSystems, you'd be better off posting your query to the PM webgroup for support. There are quite a few pmSystems experts there. Regards Pete

Hmmm. You really ought to try search on relevant keywords in the Programmer's Guide. All of the Autopilot values are together in the 07BC to 0810 area. the altitude value is called, possibly obscurely ;-) "Autopilot altitude value". A search on 'autopilot' or 'altitude' would have found it pretty quickly, but looking for any of the autopilot values would have certainly helped, them being altogether like that! :-( Pete

Does the value you write to the offset read back the same as you wrote (e.g. looking at it in FSInterrogate, or in FSUIPC's monitor)? Pete

Hmmm. That is strange. Does the change you make read back? Pete

According to my records, ActiveSky wxRE ("wxRE.exe") by HiFi Simulation Software was provided with an application Access Key for FSUIPC 3 back in June 2003. It should work as it is. You should not need to purchase any key for FSUIPC at all. Have you tried it? Why do you think you need a key? Yes, but I've got rather more doubts about CFS2 -- it should work with CFS2 -- CFS2 does have controllable weather doesn't it? I don't think CFS1 did. But the problem is that neither CFS1 nor CFS2 were ever officially supported by FSUIPC, they were just lucky by-products. Please just try it and see before spending any money on it, which I don't think you need to do in any case. Why do you want real current weather for an historical sim, BTW? Regards, Pete