Pete Dowson

Without any logs I cannot really comment on this. Can you discuss it with Damian, the ActiveSky author? I'm sure he will mention things to me if there's anything odd. Really the option will do nothing if the dynamics slider is already zero. And there are many other weather programs than ActiveSky I need to consider here. What "earlier" versions, please? I've not changed any of the weather handling for a LONG time. It would be helpful to know when you think this changed. Okay, thanks. Pete

Sorry, I don't know any Embraer panel. If they have their own autopilot then you must ask them how to operate it. If it uses the standard autopilot, like most add-on aircraft, then all the facilities you need are already implemented. Similarly for trim. As for "buttons of screen navigation", sorry, I don't know what you mean. Regards, Pete

Yes, indeed it is "create" -- YOU need to create it. You need to work out the CFG file for what YOU want to do, to suit your EPL program. I only give examples in the documentation. The one you quote above looks like an example. I cannot design your project for you. It is specific to each implementation. Er, F9? What's that? You need to write the EPL code to do what you want to do with the EPIC. I cannot help you there, you need to study the EPIC documents and get help if needed from the EPIC folks. Most certainly, after you have written your EPL program you must compile it before to load it into the EPIC. The EPIC doesn't not read source EPL! You seem to be very confused here. You are mising up buttons with EPICINFO's indications and values being SENT to the EPIC. The PHs (Pigeon holes) and QPs (QProcs) are things SENT to the EPIC for you to program from, for instance to make displays, indicators and so on. This is what EPICINFO is all about. When you've written your Epic program and compiled and and got it working, then you'll know what PHs and QPs are. It looks to me like you need help in understanding the EPIC from the EPIC folks. I've not done any EPIC programming for a long time now, and then it was different (ISA EPIC, not UB, and no Epicentre program). Regards, Pete

1.92 suffers from trying to control the global weather, which becomes not so after a little while. See the comments about this near the top of this forum, and in the FSUIPC documentation. AS2004 set weather at weather stations. The weather at those stations does get set and is reported in their ATIS. All that option does is set the dynamics slider to 0 when the Clear Weather command is used either by an outside program, or by using the FSUIPC button or hotkey. I know WxRe 1.92 uses Clear Weather, but I don't think AS2004 does. The "clear weather call" from where? Where are you seeing such a call? And how does it stop writing? You have me rather bemused. Have you been analysing FSUIPC weather logs? Regards, Pete

Not sure FSUIPC is the best place to do this -- you can assign an axis to the spoiler in FS's own assignments. Are you testing all this on the ground, before takeoff? If so, don't. Get airborne. What happens is that when operating the spoiler lever you are passing through and setting the "ARM" facility. Arming the spoilers is supposed to be done in the air so that on touch-down you get them deploying to 100% automatically. Unfortunately, in FS2004 all the time, and also sometimes in FS2002, if you are already on the ground this action will occur immediately! Get airborne and check them out there. If you like, calibrate them in FSUIPC whilst in the air. Incidentally, the normal maximum spoiler setting used as speed brake would be something like 60-75% ("flight detente"). the 100% is there to spoil lift really thoroughly and is the "ground detente". Regards, Pete

Yes, sorry. I discovered this two days ago and I am fixing it now. It only applies since 3.14, but it is annoying. The only way around it at present is to correct the INI file BEFORE re-loading FS, after any Key re-programming. The error in 3.14 is the inclusion of the extra comma. If that is removed BEFORE reloading FS then all is well. However, if you don't, then edit the keys again, the lines are made even worse, and so on ... The reason for this is that FSUIPC is reading: ,,65913,0 as ,0,65913 (the omission of a number looks the same as a 0). So when it gets written back it LOOKs like it has the control and parameter reversed. In fact it is not the parameter 0, but another 0. If you want a fix urgently then email me at petedowson@btconnect.com and I will send you the fixed interim version (it is a little too big to upload here). Otherwise it will be fixed in the next release, probably middle or end of next week (there are some other things to test and document too). Apologies for the inconvenience! Regards, Pete

Not sure I know how to do that, but I'll have a look. Pete

