Pete Dowson

They should have unique GUID values -- see the [JoyNames] section in your FSUIPC4.INI or FSUIPC5.INI file (you've not said which Sim you are using!). If there's nothing specific to distinguish them -- i.e. same name, same serial number, then it is best never to unplug them and plug them in again, as Windows may assign the GUIDs in the other order. I think later versions of Bodnar boards had serial numbers, but I'm not sure they were in the part of the ID Windows reads. Anyway, show me your INI file if you still can't sort it out. There should also be an FSUIPC Joyscan.csv file which provides more information about how the devices are identified. I use several Bodnar BU0836 boards and have no trouble with them getting mixed up, but then they are permanently installed in my cockpit. Pete

John asked me to see if I could help, so forgive me if I've missed something. Unfortunately the Log supplied is a "continuation" log -- you pressed the New Log button for some reason. Without the early part of the log, showing what has been detected and assigned and which aircraft is loaded it is difficult to know what to make of the part you have supplied. So, were you using the A320 in the Profile called "A320". Is that the only aircraft with which you have problems? If it was the A320 I'm rather worried and confused by your assignments: 1=AV,256,D,9,0,0,0 -{ DIRECT: Throttle1 }- 8=DX,256,D,10,0,0,0 -{ DIRECT: Throttle2 }- 9=DY,256,D,10,0,0,0 -{ DIRECT: Throttle2 }- You have Throttle 1 assign on your Saitek Yoke, and TWO axes assigned to Throttle 2 on your Saitek quadrant. So I'm not at all surprised by what you see happening. Have you tested your throttles in any other aircraft? I see you have two throttles assigned for the Baron, but oddly both to the Yoke along with the elevator, ailerons and the left prop pitch. The Aerosoft A320 is, I understand, a fairly sophisticated model, and it may be doing rather different things with some of the axes, like the PMDG Boeings, which read axis values at a higher level so you would need to assign to the regular "Axis Throttle" controls, not "Direct to FSUIPC calibration" as you have done. With PMDG aircraft you really can't calibrate in FSUIPC either because two different values might then be sent on to the sim's engine. The A320 may well be the same. However, before going down that route, try changing this line in the [JoystickCalibration.A320] section of the INI: UseAxisControlsForNRZ=No Change the No to Yes. Pete

Good. That was easy! 😉 Probably needed a re-boot to update the Registry properly. Pete

Excllent! Thanks for letting me know! Hmm. Yes, it does seem a very unreasonable thing to happen as a result! Pete

So there are no entries in the Registry for any USB Joystick type devices, and also no response from DirectInput to requests for Joystick type devices. That is really wierd. AND unique in my experience, unless there are truly no such devices. You said: Please, then, show me your FSUIPC4.INI file so I can see what devices it thought it saw and assigned previously. When did they all stop working? What changed to do that? The software doesn't change by itself. You say Windows Game Controllers see them. Does FSX-SE? Also please find and run HidScanner (it's one of the additional free software packages in www.fsuipc.com, and show the log that produces (it will be on screen and there will be a file in its folder too). Pete

Sorry, can you explain what you mean? But there is no reverse only capability in FSUIPC unless you assign to reversers! For a forward and reverse zone on the same axis you calibrate on the 4 throttles page of the calibration tab and make sure that the No Reverse Zone option is not checked. Then calibrate wih a minimum, a central idle zone, and a maximum. Pete

Can you please show me the FSUIPC4.joyscan.csv file from the same folder. Pete

Throttle Set is not Axis throttle set. Assign to the Axis one. I had assumed you only had the one throttle axis and so wanted to control both engines with that. Hence the need to map the one throttle to two THEN calibrate with an appropriate reverse zone. Please DO read the sections on Axis Assignment and Calibration in the FSUIPC User Guide! Pete

I think you need to read the heading and set the bug to that value. So, it is not the heading bug you want to set, but to reset any gyro drift? Pete

The centre line runs all the way down the runway. You know the direction of the runway and it's start and end, so it's just a matter of trigonometry. What data is that? I think the xml contains the same information. eg: <Len>9988</Len> <Hdg>55.050</Hdg> <Lat>53.345268</Lat> <Lon>-2.292515</Lon> and of course, similarly for the opposite end. As to whether the lat/lon give the position at the exact centre, I would assume so (where else)>. MakeRunways merely extracts it from the BGLs. Check if you like, either in the sim or using ScruffyDiuck's Airport Design Editor (ADE). Pete

You can MAP the one throttle to two throttles. Please do refer to the FSUIPC user guide. You need both throttles to be controlled in your aircraft I asume? Well, that mapping does it and allows a reverse zone on the axis during calibration as well. I've no idea, but then I've also no idea how it works if you are assigning the Generic throttle (Axis throttle set), which I assume, as that offers no reverse capability. Unfortunately you've not yet said what you assign to so I can't really help further. I am thinking it's the PMDG NGXu which is reading your joystick and not FSUIPC. Pete

Assuming your values were all between 0 and -1.0, then that's rather strange, becuase I'm pretty sure it is that value which affects the SimVar variable FSUIPC uses: "THROTTLE LOWER LIMIT", which FSUIPC converts to the appropriate proportion of 16K and stores in offset 0B00 (as a u16). For example, the default of -0.25 should give -4096 there. Perhaps you could Monitor that (right-hand side of the FSUIPC Logging tab, in its options). If it is seen in Axis Assignment, AND you've assigned it, then it really must be recognised in the calibration. If you've not actually calibrated it in FSUIPC this explains the problem, as it is the calibration which limits the reverse according to the max reverse from the Aircraft.CFG file! Without calibration the control value is simply being passed as received. The calibration should see it even if assigned in P3D1 What are you assigning to? For a reverse region you either need two separate throttles (the NGX has got two engines, after all), or you would have to map the generic throttle on page 1 of the calibration pages. Please review the FSUIPC User Guide. Also try testing on a default jet as opposed to PMDG, as the PMDG aircraft do tend to do their own thing. Many folks find they cannot assign or calibrate in FSUIPC for some of the PMDG axes. You can't if the axis isn't being calibrated -- there won't be an entry. Pete

You are too quick for me, John! 😉 Dad

FSUIPC reads the % max for reverse from P3D, and that comes from the Aircraft.CFG file. Check the value there. For example, this line in the [GeneralEngineData] section (this is a typical default value): min_throttle_limit = -0.25; //Minimum percent throttle. Generally negative for turbine reverser For my ProSim 737-800 the line is: min_throttle_limit = -0.3416 //Minimum percent throttle. Generally negative for turbine reverser This really should be correct in the PMDG NGXu already, but check that and try a different value. Otherwise, to limit the range on a calibrated FSUIPC axis you would need to change the end point values in the Calibration lines to unachievable value, e.g. less that -16384 for the minimum (more than +16383 for the maximum. But really the proper control over max reverse thrust is that parameter in its Aircraft.CFG. Pete

I don't think there's any measurable difference. maybe a few milliseconds for the extra code being used. FSUIPC uses DirectInput. Pete

If that is just as easy, fine. If not then, whilst it should be easy enough to add to the ipc.macro facility, it probably won't see release for a while due to other pressures. But let me know, and I'll take a look before John can get to it. Pete

P3D and FSUIPC detect both axes and button presses in slightly different ways. But P3D actually has two ways -- you can select between Raw and DirectX (I think they are labelled like that, or similar). Take a look. Try the other. But I must ask. If you can detect them in FSUIPC why not just assign them there? There's a much wider choice in FSUIPC, and you can have different assignments for different aircraft types, using Profiles. Pete

Okay. I won't see it till tomorrow. Late here -- off to bed now. ;-0 Pete

All this is not really relevant to FSUIPC. As a purchaser of an FSUIPC license you are entitled to use it on as many PCs of yours for your private use as you like. There is no restriction to a single PC! My point was merely that WideFS cannot link to another PC which is also running a version of FS, any version. Pete

Have you set the server IP address or server name, and the protocol to be used, in the WideCliernt.INI file for each client. That is always the first thing to do in such cases, as discussed in the WideFS user guide. Don't rely on Broadcasts. Are all your PCs in the same workgroup? If not, broadcasts won't work. Change the workgroup names to match. (I'm pretty sure this is also in the user guide). WideFS doesn't link two PCs both running FSX. I thought the old PC wasn't going to be used with FSUIPC in any case? Pete

Rain all day most days. Occasional breaks and glimpses of sun. Warmer today -- predicted to go right up to 10C this afternoon! But some days it doesn't get higher than 5C. Better than a couple of weeks ago though. It was cold when you wore shorts last time, so I expect you will this time as well.😉 Not as far as I know. But if merely adding some log lines has changed it, this points to some nasty obscure timing problem. Which would probably also explain why others don't have the same problem. It may be related to the attempted closing of the socket listeners of WideServer and those of ASP4 DLL at more or less the same time. One test we didn't do, but too late for now till you return, is whether it happens when WideServer actually has a connection to deal with. After all, when the ASP4 server has a connection you don't get the problem. The solution in WideServer then may be simply not to delay closing in order to send shutdown messages to connected clients which don't exist. It can simply close down immediately it is notified. Pete

If you mean using SPAD to drive Saitek panels, then you really want SPAD support. SPAD is not one of our products, and I know nothing about it. John may know more however. I'm sure he'll respond within the next days if he does. Pete

Hmm. I'll read about it, but I thought that must mean installing some part of VS on the subject PC. See you Tuesday at EGCC. Cheers Pete

I replaced my later version of the P3D client with the 4.5.13.32097 version, and this time the ASP4 module as_connect_64 produced a full log (btstrp.txt), matching yours ... but at the end of the session P3D closed perfectly. So, unfortunately, I cannot reproduce your problem. There must be something else going on. I wonder if it may be something to do with a Win10 update. I am of course using Win7 on this testing & development PC. Tomorrow I may test it on my VFR PC, which is running the very latest, fully updated, Win10, plus P3D 4.5.13 Academic (the Pro version is on my cockpit PC). However, on that PC I don't have any debugging tools installed, and don't really want them on either of my cockpit PCs. Pete

I suspect that you can only get this information by reading the CDU text and trying to interpret that -- but the information would have to be displayed on one of the CDUs in order for you to receive it. There are offsets dedicated to receive the text displayed on the CDUs (if enabled). See the Offset Mapping for PMDG 737NGX pdf in your FSUIPC Documents subfolder. It would be very messy. This data is really provided for you to replicate the CDU display on an external hardware CDU, not for interpreting by program. But it isn't impossible, just messy. Pete