which offset for turbulence by weather trigger

[abax2000]

I try to monitor the results of a weather trigger I have setup (nondirectional turbulence).

As the turbulence induced by the trigger should update some offsets, I use FS-Interrogate to monitor various offset values while flying; but it seems that I cannot locate any offset that gets updated when entering the trigger area (the turbulence itself is working when entering the area, but no sign of it to any offset).

I have watched the following offsets with no luck:

C904

CA88

0E98

0EF4

0F76

0F08

0F8A

CD04

CE88

0EFA

0F6C

0F02

0F84

C104

C288

0E88

Is there any idea which offset should show the turbulence generated by a weather trigger ?

[Pete Dowson]

I try to monitor the results of a weather trigger I have setup (nondirectional turbulence). ...

Is there any idea which offset should show the turbulence generated by a weather trigger ?

 

 

Sorry, but i don't really understand. What's a "weather trigger"? Are you setting weather in FS? Which version of FS? How are you setting it? Are you trying to detect wind or cloud turbulence -- the two are separate effects in FS.

 

FSUIPC does contain logging facilities for weather, which you should use to ensure your weather program is doing what you want it to do. There is also the WeatherSet utility which will read the weather details for you.

 

Pete

[abax2000]

Just to avoid naming problems, see in FSX SDK: BGL Compiler SDK\Compiling BGL\Scenery Objects\TriggerWeatherData.

TriggerWeatherData

This element is used to specify a weather setting for a trigger. Weather triggers can be used to create thermals and ridge lifts for gliders and areas of turbulence. This element is not allowed to contain other data and must be terminated with ‘/>’.

<TriggerWeatherData

type="THERMAL"

heading="270.0"

scalar=".70"/>

Attribute Description Acceptable Values

type Type of weather data THERMAL

NONDIRECTIONAL_TURBULENCE

DIRECTIONAL_TURBULENCE

RIDGE_LIFT

heading Heading vector applied to weather data 0.0 to 360.0 floating point value

scalar Scalar value applied to wind speed that is used to generate lift and turbulence. Floating point number between 0.0 and 1.0.

So, I have setup a type=turbulence trigger; I presume that as the trigger comes in action (I.e. the aircraft enters the area and turbulence is generated), some offsets' values must be changing. But I cannot find these related offsets.

I have monitored all offset in the list in OP, but none of them seem to change value entering or leaving the area (please note that turbulence is indeed generated within the area of the trigger as witnessed by aircraft motion and aircraft instruments fluctuation).

I would be obliged if you could point me to the correct offsets.

[Pete Dowson]

Just to avoid naming problems, see in FSX SDK: BGL Compiler SDK\Compiling BGL\Scenery Objects\TriggerWeatherData.

 

 

Oh, right. Never done any scenery desgning so never looked there.

 

 

This element is used to specify a weather setting for a trigger. Weather triggers can be used to create thermals and ridge lifts for gliders and areas of turbulence.

 

 

I suspect this is actually implemented as a scenery action directly into the simulation, and not through the weather system if it is not reflected in any of the weather data which is provided.

 

 

Attribute Description Acceptable Values

type Type of weather data THERMAL

 

There's no mention of "thermal" types in any of the weather facilities. If you refer to the SimConnect part of the Core Utilities SDK you will see that all the information is provided in a sort of extended METAR string. There's no place for thermal data, and the METARs are in any case related specifically to defined weather stations. Requesting details for anywhere else simply gives an interpolation from the nearest three WX stations in a sort of triangulation grid.

 

 

heading Heading vector applied to weather data 0.0 to 360.0 floating point value

scalar Scalar value applied to wind speed that is used to generate lift and turbulence. Floating point number between 0.0 and 1.0.

 

If this does affect the actual wind vectors at the aircraft then they should be seen affecting the X, Y and/or Z axis wind speeds at offsets "DC8, 2DD0 and 2DD8 respectively.  But you will probably need to make sure FSUIPC's wind smoothing option were turned off the see it in the X and Z axes as this is where its smoothing takes hold. You may or may not see it in the vertical (Y) axis).

 

 