Hi. My name is actually "Dowson", but lot's of people make that mistake. Yes, the current version of EPICINFO.DLL works okay with the USB Epic. It uses the EpicIO.DLL which should go into your Windows/System32 folder. Welll, install Fs first, and test it, make sure everything works okay. Then, as documented, put EPICINFO.DLL and FSUIPC.DLL into the FS Modules folder. Program EPICINFO by making an EPICINFO.CFG and put it in the FS main folder. The EPICIO.DLL goes into a Windows folder -- Windows, or Windows/System32 will do. Run FS2002 after you've installed all that. Regards, Pete

Well one of my internal test increments since then was 3.142, which is much closer to PI, so it gets the title. Didn't last long though -- up to 3.148 here already. :) No one asked for my 2.718 release of many moons ago to be called "e". Maybe I should make an imaginary release called "i" next? :D Regards, Pete

Both of those errors are simply my program reporting what Windows tells it. That's absolutely all I know. Something is evidently wrong with the network, but I don't know what. If I had that happening I'd have to start on a long process of elimination, trying everything, including swapping/replacing LAN cards, cables, by-passing switches or hubs, and so on, till I found what was doing it. And re-installing drivers, Windows, removing possible interfering programs like ZoneAlarm or other firewalls, etc. Sorry I can't be more specific. Just about all I know is written in the WideFS documentation -- in fact I don't know all of that, much is contributed by the experience of others. With that in mind can you please keep us abreast of what you try and what the results are? Maybe we will all learn. BTW maybe your WideServer LOG has something interesting in it too? Are you using IPX/SPX or TCP/IP? Katy Pluta, who can be contacted in the FS2004 forum here, knows a fair bit about Networks and may be able to help. Regards, Pete

HmmmI was 18 months younger then! :) . Ah, the good old days! Thanks & Regards, Pete

I saw it and, and basically agree with one of the responses you got. Apart from the first reading (which was probably taken before the FS weather had been fully settled), the others are probably where FS is getting readings from WX stations as you fly. Looks like you were flying in an area where there are many stations. I don't think all the WX station weather downloaded by FS are always for the same time-of-day, so there might even be more variation than in reality. When flying through areas of changing pressure below TA (Transition Altitude) you do have to keep adjusting your altimeter if you want to keep accurately level, though whether ATC would be giving you such calls is another matter. Probably in real life it would only do so when descending towards the transition level after flying Flight Levels, and in the approach or landing instructions. You'd be responsible yourself to tune into ATIS's en route to get interim pressure readings. You also wouldn't get told off for minor variations in actual altitude caused by minor changes in pressure. I think RC has a parameter for how accuratey ou want ATC to check this. Of course in FS you can "cheat" and simply regularly press the "B" key to correct your altimeter. Flying in the US or Canada in a light aircraft you are always below the TA (18,000 feet) and so this is a constant problem with real weather patterns. Elsewhere the TA is likely to be much lower and it is less of a problem -- e.g. here, near EGCC, it is 5000 feet. Above that, using Flight Levels, you simply set the altimeter to 29.92 (1013 here) and keep to the assigned altitude with ease. There has been a lot of discussion about pressure calls from RC in the Beta group. I don't remember what if anything has been changed, but you could pose your questions over in the RC forum or Newsgroup or whatever. Regards, Pete

When you register FSUIPC and/or WideFS as a user, it is yours, to use as you like. It can go on a roomful of PCs if you like, provided they are all yours (or your live-in family's :wink: ). I don't like the one-license one-PC system. Anyway from what you describe above you only have one machine actually running FS in any case, so it would only be one FSUIPC and one WideServer wouldn't it? You can have as many WideClient's knocking about as you like anyway. Regards, Pete

Well, except that my attempts to provide the keystrokes for Ctrl + ; all came out as a face (Ctrl+;)), thanks! :D Pete

It is not compatible. I'm pretty sure that the protocol supported for FS and X-plane wasn't even thought of 5-7 years ago. I think the controller board is completely different as well. Sorry, I don't think you have a chance without some serious upgrading. But don't take my word for it. Contact PFC and ask. http://www.flypfc.com. Regards, Pete

