Pete Dowson

You appear to have all sorts of serious errors which I've never seen before. But the log shows nothing going wrong for a long time! the first error logged is after 3212 seconds (over 53 minutes!). The "couldn't allocate buffer" message is also most peculiar (I've never seen it do that before either), but then 126976 bytes is rather a lot -- the largest block normally handled by WideFS is 31000 bytes. What are you seeing happen "after a few minutes only", just that message box? I've never seen that before and have no idea what it means I'm afraid. That is something in the run-time library installed on that PC. You say: What does "stopped manually with the mouse" mean? I don't understand that. And if you'd "stopped" it, how is it carrying on for 53+ minutes? What operating system are you using on each client, this one in particular, and the Server? I don't think the Server should be throwing up those errors: Provided it gets at least one of the two protocols it shouldn't be raising any errors for the other -- but i'll double check that here. I assume your other clients are okay, so do you mind telling me what's unique about the problem one? Is it, do you think, related to the applications you run there (try moving them and running something else, just to see)? Or is it something different about the operating system, memory, and so on? Regards, Pete

Strange. I've not heard of that one. Can you try again then show me the FSUIPC.LOG file you'll find in the FS Modules folder? Regards, Pete

Since you can reproduce the flashing Advdisplay text so reliably, perhaps you can help nail it, or at least work out whether it really is the video drivers or something in the PMDG code. In the FSUIPC Options, find the Logging page and enable IPC Write logging. Now reproduce the error. Don't make a long flight, please -- in fact best to stop after you've made the error happen (say, langing lights on, see error, landing lights off, close down). ZIP the FSUIPC.LOG file you'll find in the FS Modules folder and send it to me at petedowson@btconnect.com. Next time you load FS don't forget to go into Logging and turn the IPC write logging off, else it will gradually fill your disk! :wink: One other thing to try. Right click on the AdvDisplay window and set it to operate with multiple lines only -- this should filter off single lines (to the normal FS display) leaving multi-line usdes such as Radar Contact. Let me know, please. Regards, Pete

Okay, good. And you set the value to 2 (or whatever) and length to 1? Regards, Pete

Hmmm. What does 2^1 mean in VB? In C it would give 3, as ^ is the "exclusive OR" symbol. In my document it is just used as a power indicator, "2 to the power of 1". As I said in my last message, that is 2, so just set it to 2. To work out powers of 2, take 2^0 as 1 then multiply by 2 for each power higher. So, for instance, 2^3 is 1 x 2 x 2 x 2 = 8. The sequence goes 1,2,4,8,16,32, etc. Your FSUIPC_Write is wrong as well. You didn't read my last message very well I'm afraid. I said you write 1 byte, not 2 as you have there. As for that VarPtr stuff, sorry, that's a VB peculiarity which I have no idea about. I would have thought you'd have to derive the address somehow -- look in your VB books. The error "ByRef ..." sounds as if it is to do with that. How did you manage to read or write the other stuff you said you'd handled? As for providing it in C, that would most certainly confuse you even more judging by the VB example! :wink: Sorry. I'd better butt out now and leave it to VB folks! Regards, Pete

I wrote to them about then and asked them, and they said they couldn't reproduce it. I think this is the main problem. I expect if either they or I could reproduce it we could track down what is going on. Is your Advdisplay window locked or docked? if it is docked, can you look at the Advdisplay section in the PANEL.CFG file for the panel, and see what it is docked to, please. Better, show me the section entirely. If it is docked, see if it happens with it "locked" instead. That's why I thought originally that it must be something in their code that was somehow interfering, but if it is I don't understand why it is so rarely occurring (or at least reported), and why we can't reproduce it at all. Regards, Pete

Well, with most things you would have the read it, change the bit (or bits), then write it back. There's no other way. However, for this particular offset, the documentation does explicitly say "Write bits to operate toggles. Don’t bother to read it, there’s no meaning to anything read." Here it just means write a value with the required bits set and the others not set. So, just write a 1 byte value with the appropriate bit or bits set. i.e. for, say, NAV1 (bit 2^1), write a 1 byte value of 2 (because 2^1 = 2). If you want to operate all four swap buttons together you could do by sending 15 (2^3 + 2^2 + 2^1 + 2^0). In general, though (not in this case), you'd need to read the value first. The light switches at offset 0D0C are like that -- they are 1 when on, 0 when off. To turn one on you'd read the 16-bit word, logically OR in the bit value for the light you want to turn on, and write the 16-bit word back. To turn one off you'd do it similarly, but AND the value read with the "NOT" of the bit -- i.e. with a pattern containing all bits set except that one. I cannot give you VB examples, I don't know VB, but check in your VB manuals of documentation and find the logical bit operations. All programming languages provide OR, AND, NOT and even exclusive OR (XOR) which I won't explain here, as well as shifts left and right. They just use different symbols or names. In C the logical bit AND is &, OR is |, NOT is ~, and XOR is ^, whilst shifts are << (left) and >> (right). But they'll be different in VB. Regards, Pete

