Pete Dowson

Well I'm sure Active Sky can provide older METARs, so I assume they are keeping them on their website. It's not quite like Opus, because Opus also deals with views and spreading FS across different PCs on a network. I don't think weather was or is its main focus, thpugh it does do it quite well. On the other hand, it is Active Sky's only interest, and it has held the prime weather position for FS for many years. Pete

Well something must be providing the values 0, 90, 180 and 270 for the USB joystick "POV" type input. A normal pushbutton indication would just be a bit in a 32 bit word. You might not think of it as firmware, but it is a program in a chip, and that's what I call "firmware". Pete

All weather suppliers for FS use METAR data, of course. Even FS's own downloaded "real weather" if that still works. Take a look at Active Sky if you want historical weather. I think it might cover a lot more. If all you want is the METARs from weather stations for a specific time and date, why not find then on the web in any case? Does it have to be a particular place? ActiveSky Next (ASN) has a facility for searching for things like storms, and then it is easy enough to locate the aircraft there. This is how I tested my own weather radar graphics displays linked to ASN's facilities. Try using ASN. It is possibly the most advanced weather program at present, and supplies ready-made weather radar data. See the ASN WXradar stuff I included with my more recent FSUIPC releases. Several add-on aircraft have been enhanced recently to use its WX radar data facilities (PMDG 737NG and iFly 737NG, to name but two). Pete

If you are using a weather program such as Opus then you surely don't want to also set the weather yourself as well? Maybe I'm misunderstanding you completely. Why do you want two sources of weather? Pete

What does it do if two are pressed together? That's all a normal 8-way hat works -- the firmware in the device converts that to the intermediate positions. Pete

Basic arithmetic. The heading provided by the offset you are reading is in units of 4,294,967,296ths of a full circle. That number is more easily remembered as 65536 x 65536. Nothing magic about that. You convert to whatever units you want. Obviously your should have units of 36,000ths of a circle, so you need to do the computation as (unsigned value from offset)*36000/(65536 * 65536) By using unsigned you get 0-35999. Do the computation in floating point then take the integer part of the result. Then you can use the value directly. Pete

My earlier analysis was wrong. Sorry. It was a long time ago and my memory of how it worked was incorrect. For a docked window the figures are proportions of 16384 of the Flight Sim's width and height. The "fix" I've implemented, apart from checking the values, is full separation from the recently added "TextMenu" facility operated by WideClient. Pete

Sorry, I don't understaand the "only 4 inputs" part. Would 8 inputs give 8 way, 16 16 way and so on? Would less give more? I don't understand your point there. I have no idea. I have never built a hat nor connected one to any board. All I can explain is what FSUIPC or FS will see and how it can treat what it sees, and that is what I have done. For hardware support I can only suggest you visit the appropriate maker's support forum. You will probably find both Bodnar and Digikey users over in http://www.mycockpit.org/forums/ too, so worth visiting there, perhaps? Pete

A proper hat, recognised by Windows as a POV ("Point of View") device, and not just a collection of buttons, returns to FS and FSUIPC a value in either degrees (0-359) or 1/10ths of degrees (0-3599). Whether it can only supply discrete values like 0, 90, 180, 270, or many different values depends entirely on how it is made. I think the normal cheap ones consist of 4 buttons, but usually with the firmware in the device it is connected to able to detect two adjacent ones pressed together and so give you the intermediate, 45 degree, positions -- i.e. 8-way. FSUIPC4 can see POVs as axes, in the axis assignments tab, in which case it takes the number provided, 0-360, as an axis value. It can also see them as a set of up to 8 buttons, 32-29, (this method derives from how FS98 and earlier saw them). In that case it merely treats values 337.5 - 22.5 as 0 == button 32, 22.6 - 67.5 as 45 = button 33 ... and so on. There is of course no way FSUIPC can detect values which aren't supplied by the hardware. It can't "interpolate" given only one value, obviously. If the Bodnar implementation doesn't do the 2-button detection in order to send the intermediate values, then I'm afraid your hat will remain 4-way, not 8. Pete