I have monitored all offset in the list in OP, but none of them seem to change value entering or leaving the area (please note that turbulence is indeed generated within the area of the trigger as witnessed by aircraft motion and aircraft instruments fluctuation).

 

I suspect that's because all of the offsets you monitored appear to be weather (from the weather.DLL) rather than wind effects (from the SIM engine).

 

Regards

Pete

[abax2000]

Thermals are mentioned in SimConnect, as in 

SimConnect_WeatherCreateThermal and SimConnect_WeatherRemoveThermal

as turbulence is also (as you rightly say) both in winds extension and cloud extension (as in SimConnect_WeatherSetObservation).

 

Anyhow, I was expecting that the results of a turbulence weather trigger would be manifested in some offsets, and most probably in 0e98, 0e88, cd04, ce88. 

But this not the case, and it seems very strange.

 

Please note that "heading---> Heading vector applied to weather data---> 0.0 to 360.0 floating point value" refers to the wind heading that will permit the turbulence effect (i.e. turbulence is induced when ambient wind is coming from this heading - if the wind heading deviates the turbulence gets smaller and at wind heading +-90degrees it gets zero - but all this is not documented and this is exactly what I am trying to verify through experiment).

 

I will try to monitor the winds also (although I think that turbulence does not manifest in wind offsets)

[Pete Dowson]

Thermals are mentioned in SimConnect, as in 

SimConnect_WeatherCreateThermal and SimConnect_WeatherRemoveThermal

 

 

Yes, but no facility to read those settings at all. I expect you can only read the result, which is most likley in those wind elements I mentioned.

 

 

Anyhow, I was expecting that the results of a turbulence weather trigger would be manifested in some offsets, and most probably in 0e98, 0e88, cd04, ce88. 

But this not the case, and it seems very strange.

 

 

 

Well, not strange to me, because I don't think it is a function of the weather engine, which is striving to reproduce only the weather from the METARs. I think the thermal facility is coded just as an 2effect" on the aircraft, probably via the local wind X Y Z components. Certainly it is by using these that such effects have been obtained by add-on programs, like those doing catapuld launching and arrestor cables. And some of FSUIPC's own turbulence effects (used when wind smoothing kills the FS ones) acts using these three values.

 

 

I will try to monitor the winds also (although I think that turbulence does not manifest in wind offsets)

 

 

I think you are wrong there. Certainly it would not manifest in the prevailing wind data at all, but I'm talking about the active wind X Y Z components at the aircraft -- it is those which makes the aircraft shake in the different directions. These are simulation values not weather values.

 

Regards

Pete

[abax2000]

Yes, but no facility to read those settings at all. I expect you can only read the result, which is most likley in those wind elements I mentioned.

Oh, I think I see what you mean: that relevant data can be fed to the FS, but not read back.

 

 

I think you are wrong there. Certainly it would not manifest in the prevailing wind data at all, but I'm talking about the active wind X Y Z components at the aircraft -- it is those which makes the aircraft shake in the different directions. These are simulation values not weather values.

Of course offsets 2DC8, 2DD0, 2DD8 do fluctuate while in turbulence (regardless of how this turbulence was induced).

 

The problem is that the task on hand (see note) would require some solid measurement of the induced turbulence, in order to map the behaviour  of the weather trigger. So eyeballing, aircraft instruments or (2DC8, 2DD0, 2DD8) for that purpose do verify that turbulence is active but do not tell how much.

 

Is there any possibility that some offsets have been yet unexplored :???: ?

 

 

Note: What I am trying to do is map the behaviour of the induced turbulence by the weather trigger against wind direction, wind speed and scalar.

[abax2000]

Just a clarification for further testing:

