CATIII

Good evening, since my collegue added a steering tiller to our flight deck, I wonder how to control this via FSUIPC in FS2004. The tiller is connected as an analog axis via EPIC-USB to a control computer on the network. There, all EPIC inputs (digital and analog) are analysed and converted to FSUIPC commands to the MSFS computer. While browsing through this forum, I found that everybody had connected their tillers directly to the MSFS computers and calibrated it inside the FSUIPC form. Since this approach is not suitable for our setup, what is the correct offset for driving the tiller? Is it 0x0C08? Is there another one that I missed? Of course, then we cannot use FSUIPC's tiller functionality (like effectivity of rudder/tiller until 60 knots). This will be done in our control software. Thank you for any hint! Best regards, CATIII

Great, your post clarifies a lot to me. If I get you right, the tiller only uses the rudder to accomplish turns on the ground, i.e. the tiller control cannot accomplish tighter turns than with the rudder. I will then write some code as you suggest and use the rudder input 0BBA for the tiller. Ciao! --CATIII

Hi Pete, in the latest FSUIPC 3.85 for FS9 I noticed a new offset at 0x0C08 for the steering tiller. Is it possible to write values there? We have a B737 steering tiller here with a poti which is connected to an EPIC analogue input. Calibrating it in the FSUIPC menu is not an option for us since the EPIC hardware is not connected to the computer running FS9. Everything in FS is controlled via FSUIPC_Write() calls from another host on the network and this would be our approach in controlling the steering. I hope my description is not too complicated :roll: Best regards, CATIII

Dear Pete, here comes an interesting problem which is IMHO related to the NWI facility or to the weather processing code of FS2004 in general. Weather setting and reading is done here from a separate host on the network running WideClient. For this we're using NWI through a self written Delphi GUI. Everything works great EXCEPT setting of wind direction in upper layers. I'm always writing 3 wind layers [1..3] altogether with all necessary properties. After hours of testing I found the following phenomenon: If the wind direction of an upper layer (let's say no. 2) is numerically smaller than the previous one (no. 1), it gets screwed up and has (nearly!) nothing to do with the original one. Or to say it in other words: as long as the wind direction of the next higher level is greater than the one in the lower level, everything is fine. Winds can only shift to the right in the next higher level. Shifting to the left (smaller direction values) are not accepted by FS. Below you see some results of tests that I made with FSInterrogate2. Of course I checked my software for probable mistakes, but the values which I send are identical to those which FSUIPC receives. FSUIPC Offsets Test1 Test2 Test3 Test4 Test5 Test6 ============================================================================ Wind Layer1: Written (C902): 107 240 251 163 200 200 Last Set (C502): 107 240 251 163 200 200 Current (C102): 107 240 251 163 200 200 ============================================================================ Wind Layer2: Written (C912): 115 270 189 133 110 270 Last Set (C512): 115 270 189 133 110 270 Current (C112): 115 270 313!! 193!! 290!! 270 ============================================================================ Wind Layer3: Written (C922): 178 293 138 143 80 90 Last Set (C522): 178 293 138 143 80 90 Current (C122): 178 293 240!! 143 140!! 90?!?!? Tests 1 and 2 have no exclamation mark, they work fine since the wind direction in the next higher level is greater than the previous one. Tests 3, 4 and 5 clearly show the problem. The resulting values (which are current in FS9) are NOT identical to the written values. It seems as if FS takes the difference in direction between no.1 and 2 and just ADDS it to the no.1 direction. In Test 3: 251-189=62. 251+62=313. 313 degrees is what I get in no.2, but I want 189°. FS should take my absolutely supplied value and NOT just add the difference. From my point of view I'm stuck in a blind alley now. There's no way for me to work-around this problem. Since you're the one who has the insight and experience with MS and FS, I'd like to ask if you know any solution for this dilemma. Let me know if you need more test results from me. I'm really interested in finding an acceptable solution. Thank you very much for your help in advance. Best regards, CATIII FS9.exe 9.1.0.40901 FSUIPC.dll 3.7.6.6 WideServer.dll 6.7.5.0 WideClient.exe 6.7.5.7 WeatherSet2.exe 1.4.0.0 PS: And last but not least: all smoothing/fading/changing facilities in FSUIPC are disabled.

Jeroen, in the file "NewWeather Readme.txt" in Peter Dowson's FSUIPC_SDK you find the following paragraph: CC00-CFFF (Area 3): Weather reading area [NOTE IMPORTANT CHANGES HERE in FSUIPC >= 3.50)... the NWI facilities have changed in 3.50 and you have to adjust your weather reading procedure accordingly. Hope this helps. Bye! CATIII

Dear Pete, currently we're using both Project Magenta and self-written EFIS software in our sim. We do quite a lot of training for line pilots as well as maintenance engineers. Everything is fine except when it comes to properly simulating different kinds of engine failures. As you certainly know, most jet engine parameters provided by FS are not really realistic. N1, N2, FF, EGT are the most important candidates. So much for that. Since you were able to implement the great and really useful 'position freeze' feature in FSUIPC, I kindly ask if there is a chance to be able to override these (mostly read-only) values in FSUIPC in some way. I think this is the most generic approach that results in proper indications on all client applications which display FS values. For the time being I'm overriding all values 'artificially' by writing to some 'read only' offsets like for example 'oil pressure Eng 1'. This works for most offsets (not all engine params) but only if my application is at least twice as fast as FS' own framerate. This action is (of course) very, very dirty. In addition, sometimes FS & FSUIPC are faster and I get unwanted 'runaways'. We have original manufacturer's data for the engines we're using and all the data is readily available in our application. But instead of blindly throwing all the data on the FSUIPC bus permanently, I prefer a more gentleman-like way ;-) Last but not least, I can not pre-estimate the complexity of this request and if it's actually possible. Furthermore, our sim is mainly used in a commercial environment. Let me emphasize that I don't(!) ask to spend your time for free. We're aware of the fact that the constantly good work you deliver (for years) deserves some kind of financial compensation. We shall discuss this on an e-mail basis (BTW: what is your email address please?) It would give us great pleasure if we can come to an agreement. Have a nice week and best regards! CATIII

Dear Pete, have some trouble when inserting planes into the TCAS table. I write a completely filled TCAS_DATA structure to 0x1F80 with the size set to the value read from 0xF000 (always 40). The traffic appears fine in your TrafficLook utility but NOT on Enrico's pmTCAS application. This app displays all traffic except mine :-(. Did I miss something important? The only difference to "real" AI aircraft is that my traffic does not have a TCAS_DATA2 structure... Thank you for you input! Bye, CATIII

No ;-)

