Jump to content
The simFlight Network Forums

CATIII

Members
  • Posts

    45
  • Joined

  • Last visited

About CATIII

  • Birthday 01/01/1970

Contact Methods

  • Website URL
    http://

CATIII's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. 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
  2. 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
  3. 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
  4. 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.
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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.
  10. 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'.
  11. 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
  12. Mick, would you mind sending me your application project? Maybe I can find something... CATIII
  13. 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
  14. 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
×
×
  • Create New...

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.