Pete Dowson

Here's some of your confusion. Just because the FSUIPC offsets are documented and known in hexadecimal doesn't mean that they can only be addressed in hexadecimal. That's merely a convention. It's a number. You can express numbers in a lot of different ways. The offset &HF080 is the same as decimal 61568 or binary 1111000010000000 or octal 170200. Inside the computer they are all the same! You simply use the most convenient format in your program, the compiler converts it all to internal representation. This is all basic fundamental computer science, something which should be in the first chapter in any programming book, even one on VB. Why on Earth are you copying from one place to another? Why not simply USE the data where it is? I don't understand your obsession with making copies of everything. It is so wasteful, and anyway completely irrlevant to anything to do with the FSUIPC interface. Once you have the complete array of 96 slots in your program, do with it as you wish. That part is entirely your concern, that's YOUR program. I don't mind helping ith the FSUIPC interface, but everything else is yours. I thought you said you'd written programs already? Regards Pete

I think you must have posted in the wrong Forum? Pete

Good grief! Can't you read the whole set in one statement? Why not replace all that with If FSUIPC_Read(&HF080&, 3840, VarPtr(AI(0)), dwResult) Then If FSUIPC_Process(dwResult) Then I really cannot see how the compiler knows what the 3840 means, compared to the 40, and it is the FSUIPC interface code which is filling the bytes in, so why not read all 3840 in one statement? And why use strings for numbers anyway? What's wrong with CurrOffset = &HF080& + (i * 40) Something's getting very very muddled here. I've never known any programming language in which you have to give literal numbers in strings when you are operating on them arithmetically! Pete

In that case I'm afraid I've no idea where your "zero" readings are coming from. SimConnect and interception of axes doesn't come into it with that route, and as I say FSUIPC doesn't create its own values to send. Maybe you could enable Axis logging in FSUIPC (Logging page) so we can see what FSUIPC traps as being sent to FSX. I'm not sure how you are measuring this "zero" raw value in any case? Regards Pete

Well, I more or less gave you it. With TCAS_DATA tcasAirBorne[96]; declared, the Read call would simply be: FSUIPC_Read(0xF080, 3840, (BYTE *) &tcasAirBorne[0], &dwResult); or even just FSUIPC_Read(0xF080, 3840, (BYTE *) tcasAirBorne, &dwResult); because C/C++ uses the address of an array when its name is used, though I like to explicitly show I'm taking the address (&...) of the first element of the array ([0]) because i think it is less ambiguous when reading it. The (BYTE *) casting probably isn't needed either -- the prototype for the call specifies this parameter as a "void *" (pointer to a void), meaning what it points to doesn't have to be typed. However, again, I don't like the possible uncertainty, and when the call gets to where it is going it is being cast into a BYTE pointer in any case, so it can be copied across into the shared memory block. Pete

Most of the capitalised types are Windows API types, declared for C/C++ users in Windows.h or one of its subsidiary files. DWORD is simply an unsigned 32-bit integer, much as WORD is an unsigned 16-bit one and BYTE is an unsigned char, or 8-bit quantity. I use standard Windows types (as opposed to C/C++ types) a lot, because much of programming for Windows, and FS, uses API calls which declare them for their parameters, and it saves having to use casts all the time. I seem to remember from other VB users that "&HF080" is actually changed by VB's compiler into &HFFFFF080, which is no good. Even giving it as &H0000F080 seems to be no good. I think you have to use a postpended & to tell the stupid compiler not to mess about, thus: &HF080&. But please check this. I'm only vaguely remembering it. Really you need to talk to someone who knows a bit about VB. This isn't FSUIPC programming. Not sure why you have to copy data from one place to another. And I don't understand the syntax of these assignments at all. Why can't you simply use the data as it is, in the Array? Why so ccomplicated? Well, sorry, I can't help with that at all. All your troubles are now with understanding VB, more than FSUIPC. You need to read up some more, maybe, or hope for some VB guru to come along. Maybe you should now formulate all your VB questions and post in a new thread with "VB Help Please" some place in the title. We do get some helpful VB experts popping in here now and then, but they won't be enticed by the current thread's title. Regards Pete