Yes, of course. Don't select it then. :wink: I cannot reproduce this here with default weather settings in FSUIPC, but with any of the weather options selected, you would need to reload the current flight (Ctrl+;) or load a new one in order to reset the weather engine -- I think it is probably still assuming something has changed it outside the current "theme" -- which it has, actually. You don't need (or want) to select the "Allow Changes" option just to use an outside weather source -- that only affects FS's own "global" weather in any case, which won't apply if you use an outside source. You don't need to restart FS, only reload the flight (Ctrl+;) or select a new one. By the way, exactly the same consideration applies to FS itself, without FSUIPC. If you go into the weather menu and select "user defined weather", then "customize weather" and go and change something, you then cannot select a Theme until you reset or reload a flight. In other words it is a function of how the themes work in FS -- you either have themes or you don't. If you do but then change something, the weather engine cannot continue the theme operation until it is reset. I think only loading a flight resets it. Regards, Pete

The weather will ALWAYS default to user defined if you tick the "allow changes". Otherwise it will only do this if you have something else manipulating the weather through FSUIPC. If unticking that option doesn't help then something else is doing it. If you wish to make sure that all the other options in FSUIPC are defaulted, either delete your FSUIPC INI file before loading FS, or pressing one of the buttons on the About page in the options. Regards, Pete

Okay, so it is definitely either your stick or its drivers. Try without FF, maybe that is interfering. Regards, Pete

Ah, I see from your original message that you said "If I change aircraft I get it back....sometimes". That actually sounds suspiciously like ot might be something going on with the flight model. Does this happen with all aircraft? Can you look to see if you are actually getting full aileron and elevator movements (use spot view)? Pete

The axis certainly seems to be calibrated very lopsidedly in Windows. Re-calibrate there. FSUIPC doesn't allow reversed axes -- you can reverse them in FS I think. In FSUIPC a negative number is ALWAYS less than a poitive one. Have you yet tried with FF turned off? Otherwise I'm sorry, I can't think of anything else to try. Does it stay like that till you reload FS, or power the PC off/on, or what? When does it come back to normal? Pete

All I can offer is the FSUIPC SDK -- get it from http://www.schiratti.com/dowson. You can read all sorts of velocity and acceleration information (check offsets 3060-30B8 and 3178-31D0. Which of those you use and what you do with them is another matter though. Sorry, I don't know. And the hardware to convert signals from, say, a parallel or serial or USB connection into 3 amp currents is completely not my area of expertise -- I'd be looking at some of the harware add-on sites for such things. I expect EPIC do them, as I know R&R have implemented at least one motion platform. Regards, Pete

So it's okay one minute, unresponsive the next? Sounds like a problem either with the joystick itself or its driver, or some interference with the Force Feedback. I think you need to go through a process of elimination to see what it might be. Have you another, maybe simpler, joystick to try? Can you try without the FF? I'm not really an expert in joystick berhaviour I'm afraid. If no one else jumps in here you may need to find a more hardware-oriented forum. In other words the actual INPUT range goes from -16000 or something up to +10000, no further? That sounds like it isn't calibrated very well in Windows to start with. You should have roughly equal amounts either side of the nominal "centre" (0). -10000 to +10000 is kay. Even -100 to +100 is okay. But not -16000 to +10000. You'll get much coarser behaviour to one side compared to the other. See if you can recalibrate in Windows Game Controllers to get a more even result. Regards, Pete

I don't think anything you can do in FSUIPC will turn a sluggish joystick into a fast one. Is it the same with force feedback disabled, wherever you can do that? Check the FS sensitivities -- Options-Controls-Sensitivities. Set them higher. If all axes all read 16383 for output all the time then they won't be at all usable. In that case you have set them up wrong in FSUIPC. Press the button marked "Reset" for each axis so that FSUIPC doesn't do anything, then try them in FS. If you want to use FSUIPC to set more precise end zones and centering, please follow the instructions very carefully, step by step. The "bing" noise indicates as impossible setting you are trying to make. The calibrated numbers to the right of the INPUT and OUTPUT values need to go from lowest (most negative in this case) on the left, to most positive on the right. The two centre ones must be in between. FSUIPC won't allow you to set any other order. The gap between the two centre values controls how much central null zone you have, for a good centre. Regards, Pete