You can fail engines by setting bits in offset 0B6B: TempByte = 0 TempByte = TempByte or Bit0 <= fails Engine No. 1 FSUIPC_Write(0B6B, 1, TempByte, dwResult) FSUIPC_Process(dwResult) For repairing the engine, use TempByte = TempByte and not Bit0 Good luck! CATIII

Dear Pete, I experience the following behaviour when writing a non-zero byte-value to offset 3541 (using FSInterrogate): The first flight freeze works perfectly. After releasing the aircraft (writing 0) it continues flying. But when I write a non-zero value to 3541 again, the aircraft is put back to the exact position of the first(!) flight freeze. I can do the same game over and over - the aircraft always returns to the first position. Am I doing something wrong or did I miss something? Thanks for enlighting me... Bye, CATIII PS: Just to let you know: the new versions 3.45 and 6.45 work perfectly in our environment. Former versions had trouble when the data queue built up and crashed. Thank you for that! Our simulator is really stable now.

Mick, some excerpts from my code (free to use but no guarantee): var Lat_FS, Long_FS: Comp; // $0560, 8 / $0568, 8 (in FS format) Latitude, Longitude : Double; FSUIPC_Read($0560, 8, @Lat_FS, dwResult); // Latitude of A/C FSUIPC_Read($0568, 8, @Long_FS, dwResult); // Longitude of A/C function Decode_FS_Latitude_to_Decimal(lat : comp) : Double; begin Result := lat * 90 / (10001750.0 * 65536.0 * 65536.0); end; function Decode_FS_Longitude_to_Decimal(lon : comp) : Double; begin Result := lon * 360 / (65536.0 * 65536.0 * 65536.0 * 65536.0); end; // Extract and display current position of aircraft Latitude := Decode_FS_Latitude_to_Decimal(Lat_FS); Longitude := Decode_FS_Longitude_to_Decimal(Long_FS); if Latitude &gt;= 0 then begin Label_Lat.Caption := 'N ' + FormatFloat('0.00', Latitude) + '°'; end else begin Label_Lat.Caption := 'S ' + FormatFloat('0.00', Latitude) + '°'; end; if Longitude &gt;= 0 then begin Label_Lon.Caption := 'E ' + FormatFloat('0.00', Longitude) + '°'; end else begin Label_Lon.Caption := 'W ' + FormatFloat('0.00', Longitude) + '°'; end; This should get you up and running... Bye, CATIII Edit: 'greater than' changed to 'greater than or equal to'.

