Writing New Weather information

[scruffyduck]

Hi Pete

I am just now getting to grips with the NWI for FS9 and have a couple of questions:

Firstly I assumed that I needed to write all 1024 bytes at one go but reading this post:

http://forums.simflight.com/viewtopic.pht=weather

it seems that I don't need to. In the same post you write that to get the data to change I need to write to the signature field - is that just any randomised number. I read in your notes that it is important for reading data - but is that what causes the changes to take effect.

I am pretty much at the start of the learning curve on this. My first attempt was to put the vairous bits of data into the weather structure using GLOB and then write it to FS. I am actually writing it every 10 seconds of so to fix it - but I suspect that is the wrong thing to be doing :? :?

At the moment I am getting the expected results with the weather items such as visibility and pressure which are not set in layers. Do I need to keep track of the layers myself? I am not sure how they work. For example could I send that there are 24 layers and say treat each one as being related to 1000ft of altitude. The one that gets the data is the one which relates to the base of the items such as cloud or wind. Probably that is the completely wrong way to go about it. Do the layers have to be in order so that layer 1 is lower than layer 2, or are they just items in an array?

Sorry for so many questions

[Pete Dowson]

Firstly I assumed that I needed to write all 1024 bytes at one go but ...

You can do, but it's really more efficient just to write each part. Obviously the fields which are adjacent would be more efficient together, and this would apply really to anything less than 16 bytes or so apart (the overhead for a new block). But you can do it all in one process. The only thing to be sure of is to write the command (at offset C800) LAST, as it is that which triggers FSUIPC into action.

In the same post you write that to get the data to change I need to write to the signature field - is that just any randomised number. I read in your notes that it is important for reading data - but is that what causes the changes to take effect.

I've just re-read that, and I've had to make a correction. Sorry. I was pretty busy and confused then I think.

I shall have to write some extra documentation for the NWI, because even I had to refer to my code to make sure of some of these things.

Here's the low-down on signatures and what triggers what. This is sort of a draft expansion for the current flimsy documentation, so please have a good read and let me know if it makes things clear:

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

SIGNATURES and Reading Weather

The signature fields are only really used when READING weather, in the CCxx offsets. This is to prevent one application reading one thing and another reading another before the first has picked up his data. Since, for reading, the signatures are so important, it is they which trigger the actual operation in FSUIPC of asking FS for the weather at XXXX ICAO or the particular Lat/Lon.

When reading weather it is also important to wait for the TimeStamp to change to indicate that it has been read. This can give rise to some interesting situations if your program runs on a WideFS client PC. I have recently devised a scheme which I think makes things foolproof (and this applies to other read facilities in FSUIPC which use signatures and timestamps):

At the start of the program, sleect or generate a pseudo-random number as a starting signature.

Then, for each read:

1. INCREMENT your signature

2. Put together the FSUIPC block of requests and issue the Process call. The order would be:

(a) read the timestamp CC04 (to be checked AFTER)

(b) write ICAO to CC08, or Lat & Lon to CC10 & CC18 with all spaces to CC08

© write signature to CC04 (must be last to trigger the read)

(d) read CC24

(e) FSUIPC_Process

3. If CC04 was read as non-zero, retry from step 1 (this is effectively a

normal CC04 wait, in case something else was reading already).

4 Else, wait for CC24 to change (i.e. read CC24/process till CC24 reads differently).

Now this is good for reading a single weather station, such as for giving ATIS reports or ATC instructions. If you want to read a whole bunch or stations or positions, for instance in order to build a weather map, then this will be too slow. Because you are incrementing the signature each time, the next request won't be accepted till the previous one has timed out -- about 8 seconds in the current FSUIPC.

So, when reading a whole bunch of weather stations or positions, after the first time for the batch, you need to skip step 1 (i.e. leave the signature the same) and bypass the check in step 3. This is ONLY for that batch, mind. Next batch, first time through, you do the whole thing.

COMMANDS and Writing Weather

When writing weather to a WX station, via offsets C8xx, all you have to do is write all the assorted weather data you want to set, but be sure to write the Command value, at offset C800, last. It is writing that which triggers FSUIPC into actually doing anything. Prior to that, anything written to the rest is simply ignored.