offsets C000-C3FF refer to "weather at aircraft" taking into account also the altitude (i.e at the actual point in space where the aircraft is) or just the aircraft lat-lon?

[Pete Dowson]

The problem is that the task on hand (see note) would require some solid measurement of the induced turbulence, in order to map the behaviour  of the weather trigger. So eyeballing, aircraft instruments or (2DC8, 2DD0, 2DD8) for that purpose do verify that turbulence is active but do not tell how much.

 

You'd need to measure the frequency and amplitude of the fluctuations to determine the strenght of the turbulence. I really can't think of any other way.  Perhaps start by measuring the peaks and their frequency.

 

Is there any possibility that some offsets have been yet unexplored :???: ?

 

 

I see you misunderstand. Not since FS98 days have the offsets actually mapped into real FS variables. All of them in FSUIPC4 are part of a data area inside FSUIPC which is populated by reading SimConnect variables plus a lot of derived values computed for compatibility with previous FS versions.

 

Note: What I am trying to do is map the behaviour of the induced turbulence by the weather trigger against wind direction, wind speed and scalar.

 

 

Yes, but it seems you will have to do it by analysing the results. You are not provided with some simple measure, which probably doesn't exist at all in any case.

 

 

Just a clarification for further testing:

offsets C000-C3FF refer to "weather at aircraft" taking into account also the altitude (i.e at the actual point in space where the aircraft is) or just the aircraft lat-lon?

 

Doesn't it say that? Except at weather stations you can only read, from Simconnect, the specific weather at a particular position -- Lat, Lon and Altitude.  You can ask for that anywhere yourself. The automatic reading of "weather at altitude" is from the same sort of request to SimConnect as that but with the aircraft's Lat/Lon/Altitude. It is that data which is used to populate most of the other "at aircraft" weather offsets. Of course it comes from SimConnect as a "extended" METAR string, and I'm pretty sure it won't contain anything about your thermal effects.

 

So, what isn't actually clear? I don't really know what you are confused about.

 

Regards

Pete

[abax2000]

You'd need to measure the frequency and amplitude of the fluctuations to determine the strength of the turbulence. I really can't think of any other way.  Perhaps start by measuring the peaks and their frequency.

No thanks, I think that I'll pass :cry:

 

I just asked for a confirmation about "weather at aircraft" because flying low I saw discrepancies between whatever reported as turbulence in the first cloud layer (in WeatherSet) and the value in C288 and 0E88 (I was expecting these all three to coincide, but maybe it is my wrong understanding. I will run a new test flight to visit it again).

 

I see you misunderstand. Not since FS98 days have the offsets actually mapped into real FS variables. All of them in FSUIPC4 are part of a data area inside FSUIPC which is populated by reading SimConnect variables plus a lot of derived values computed for compatibility with previous FS versions.

It is true that I do not have a clear view of the structuring or origin of data available in the various FSUIPC offsets.

If there is any document/source that explains in layman's terms the concept and general terms of the mapping of data between FS and FSUIPC, please point to it.

[Pete Dowson]

No thanks, I think that I'll pass :cry:

 

 

Why? It would be easy enough with a Lua plug-in accumulating say 100 values over a given period and doing a little calculation.

 

 