I've tried all sorts of things to reproduce this, and I can't. I can have the RC menu window, a GSX menu called up, and a message strip from FS telling me my QNH setting is all wrong and to press 'B', and all are independent of each other. The only way I can clear the RC menu is to write an empty message to it, or to set it to time out via the control parameter so that it limits how many seconds it is displayed. I've tested it on FSX and P3D in both Windowed and full screen mode. So, I'm going to give up on this one for now and make a release 4.933 tomorrow or Wednesday. I'm sure it is now working as it was designed originally. If something else is making it disappear I'll need to try and get that identified at a later date. Regards Pete

Of course no one "understands LUA" without at least looking and reading and thinking. You only need to read the brake settings (one of the ipc.readXX functions) compare the numbers returned to whatever your threshold should be, and so decide whether to write to the offset which controls your switch (using one of the ipc.writeXX functions). I can help and advise, but I don't write programs for folks. Try at least looking at what it provided -- there are lots of examples. Ask questions if you get stuck, but make a start. You can't actually get stuck if you haven't even started! Pete

You could do that easily with a small Lua plug-in. Pete

This is really the wrong place to ask -- I support FSUIPC and WideFs, but no weather programs. Certainly programs like ActiveSky and OpusFSX and others are capable of providing weather for almost any date, time and place. Please refer to their documentation. look for "historical weather" or somesuch. There is no XML in FSUIPC. It does not support XML. Offset C000 is the start of a 4kb area in which binary encoding of current weather in FS can be read and written. It is documented as "New Weather Interface" in the FSUIPC SDK, and demonstrated by the program "WeatherSet2". METAR string data can be read and written as an alternative to the binary data, and that is in the 4kb area starting at B000. This is a direct interface to the METAR facilities of SimConnect. Pete

There aren't different versions. Registreation is simply a matter of providing the key and valid user details during installation. Why? That really is not a good idea! Either you purchased the wrong key -- make sure it is for FSUIPC4 not FSUIPC3 -- or you are entering something incorrectly. All three parts, name, email and key MUST be exactly right. Use cut and paste to be sure. And the Installer you should be running is the current one, for version 4.931. (Version 4.933 will be released later this week). Pete

ActiveSky uses SimConnect, not FSUIPC or WideFS. you need SimConnect configured correctly for network use. See ActiveSky documentation. Pete

Shouldn't be a factor. Pete

Well, it would seem unlikely if it doesn't happen with FSX. You could test one more thing. Just remove PFCHid.dll from the Modules folder (or simply rename it, eg PFCHid.DLX), then see if running P3D still stops the PFCtest program without a PC power cycle. If so it is most certainly down to something odd in P3D and needs reporting. If the controllers are disabled they should touch any USB devices at al. You could try asking PFC what they think, but they'll point to it being okay with FSX. One other thing. in case it's a problem between P3D and the specific USB ports, try different ones. Maybe its a clash with a keyboard or mouse -- USB ports are in pairs, and it's best to put some devices separately. Pete

Well, it isn't quite right yet, then. It shouldn't disappear. It's a separate Window. The sim is able to support many of them -- I can open several and keep them open with no problem. I'll see if i can reproduce this here. At least with FSX most of my testing tools are usable. Pete

Does the PFC test program work if you unplug and replug-in the devices after P3D seems to disable them, as this appears to help PFCHid after all. A PC power cycle seems to indicate something even more serious. Pete

Even unplugging them and plugging them in again? Either way, it's a very telling fact. I don't know what P3D is now doing, but it is certainly succeeding in messing things up. I think you need to report this on the P3D forum, with a request that when controllers are disabled they don't touch any USB devices at all. I really can't see another possible solution. i can't imagine what could be happening to make devices unrecognisable afterwards like that. Maybe also a report to PFC? Maybe they can understand what can happen on the USB ports, though maybe not as I suspect they buy in standard USB chippery. I'm not sure I can advise anything more productive at present I'm afraid. EW321, who contributed above, tells me he also does get a few "error 2" reports on the avionics stack, but nevertheless it carries on working. Some sort of timing or hardware difference, maybe? Are you using Windows 8 -- that could be a significant factor too. I think EW321 is using Windows 7. Pete