To avoid other programs interfering with what you want to write, it is best, however, to write it all in one call to FSUIPC_Process. In other words, you can have as many separate FSUIPC_Writes to set the various weather aspects (those you don't want to change could be copied direct from the Read area, of course). At then end of the sequence of Writes, you have one to write the command, then the Process call.

The normal rules about efficiency apply to these writes. It is more efficient to have less numbers of separate writes, so writing larger areas, but only if this doesn't involve writing masses which you don't need. Writing all 1024 bytes is easier program-wise, but less efficient as far as the data transfer goes. But bear in mind that each separate write or read carries an overhead of about 16 bytes, and of course a little extra processing time in FSUIPC.

After each weather write you do need to wait for the TimeStamp at C824 to change before writing the next, otherwise the data you then write may supersede the previous one. FSUIPC can only write one station at a time using the interface it has to FS's weather engine.

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

My first attempt was to put the vairous bits of data into the weather structure using GLOB and then write it to FS. I am actually writing it every 10 seconds of so to fix it - but I suspect that is the wrong thing to be doing :? :?

I'm afraid that, although after clearing all the weather, setting GLOBal weather does take effect, the weather at each WX station gradually becomes localised. Once it is using its own local weather, no amount of simply writing GLOBal weather again will change it -- such writes will only succeed for stations not yet "localised" (i.e. usually those well out of range of the aircraft).

I'm afraid, using only GLOBal weather, you would have to periodically "clear all weather" as well, to enable any changes. This would be okay if you could do it without it having any real effect until you then set the new global weather, but I'm afraid the effects are noticeable and not nice.

What it comes down to, really, is that for decent weather control in FS2004 you have to set local weather -- i.e. weather at local weather stations.

At the moment I am getting the expected results with the weather items such as visibility and pressure which are not set in layers. Do I need to keep track of the layers myself?

Yes. You simply specify the number of layers and provide the values for each. There's no automatic layer generation if that's what you mean.

Do the layers have to be in order so that layer 1 is lower than layer 2, or are they just items in an array?

They are items in an ordered array, lowest to highest.

Regards,

Pete

[scruffyduck]

Hi Pete

Many thanks for that

Sorry. I was pretty busy and confused then I think

Well I don't think so - how you managed to sort out what MS had done is definitely in the miracle happens here box as far as I am concerned.

So it looks like I needs to get into writing to individual weather stations then :cry: That makes it kinda difficlut to completely control the weather at a airport which is not a weather station though as far as I can see

The information on reads and writes make sense to me. Just reading the original documentation again I do not need to specify a lat/lon if I specify an ICAO - is that correct? Is the best way to get a list of weatherstations to download a metar cycle. I could then add something into the program to stop the use of non valid ICAOs

[Pete Dowson]

That makes it kinda difficult to completely control the weather at a airport which is not a weather station though as far as I can see

Yes, you'd need to set those around you. I don't think FS has any way of recording weather for anything by the at the weather stations. Everything in between is interpolated.

At some of the larger airports, in areas where there are several airports close to, and all are WX stations, you can get the weather varying over the one airport, due to interpolation. This can be a little odd when downloaded weather features weather for near stations with different reporting times!

The information on reads and writes make sense to me. Just reading the original documentation again I do not need to specify a lat/lon if I specify an ICAO - is that correct?

For READING weather, you can use either. If it's a lat/lon between stations it will be interpolated. For WRITING weather, the ICAO is needed -- not only that, it must be one listed in FS's list (which does change from time to time -- current one is the WxStationList.BIN in the same folder as your FS9.CFG file. Don't worry about the ".BIN" filetype. It's just a compact list of 4 characters per station, just the ICAOs). The positions and names are given in files in the weather folder in the main FS folder.

Is the best way to get a list of weatherstations to download a metar cycle. I could then add something into the program to stop the use of non valid ICAOs

It won't do any harm writing to invalid ICAOs. They just won't work. Depending where you get your METARs from, they won't necessarily correspond to FS's (from Jeppesen) in any case. The main weather programs do try to set stations which aren't listed and come to no harm.

If you want to be sure, or even want a data base of positions and names, check out the files in the FS weather folder. note that locations (lat/lon/alt) are in 32-bit "floats" in those.

Regards,

Pete