I just asked for a confirmation about "weather at aircraft" because flying low I saw discrepancies between whatever reported as turbulence in the first cloud layer (in WeatherSet) and the value in C288 and 0E88 (I was expecting these all three to coincide,

 

 

Were you IN the cloud with the turbulence at the time?

 

If you have questions about what weather is coming from where, try the weather logging facilities in FSUIPC (logging tab). You'll see that actual METAR strings being received as well as their decoding.

 

 

If there is any document/source that explains in layman's terms the concept and general terms of the mapping of data between FS and FSUIPC, please point to it.

 

 

 

There's no way. Every piece of data is obtained in whatever way is necessary or most efficient. It is different in every version of FS and different for most of the values therein. The documentation of how it is done would be pretty much the entire source of the IPC interface in FSUIPC. What is it you need to understand other than FSUIPC obtains the data which is documented?

 

In FS98 it was not even mapped. FSUIPC like FS6IPC before it merely was merely a portal into a DLL in FS called "GLOBALS" (only 2kb's worth then),  which handily stored everything anyone wanted into or out of FS. Nice and simple. Then FS2000 came alone and most was still that way, but some data became hived off into different modules. That's when "mapping" started, bringing disparate areas of FS memory into one imaginary memory sequence. That continued into FS2002, but much of the data then became unmappable because it either didn't exist as such, and had to be derived or obtained via procedure calls, or it was part of some almost impenetrable "black box" which I had to hack into to find the right places to hook code into to get stuff.

All this rewriting in FS, from nice straightforward assembly code to tortuous object-oriented C++ "classes" (black boxes) cam to a head with FS2004 which cost me many many 100's of hours of work and brought me to the point where I was ready to give it up. But then Microsoft appeared to realise the benefits of the sort of thing I was doing and called me over to Seattle to discuss it. That's when "SimConnect" was born and releived me of most of the hacking I would have otherwise have baulked at.

 

Now probably 90% of the data in FSUIPC4 offsets, other tthan that related purely to FSUIPC facilities, is derived from SimConnect variables, asynchronously (because that's how SimConnect works), and kept for synchronous application access in FSUIPC memory (now 65kb). There is still some hacking, but much less than in FSUIPC3.

 

So, if you want to know more about the data and where it comes from and how, best take a look at the SimConnect SDK.

 

Regards

Pete

[abax2000]

Pete,

thanks you very much for your suggestions and the insight provided.

[abax2000]

Pete,

 

here is an example about the discrepancies in values I was talking about.

The aircraft is on the ground.

0E88 reports 0 (which makes sense since the a/c is below the first layer carrying cloud turbulence).

On the other hand, C288 does have a non-zero value.

 

I used also the FSUIPC weather logging facility. For the time I have some problems in decoding METAR strings, but I am working on it.

What would be the meaning of a message as this (**** METAR errors: length=1684, spurious layers removed: Wind 21, Temp 22) ?

[Pete Dowson]

The aircraft is on the ground.

0E88 reports 0 (which makes sense since the a/c is below the first layer carrying cloud turbulence).

On the other hand, C288 does have a non-zero value.

 

What's wrong with that? C288 is the first cloud layer entry (out of 16) in the weather table "at the aircraft".  Your aircraft is on the ground. Is the cloud layer on the ground? You are making no sense!

 

0E88 is in fact derived in FSUIPC by it scanning the cloud layers to see if the aircraft is in one and if so that shows its turbulence value. So 0E88 will only reflect the layer you are in. Why is that a "discrepancy"?

 

I get the feeling you completely misunderstand something here. There is only one source for all these values, the METAR string read from SimConnect, which you can easily monitor yourself. The weather tables and all the weather offsets, EXCEPT the X/Y/Z wind components at the aircraft, are derived from that one source. Why do you think this results in "discrepancies"??? :-(

 

I used also the FSUIPC weather logging facility. For the time I have some problems in decoding METAR strings, but I am working on it.

 

They are not standard METARs. You need the SDK reference.

 

What would be the meaning of a message as this (**** METAR errors: length=1684, spurious layers removed: Wind 21, Temp 22) ?

 

 

The length is the length of the METAR string (obviously?), the spurious layers removed are layers which are identified as "spurious" because they are very very thin (sometimes zero feet), or feature almost exactly the same values.

 

These sorts of rubbishy METARs settings don't normally occur if you are using default weather sources, but they do get generated, and get worse and worse, when using external weather programs -- unless those programs use the only really safe weather setting  mode, "Global". The spurious layers generate because of bugs in the FSX weather interface.

 

Pete

[abax2000]

What's wrong with that? C288 is the first cloud layer entry (out of 16) in the weather table "at the aircraft".  Your aircraft is on the ground. Is the cloud layer on the ground? You are making no sense!

 

0E88 is in fact derived in FSUIPC by it scanning the cloud layers to see if the aircraft is in one and if so that shows its turbulence value. So 0E88 will only reflect the layer you are in. Why is that a "discrepancy"?

 

I get the feeling you completely misunderstand something here. There is only one source for all these values, the METAR string read from SimConnect, which you can easily monitor yourself. The weather tables and all the weather offsets, EXCEPT the X/Y/Z wind components at the aircraft, are derived from that one source. Why do you think this results in "discrepancies"??? :sad:

 

The a/c is on the ground; there is no cloud layer on the ground (the first one is 1001-5000ft).

So "at" the a/c there are no clouds.That is why I find reasonable 0E88, but not C288 (which is supposed to report also "at" a/c position; although it reports whatever exists 1000ft higher). Since both are supposed to report at a/c, I would expect 0E88=C288=0 (since a/c is out of any cloud layer).

 

 

They are not standard METARs. You need the SDK reference.

I am studying.

 

 

These sorts of rubbishy METARs settings don't normally occur if you are using default weather sources, but they do get generated, and get worse and worse, when using external weather programs -- unless those programs use the only really safe weather setting  mode, "Global". The spurious layers generate because of bugs in the FSX weather interface.

 

 

That explains it; I use AS2012 at "Standard" mode.

[Pete Dowson]

The a/c is on the ground; there is no cloud layer on the ground (the first one is 1001-5000ft).

So "at" the a/c there are no clouds.That is why I find reasonable 0E88, but not C288 (which is supposed to report also "at" a/c position; although it reports whatever exists 1000ft higher). Since both are supposed to report at a/c, I would expect 0E88=C288=0 (since a/c is out of any cloud layer).

 

 

The "weather at aircraft" area ax C0xx provides all the information which FSUIPC can obtain when reading weather at the aircraft position. It provides some or all cloud layer information.

 

By only reading C288 and not the base altitude of that one cloud layer you are utterly confusing yourself. You should not pick out "C288" by itself, it is part of a structure defining a cloud layer, and that cloud layer contains some turbulence information. If the aircraft was in that layer, that turbulence information would affect 0E88. In fact the code in FSUIPC to set 0E88 loops along the number of cloud layers checking the aircraft altitude with the cloud altitudes in order to set that value. (Here it has to use an estimate of the cloud height, based on its type, because, alas, FSX does not supply this detail).

 

How may more ways can I explain it? you seem not to understand the New Weather Interface data structures. Sorry they are only provded in C/C++ terms, but surely they are still reasonably clear?

 

Pete

[abax2000]

So, trying to sum it up:

The range C000-C3FF contains weather data at lan-lon of the aircraft from ground up (not only at a/c height)- at least this is true for cloud layers.

The offsets within that range published in latest version of FS-Interrogate2std are not the only ones in this range. For a complete picture, all other offsets in this range must be taken into account.

WeatherSet2 is the only "user-friendly" means of getting most (but not all) of the info in this range.

I have read (multiple times) the NewWeather Readme.txt contained in your documentation, but that's about it; I could not locate a more detailed doc.

[Pete Dowson]

So, trying to sum it up:

The range C000-C3FF contains weather data at lan-lon of the aircraft from ground up (not only at a/c height)- at least this is true for cloud layers.

 

Please refer to the FSUIPC4 Offsets Status document, look up offset C000, and note that there's a red asterick on the C000-C3FF section  Refer further down to the meaning of that asterisk, also in red where it tells you reasonably clearly what you get in that area.

 

I have read (multiple times) the NewWeather Readme.txt contained in your documentation, but that's about it; I could not locate a more detailed doc.

 

 

None more detailed, and that's all that is needed for programmers, but the first port of call is surely always the main Offsets reference documnet?

 

Regards

Pete