Hmm. Strange, because there's absolutely no difference in FSUIPC or PFCHID in dealing with any devices whether you are using FSX or P3D (or indeed, any other version of FS back to FS98). So i'm at a loss to understand why using P3D can mess things up. One thing to check: have you disabled controllers in P3D? Maybe it is doing something with those USB ports when PFCHid is also trying to get things sorted. That certainly indicates some sort of USB problem. So does nothing then allow PFC's test program to see them again until, what ... PC power cycle, USB re-connection, what? That also implies that P3D is doing something which has messed things up. I know P3D 2.2 now does something different for Joystick devices than it used to -- part of L-M's attempts I think to get over all the problems folks were reporting with joysticks and Windows 8. Those affect FSX as well, of course, but no one is amending FSX any more, and folks are instead solving it by disabling controllers in FSX and using FSUIPC exclusively. Can you clarify whether the logs refer to the exact same test session? The FSUIPC log shows only one significant entry: 184908 ***** HID USB device reconnected: re-initialising FSUIPC connections Is that when you unplugged it and re-plugged it? The PFCHid log shows both the Console and Avionics are detected, but: 15: ... Ok, added as device #2 10218: **** ERROR: Device #2 command discarded due to "WriteFile" failure [00000002] 20249: **** ERROR: Device #2 command discarded due to "WriteFile" failure [00000002] 30280: **** ERROR: Device #2 command discarded due to "WriteFile" failure [00000002] etc, ad nauseam. Every attempt to send data to the Avionics encounters error 2, which is "file not found" -- in other words the device is no longer there! Of course nothing is sent at this stage to the console, so no error is reported there. There are only two things I would have suggested, but since you presumably have no trouble with FSX (?) maybe there's only one: 1. Check the USB connection. Avoid using a hub if possible -- if not possible make sure it is a good quality powered hub. 2. Make sure controllers are completely disabled (not just de-assigned) in P3D. There is just one checkbox I think. #1 is probably not applicable if it is all okay, consistently, with FSX. Obviously it is possible to make these things work with P3D 2.2, because Thomas (EW321 above) confirms this. I can't think of anything else but the above at present. Oh, one other thing. Instead of unplugging them and plugging them back in again, see if going into FSUIPC's options, selecting either Axes or Buttons & Switches, then simply exiting again helps. That should also re-scan USB devices and might also do the job. If not, then there's definitely something messing up something deeper in Windows, as in fact your report about the PFC test program indicates. Pete

Only if you do get a crash. I'm awaiting confirmation of other changes, for the Radar Contact window, before i make a formal release. It'll be 4.933. Pete

Really? When I had the Cirrus the yoke was definitely always treated as a normal joystick. I do have support for aileron and elevator built into PFChid, but I'm pretty sure I never had it routed that way. Strange. Yes, but of course you can do that with any joystick type device axes. Anyway, I would need to see what the OP has got in those files. I'm wondering if he actually has a Cirrus configured for a third party seller, like Elite. I know the older serial port devices made for Elite won't work with my drivers. The protocol is completely different. Pete

You've not supplied enough information I'm afraid. Some clarifications: 1. The connection of the PFC USB devices through PFCHid and FSUIPC is totally independent on the version of flight simulator used. There is no difference between FS2004, FSX, P3Dv1 or P3Dv2.x in this regard. 2. The yoke (and pedals if connected) on the console is NOT handled by PFCHid. It should be recognised as aileron, elevator (and optionally rudder and toe brakes) directly in P3D and in FSUIPC's axis tabs. So, questions: 3. Have you not used this console before? Is it new from PFC? 4. Does P3D see the yoke? 5. Is the a PFCHid menu entry in the P3D Add-Ons menu entry, as well as an FSUIPC entry? I need to see the following files. Paste them into a message here or Zip them together and send them to petedowson@btconnect.com: FSUIPC4.LOG FSUIPC4.INI PFCHID.LoG PFCHID.INI You will find them all in the P3D modules folder. There are other tests you should do as well. I think PFC provide or make available a test program for their USB devices, called something like "PFCtestGUI". (not sure about that). Did you get it with the device, or can you obtain it from them and run it to see that the devices are indeed working properly? Download and run this program of mine: HidScanner It produces a log file, displayed on screen and written to the folder in which it is run. Show me that log file (or include it in the Zip you attach). ("Hidscanner.log"). Really it is PFC's job to support their devices, but I'll see what I can do once I have the information. Pete

I've fixed the P3D 2.x call for Traffic Zapping and tested as best I can here. Please try the interim update and let me know. Download FSUIPC4932bTest and try it. Please let me know as soon as you can -- I'm on holiday from Saturday for 10 days and would like to get this sorted and release 4.933 before then if possible. Thanks! Pete