Getting the weather

[tim arnot]

I'm trying to read the weather at the nearest weather station, but getting myself into somewhat of a muddle in the process. I'm using Paul's managed DLL, and FSX (the code will also need to cope with FS9, but one thing at a time...)

The scenario is: My plane is parked at Wellesbourne. I request the nearest weather, which should be Coventry (EGBE), and that appears to be fine.

But I also want to get weather information about my planned route. And so I try passing in my route details, and here it comes unstuck. Sometimes I et back EGBE, sometimes I get back ???? (presumably that's the 'global' weather, and occasionally I get back the weather station I was after (although not till the following call!)

Now there has to be something that I haven't understood, given that the 'New Weather Interface' doc only talks about FS9, and the only FSX reference I can find is a bried comment under the B000/C000 offsets

The offsets referenced are:

        Offset wxFSX = new Offset("Weather", 0xB800, 2048);     // Weather Reporting Area (FSX only)
        Offset wxSetICAO = new Offset("Weather", 0xCC08, 5);    // Set ICAO
        Offset wxSetLat = new Offset("Weather", 0xCC10);        // Set Latitude
        Offset wxSetLon = new Offset("Weather", 0xCC18);        // Set Longitude
        Offset wxTimeStamp = new Offset("Weather", 0xCC24);        // Time Stamp

This has been mashed about a bit in trying ti get it to work, but hopefully you can understand the gist of it...

The snippet is called from a timer. It's passed a lat, lon and an ID code. The ID code is "" for "nearest weather to user", otherwise it is a waypoint identifier, which may be an airport ICAO, VOR id etc.

            if (FSUIPCConnection.FlightSimVersionConnected == FlightSim.FSX )
            {
                FSUIPCConnection.Process("Weather");
                uint timeStamp = wxTimeStamp.Value;
                uint ts2=0;
                LogEvent(this, new LogEventArgs("WX Start time stamp:  " + timeStamp));

                if (wptID == "")
                {
                    wxSetICAO.Value = "<??>";   // Nearest station to user
                }
                else
                {
                    if (wptID.Length == 4)
                        wxSetICAO.Value = wptID;
                    else
                        wxSetICAO.Value = "    ";   // Nearest station to waypoint?
                    wxSetLat.Value = Lat;
                    wxSetLon.Value = Lon;
                }
                wxSignature.Value = 0;
                FSUIPCConnection.Process("Weather");
                ts2 = wxTimeStamp.Value;
                LogEvent(this, new LogEventArgs("WX time stamp:  " + ts2));
                while (timeStamp == ts2)
                {
                    System.Threading.Thread.Sleep(20);
                    FSUIPCConnection.Process("Weather");
                    LogEvent(this, new LogEventArgs("Nearest WX to " + wptID + " (LAT " + Lat.ToString() + " LON " + Lon.ToString() + "): " + wxFSX.Value.ToString()));
                    ts2 = wxTimeStamp.Value;
                    LogEvent(this, new LogEventArgs("WX time stamp:  " + ts2));
                } 
                if (wxFSX.Value != "")
                {
                    Weather wx = new Weather(wxFSX.Value);
                    WeatherReportEvent(this, new WeatherReportEventArgs(wx, wptID == "" ? false : true));
                }
            }

It's hard to post logs, since they run into megabytes very quickly, but If you could point me in the right direction, I'd be very grateful -- this is driving me bald!

One area of concern is the time stamp. I'm not sure if this is needed for FSX - sometimes it doesn't seem to change for several seconds. I'm not even sure I'm referencing the right timestamp, since there seems to be one associated with each Cxxx block. Any light you can shed will be a great help.

Thanks

Tim

[Pete Dowson]

I'm trying to read the weather at the nearest weather station, but getting myself into somewhat of a muddle in the process. I'm using Paul's managed DLL, and FSX (the code will also need to cope with FS9, but one thing at a time...)

The scenario is: My plane is parked at Wellesbourne. I request the nearest weather, which should be Coventry (EGBE), and that appears to be fine.

So, you don't have a problem reading weather at "nearest weather station"?

But I also want to get weather information about my planned route. And so I try passing in my route details, and here it comes unstuck. Sometimes I et back EGBE, sometimes I get back ???? (presumably that's the 'global' weather

No. Global weather is "GLOB". Where are you reading this "????"? That's normally part of the FSX Metar string for weather at points which aren't weather stations. It is also used in requests to get weather at the user aircraft.

Now there has to be something that I haven't understood, given that the 'New Weather Interface' doc only talks about FS9, and the only FSX reference I can find is a bried comment under the B000/C000 offsets

Surely the FSX Offsets Status tells you, or at least implies, that the facilities are totally compatible / identical, except for the extras mentioned, like the METAR strings facilities. The differences in the areas you mention are explicitly colour coded -- blue for additions, red for differences.

You seem to miss some of the point of FSUIPC, and that is compatibility. I dared not change the NWI. I even had to support the old AWI and the older still FS98 weather offsets. All of them, all supported in FSX, all in the name of compatibility! Urrrggghhh.

The offsets referenced are:

Offset wxFSX = new Offset("Weather", 0xB800, 2048); // Weather Reporting Area (FSX only)

As documented, that's new to FSX and provides a METAR string. Are you decoding that?

This has been mashed about a bit in trying ti get it to work, but hopefully you can understand the gist of it...

The snippet is called from a timer. It's passed a lat, lon and an ID code. The ID code is "" for "nearest weather to user", otherwise it is a waypoint identifier, which may be an airport ICAO, VOR id etc.

Two important points there. first the ID code to force FSUIPC to use the Lat/Lon is [b]FOUR SPACES[/b][i] not[/i] ""!! Check again item 2 in the list of steps for reading the weather:

[b]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[color=#FF0000] 4 spaces (" ")[/color] 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[/b]

Second, there is absolutely no point using any old "waypoint identifier, which may be an airport ICAO, VOR id etc.". If you are providing an ID it must be a weather station known to FSX -- most 4-letter airports are (but not all). Rarely US 3-letter airports, and certainly no waypoints, VORS etc. You just won't get a meaningful response for unknown weather stations. If you don't know, always use Lat/Lons. Programs like Radar contact use only lat/lons, not IDs for just that reason.

It's hard to post logs, since they run into megabytes very quickly, but If you could point me in the right direction, I'd be very grateful -- this is driving me bald!

Use weather logging. Use WEATHERSET2 to compare results. Double-check that you are reading and writing the right things in the right sequence.

One area of concern is the time stamp. I'm not sure if this is needed for FSX - sometimes it doesn't seem to change for several seconds. I'm not even sure I'm referencing the right timestamp, since there seems to be one associated with each Cxxx block.

It is always applicable. It tells you when data is available. Getting the weather is NOT immediate -- a request is placed. The data arrives later. The reading interval could be anything for 1 to several seconds -- SimConnect is a busy beast and FSUIPC refuses to overload it with weather requests (though this is adjustable with obscure parameters). The relevant timestamp is ALWAYS the one in the zone in which you are performing the transaction. How else could it be? What would be the point otherwise?

Regards

Pete

[tim arnot]

So, you don't have a problem reading weather at "nearest weather station"?

Poor editing on my part -sorry. The nature of the question changed during the writing

No. Global weather is "GLOB". Where are you reading this "????"? That's normally part of the FSX Metar string for weather at points which aren't weather stations. It is also used in requests to get weather at the user aircraft.

I am reading it from the B800 "FSX Extended METAR" block. The data is also reproduced in FS9 format in the C000 block. Here are examples of the two FSX returns:

18:18:56 WX Start time stamp:  34234669
18:18:56 Raising PLAN WX Event: EGBE&A86 041239Z 26208KT&D304NG 228V296 32128KT&A828MG 32127KT&A1742NG 32122KT&A2657NG 34523KT&A3571NG 05731KT&A5400NG 22438KT&A7229NG 32750KT&A9058LG 33451KT&A10277NG 32237KT&A11801LG 80KM&B-1586&D2652 2ST035&ST001FNMN000N 06/02 -2/-17&A828 -5/-10&A1742 -11/-21&A2657 -17/-31&A3571 -28/-32&A5400 -36/-49&A7229 -41/-49&A9058 -45/-49&A10277 -46/-49&A11801 Q1000 @@@ 30 -2 321 28 | 60 -5 321 27 | 90 -11 321 22 | 120 -17 345 23 | 180 -28 57 31 | 240 -36 224 38 | 300 -41 327 50 | 340 -45 334 51 | 390 -46 322 37 | 

18:18:58 WX Start time stamp:  34238959
18:18:58 Raising PLAN WX Event: ????&A0 041253Z 01100KT&D310NG 80KM&B-1500&D2748 1ST040&ST001FLMN000N 03/01 Q1001 

I've never had a "????" return from SimConnect - it only ever throws a Weather not available exception if you ask it for data that's not at a weather station

Surely the FSX Offsets Status tells you, or at least implies, that the facilities are totally compatible / identical, except for the extras mentioned, like the METAR strings facilities. The differences in the areas you mention are explicitly colour coded -- blue for additions, red for differences.

You seem to miss the point of FSUIPC, and that is compatibility. I dared not change the NWI. I even had to support the old AWI and the older still FS98 weather offsets. All of them, all supported in FSX, all in the name of compatibility!!!

It implies, and I seek confirmation. You have been neck-deep in FSUIPC for many years and such things to you seem blindingly obvious. For someone who is just starting out, that is not the case. I am also approaching from the opposite direction, namely that I have an existing working connection with SimConnect, but have been asked to add support via FSUIPC. Which is why I'm trying to work with the newer FSX data rather than old compatible stuff.

The offsets referenced are:

        Offset wxFSX = new Offset("Weather", 0xB800, 2048);     // Weather Reporting Area (FSX only)

As documented, that's new to FSX and provides a METAR string. Are you decoding that?

Yes. I already have code to decode the FSX extended METAR, so it makes sense to use it.

Two important points there. first the ID code to force FSUIPC to use the Lat/Lon is FOUR SPACES not ""!! You haven't read item 2 in the list of steps for reading the weather:

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

Yes I did. Read my code again. The "" is the waypoint value that is passed in to this code from outside. It's significance is "no waypoint" and triggers to code to look for the nearest weather to the aircraft. If the id is "", then it calls FSUIPC with "<??>" which is clearly documented as "give me the nearest weather station to the user aircraft". And this is working fine.

When the id is specified, if I think it might be a weather station (a simplistic test - just checks for a 4 character length string), it will use the value directly. Otherwise it uses four spaces " ".

This is where I'm getting problems -- specifying four spaces only ever brings back the "????" result shown above. Specifying an ICAO does get the right data, but it gets very out of sync.

Second, there is absolutely no point using any old "waypoint identifier, which may be an airport ICAO, VOR id etc.". If you are providing an ID it must be a weather station known to FSX -- most 4-letter airports are (but not all). Rarely US 3-letter airports, and certainly no waypoints, VORS etc. You just won't get a meaningful response for unknown weather stations. If you don't know, always use Lat/Lons.

Which is why I have this test. I started off just using the lats / lons, and " ", but that never got me back anything other than ????

Use weather logging. Use WEATHERSET2 to compare results. Double-check that you are reading and writing the right things in the right sequence.

How do you make WEATHERSET2 bring back data from an arbitary station or lat/lon? All the display appears to be read only and there are no boxes to type these thing in to.

It is always applicable. It tells you when data is available. Getting the weather is NOT immediate -- a request is placed. The data arrives later. The reading interval could be anything for 1 to several seconds -- SimConnect is a busy beast and FSUIPC refuses to overload it with weather requests (though this is adjustable with obscure parameters). The relevant timestamp is ALWAYS the one in the zone in which you are performing the transaction. How else could it be? What would be the point otherwise?

Yes but the FSX-format data comes back in the B800 zone, which does NOT have a timestamp. Hence me not being sure which one to use. I'm using the CC00 block one on the basis that that is where the lat/lon is written. But if the data comes back in B000... Or am I supposed to read the FS9 format data first from C000 (would I then use the timestamp from the Read block or the write block?) and *then* read the FSX data?

[Pete Dowson]

I've never had a "????" return from SimConnect - it only ever throws a Weather not available exception if you ask it for data that's not at a weather station

It returns the ???? for requests for weather at a location, because such requests have nothing to do with weather stations. They report interpolated weather. It's a different SimConnect API call. If you enable SimConnect's logging you'll see.

I am also approaching from the opposite direction, namely that I have an existing working connection with SimConnect, but have been asked to add support via FSUIPC. Which is why I'm trying to work with the newer FSX data rather than old compatible stuff.

Okay, understood.

Yes I did. Read my code again.

Sorry, i did not read your code in the first place. It is really not for me to comment on code I don't understand. Sorry.

The "" is the waypoint value that is passed in to this code from outside. It's significance is "no waypoint" and triggers to code to look for the nearest weather to the aircraft. If the id is "", then it calls FSUIPC with "<??>" which is clearly documented as "give me the nearest weather station to the user aircraft". And this is working fine.

Okay, good.

This is where I'm getting problems -- specifying four spaces only ever brings back the "????" result shown above.

The 4 spaces call uses a different API into SimConnect as you'd see if you logged it. The call is

SimConnect_WeatherRequestInterpolatedObservation

It is the only call which gives weather at specific locations rather than at weather stations. If that is not what you want, best not to use it. Sorry, I'm not sure why you would not know this if you have already implemented a direct SimConnect interface.

Specifying an ICAO does get the right data, but it gets very out of sync.

Out of sync with what?

Which is why I have this test. I started off just using the lats / lons, and " ", but that never got me back anything other than ????

But that's what you always get. That's what that call is for -- not to get weather at a weather station, but to get weather at a Lat/Lon location. How do you expect to have an ICAO ID for every lat/lon location? The ???? signifies it isn't a Weather Station METAR.

How do you make WEATHERSET2 bring back data from an arbitary station or lat/lon? All the display appears to be read only and there are no boxes to type these thing in to.

Evidently you've not read the short text documentation at all? It isn't very long and shouldn't be too much of a chore to read. You can use WeatherSet2 to set weather at stations and to read weather at weather stations or at Lat/Lon locations. How to do it is set out in easy-to-read short text. WeatherSet2 was written as a test aid for the NWI, just as WeatherSet(1) before it was the test aid for the AWI interface.

Yes but the FSX-format data comes back in the B800 zone, which does NOT have a timestamp.

But the request was made in the area where the timestamp is relevant, of course. Isn't that logical? Why have a timestamp in a place divorced from the request? Please apply a little logic and the answers to your questions will be easy. The METAR strings being returned are just a bonus for FSX, additional to the original NWI facilities transposed from FSUIPC3. Why would I then move the timestamps away from their place associated with the request and the returned interpreted data? Can't you see that would be nonsense?

Regards

Pete

[tim arnot]

It returns the ???? for requests for weather at a location, because such requests have nothing to do with weather stations. They report interpolated weather. It's a different SimConnect API call. If you enable SimConnect's logging you'll see.

Ok, so I learn these are interpolated values. Now I can figure out what to do with them.

The 4 spaces call uses a different API into SimConnect as you'd see if you logged it. The call is

SimConnect_WeatherRequestInterpolatedObservation

It is the only call which gives weather at specific locations rather than at weather stations. If that is not what you want, best not to use it. Sorry, I'm not sure why you would not know this if you have already implemented a direct SimConnect interface.

Because my program is not interested in interpolated data, and so I don't request it. It's not what I want, so I don't use it. As for "I'm not sure why you would not know this", like 99.9% of all developers I don't know the intimate minutae of every function that I don't use, and neither can I be expected to. That's why support forums were invented.

Out of sync with what?

Out of sync with itself. I make a call that requests data for weather station "AAAA", and watch the timestamp change, and I've got back, say, "????" (purely for the sake of argument). I wait for maybe 10 seconds just to see if anything happens, but no. Then I call again for station "BBBB", and immediately back comes data for "AAAA"

But that's what you always get. That's what that call is for -- not to get weather at a weather station, but to get weather at a Lat/Lon location. How do you expect to have an ICAO ID for every lat/lon location? The ???? signifies it isn't a Weather Station METAR.

Because Simconnect behaves differently, and that's where I've come from. Now I understand that FSUIPC gives me interpolated data, I can deal with it appropriately.

Evidently you've not read the short text documentation at all? It isn't very long and shouldn't be too much of a chore to read. You can use WeatherSet2 to set weather at stations and to read weather at weather stations or at Lat/Lon locations. How to do it is set out in easy-to-read short text. WeatherSet2 was written as a test aid for the NWI, just as WeatherSet(1) before it was the test aid for the AWI interface.

Oh but I have. Backwards, forwards, printed, upside down. Nothing that I click on lets me type or change anything. Which is why I asked.

But the request was made in the area where the timestamp is relevant, of course. Isn't that logical? Why have a timestamp in a place divorced from the request? Please apply a little logic and the answers to your questions will be easy. The METAR strings being returned are just a bonus for FSX, additional to the original NWI facilities transposed from FSUIPC3. Why would I then move the timestamps away from their place associated with the request and the returned interpreted data? Can't you see that would be nonsense?

It can be inferred, but it isn't stated. Because this piece of code isn't working right, everything is suspect and open to query. "Logic" can be faulty, and what isn't stated must be assumed, and we all know where assuptions can get us. Rule one in aviation is "there are no stupid questions", and this should also be applied to support. Planes have crashed and people have been killed because someone didn't query something that somebody else thought should be bleedin' obvious. I'm not suggesting this is anything as momentous, but no amount of intimidation or questioning my logic is going to stop me asking a "dumb" question if I think something isn't clear.

BTW, you didn't answer, if I'm writing to CC00 and reading from C000 (I infer, since the B800 Metar data is "just a bonus"), do I monitor the CC timestamp or the C0 timestamp? Is it the writer or the reader? :wink:

Cheers

Tim

[Pete Dowson]

Out of sync with itself. I make a call that requests data for weather station "AAAA", and watch the timestamp change, and I've got back, say, "????" (purely for the sake of argument). I wait for maybe 10 seconds just to see if anything happens, but no. Then I call again for station "BBBB", and immediately back comes data for "AAAA"

Sounds like you aren't following the request protocol. Both the signature and the ICAO id (or Lat Lon) must be written in the same FSUIPC write call, or else in two writes but in the same Process call with the ICAO then written first. The activating offset is the signature. If you get this wrong you'd get exactly the effect you describe, because it will be using the previous ID or location.

But that's what you always get. That's what that call is for -- not to get weather at a weather station, but to get weather at a Lat/Lon location. How do you expect to have an ICAO ID for every lat/lon location? The ???? signifies it isn't a Weather Station METAR.

Because Simconnect behaves differently, and that's where I've come from.

No, SimConnect does NOT behave differently. FSUIPC is using SimConnect 100% for weather. What you get is EXACTLY what SimConnect returns if you ask for weather AT a latitude/longitude. Evidently you've never done this before, and I'm not sure why you want to now, via FSUIPC, when you never did directly?

Now I understand that FSUIPC gives me interpolated data, I can deal with it appropriately.

It only does so for Lat/Lon or "at aircraft" weather. I don't understand how you expected weather at any chosen location to be anything other than interpolated. FS does not store weather for every possible position, it interpolates between weather stations.

Oh but I have. Backwards, forwards, printed, upside down. Nothing that I click on lets me type or change anything. Which is why I asked.

You can't change weather at any lat/lon, only at weather stations. This is an FS restriction -- it doesn't store weather at every location. To select a weather station or a lat lon you simply put the mouse in the correct place and press Enter, as documented. If you select a weather station all of the other fields will accept Enter and come up with an editing dialogue for the values.

BTW, you didn't answer, if I'm writing to CC00 and reading from C000 (I infer, since the B800 Metar data is "just a bonus"), do I monitor the CC timestamp or the C0 timestamp? Is it the writer or the reader? :wink:

Oh dear. Sorry, but how do you get yourself so confused? If you write to CC00 you read from CC00, not C000. Please see the descriptions for each slot, from the text documentation:

C000-C3FF (Area 0): Weather at aircraft

C400-C7FF (Area 1): Last set global weather

C800-CBFF (Area 2): Weather setting area

CC00-CFFF (Area 3): Weather reading area

If you are reading weather by request you use CC00. Nothing you do in CC00 will affect the C000 area which continues on doing its job regardless, as does C400.

Sorry if I appear impatient, but I don't understand what it is that gets you so confused. Sorry. Even relatively non-programmers have not been confused by this clear demarcation of offset functions. What is it that makes it so for you, now? I'll fix it if I know.

Pete

[tim arnot]

C000-C3FF (Area 0): Weather at aircraft

Pete

Actually that's not the immediate problem. I think the confusion arose from seeing C000 coming back in the log file, and I just ended up getting muddled in this conversation. The code at this time is only reading the B800 block for FSX data (but it will need to look at the CC00 block for FS9, so you have at least saved a repeat match! :lol: )

The activating offset is the signature. If you get this wrong you'd get exactly the effect you describe, because it will be using the previous ID or location.

That I think is the crux of the matter.

Sometimes it takes another pair of eyes (and big writing) to spot what is staring you in the face :wink:

Sorry if I appear impatient, but I don't understand what it is that gets you so confused. Sorry. Even relatively non-programmers have not been confused by this clear demarcation of offset functions. What is it that makes it so for you, now? I'll fix it if I know.

It's the gnawing belief that I haven't got something right, and I know it has to be somewhere in this area, so I question everything, even if it's "obvious" and something will eventually fall out. If I hadn't pushed the issue, the answer wouldn't have come out (at least not so quickly). I don't care if it makes me look like an idiot - all I'm doing is trying to get my code working, and if that means looking like an idiot, well I'm thick skinned, and I've been called much worse :wink:

Cheers

Tim

[Pete Dowson]

I don't care if it makes me look like an idiot ...

I don't think it did. I just get worried that there's something in the way I've written the stuff up which is misleading. Naturally this part is intended for programmers, but maybe too much is assumed.

Hope everything works for you now!

Regards

Pete

[tim arnot]

There are some optimisations left to do, such as a check against wxstationlist.BIN, but yes, all is now tickety boo. Thanks. :)

Tim

[Harvey Eidenberg]

JustFlight advises that FSUIPC (unregistered) is required to use the weather gauge on their Embraer 170.  I have downloaded the latest, FSUIP 3.999z4, and enabled all of the weather-related switches on the panel.  Still no weather, or TCAS information.  The Weather button on the FSUIPC cfg panel will not turn ON.  Thanks for helping!  Al.

[Pete Dowson]

JustFlight advises that FSUIPC (unregistered) is required to use the weather gauge on their Embraer 170.  I have downloaded the latest, FSUIP 3.999z4, and enabled all of the weather-related switches on the panel.  Still no weather, or TCAS information.  The Weather button on the FSUIPC cfg panel will not turn ON.  Thanks for helping!  Al.

 

Sorry, what "Weather button" on what "FSUIPC cfg panel"? I'm lost here I'm afraid.

 

Also, I don't know the aircraft and didn't even know it used FSUIPC. I think you need their support to help with this.

 

BTW, I suppose you do realise that you added this message to a 4 year old thread about a completely different subject? Isn't yours important enough to merit a fresh thread?

 

Regards

Pete

[Harvey Eidenberg]

Hi Pete,

 

I'm a brand new just signed on member of the forum, and embarrassingly, couldn't where to post a new topic.  I appreciate you replying to my post, nevertheless, and I'm probably lucky you saw it!  

 

I was referring to the FSUIPC Options and Settings box that appears when clicking on FSUIPC in the Modules folder when FS2004 is started.  The box to the right of the Normal defaults and Clear All Weather is the Weather Settings Off box.  Can this box be turned ON in the unregistered FSUIPC?  

 

The support people at Just Flight, who markets the Embraer series of eJets, advises that just the unregistered FSUIPC, newest version, is sufficient to use the Weather gauges on the Embraer aircraft.  If the registered FSUIPC is actually required to turn on the Weather settings, I will gladly purchase it.  Thanks again for your assistance!

 

Al.

[Pete Dowson]

I was referring to the FSUIPC Options and Settings box that appears when clicking on FSUIPC in the Modules folder when FS2004 is started.  The box to the right of the Normal defaults and Clear All Weather is the Weather Settings Off box.  Can this box be turned ON in the unregistered FSUIPC?

 

All that does is select the "clear weather" theme, in order to clear the weather. The first click just resets any weather set by an external Weather application which set its weather through FSUIPC, the second click does the weather clearance to effectively select "no weather". It isn't "on" or "off" at all. It's an action. and it really isn't relevant unless you are setting the weather through an FSUIPC application.

 

There are no user facilities in an unregistered install of FSUIPC except that one, which is related to weather setting FSUIPC applications, and the option to divert messages sent to fSUIPC for display on the FS screen. Oh, and the logging facilities. An unregistered install is only useful as an interface to FSUIPC-using add-ons.

 

The support people at Just Flight, who markets the Embraer series of eJets, advises that just the unregistered FSUIPC, newest version, is sufficient to use the Weather gauges on the Embraer aircraft.

 

If they read the weather through FSUIPC it needs no action whatsoever on your part to enable this in FSUIPC. It is just one of the interfaces supported for any application or add-on.

 

If the registered FSUIPC is actually required to turn on the Weather settings, I will gladly purchase it.  Thanks again for your assistance!

 

No, you do not need to register in order to enable the application / add-on interface. Just install it. That's all.

 

Pete