Questions about weather Offsets

[VOZzer]

Hello everyone,

Now, as some of you may know, the Level-D 767 does not come with a weather radar. as such, I am planning on making my own weather radar system in which LEDs ligh up (in real life) if certain Offsets (such as precipitation Offsets) are above a certain level. This will provide a simple yet very reliable system (I hope).

For example:

"If Offset X is more than Y, then LED Z lights up"... If you're wondering how I get them to light up it is with Opencockpits Hardware (Mastercard).

However, before I start the scripting, I have a few questions about certain relavent offsets...

- Offset 04CB, Precipitation Rate. In the manual it says that this value is represented by 0-5. I take it this is the default FSX values of "Light", "Very Light", "Heavy", etc?

- CAB8, Written Cloud Turbulence (4). First of all, what do the numbers in brackets mean? This also applies to other Offsets such as Cloud Precipitation Rate, etc. Secondly, does this Offset have any adjustments tagged to it (ie is it doubled, divided, etc)?

- What is the difference between Precipitation Rate Offset, and Cloud Precipitation Rate Offset?

Thanks, I will probably have more questions as the thread progresses,

VOZzer (Jack) :D

[Pete Dowson]

- Offset 04CB, Precipitation Rate. In the manual it says that this value is represented by 0-5. I take it this is the default FSX values of "Light", "Very Light", "Heavy", etc?

I assume so too.

CAB8, Written Cloud Turbulence (4). First of all, what do the numbers in brackets mean? This also applies to other Offsets such as Cloud Precipitation Rate, etc. Secondly, does this Offset have any adjustments tagged to it (ie is it doubled, divided, etc)?

CAB8? You've jumped from FS98 weather offsets to something in the Advanced or New weather interface? Please tell me what you are looking at.

- What is the difference between Precipitation Rate Offset, and Cloud Precipitation Rate Offset?

No idea without more information. Where are you reading?

Thanks, I will probably have more questions as the thread

In that case it might be a good idea to be a little more specific, please.

Pete

[VOZzer]

Right, I'm talking about using FSInterragator.

If i setup the fields in the FSInterragator interface so that only FSX Compatible and "Weather" Offsets appear in the table, then I get Offsets such as CAB8.

However, CAB8 is just a number of FSUIPC Offsets that apply to "Written Cloud Turbulence". This is detailed in the following picture:

As a summary of what I'd like to know:

- What do those numbers in brackets mean after all the FSUIPC Offsets?

[Pete Dowson]

- What do those numbers in brackets mean after all the FSUIPC Offsets?