No, the timing you are referring to was the additional smoothing to stop any longer term "jitter" than the filter I had already incorporated (which was for less amplitude and only 150 mSec). Personally I saw no need for it, but someone else did and was happy with the result as far as I know. The new facility I put in is a "Throttle Sync" control as documented in the PFC DLL user guide. To quote the explanation there: "This toggles a facility to synchronise the settings of throttle, propeller pitch and mixture on all engines. Basically, when enabled, it uses the Engine 1 values for all the engines and ignores the inputs from the other axes. When toggled off, the current settings for the other axes are re-instated. This is not related to the “Prop Sync” switch fitted to some aircraft." To use it simple assign it to a button. The latter part seems to argue against the former part of this statement. I am at a loss to understand what is happening. How do you know it is due to the throttle quadrant then, or my presumed bad programming? Have you any other such controls to compare it with or to exonerate the FS programming or specific aircraft? When you say "always", you mean with all versions of FS, and with all connected controls? I'm getting a bit confused now, I'm afraid. There must be some way of determining WHAT it is that is causing the wobbles. You say the controls, graphically, seem to move smoothly and in concert, no apparent jitter there. Obviously the graphics may not have adequate resolution (though with only 40 steps I should have thought they would), but what about the instruments? Do they show any irregularity that could cause this? I'm not familiar with turboprop instrumentation so I can't tell you what to look for. The other thing you can do is use the Monitoring in FSUIPC to watch the prop and throttle values actually being used in FS. Go to FSUIPC options (Alt M F) select Logging page. On the right enter these: Offset 088C, Type S16 (this is Throttle 1) Offset 0924, Type S16 (Throttle 2) Offset 088E, Type S16 (Prop pitch 1) Offset 0926, Type S16 (Prop pitch 2) then check the "Adv Display" selection below and OK exit. You will get a window on screen where these values will be constantly displayed and updated as they change. See what happens, looks for too much fluttering, or differences where they should be similar. You can also see the Mixture values (offsets 0890 and 0928) but you can only see 4 values at a time. If there are always disparities between engines 1 and 2 when the levers appear to be together, this can mostly be corrected by better calibration in the PFC joysticks section. However, it is unlikely to get rid of them altogether. Maybe there are some points along the axes where the "linearity" is definitely different. It is this sort of thing where I'd hope to apply some of what has been suggested here earlier, to improve matters. However, I feel that the only sure way to get two or more levers reading exactly the same is to use the Sync facility I've provided for just that purpose. BTW how is it really achieved in the real aircraft? If they don't have some "sync" override, how can every lever guarantee the same setting at every equivalent position? It doesn't seem feasible. Wouldn't you even things up by checking the instruments, nudging one lever up, another down, to achieve parity? Or presumably do it all be feel when experienced enough? Not by simply lining up the levers, surely? (Unless it is fly-by-wire, but even then). Regards, Pete

Considering the step seems to be 3 out of the maximum (never achieved) range of 127, the resolution is more like 40 steps or a bit less than 6 bits. However, as far as I can see, this order of resolution is quite normal with the standard sort of pot and AtoD chippery in use. I just checked the throttle on a Microsoft Sidewider USB and its smallest increment (at FS's maximum sensitivity) is 542 out of a range of -16193 to +16192. That's 60 unique positions -- the benefit of optical decoders I think -- but that's still less than 7 bit. At the moment the only way to get that is to enable my PFC DLL logging. This would contain lots of stuff you wouldn't want, so need a lot of editing. And it would basically be a log of received (optionally decoded) data sent by the unit to the PC when IT wants to -- that's a regular sample every second, approximately, and only changes in values in-between. I can supply something with all that if you thought it was any use, but ... ... After your suggestions earlier I have been thinking of how to get regular 18 Hz readings so that I can apply your filtering. I've had a look at my code, and it is a lot more coding than I had been prepared for, but I have plans for how to do it. It isn't a quick change, though. I have to separate the code reading the data and that scaling it and acting on it -- storing the former and sampling it on a timer (actually an FS timer tick chain call) before filtering it, scaling it and acting on it. I will only apply this to throttle, prop pitch and mixture inputs. For aileron, elevator, rudder, spoiler, flaps and brakes I think it would be unnecessary and possibly give rise to delays and hence over control (in the main flght controls that is). But all of throttle, prop and mixture controls will be potentialy contributing to asymmetric thrust. This is why the "throttle sync" facility I added in version 1.80 applies to all three sets of axes. I'm now wonering if the new compalinant is actually using any of the additionas I made. Let me know what you want to see out of all this. I can't promise anything quick, mind. Regards, Pete