Well, i don't know VB, but aren't their Strings fundamentally different in storage to standard ASCIIZ? For example, don't they start with a length byte instead of ending with zero? And I seem to recall that by default it uses either Unicode or wide character format, not ASCII. You may need to declare that field as an array of 15 BYTES instead, to be safe, then convert it to a VB string afterwards. After that, provided Integer is definitely 16-bit ("WORD" is a Windows type defined as "unsigned short"), and provided VB doesn't pack any extra bytes between any of the fields, it should be okay. I suspect VB doesn't support "unsigned" types -- if not, take care with the heading as you'll get that in the range -32768 to +32767 (representing -180 to +179.9999), so you'll need to correct for that to get the proper unsigned range, 0-359.9999. If you can declare an array of 96 of those structures, and read the complete 96 x 40 bytes in, you have all the data to hand. read it at, say, 1 second intervals (normal TCAS scan rate) and you should be fine. Regards Pete

I'm afraid it is looking rather like a hardware problem, possibly something on your motherboard as it appears to be affecting both COM and USB ports. Before rushing to replace that, however, there's a chance that some installed driver, maybe for the DSL connection you had changed, may be clobbering things (e.g. trying to share the IRQ and failing), so you could try a process of uninstalling the Network / DSL connection altogether to see if that brings things back to life. However, this isn't something to be taken lightly and if you are not totally confident of being able to reinstall everything and get back on-line I wouldn't start. I assume you've tried alternative USB sockets? Do you have any USB devices which are working at all (oher than simple LED lights, which only use the power line, of course). Maybe you can plug your mouse into one and see if that still works? You might try to find a hardware help forum, but in the end you may need to take it to a commercial company to get them to diagnose the problem and fix it. I cannot see how us software types can help a lot, at least not without access to your machine. On the specific observations: Unfortunately many folks find that uninstalling and reinstalling FSX clobbers the Simconnect system, essential for FSUIPC and many other FSX add-ons. The problem is that uninstall doesn't properly uninstall SimConnect, as it is then part of the Windows SxS (Side by Side) library system. Then it doesn't get instaled correctly. Help for this is given in the FSX Help announcement above. Really none of your symptoms were at all related to FS or the PFC or GoFlight drivers in any case: Yes, this is what it looks like when there's no connection. Something en route is broken. Regards Pete

Doesn't look like it helps there with structures, does it? I just Googled for "structures in VB" and found these two which may help. http://msdn.microsoft.com/en-us/library/78kf2xd4(VS.80).aspx http://weblogs.asp.net/pleloup/archive/20138.aspx The first most certainly seems to indicate that VB supports structures and arrays of structures. I don't know VB at all. Don't you have any reference material you can read? Erplease re-read my last message, in which I declared the data area for reading, the offset and the size. You seem to be skipping things! Please read what I write otherwise we will get nowhere. We? I am not confusing them, and you must not either. Your program will never work if you don't take care to use the correct types and not mix them up. Bits are not bytes! Pete

What do you want to achieve with limited sensitivity? That is an ambiguous term. Does a more sensitive axis give finer control (one interpretation), or does it make things change faster (so, coarser control)? Do you want to be able to access the full possible range of movement of the aircraft's control capability, or put upper and lower stops on what it can get to? FSUIPC's calibration is designed to ALWAYS achieve full control, from minimum to maximum FS capability. So if you aim to prevent, say, full throttle, or full elevator up/down, etc, then I'm afraid FSUIPC will defeat that objective every time UNLESS you use RAW input in FSUIPC's axis assignments, then, after calibration, alter the calibrated values in the INI file so that the min and max values it uses are outside the axis's RAW range. That makes the FS extremes unattainable, as the RAW values can never get there. (You could achieve the same without using RAW mode if the normal non-raw axis inputs are substantially less than 16380 -- that depends on their drivers and what happens in Windows calibration, which would normall scale them). This cheat is, however, thoroughly NOT recommended. In my opinion you must ALWAYS be able to get to all possible settings FS allows. So, it comes down to whether you want finer control in the central areas, or courser control. For that it has to be adjustment of the slope. The extremes are "tethered" to achieve the full range, but the spread is placed to give you the "sensitivity" (in whichever possible interpretation you meant it) where you want it. Incidentally, as far as I can tell, FS's own "sensitivity" is basically a divisor -- it divides the value it receives from Windows calibration by a different amount depending where it is. Effectively the lower you set the slider there, the cheaper and more granular you are making your joystick -- so you can buy a really expensive joystick with maybe 256-512 step resolution on each axis and make it operate worse than one with the usual 32-64 steps (or even less) you can pick up in a toyshop. This is why I always advise setting that at maximum. Regards Pete

