Jump to content
The simFlight Network Forums

Pete Dowson

  • Content Count

  • Joined

  • Last visited

  • Days Won


Pete Dowson last won the day on June 27

Pete Dowson had the most liked content!

Community Reputation

222 Excellent

About Pete Dowson

  • Rank
    Advanced Member
  • Birthday 08/27/1943

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Near Stoke-on-Trent, UK
  • Interests
    Flight Simming, Steam Railways, Travelling, Real / Craft Ale,, worldwide

Recent Profile Visitors

31,238 profile views
  1. Pete Dowson

    trouble with bank angle

    I used Ardino once, but I don't remember a lot about it, but the folder with the Arduino software contains Arduino_debug.exe as well as Arduino.exe I seem to remember debugging my little program before using them in practice. Maybe I'm mis-remembering. it was a while back and I am getting old! Okay, so the Lua program is working, though I still think you need to consider what the \n terminator is actually doing. Maybe making the messages fixed length and only sending and reading that number of characters would be better. Well, if the clocks in both Arduino and the PC were also somehow synchronised, and ran at exactly the same speed, and P3D and other threads in the PC didn't interfere with the Lua timing, and the value you are reading changed often enough to guarantee a new value at least on time, and you somehow started the Arduino loop running a millisecond or so after the Lua sending started, then, yes, they might stay synchronised. But no, that isn't possible for most of those reasons. So, if the Arduino read just waits for more to arrive before diving a result then the Arduino loop should be running faster that the Lua. However, none of that explains why the Arduino end isn't seeing the data. Is there no way you can log what it gets -- as you say it is obviously getting something. But I think it will be the Arduino side you need help with. If you want to see what is going out of the COM port you can either use logging in FSUIPC (see below) or a port monitor program. To log COM data add these lines to the [General] section of the FSUIPC5.INI file: Debug=Please LogExtras=x40 The data will be in hexadecimal of the ASCII byte values. This will be all from me till 19th, earliest. Pete
  2. Pete Dowson

    trouble with bank angle

    Sorry, what is "OACSP"? Don't you have any means to track what the Arduino is actually receiving? I thought there was a program which could show you everything your program did? I really don't know Arduino. Is "lcd" a standard Arduino library? Sorry, I don't understand the terms used here either. Consistent with what you intend, you mean? So you know the Lua part is okay, then, right? In the Arduino code I assume "Setup" is automatically run on loading. Does the "All Good" message get displayed? How does the "loop()" function get called? How many lines does the LCD have? If only one, wouldn't the '\n' character at the end of each string cause it to scroll off? One other thing I do notice: you are sleeping for 200 mSecs in the Lua, presumably to prevent a pile up of messages in the Arduino. In the Arduino code you seem to have defined the \n as "endmarker" but i don't see that being used anywhere. And in your loop reading the serial data you also delay 200 mSecs. Couldn't having the same delay both ends possibly cause a clash, where you get the last half of one message and the first of the next? I suspect you want to have the Arduino code reading a lot more often. Is there a good reason to have a delay at all? I assume the "readString" will wait till there's something to read? ========================================== Please note that FSUIPC is really just a utility program, not a hardware driver. Specific hardware support does really need to be addressed by the corresponding hardware maker or it's included software. Possibly there's an Arduino support forum which can help, if you are seeing the data logged by Lua matching what you expect. Pete
  3. Pete Dowson

    Joystick number

    I'll let Paul answer the questions about the facility in his DLL, but the example picture you show is from a WideClient-connected Joystick, not one local to the simulator PC. Jpysticks 0-15 are the only ones representing true DirectInput joysticks which are scanned regularly on the Sim PC. 64-72 are "virtual buttons" only. These are really just offsets which are changed by FSUIPC applications. You can monitor those using Offset reading facilities. For the correct offsets please check the Offsets list PDF in your FSUIPC Documernts folder. Pete
  4. Pete Dowson

    Makerwys v4.801 fails to make data files

    Well, the LorbySceneryExport program is merely a special version of that AddOnOrganizer which MakeRunways can call directly to do the same processing, -- generating the scenery list you see in AddOnOrganizer, and writing it out to the MakeRunways-chosen filename. The same sort of export can be produced also by AddOnOrganiser (I think you just right-click and select export). So, without being able to see the details in the log ("runways.txt"), I think you need Lorby-SI support to resolve your problem. Pete
  5. Pete Dowson

    Makerwys v4.801 fails to make data files

    I am away from early tomorrow until the following Friday (the 19th), but maybe John or others can help. But you can also try Lorby-Si support, because the MakeRunways_Scenery.CFG file is built by the Lorby-Si scenery export program, and that needs to be correct for MakeRunways to process the scenery files added via the Add-Ons.XML methods. If you have the Lorby AddonOrganiser, run that free-standing and see if that finds all your sceneries okay. If not, then the problem is to do with your folders not found under the correct names. You haven't renamed the Prepar3D.exe file have yo? Just check that it is there is the same folder you placed MakeRunways into. I get the feeling that you are placing it into the wrong folder. Another test: if you remove the scenery export EXE from the MakeRunways folder, then execute MakeRwys, if the folders are correct it should find all of the default scenery layers and any add-on sceneries added the old way, via Scenery.CFG. Pete
  6. Pete Dowson

    Makerwys v4.801 fails to make data files

    The Runways.txt file, which will certainly be there, is the log file showing everything it did. How big is that? Were any of the expected files produced? Also: are you using version 4.801, as per the title of this thread? If so then that will probably explain it. The current version is 4.872! If the Runways.txt file is short enough, or you can cut and paste just the first page or so, then please show us what it says. Pete
  7. Pete Dowson


    and So the throttle unit is a normal Windows-recognised throttle, or does it have specific drivers? What make is it? Check Windows "Game Controllers". Is it seen there, as throttle, and will it show its actions there? If not then that's what FSUIPC doesn't see it. Well the slave PC change would have no effect at all on the main PC so that's not the main problem. And it really isn't possible for things to get messed up by only a change from P3D3 to 4 and FSUIPC4 to 5. They are completely interchangeable as far as FSUIPC is concerned -- well, except for isolated facilities like "mouse macros" which won't apply to ProSim aircraft in any case. So i'm sure something else must have changed in your changeover process. It would be useful to know what, but never mind. Let's move on. I don't think there's much to worry about on the 'slave'. I think we're now only trying to work out why the throttles aren't seen. Incidentally, have you considered assigning and calibrating the throttles in Prosim instead, in any case. I'm sure it suits it better -- as i say, i've been using this method through all ProSim 1 and 2 versions. Why? Prosim is becoming more and more capable. What other cockpit software would you consider? Pete
  8. Pete Dowson


    FSUIPC5 always created the FSUIPC5.Joyscan.csv file. It will certainly be there, in the same folder as your FSUIPC5.INI and FSUIPC5.Log files. I'm finding this a bit confusing. If the Bodnar board is connected to the same PC as your P3D Installation, then that's where the throttle axes will be seen, and directly, not via WideFS. If your throttles are connected to a Bodnar board on a different PC, then WideClient does not send the axis inputs through to FSUIPC, only buttons -- these will be seen as connecting to joysticks with numbers with a client PC number first. Client numbers are listed in your FSUIPC5.INI file, here: [ClientNames]1=SLAVE122=SLAVE133=SLAVE14 I don't know what troubles you are having with connection, or which WideFS client your Bodnar board is connected to (if it is), but the WideServer.LOG you posted showed a healthy connection with "SLAVE14": ********* WideServer.DLL Log [version 7.076] *********Blocksize guide = 8192 (double allowed)Date (dmy): 07/07/19, Time 21:17:29.187: Server name is MASTER11 15085 Initialising TCP/IP server 15085 Initialising UDP/IP server 17082 Connected to computer "SLAVE14" running WideClient version 6.860 (IP= UDP 726028 Auto send for 0 stopped before sending all data (0 of 47 sent), Error=10013 (IP= UDP 732549 Close signalled to clients 733657 Closing down now ...Memory managed: Offset records: 244 alloc, 242 freeRead buffer usage: 6932 alloc, 6932 free, max in session: 1Write buffer usage: 31690 alloc, 31690 free, max in session: 1Throughput maximum achieved: 20 frames/sec, 789 bytes/secThroughput average achieved for complete session: 4 frames/sec, 137 bytes/secAverage receive rate from "SLAVE14": 9 frames/sec, 552 bytes/sec********* Log file closed ********* The error 10013 is only the disconnection when you closed the P3D session. It was obviously quite happily exchanging data for nearly 12 minutes before this. However, WideFs is not involved in your throttle axis problems. If the only change was from P3D3 to P3D4 and so FSUIPC4 to FSUIPC5, and no changes were made to the hardware at all, then everything would have worked exactly as before. That's always been one of the whole points of the FSUIPC interface -- continuity right through FS versions since FS98. Changes to the USB connections would mean the assignments have to be re-matched, for which I see John has helped sort out for you. Also, re-installs of Windows changes things too because it will generate new "GUIDs" -- the unique identity assigned by Windows to everything (all devices, all objects, even all internal textures and so on). Incidentally, I assume you are using the old version of ProSim (v1)? The latest versions of Prosim v2 do require you to assign and calibrate all flight controls in ProSim. But i have been doing this for my throttles successfully now since first using ProSim, which was then an early version 1. I've only just recently moved my flight controls (yoke, rudder, till0 to ProSim. Pete
  9. When a device is connected, FSUIPC will automatically re-scan the devices in case there are are any assignments which will now work, necessitating a regular devices scan. This is really an essential action, so it shouldn't be inhibited. The answer is to determine why you have disconnections/reconnections occurring so you can fix them. It might be a bad connection in a device, a bad USB connection, a faulty HUB, or even a problem in the USB port on the PC. You've eliminated the last by trying on a different PC To find the culprit among the others will need a process of elimination. The logs and other results John has asked for would also help. Pete
  10. Pete Dowson


    In order to assign any controls in FSUIPC, then FSUIPC must see them! You say they do not work, but maybe you haven't assigned them anywhere? If you didn't use your FSUIPC4.INI as I said you could, then you won't have ANY assignments in FSUIPC if you haven't used the Axis tab to assign them in FSUIPC Options, which, since you don't seem to know about it, you have not. (Please look in the FSUIPC documents subfolder in the Modules folder. there you will finf DOCUMENTATION. Please read through the relevant chapters of the User guide you'll find there. I shows it all with pictures too). Really? In that case I can be of no help as I know nothing about SIOC. You would need help elsewhere. WideFs talks to FSUIPC directly. It doesn't care which version of P3D it is nor which version of FSUIPC. Provided you entered your WideFS key when you installed FSUIPC, then, without any network changes, it will work as it did with P3D3. Perhaps you'd better clarify. Does WideClient, running on the client PC, show that it is waiting for something in the title bar when P3D is running? If not, what does it say? Well, yes, you have to delete it -- otherwise Windows won't let you rename the FSUIPC4 version to the same name. I'm afraid I'm away now for over two weeks. or more questions on FSUIPC5 + WideFS John or others can help here, but for SIOC and ProSim you'll probably need to go elsewhere. Try the ProSim support forum first. Pete
  11. Pete Dowson


    BTW I moved your post to this, the Support Forum, so it can be answered. The FAQ subforum is for long term reference material. By "working" do you mean the AddOns menu has FSUIPC listed, and that b clicking on it you get the options screen showing? If so, then that's fine. Did you use your FSUIPC4.INI file renamed as FSUIPC5.INI? If so, and you didn't re-install Windows as well, then the assignments will be the same. Does FSUIPC recognise the throttles in the Axis assignments tab? The Network settings in your Windows won't have been changed just by installing P3D4 and FSUIPC5. So what else have you changed? Yes, and you can use that with FSUIPC5 just by copying it into the P3D4 Modules folder and renaming it FSUIPC5.INI. That way you retain all your settings. I'm afraid I know nothing about SIOC. I thought ProSim had its own SIOC drivers. Where does FSUIPC or WideFS come in? No, it is a DLL, a module which runs only inside P3D4. It can't be used outside of P3D4 at all. WideFS client PCs just have WideClient.exe installed and configured to recognise the server (the P3D PC). But if that was all working with P3D3 and FSUIPC4 then it doesn't need changing. It stays as it was. The version of FSUIPC doesn't matter. I'm afraid I don't know SIOC at all, or how it uses FSUIPC. You do really need either SIOC support or, probably more appropriately, ProSim support. But as I say, provided you've not changed the Client PC, and provided you've not reinstalled Windows or changed the Network, then it should all work as it did before. The version of P3D and FSUIPC is not relevant to this. Pete
  12. Pete Dowson

    WideFs and Matlab

    It is possible, but only with some programming. FSUIPC with WideFS does this sort of thing, but then you'd need to write a program to interface to FSUIPC. If you wanted a more direct method you'd need to write a program running alongside P3D to use Simconnect to extract the data you need and send it in whatever format you are expecting. I don't think there are any features actually built into P3D in the way you imply is provided directly in X-Plane (with no add-on like XPUIPC?).Possibly with P3D you could adapt to their multi-PC network linking system. it isn't really an area I've ever invetstigated. You'd be better off asking Lockheed Martin over in their Support Forum -- https://www.prepar3d.com/. Pete
  13. Pete Dowson

    Joystick calibration

    They don't change, not until you set them using the associated button! Then they stay at those values and are saved in your settings file (FSUIPC INI) as the calibrated values to be used. Pete
  14. Pete Dowson

    Offset's 3160, 313C and 3148.

    Are you using Paul Henty's .NET DLL here? If so, I should move this into his Subforum just above. I can't really with programming his DLL. There are ways you can check that the offsets do contain what you expect. Eith use the "monitor" facility on the right-hand side of the Logging tab. just enter up to 4 offsets, select the type, and the values (up to a limited length, at least) will show in the FSUIPC LOG. You can also check any (or all) offsets by using the utility program "FSInterrogate" which you'll find in the FSUIPC SDK. Please also always state which versions you are using -- version of FS, version of FSUIPC, and, if used, version of the .NET DLL. Provide the full version numbers. Pete
  15. FSUIPC itself never tries to "control" AI. That's just a facility for external applications -- RCV4 in your case, AIseparation for others (or both of course). Pete

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.