No, we didn't understand that before. It doesn't happen here and PMDG couldn't reproduce it. I can only think it is specific to particular video cards and/or drivers. Try windowed mode, try 2D panel instead of VC or vice versa, try different options in FS (eg render textures option). If we could get the two folks reporting this together to say what video cards and drivers they are using then maybe there'd be a clue. Have you looked on the PMDG forum to see if there are others there? Regards, Pete

Other aircraft aren't "showing up" where, in the FS aircraft menu, or are you talking about AI aircraft on screen or multiplayer? FSUIPC doesn't have anything to do with the appearance of aircraft in menus or on screen. If you have problems with multiplayer (as used by Squawkbox for instance) I'm afraid you'll need to ask elsewhere as it's an area I know nothing whatsoever about. And AI aircraft are to do with scenery files -- if they aren't showing up it's more likely due to your scenery library file not pointing to wherever your AI traffic BGLs are. Regards Pete

The thing with the landing lights was reported once some time ago, but neither I nor PMDG could reproduce it. I think the original person reporting it was using an older version of the aircraft than either of us, so it might be worthwhile trying an update. I can't really imagine how the landing lights can have anything at all to do with text displays in a completely separate window, but I presume it's something to do with video drivers and complex interactions at that level. Regards, Pete

Do you mean "FSInterrogate", as supplied with the FSUIPC SDK? If so, then of corse that only includes those locations documented in the FSUIPC Programmer's Guide and populated by FSUIPC. The use of all the private user application areas is entirely a matter for those applications. It would be nice if application writers did provide FSI files for FSInterrogator to support their products, but this would only be meaningful in those cases, like PM, where the interface is open for programmers to use. As it is, for PM, you have the PM Offsets document on the PM documentation web page, and the SYSVAR lists in the pmSystems package. .That's not true. You can always read them -- write them too for that matter. FSUIPC does not prevent anyone reading or writing any of the application-allocated offsets, but of course they are really only of any use if the application is actually running. What do you mean "not known"? Of course they are "known". They are known simply as offsets in the memory it maintains (and communicates via WideFS) for the applications which have 'claimed' them, whether this be PM CDU, PM PFD, PM MCP, PM Systems, or any one of many other applications. You can write to them and read from them at any time. There is absolutely no restriction. but if nothing else is running which uses them, it will be just your program talking to itself, won't it? You are severely misunderstanding something most fundamental if you think that. You can write a value to 5602 and you can read that value back. What makes you think you can't read it? Are you getting an error? Why are you so convinced that there's anything complicated going on here? It's just a repositary, a way for two or more things to communicate. If you're only running one program, what are you trying to communicate with? Regards, Pete

The only thing I can think of is that it is hanging on the Epic access. Try running it with the EPIC driver removed -- EPICINFO actually can be run with no EPIC, just for logging purposes for instance. If it runs okay with no EPIC then it is likely to be some clash there. I'm afraid you'd need to seek support from the EPIC folks then. I don't really use EPIC these days and, apart from making it work with each new FS release, I've not worked on EPICINFO for years. The other thing to do is check the contents of the EPICINFO log file. I'll look up one of mine so we can compare. BTW please always mention version numbers -- Version of EPICINFO and FSUIPC (the latter is needed by EPICINFO). Regards, Pete

Received via Email along with files as requested: Aha! This line is the clue: 75735 Module "FSFlightVentures.dll" access registration is okay If you remove the FSFlightVentures DLL you will see there's no problem. There's a little bug in the FlightVentures DLL (resulting probably from a misunderstanding in my rather brief documentation of some of the more complex FSUIPC interface features) which actually falls foul of a correction to a bug which was present in FSUIPC 3.40 and earlier. Both of us have actually "fixed" it recently. The author of FlightVentures has fixed it, and also I've changed FSUIPC too so that it copes with the way FlightVentures was coded. I don't know if the FlightVentures fix is out yet, but meanwhile I have emailed you an interim test (read Beta) of FSUIPC (version 3.426). Please be sure to replace this with the official release (3.43 I expect) in early December (I hope). Regards, Pete

One thing which will do exactly what you say, and that is if your FS9.1 installation is actually a mixture of FS9.0 and 9.1. You can check the modules using the list I posted in my FS9.1 announcement at the top of this Forum. I've fixed FSUIPC for such mixed up 9.0/9.1 updates but the new version isn't ready for release yet -- hopefully 6th December or so. If the FS9.1 update looks complete according to that list, then please try again, then Zip up the FSUIPC.LOG and FSUIPC.KEY files (from the FS Modules folder) and send them to me at petedowson@btconnect.com. I should be able to work out what is wrong from those. If you miss me tonight, I'll be out all day Saturday at the UK FS show in Birmingham, but I'll get to it on Sunday. Regards, Pete