Sorry, what exactly IS "the next airplane? The table contains details of up to 96 aircraft. Each slot can contain details of an aircraft, or it can be free. As aircraft come and go slots get freed then re-used. You can tell when slots are used or not and when they change from the ID. There is no such thing as a "next airplane". What sort of idea is that? And what do you mean by "not fair" in this context? Of course there is. Where are you learning your programming? Structures can be of any length. Just define the structure as documented for you. That's most of the programming already done! And why are you referring to 32 bytes? Neither of the tables have 32-byte slots. One is 40 bytes per slot, and the other is 20 bytes per slot, as clearly documented. Assuming you only want the data in the main Airborne table, the 40-byte per slot one, all you'd need to do is declare your array: TCAS_DATA tcasAirBorne[96]; then read into it (i.e. to (BYTE *) &tcasAirBorne[0] ) 96 x 40 (i.e. 3840) bytes from offset 0xF080. When that completes you have all the data in your own array of 96 entries and you can scan reading the id's, for example: for (i= 0; i < 96; i++) { if (tcasAirBorne[i].id != 0) // deal with airborne aircraft } I shouldn't really have to teach programming here. Regards Pete

I don't think that's FSUIPC4 -- it will be FSX. In order to make sure it doesn't intercept any axes not actually being used, since a few versions ago it doesn't intercept (nor therefore calibrate) any axis until it sees an input for one. It can't stop that first one going through as it isn't intercepting at that time. So, until you move the axis, FSUIPC4 isn't actually interfering with it at all. That was the only way I found to deal with some of the peculiarities of SimConnect and how they affected some of the sophisticated add-ons, like the Level D aircraft.. The interception is reset whenever you load a new aircraft in case you use different axes with it. The one way to stop this to is bypass both FSX and SimConnect and only use FSUIPC4 axis assignment, with axes directed straight ot FSUIPC4's calibrations. Then SimConnect isn't used, and there's no interception of axes needed at all (because none are seen by nor transmitted from FSX). Hmmm. If that's the case, then the explanation I've just given cannot really be the reason -- unless the USB driver for that controller does feed values for all operating axes on that controller when you move just the one. FSUIPC's own axis assignments doesn't take any notice of unchanging input values, it only acts on them when they change. This makes it much more efficient than the regular 6 per second readings FS performs, and it means it can operate faster when needed. However, it too may be contributing to what you observe. It puzzles me as to why you'd get a zero input. There's never anything in FSUIPC which creates an input value. It either intercepts (or reads) and calibrates or it doesn't. So I don't really understand where your zeroes are coming from. It might have helped a little to understand if you'd described how you are dealing with the axes. There are several combinations, different paths through FSX and FSUIPC4. Regards Pete

Does FS9 do that, or is it supposed to be a function of the Level D 767? Parking brake key? "Ctrl+." you mean? That would toggle the Parking Brake on, so tapping is the same as holding it down -- or do you mean just the Brakes (.)? The latter sounds more likely to me. Maybe something is watching for the BRAKES control and not the AXIS LEFT and RIGHT BRAKES controls, which would be used by the pedals. I don't see how calibration would change anything, that's for sure. Of course, if you assign them via FSUIPC you can also assign a Control to be sent when a particular range is entered on the axes, so you could get it to send a BRAKES control (if that is what is needed). Better to send a Left Brake for LEft and Right Brake for right, if they work -- you could test those by "tapping" F11 or F12. What about the defaults? I really don't know if this is an add-on function or not. If it is built into FS (which I don't really think it is), then it sounds like there's something about the way the LEvel D is intercepting things which is stopping that happening. More likely, though, it isn't an FS9 function and the implementation on the Level D is only taking note of the Button/Keypress Brakes control(s) and not the axis ones. Regards Pete

As you will see from the data definitions 9the structures in the documentation, yes, the one field which needs to be an ASCII string is an ASCII string, but its only the one. Well, writing is the same as reading except you supply the data and use a different command. But there's certainly no writing involved whatsoever in READING traffic data! Where do you get that idea? Sorry, what is this about? Please be more specific. The structures are most certain of a specific length, each variable in them is defined by the language they are shown in. And the size of each slot is defined. What are you reading? You seem to be reading something completely different! I've never had so much trouble with such simple things! Have you done much programming before? Which is fully defined in the documentation if you'd only read about it! :-( Please, if you are going to misread documentation, at least be specific so I can see what you are reading. It evidently isn't the parts in which I describe this facility. Regards Pete

Er, do you have the FSUIPC SDK? If not download it. Inside you will find a "Programmers Guide" document. There's sections near the front describing the structures I mentioned. Structure definitions include variable types, of course. The offsets are listed -- there's a large table of all the offsets and you'll find the ones you want in there. I really thought you would have looked first. It makes sense now that your earlier questions were so, basic and confused. You should really use the tools provided, including the SDK. Get it from www.schiratti.com/dowson. Of course not. Why encode stuff like Lat/Lon/Alt/Hdr etc in string format? There's not enough space as it is! That would be very inefficient! Pete