Hi, I will leave it to Pete to interpret your log file but it seems to me as if you have to use a _registered_ version of FSUIPC/WideServer. Obviously, the unregistered version does not allow you to read the requested data. Cheers, CATIII

Mick, would you mind sending me your application project? Maybe I can find something... CATIII

Now it gets interesting... Are you running the app on the FS host or another WideFS-connected computer? What happens if you let the aircraft fly (maybe from another airport). Did you restart your computer recently? CATIII

Michael, something must be wrong with your application. Please run the attached example which works fine with my FS9.1. It uses your code. Best regards, CATIII FSUIPC-Example.zip

As an example: in case you want the airspeed from FS the programmers guide says: 02BC 4 IAS: Indicated Air Speed, as knots * 128 Therefore you have to do a FSUIPC_Read($02BC, 4, @IAS, dwResult); and for the conversion: Label2.Caption := IntToStr(round(IAS / 128)) + ' kt'; Good luck! CATIII

Try this: procedure TForm1.Timer1Timer(Sender: TObject); var dwResult : DWord; height : DWord; //$0020 has a value of 4 ?? (no value -&gt; length in bytes...) begin Timer1.Enabled := False; // avoids 'overlapping' of Timer events, suggest 50 to 100ms FSUIPC_Read($0020, 4, @height, dwResult); FSUIPC_Process(dwResult); Label2.Caption := IntToStr(round(height * 3.28084 / 256)) + ' ft'; Timer1.Enabled := True; end; You get the proper conversion factors from the 'FSUIPC for Programmers' document or from FSInterrogate. Ciao, CATIII PS: Why do you want ground altitude? A/C altitude is much more interesting: $0570(8)

Hi Michael, you may post some code snippets here which describe the problem you have more clearly. Ciao, CATIII

Hi Pete, let me try to explain some things concerning my last posts. My application often crashed after a few minutes of operation. However, the log file was saved from a session which lasted obviously longer. I didn't check that. Sorry! For time synchronization I'm using a self-written procedure that adjusts FS time and date according to local time when a button is pressed. This causes a wideclient crash with the latest test versions, so I must have a look at this procedure. After Wideclient doesn't run anymore (no blinking on my network switch) I killed the task Wideclient.exe in the W2K task manager. While the OS kills the process, the error message appears. After pressing OK, Wideclient is ready for another restart. My application has been run now on W2K, WinXP and WinME. The OS doesn't make a difference. I'm quite sure that my time syncing function does something bad which worked before (at least before updating to FS9.1). With my original post I didn't want to blame you on the error. Just wanted to look for some help. Furthermore I wouldn't dare to request support for old versions. Currently I don't have the time to re-program something, but I will keep you posted as soon as my problem is solved. I hope my point is clearer now. Best regards, CATIII

Pete, thank you for your reply. In the meantime I did some more investigation on this problem. My application has been run on different computers with different operating systems. I was able to reproduce the error by synchronizing FS-time with local time (and date). The affected procedure has not changed the last 6 months but for some reason it crashed WideClient (and sometimes even FS9). After reverting everything to WideFS 6.41 and FSUIPC 3.411 the error is gone. Maybe a mixture of different versions of Wideclient in my setup was causing the crash. Maybe something else caused it but today everything is running properly for 12+ hours. If the error appears again I'll be trying to track it down more precisely. That's a promise 8) Best regards, Michael (CATIII)