No, sorry. GPSout is actually an FS DLL (module) which only runs inside FS. It pre-dates FSUIPC by quite a way and probably WideFS too, though I can't remember that long ago I'm afraid. A program could be written to run through the FSUIPC interface. I don't think GPSout uses anything which is not, nowe, available from FSUIPC. But it is another separate job and not one I have time for at present I'm afraid. What would be the reason for this, by the way? I don't think GPSout has any measurable affect on FS performance, that is not unless you are asking for a lot of data (too many sentence options) and you are also setting too slow a line speed and/or too short an interval for updates. For the usual need, 2 or 3 sentences once a second, the default 4800 bps should be fine, but try for the highest speed your receiving program can be set to. Currently I use something like 115200 with FliteMap. Regards, Pete

Ah, sorry. Missed that. Easily done when you are only looking at additions to the end of the thread -- your earlier one must have crossed with mine. Anyway, glad it is sorted. Shame it isn't automatic though. Regards, Pete

That's exactly what slew mode is -- yet you say you've tried that with no difference. The other ways include pause mode and setting the simulation rate to zero. I think the only way you will get it relatively smooth is to try to synchronize FS and your update rate. For instance, if your updates are regulated to 20 per second, set the frame rate limiter in FS to the same. No idea what coordinate system is used, but the best scenery uses satellite data to position things, so I guess the system is the same as whatever the satellite data is using. If you are talking about specific sceneries, then whose are you comparing it to? Most good add-on scenery is a lot more accurate than the defaults. Regards, Pete

What was wrong? Was it a manually entered key, listed in the documentation? Regards, Pete

Have you checked with PortMon as I suggested? Is perhaps Windows doing some unwanted power management on the USB subsystem -- I have heard that can cause problems. Also, the first time I tried a USB serial adapter on a PC with Windows XP, the exchange of data dried up and stopped after a number of minutes. This wasn't with GPSout, but my PFC equipment driven by my FS PFC driver. It worked fine under Win98. It turned out, eventually, to be the drivers supplied with the serial port USB adapter. Although they purported to be suitable for WinXP it seems they were designed and tested in WinNT4 days and obviously didn't work properly in XP. I found later drivers which then worked fine and have done ever since. In fact, once you get a good adapter with properly working drivers they are better than a "real" serial port! Even stranger that in over six years of GPSout's availability no one has had this problem before, or at least no one has mentioned it. No, please check things out with PortMon and investigate your drivers. All the code used in GPSout for driving serial ports is rock solid basic Windows API stuff which has seen good use in at least a dozen of my programs over more years than I like to count, including Fax software which is very testing of serial port usage. Regards, Pete

GPSout relies only on being woken up by Windows at the intervals you set. It's always worked fine for many years with no changes to this. that sounds more like something queuing or blocking on your serial port. Are you using a true serial port or a USB with serial adapter? The only changes which have been made to GPSout over the years have been to add additional sentence options (such as the AV400 format) and to correct the course from the bearing when it was found that the GPS course from FS was suspect. Nothing has been changed in either the way the timing is set nor in the actual serial port handling for about six years -- ever since it was written, in fact. It really does sound like there's either something wonky with the serial port you are using or with the receiving end. Try checking the GPSout activity on the port with PortMon (a free utility from http://www.systeminternals.com) and also try port another if you have one. If the output from GPSout looks okay with PortMon (and it is easy to see it all with that utility), then you will need to investigate your receiver. What's "Error 34"? What reports that? Doesn't it say anything else? Having the original disks isn't as important as having an original installation. The update doesn't look at your disks. Regards, Pete

It's actually Enrico Schiratti's site. I just downloaded and checked, and you are correct -- although Enrico has written it up as 1.90, he hasn't actually changed the ZIP for the new onle I sent him in July!!! I'm sure it used to be okay. I think he must have slipped up when he trasferred all the Schiratti sites to new Servers. I'll write to him and get it sorted. Thanks! Pete

I think ActiveSky controls most of those options. including wind smoothing, in any case, when it is running. Have you checked the ActiveSky documentation? Regards, Pete

Hold it there first. What does that mean? "loading the information on the flight yoke ..."? Have you calibrated your flight yoke in Windows, or in the CH driver? Get it working reasonably well in FS before even attempting to do anything in FSUIPC. All FSUIPC offers is more accurate end and centre points with possibilities of null zones, response curves and filtering. But the input values need to be reasonable to start with, otherwise you will have problems. Delete your FSUIPC.INI file, or at least the section for Joystick Calibrations. Calibrate your yoke properly in Windows. Load up FS and make sure the assignments are correct and the sensitivity is high and null zone low. Test it all to make sure it works. If you cannot get this far you need help from CH, not me. THEN try calibrating in FSUIPC, following the steps in the documentation. If you come back for more support please always state the version of FS and the version of FSUIPC you are using. Regards, Pete

Well, there's no attempt whatsoever by the program to provide a Key. Please re-check the documentation. Possibly the author intended users to enter the Key manually. Else, either it is the wrong version (possibly an FS2002 version?) or a mistake has been made by either the suppliers or author. Please feel free to cut and paste this entire message and send it to them in your request for assistance. If I can find the author's email, I will point him to this thread as well, Regards, Pete

Good, glad you resolved it. Regards, Pete