Yes, as you already said I think. All that is available for AI traffic (though not necessarily tail number -- it's a user option. Mostly for commercial flights it would be airline and flight number. Whether on-line MP traffic injectors provide all that or not I don't know. What took a long time to load? The traffic, TrafficLook, or the data in the display? It appears as it is available -- the traffic build up in FS is not instantaneous in any case. I'm not at all understanding what you mean. Nothing takes very long on any system I've ever used it on. Really? Why on Earth longer than one second? Most TCAS displays using FSUIPC work very well much faster than that. What is the problem? Yes, of course, as I've said (several times already?). FS can only read AI traffic details from FS. Eryou read the tables in FSUIPC, if you want to use FSUIPC. I am really bewildered by your questions. You ask about reading traffic data from FSUIPC, I point you in the right direction, then you ask me if you have to read it to get the information you want? Sorry, this is nonsense questioning. Please, can you try to be more specific? No. Why do you think that? Where would you supply a "slot number"? What are you reading which even suggests such a thing? All the traffic data is laid out in 4 tables in FSUIPC's offsets -- 2 for ground traffic, 2 for airborne traffic. There are only so many slots. When a slot is freed (because the aircraft leaves the area or transfers from air to ground or vice versa, that slot may be reused. You can tell which slots are used by the non-zero ID. The two tables for ground (and also those for airborne) have the same slot allocations -- it should be one table but as more data was added the space ran out, so one table is just an extension of the other. Why? There's lots of information provided in the Programmer's Guide, including the structures to use to define the data format for each slot. All you need is an equivalent set of arrays of structures in your program to read the offset data into, maybe all in just the 4 reads, then deal with the contents as you like. This is effectively what TrafficLook does. Pete

Nice. For multiplayer on FS9 or before you have to be sure the on-line link program injects the data into FSUIPC's TCAS tables. I think Squawkbox 3 does. Not sure about the IVAO programs. There was a program called AIBridge which did it for previous programs (that's by Jose Oliveira). For FSX I think the on-line flying programs create AI traffic instead of using the MP interface -- if they do they should be already sorted. Well TrafficLook will allow to corroborate what you are reading with what it sees. Of course you can also use FSInterrogate to show the TCAS tables areas in FSUIPC offsets. I can answer specific questions if you stumble over anything. Regards Pete

Yes, I don't think one specific unit can be "shared" as all the LEDs are controlled by the same command. Regards Pete

Copy and paste from someone else's bad code you mean? Regards Pete

Download and check through the FSUIPC SDK then. Maybe one of the languages supported by contributing enthusiasts may appeal to you? You'll need full information on programming the displays you have too, though. Regards Pete

If there's nothing else driving these LEDs, and it takes several minutes to change, then it seems to indicate that the trigger is changing -- i.e. the bits in offset 5678. Use the FSUIPC Monitor facility (on the logging tab) to see what is happening to those. Are you sure they're correct? Pete

I don't know VB, but don't "" normally enclose a string? If so, then all these are wrong: A string "0" is NOT the same as an integer which is zero, nor (for 32FA or 1274 a 2-byte (16 bit) value which is 0! "0" is certainly not 0! Why are you writing to 1274? That is an FS menu option. I'd delete that part if I were you, in any case. It isn't part of this facility. And here: it is very inefficient to write 128 bytes when the string is a lot shorter than that, and may cause your program to crash if the undeclared bytes are not in accessible memory. Do you have any VB programming books you can learn a little more about it from? Regards Pete

Sorry, but you've wasted your money buying FSUIPC, then, as it doesn't drive displays. It never has been a hardware driver. If it is the FSUIPC application programming interface you were interested in, that's free in any case for personal use or for freeware applications. You can't. There are no facilities to drive displays. FSUIPC is not and never has been such a program. You have to be a programmer and write your own program. You'll need to get yourself some books on pogramming, then refer to your hardware manual for your display and the FSUIPC SDK for the interface. The user facilities you pay for when you buy FSUIPC are all described in the user manual. If what you want to do is not described there, it doesn't do it. Regards Pete

You should have mentioned this to SimMarket. They should still be able to sort it out for you if you raise a problem ticket with them. Otherwise you can send me all the details -- full details of both FSUIPC and WideFS registrations, and I will update the FSUIPC one for you. Send to petedowson@btconnect.com. Regards Pete

Sorry, I'm not sure i understand you. If you mean to have separate bits for up to 4 pumps, then how do you expect to accomplish this? FSX only provides one switch! Maybe FSXI or ESP2? Regards Pete