Dear Pete, with the latest FSUIPC/WideFS I get some serious errors which make WideClient stop working. On the client host, I have 2 applications running using FSUIPC. The error appears after a few minutes only. On the task manager nothing changes concerning wideclient.exe. The error message shows up if wideclient is stopped manually with the mouse. You can have a look at the logfile here: http://www.unixland.de/sim3sim/wideclient.zip Thanks for your help! Best regards, --CATIII PS: Attached you see the Wideserver.log. The affected computer name is 'IOS'. ********* WideServer.DLL Log [version 6.414] ********* Blocksize guide = 4096 (double allowed) Date (dmy): 29/11/04, Time 09:58:41.031: Server name is ACFT 18640 Initialising TCP/IP server 18640 Initialising IPX/SPX server 18640 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 18640 Failed to start IPX/SPX Server 41187 Restarting service due to total lack of use 41203 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 41203 Failed to start IPX/SPX Server 63750 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 63750 Failed to start IPX/SPX Server 86250 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 86250 Failed to start IPX/SPX Server 108937 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 108937 Failed to start IPX/SPX Server 131640 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 131640 Failed to start IPX/SPX Server 154343 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 154343 Failed to start IPX/SPX Server 177000 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 177000 Failed to start IPX/SPX Server 199687 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 199687 Failed to start IPX/SPX Server 222343 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 222343 Failed to start IPX/SPX Server 244890 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 244890 Failed to start IPX/SPX Server 267593 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 267593 Failed to start IPX/SPX Server 290218 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 290218 Failed to start IPX/SPX Server 312750 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 312750 Failed to start IPX/SPX Server 335437 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 335437 Failed to start IPX/SPX Server 358140 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 358140 Failed to start IPX/SPX Server 380843 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 380843 Failed to start IPX/SPX Server 403484 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 403484 Failed to start IPX/SPX Server 426187 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 426187 Failed to start IPX/SPX Server 448890 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family 448890 Failed to start IPX/SPX Server 455843 Incoming connection Accepted ok (skt=288) 455843 Connected to computer "IOS" (skt=288) 3919453 Incoming connection Accepted ok (skt=4880) 3919781 Connected to computer "CPT-CDU" (skt=4880) 3921593 Incoming connection Accepted ok (skt=4892) 3921828 Connected to computer "FO-MFD" (skt=4892) 3923234 Incoming connection Accepted ok (skt=4888) 3923515 Connected to computer "CPT-MFD" (skt=4888) 3925875 Error 10054: client socket disconnected at Client: removing (skt=288) 3928890 Incoming connection Accepted ok (skt=308) 3929172 Connected to computer "FO-CDU" (skt=308) 3934812 Incoming connection Accepted ok (skt=296) 3937109 Connected to computer "MAP" (skt=296) 3944203 Incoming connection Accepted ok (skt=4928) 3944718 Connected to computer "EICAS" (skt=4928) 4358328 Incoming connection Accepted ok (skt=4964) 4358328 Connected to computer "IOS" (skt=4964) 7800531 Incoming connection Accepted ok (skt=4980) 7800562 Error 10053: client socket disconnected at Client: removing (skt=4964)

Hi and BTW, you don't need to write 1024 bytes to send the clear command. Just send the 'unsigned short' to 0xC800 and that's it! MyWord := NW_CLEAR; FSUIPC_Write($0800, 2, @MyWord, your_dw_result); FSUIPC_Process(your_dw_result); Best regards, CATIII

maxmax20, here are some example code lines (written in Delphi) to get the kg value for the center tank. Factor_LbsToKg: Single = 0.4535924; Fuel_Lvl_C: LongInt; Fuel_Cap_C: Longword; FuelWeight: Smallint; Fuel_kg_C: Single; FSUIPC_Read($0B74, 4, @Fuel_Lvl_C, dwResult); FSUIPC_Read($0B78, 4, @Fuel_Cap_C, dwResult); FSUIPC_Read($0AF4, 2, @FuelWeight, dwResult); // Fuel Weight is calculated as follows: // // - how many gallons? (Max Capacity * Percent filled) // - multiply with Fuel Weight to get lbs // - convert to kg by using 'Factor_LbsToKg' Fuel_kg_C := Fuel_Cap_C * ((Fuel_Lvl_C * 100 / (128 * 65536)) / 100) * (FuelWeight / 256) * Factor_LbsToKg; Note that this is certainly not the most elegant solution but it works well for me 8) Good luck! CATIII

Unfortunately I don't have a log file right here, but my wideclient ini-files have only plain ip-addresses set. If I remember correctly the log file says something about "protocol not supported". That's why I tend to say it's a windows problem in general. Personally I don't like the idea of a MessageBox() since this implies interaction by the user (difficult without any peripherals connected). A new option like ConnectionRetry or similar will be better. Best regards, CATIII

I experience the same from time to time. It seems to me as if sometimes Windows starts the Autostart items before the network is really initialized. This makes WideClient think, there's no TCP/IP support (although it will be started a few seconds later). I have 7 PCs with WideClient (WinME) and every week another host shows this message. Maybe there's a way for WideFS to check if TCP/IP is being loaded or not configured at all? Ciao, CATIII