It is the cloud layer number. You are viewing elements in an FSInterrogate array. I think the FSInterrogate documentation will explain it (but I've not checked).

FSUIPC handles up to 16 cloud layers, 24 wind layers, 24 temperature layers and 12 upper visibility layers. Please refer to the "NewWeather.h" header file in the SDK.

Pete

[VOZzer]

Hi Pete,

Thanks alot. That really hellps because I can now use a rotary knob labelled 1-10, and when it is turned to a certain number, it shows data for that layer (eg rotary position 3 = cloud layer 3).

Another question though:

What is the difference between Cloud precipitation rate and precipitation rate?

Is Cloud Precipitation Rate also "numbered" 0-5, only difference being that it applies to one cloud and not a "generic" figure which I think precipitation rate is?

[Pete Dowson]

What is the difference between Cloud precipitation rate and precipitation rate?

Erthere's only one "precipitation rate" per cloud layer. Please see the New weather Interface definitions in the SDK. You can'tlearn this stuff from FSInterrogate data files.

Is Cloud Precipitation Rate also "numbered" 0-5, only difference being that it applies to one cloud and not a "generic" figure which I think precipitation rate is?

Where are you seeing the latter? Without specific references it is hard for me to understand your questions.

Regards

Pete

[VOZzer]

Hi Pete,

This screenshot may help:

As you can see, there are two types of Precipitation Offset.

[Pete Dowson]

As you can see, there are two types of Precipitation Offset.

There are more than that. Please please do refer to the SDK documenta. Do NOT continue to try to learn from FSInterrogate, which is a utility foryou to try stuff NOT an educational tool, and most certainly NOT the source or definition of interface information.

There are THREE weather interfaces.

1. The offsets in the lower ranges, mainly 04B4 through to to 05DA, and 0E8A through to 0F8C, all of which derived from original FS95 and FS98 offsets with some additions in FS2000. In general these all relate to the single "global" weather settings which was all that was supported by FS in those days. They are maintained as the "weather at aircraft" to this day, for compatibility (FSUIPC's whole reason for existence was, and is, ongoing compatibility for applications). The SDK's documentation has a lot of text about all this if you want more information.

2. The "Advanced Weather Interface" implemented for FS2002, which included localised weather stations stuff too, but was not offset based but command / response methods. This is now largely defunct, but still works. The original "WeatherSet" application demonstrated this.

3. The "New Weather Interface", developed for FS2004 and extended for FSX and ESP, which is documented in the SDK and which is recommended for all new programs over both of the others. That uses the offset range B000 to CFFF.

Regards

Pete

[VOZzer]

Right Pete,

I'm using the Offsets such as CE8D which fall into the latter, FSX "New Weather" range. Especially handy for me because I'm using FSX.

So I'll just stick with those. The Offset I'm using are the Cloud Precipitation Rate layers, numbered ones, which as you said refrence to cloud LAYERS.

I do very much apologise if the next question's answer can be derived from documentation. It's just that I personally haven't found it yet in the Manual(s).

SIOC Programming requires knowledge of the "Length" of the Offset in Bytes. Where can I find this in regards to Offsets such as CE8D? It isn't in the FSUIPC Offsets status manual.

Thanks,

Jack :D

EDIT: Had another peek. Is it, by any chance, 16 Bytes?

[Pete Dowson]

SIOC Programming requires knowledge of the "Length" of the Offset in Bytes. Where can I find this in regards to Offsets such as CE8D? It isn't in the FSUIPC Offsets status manual.

The New Weather Interface is defined in a package in the SDK called (obscurely?) "New Weather Interface for FS2004.zip". (It was new to FS2004, remember?). That contains a text document explaining how to use the interface, and a C header file which defines the structures used. The latter, in turn, define the data type of each field. so for clouds it defines:

// Cloud structure (size 16 bytes)
typedef struct _NewCloud
{	unsigned short UpperAlt;	// Metres
	unsigned short LowerAlt;	// Metres
	unsigned short Deviation;	// Metres
	unsigned char  Coverage;	// Octas, 0-8
	unsigned char  Type;		// 1-10
	unsigned char  Turbulence;	// 0-4
	unsigned char  Icing;		// 0-4
	signed short   PrecipBase;	// Metres
	unsigned char  PrecipType;	// 0-2
	unsigned char  PrecipRate;	// 0-5
	unsigned char  TopShape;	// ?
	unsigned char  Spare;
} NewCloud;

and as you can see from that the Precipitation Rate is defined as "unsigned char", meaning it is one byte.

EDIT: Had another peek. Is it, by any chance, 16 Bytes?

No, most certainly not! It's a simple number as you know already. Each whole cloud layer entry is 16 bytes!

Please use the documentation supplied. I'm not sure how you are using the NWI, but it sounds as if you are trying to pick individual values from it which may not actually work the way you think. If you only want the weather at the aircraft you are really better of using the old FS98 style offsets in the lower areas.

Pete

[VOZzer]

Hi Pete,

When you say they won't work how I want... Don't they just show a simple value from 0-5 regarding precipitation? I'm not exactly sure what the problem is with the NWI, 0-5 sounds like a simple reading to me, and if it is Length 1 Byte, that is all I need to know. Each Offset named represents a cloud layer (correct?).

I did find the txt file you posted - I read it wrong.

This is exactly what I want it to do (please tell me if this WON'T work):

- If Turbulence/Precipitation is MORE than "3", then an LED Lights up (ie Offset read)

[Pete Dowson]

When you say they won't work how I want... Don't they just show a simple value from 0-5 regarding precipitation?

Are you just reading weather or wanting to set it too? If only reading, are you wanting to read weather at the aircraft, or at some specific place?

I'm not exactly sure what the problem is with the NWI, 0-5 sounds like a simple reading to me, and if it is Length 1 Byte, that is all I need to know. Each Offset named represents a cloud layer (correct?)

Er, named? I don't name offsets individually. The structure for clouds has a name, as do its components, of course.

Whatever weather you are reading, there may be anything from 0 to 16 cloud layers. You need to read the number of cloud layers and not read any offset which isn't valid for the number of cloud layers actually present. FSUIPC doesn't guarantee to zero unused offsets.

This is exactly what I want it to do (please tell me if this WON'T work):

- If Turbulence/Precipitation is MORE than "3", then an LED Lights up (ie Offset read)

Turbulence and precipitation where? At the aircraft, on the ground, at a weather station, at agiven Lat/Lon?

I assume you want it at the aircraft, in which case you have to scan the cloud layers, if there are any, and find out which one you are in (for turbulence) or is just above you (for rain). For wind turbulence you have to scan the wind layers to find which one of those you are in.

Yes, of course it is possible (assuming you have a way of lighting a LED). It just may not be quite like you think. If I am wrong I apologise, but your earlier referring only to FSInterrogate had me worried you were missing too much. For simple "at aircraft" values I recommended the old original FS98 offsets for this reason. They have been maintained throughout all the FS versions for a reason! ;-)

Regards

Pete

[VOZzer]

Hi Pete,

I will go more in-depth at what I'm trying to do, as your above post's question can easily be answered.

On my weather radar panel, I have two rotary Knobs. One is for turning the radar ON (not applicable in this discussion), and the other is for selecting the cloud LEVEL scanned (the knob runs from 0-5).

For example, if the radar is ON, and the rotary knob is set to 4, it will use the Offsets $CEBD (Precipitation) and $CEB8 (Turbulence), as they ONLY apply to cloud level four. If Offset CEBD/CEB8 is above 3, an LED will light up.

So, in short, the rotary knob numbers give the signal of which Offset to use (ie if in position 1, only Offsets for cloud level 1 are given).

This is all controlled through the SIOC Scripting.

Jack :D

[Pete Dowson]

I will go more in-depth at what I'm trying to do, as your above post's question can easily be answered.

...

So, in short, the rotary knob numbers give the signal of which Offset to use (ie if in position 1, only Offsets for cloud level 1 are given).

Ah, okay. Thanks. I understand now.

Pete

[VOZzer]

So will it work? I'm dying to know! :P :P :P

[Pete Dowson]

So will it work? I'm dying to know! :P :P :P

No, not with the offsets you are quoting. The CC00-CCFF offsets show the weather results after an NWI READ command. You don't appear to be issuing any NWI commands at all. Weather radar mappers use the facility to read the weather at points around the aircraft, to build up a picture. But there's a protocol for that, as documented.

If you want weather at the aircraft then either read the FS98 offsets as I said, or use the NWI weather populated in offsets C000-C3FF. However, note that when supplying weather at the aircraft, FSX does NOT supply any data for wind layers other than the one you are in. FSUIPC4 fills in the other layers from the nearest weather station.

This information is in the offsets listing by the way.

Regards

Pete

[VOZzer]

Hi Pete,

When you say "NWI Command", what are you referring to?

Also, I do NOT want weathe reports at the ircraft, or the weather station. My system also does not work like a conventional radar, it just takes weather and illuminates if there's a certain condition. Nothing fancy.

I was under the impression, for example, if CE8D is more than 3 SIOC will read this and give an output as necessary?

If there something I keep missing in what you or the documentation says? :?

[Pete Dowson]

When you say "NWI Command", what are you referring to?

The commands, as documented in the SDK, as I referred you to, which operate the reading from and writing of weather to FS.

It appears you aren't referring to any of the documentation provided! :-(

Also, I do NOT want weathe reports at the ircraft, or the weather station.

In that case there's only one other option, and that it weather at a given Latitude and Longitude. You certainly have to request that. Neither FSUIPC nor FS can guess what you want!

My system also does not work like a conventional radar, it just takes weather and illuminates if there's a certain condition. Nothing fancy.

Weather WHERE though? If not at a nearby weather station, and not at the aircraft, where? You are not making sense I'm afraid!

I was under the impression, for example, if CE8D is more than 3 SIOC will read this and give an output as necessary?

But CE8D will only ever be populated with weather when something, some add-on, makes a request to read the weather. And then the weather may be at a distant place. If you don't request the weather, how will you know if there's any provided for that ofset or where it relates to?

If there something I keep missing in what you or the documentation says? :?

Evidently you've not read much if any of it!

Regards

Pete

[VOZzer]

Hi Pete,

Isn't the "add-on requesting the weather" going to be SIOC? If I use a FSUIPC_IN Link it usually reads the offset and gives a necessary output.

Which particular documentation are we referring to? I've read the new_weather.txt file in the SDK (both of them).

I think I'm not understanding the physical purpose of Offset $CE8D. I thought it gave the precipitation level (0-5) for Cloud Layer 1. If SIOC reads this, and gives an output, what is the problem?

[Pete Dowson]

Isn't the "add-on requesting the weather" going to be SIOC? If I use a FSUIPC_IN Link it usually reads the offset and gives a necessary output.

To ask FSUIPC to read specific weather it has to Write offsets first. There are a number of NWI Commands to do different things. One is to read the weather, and before sending it the requesting program has to set values such as the ICAO ID of the weather station, or the Latitude and Longitude for the weather it wants.

I doubt that SIOC is doing that unless it is a pretty sophisticated weather program designed to do so. I provided an example utility which uses the NWI -- WeatherSet2. Play with that and you'll see what the NWI can do.

You say you don't want weather at the aircraft nor at any weather station, but you don't say where it is you want the weather for! Really there's not much other weather, as FS doesn't simulate other planets.

How can I possibly advise you unless you make up your mind what weather it is you want to know about?

Which particular documentation are we referring to? I've read the new_weather.txt file in the SDK (both of them).

And you completely missed the whole section on the offset area you are trying to use? Incredible! :-( Here, please note the parts I highlight in RED:

CC00-CFFF (Area 3): Weather reading area [NOTE IMPORTANT CHANGES HERE in FSUIPC >= 3.50)

========================================

This is the most complex area to use, because it can provide the complete weather structure for any known weather station given its ICAO. Since the data has to be read, on request, and be made available for a time so that the application can actually read it all, an interlocking mechanism is provided to prevent another application from trying to read a new location within a reasonable time.

The procedure is as follows:

1. The application generates a "signature", any 32-bit pseudo-random number. It will use this as its temporary access key into this area.

2. Each time it wants to read weather for a station, it writes the signature to the ulSignature field and the ICAO to the chICAO field, AT THE SAME TIME -- i.e. a write of 8 bytes altogether*. If it wants to read the weather at a specific location instead, not at a station, then the ICAO code should be set instead to 4 spaces (" ") and the Latitude and Longitude fields should be written at the same time as the signature and this blank ICAO code. That makes a total of 28 bytes written (the dynamics and spare fields can be set zero. they are ignored).*

* You can write them with separate writes provided that (a) they are in the same FSUIPC_Process call, and (b) the writing of the Signature comes after the writing of the ICAO or Lat+Lon.

3. If the area is free (signature is zero) or this signature is the same as the last one written, then this access works, and FSUIPC obtains the requested weather. If, however, the signature does not match and someone else is reading the weather here, this write will be discarded and the weather already being read will continue to be updated.

A program which wants to be cooperative can use a signature of zero -- this works providing it is zero already, but it doesn't stop any other program from reading whatever it likes. The program which is being so friendly must be prepared to see a different ICAO or location being read than the one it asked for -- the WeatherSet2 program does this. You can ask it to display any location or WX sttion, but it will display whatever any other program is reading too, or, rather, instead.

4. FSUIPC clears down the signature approximately 14 seconds (at most) after it is validly written, thus opening up access to all again. If you want to keep the access for your own program you have to refresh the signature within this time, say every 5-8 seconds to be safe.

5. If the request succeeds, then at some time later (a few milliseconds probably, depending on FS frame rates) the weather details will be filled in and the chICAO field will reflect which weather station this is for. Furthermore, the ulTimeStamp field will be updated, and the Latitude, Longitude and Elevation of the ICAO station will be valid. If the request fails the weather at the aircraft is substitued, and if that fails the GLOBal weather is substituted. In the former case the ICAO id will be zeroed and the aircraft Lat/Lon set. In the latter case the ICAO identifier will be changed to 'GLOB'.

If programs want to check that the weather provided genuinely is for the location they requested, they should read the ICAO and/or Lat/Lon back in the same Process call as reading the weather data, and check that they are as they requested.

For requests of weather at a Lat/Lon, any such check should ideally check that the Lat/Lon is close enough -- eg within say .02 of a degree (a max of 2 nm off).

6. FSUIPC keeps the data updated at roughly 1 second intervals. The weather data should always reflect the ICAO code or Lat/Lon actually readable in this area. If the signature expires (i.e. it is not refreshed in time), then, since version 3.499a of FSUIPC, these updates still continue. Before any valid requests are made in an FS session, the area is updated with weather at the aircraft position, and the LLatitude and Longitude fields are updated accordingly.

Note that you can read the global weather settings here by setting the ICAO to "GLOB". In this case the Latitude/Longitude/Elevation values will all be zero.

So, how could you miss the complete section detailing exactly how to use the offsets you are trying to use?

I think I'm not understanding the physical purpose of Offset $CE8D. I thought it gave the precipitation level (0-5) for Cloud Layer 1.

That is true ONLY if some program has requested that the weather, for somewhere specified, be read into those offsets. If you don't do the request then either the offset will contain rubbish or will contain the correct value for some place you don't know (unless you read the offsets giving place too).

If SIOC reads this, and gives an output, what is the problem?

No problem if you just want to use a random value, obviously. But you don't seem to even know what weather you want it to relate to! FSX doesn't have the same weather everywhere you know! Is that what you were thinking?

Pete

[VOZzer]

Hi Pete,

I think I'm finally starting to understand what you're saying, and I think you're starting to understand what I'm saying. :D

I *think* you're trying to say that Offsets like CE8D only give such a reading if a LOCATION is specified. Is this correct?

All I want to happen (now that you mention weather stations) is for SIOC to receive:

- Precipitation reports for cloud levels one to five at the NEAREST weather station

- Turbulence reports for cloud levels one to five at the NEAREST weather station

Is this possible, without using any fancy programs, just writing a SIOC Script that reads FSUIPC Offsets? All I want are Precipitation/Turbulence Reports for Cloud Layers 1-5 at the nearest weather station.

[Pete Dowson]

I think I'm finally starting to understand what you're saying, and I think you're starting to understand what I'm saying. :D

I *think* you're trying to say that Offsets like CE8D only give such a reading if a LOCATION is specified. Is this correct?

Yes, and the document says the same thing. Locations like an ICAO ID for a Wx station, or a Lat/Lon, or "GLOB" for global default weather (used to populate Wx stations with no other weather). There's a sequenced procedure for specifying the place, waiting for the response, and checking that it is YOUR request answered and not someone else's. Exactly as documented!

It sounds like you've STILL not read the section about the offsets you are interested in, even though i posted a copy in my last message! Why not?

You still haven't said WHERE it is you want this weather data for. If not at a weather station or at a given position (Lat/Lon) at the aircraft, where on Erath can it be?

Pete

[VOZzer]

Hi Pete,

I said in my last post I'd like the Cloud Layer Datas for the nearest weather station.

[VOZzer]

Hi Pete,

I re-red you last post and understood things better.

To get the weather readings "filled-in", an application must have a specific signature. If this signature is accepted by FSUIPC, then FSUIPC fills the weather in and it is red. Correct?

Question is though, how can I get SIOC to receive these readings if you said it is not a compatible program of which FSUIPC Weather Signature works with.

[Pete Dowson]

To get the weather readings "filled-in", an application must have a specific signature. If this signature is accepted by FSUIPC, then FSUIPC fills the weather in and it is red. Correct?

Oh dear, you don't read much of what I write do you? :-(

It is just not that simple. Can I repeat the extract I showed you again, from the document you claim to have read? Look, don't you see there are 5 steps. Not just a signature, but an ICAO id for the Wx Station. As it clearly says, a total of 28 bytes written.

Then the program waits for the reply. it takes time for FSUIPC to send the request to FS, get the reply and populate the offsets. And that is assuming your access doesn't clash with anyone else's -- so you have to check for acceptance and be prepared to retry a few seconds later if not. See:

The procedure is as follows:

1. The application generates a "signature", any 32-bit pseudo-random number. It will use this as its temporary access key into this area.

2. Each time it wants to read weather for a station, it writes the signature to the ulSignature field and the ICAO to the chICAO field, AT THE SAME TIME -- i.e. a write of 8 bytes altogether*. If it wants to read the weather at a specific location instead, not at a station, then the ICAO code should be set instead to 4 spaces (" ") and the Latitude and Longitude fields should be written at the same time as the signature and this blank ICAO code. That makes a total of 28 bytes written (the dynamics and spare fields can be set zero. they are ignored).*

* You can write them with separate writes provided that (a) they are in the same FSUIPC_Process call, and (b) the writing of the Signature comes after the writing of the ICAO or Lat+Lon.

3. If the area is free (signature is zero) or this signature is the same as the last one written, then this access works, and FSUIPC obtains the requested weather. If, however, the signature does not match and someone else is reading the weather here, this write will be discarded and the weather already being read will continue to be updated.

A program which wants to be cooperative can use a signature of zero -- this works providing it is zero already, but it doesn't stop any other program from reading whatever it likes. The program which is being so friendly must be prepared to see a different ICAO or location being read than the one it asked for -- the WeatherSet2 program does this. You can ask it to display any location or WX sttion, but it will display whatever any other program is reading too, or, rather, instead.

4. FSUIPC clears down the signature approximately 14 seconds (at most) after it is validly written, thus opening up access to all again. If you want to keep the access for your own program you have to refresh the signature within this time, say every 5-8 seconds to be safe.

5. If the request succeeds, then at some time later (a few milliseconds probably, depending on FS frame rates) the weather details will be filled in and the chICAO field will reflect which weather station this is for. Furthermore, the ulTimeStamp field will be updated, and the Latitude, Longitude and Elevation of the ICAO station will be valid. If the request fails the weather at the aircraft is substitued, and if that fails the GLOBal weather is substituted. In the former case the ICAO id will be zeroed and the aircraft Lat/Lon set. In the latter case the ICAO identifier will be changed to 'GLOB'.

If programs want to check that the weather provided genuinely is for the location they requested, they should read the ICAO and/or Lat/Lon back in the same Process call as reading the weather data, and check that they are as they requested.

Why do you want this data for a weather station which might be many miles away? What on Earth is the point?

Question is though, how can I get SIOC to receive these readings if you said it is not a compatible program of which FSUIPC Weather Signature works with.

I did not say that. I said that the procedure, as documented, has to be programmed. Is SIOC a Weather Program? Is it written with this job in mind? I thought it was merely a hardware interfacing program, nothing to do with weather. For weather programs look at ActiveSky and FSMeteo, for example. They use this facility because they are programmed to. But a program designed to do something entirely different won't be programmed to do the same thing. Don't you see this?

I am about to give up with you I'm afraid. You seem to only read a little of each of my replies, and at that rate it will take several more weeks. you do not seem to appreciate that handling data in computers needs programming. Folks write programs to achieve certain things. SIOC is not a weather program.

:-(

Pete