Radar Precipitation Intensity

[pilotjohn]

Would you know how the simulated radar echoes are determined by RXP or CaptainSim radar?

Would any of the current offsets provide anything comparable, such as precipitation intensity at aircraft, including cloud type? I see the cloud type and coverage offsets (0x0E84...), but I'm guessing that doesn't exactly tell me whether I'm IN cloud. I also see 0x04CB but that doesn't tell me whether it's at the aircraft.

I'm trying to create some incentive for avoiding weather (since, as-is, it makes no difference whether you pummel through heavy precipitation in a CB cloud or not) by increasing the failure rate of systems through my random failure script if you're in certain weather conditions.

[Pete Dowson]

Would you know how the simulated radar echoes are determined by RXP or CaptainSim radar?

No, not offhand. For FSX they could simply be reading the cloud distributions from SimConnect. For FS9 or FSX they could simply be reading METARs for weather stations in range, and interpolating, much as SA_WXR does, for instance. If they are getting more accuracy and detail then I can only assume they've managed to hack into the FS code.

Would any of the current offsets provide anything comparable, such as precipitation intensity at aircraft, including cloud type? I see the cloud type and coverage offsets (0x0E84...), but I'm guessing that doesn't exactly tell me whether I'm IN cloud. I also see 0x04CB but that doesn't tell me whether it's at the aircraft.

Cloud types readable are only cirrus, stratus, cumulus or cumulonimbus (storm). In FSX there's no information about cloud top altitudes, only cloud bases. And unless the cloud is 8 oktas there's not even a way of telling whether you are in or between clouds even at the right altitudes. It is all very unsatisfactory. These things were on the list for "future SimConnect updates". :-(

Pete

[pilotjohn]

By cloud distributions do you mean what's given in the SimConnect METARs?

Is the precipitation types/rate (0x04CB) give at aircraft, or is that also based on your METAR translations? How about the cloud/wind turbulence at aircraft?

[Pete Dowson]

By cloud distributions do you mean what's given in the SimConnect METARs?

No. SimConnect, from SP2 I believe, includes this call:

SimConnect_WeatherRequestCloudState

The SimConnect_WeatherRequestCloudState function requests cloud density information on a given area.

The main purpose of this function is to enable weather radar.

If the call is successful, the cloud state information will be returned in a SIMCONNECT_RECV_CLOUD_STATE structure. This structure will contain a two dimensional array of byte data. The array will be 64 x 64 bytes in size, and each byte will contain a value indicating the cloud density for each cell. A value of zero would mean no clouds, to a maximum of 255. The area defined in this call is divided into 64 by 64 cells, so the size of each cell will be determined by the values given for the parameters above. Note that the entire World's weather is not simulated all the time, but only a region around the user aircraft, with a radius of approximately 128 kilometers, is modeled at any one time. A request for cloud data outside this region will simply return zeros.

The defined area can cross the Equator or the Greenwich Meridian, but it cannot cross the Poles or the International Date Line.

Is the precipitation types/rate (0x04CB) give at aircraft, or is that also based on your METAR translations? How about the cloud/wind turbulence at aircraft?

04CB is at the aircraft location, but not necessarily the aircraft's altitude. It is precipitation to ground. All weather data provided by FSUIPC is by reading it from FSX, which ofr FSX means FSX SimConnect style METAR readouts (which are subtly different from METARs being written). For the aircraft location it is the interpolation ptrovided at that position provided by SimConnect on request. It's similar in FS9 and before, but the data is obtained in binary form from FS's internals.

Cloud/wind turbulence at the aircraft is derived from determining the wind layer you are in and checking that, normally in the C000-C3FF area. but in FSX there are new offsets for this at 0E88 and 0E98.

Regards

Pete

[pilotjohn]

No. SimConnect, from SP2 I believe, includes this call:

Cloud/wind turbulence at the aircraft is derived from determining the wind layer you are in and checking that, normally in the C000-C3FF area. but in FSX there are new offsets for this at 0E88 and 0E98.

Is the cloud SimConnect_WeatherRequestCloudState data available from an offset? If not, could it be added, either as call for some static alt/lat/lon around the aircraft, or a similar mechanism to the current weather system, where the request could be written in one area, and read from another? Maybe even reuse the existing weather area?

Is 0xE85-0xE88 retrieved through this mechanism or METAR?

[Pete Dowson]

Is the cloud SimConnect_WeatherRequestCloudState data available from an offset?

No.

If not, could it be added

Not really -- I'd really be loathe to add it now. It's a SimConnect function only and has no similarity to anything in FS9 and before, which is really where FSUIPC's job lies -- providing compatibility. I know I've added some FSX only stuff, but only where it fitted in with the FSUIPC way of doing things. This doesn't, and it not only needs another one of those horrible multi-user interlock and timing mechanisms, which I swore I'd never do again, but it also needs 4096 bytes of valuable offset real estate. The latter is limited to the current 65k because if it ever exceeds that i have a massive WideFS rewrite to do.

(When all this first started, with a 2k global area defined for offsets, no one would ever have dreamed that (a ) the whole interface system would still be alive and delveloping, now and (b ) the 16-bits allowed for offset identification would ever be a serious limit).

It's sounding to me more and more as if you should be using SimConnect rather than FSUIPC. I'm sure you'll be finding a lot more you need and I'm really not developing FSUIPC in those directions any more, but concentrating only on user facilities. For FSX interfacing I always expected all new programs to use SimConnect directly, as Microsoft intended, of course.

Is 0xE85-0xE88 retrieved through this mechanism or METAR?

Neither, but by doing what you could have done, reading the layers in C000-C3FF and determining which is the most likely to be the one containing the aircraft. That's how you'd do it if you wanted compatibility with FS9.

Regards

Pete

[pilotjohn]

I have no interest in writing full-fledged apps for FSX. If MS Flight offers similar capabilities I definitely have many plans for it, but no desire to venture into FSX/ESP/Prepar3D world right now.

FSUIPC offered a quick and easy scripting platform. Since it seemed to be providing nearly everything that SimConnect provides, I thought this would simply complete the circle. The existing weather facilities/space could have been re-used for it. (e.g. write with a new uCommand and use some of the spares, and read the entire array from the METAR read/write string area which is 4k).

[Pete Dowson]

facilities/space could have been re-used for it. (e.g. write with a new uCommand and use some of the spares, and read the entire array from the METAR read/write string area which is 4k).

I can't force programs which might be reading the METAR read area to wait until something else has read the cloud data or timed out. And I can't tell whether whatever is reading it is wanting METAR data or cloud data. One wanting one could crash if the other was there instead. It might be different if the whole 4k were a write area which I can separate.

Pete

[pilotjohn]

I can't force programs which might be reading the METAR read area to wait until something else has read the cloud data or timed out. And I can't tell whether whatever is reading it is wanting METAR data or cloud data. One wanting one could crash if the other was there instead. It might be different if the whole 4k were a write area which I can separate.

Pete

How about reading it in two chunks with two consecutive reads? 1st 2k, 2nd 2k, or with something specified in the NWI struct. Anyway, no biggie. It'll likely not do what I expect it anyway. It was probably just going to be an experiment in futility.

[Pete Dowson]

How about reading it in two chunks with two consecutive reads? 1st 2k, 2nd 2k, or with something specified in the NWI struct.

No, I don't like that idea. But I could consider doing a lower resolution version. Instead of 64 x 64 values of 0-255, either 32-32 (each being an average of 4 neighbouring areas), or, probably better, 64 x 64 4-bit fields giving a density range of 0-15 instead of 0-255.

Note that it wants parameters for:

float minLat, float minLon, float minAlt, float maxLat, float maxLon, float maxAlt,

so you could offset the loss of resolution at one scale by asking for a smaller area. with that thought a 32x32 with averaged values would be more flexible I suspect.

If the only application is always an area of x nm around the aircraft -- or, better, ahead of the aircraft, the the lat/lons could be worked out in FSUIPC, leaving only three parameters needed -- range, min alt and max alt.

Anyway, no biggie. It'll likely not do what I expect it anyway. It was probably just going to be an experiment in futility.

I don't even know if the facility in SimConnect works -- I've never used it and I don't know if any of the WX radars do. I suspect RXP especially of implementing theirs via direct hacks into FS.

Regards

Pete

[pilotjohn]

I don't even know if the facility in SimConnect works -- I've never used it and I don't know if any of the WX radars do. I suspect RXP especially of implementing theirs via direct hacks into FS.

Well, if you feel like trying it out, a 32x32 (either center subset, or averaged) array would seem like a good compromise. I think looking only forward is logical if I'm implementing a weather radar, but I'm looking more to try to use it as a predictor for failures and might want to look at where the aircraft came from, in which case forward-only wouldn't work. If you have the time, and want to hack at it, I'll play with the result.

[Pete Dowson]

Well, if you feel like trying it out, a 32x32 (either center subset, or averaged) array would seem like a good compromise. I think looking only forward is logical if I'm implementing a weather radar, but I'm looking more to try to use it as a predictor for failures and might want to look at where the aircraft came from, in which case forward-only wouldn't work.

32x32 only needs 1024 bytes of course. If I were to re-use the B000-B3FF METAR writing area for reading this array, I could do 2 x 32x32 arrays, one front and one behind, making effectively a 64 x 32 with the aircraft in the middle. But it would mean two separate calls to SimConnect and I'm not sure how the timing would work.

I might have a look at it when I have a free moment. No promises -- I hope you have something else to occupy yourself!

Regards

Pete

[pilotjohn]

I might have a look at it when I have a free moment. No promises -- I hope you have something else to occupy yourself!

Thanks... 32x32 is fine averaged.

[Pete Dowson]

I might have a look at it when I have a free moment. No promises

I wrote a bit of extra code just to read the cloud array now and then and tried it with different weather patterns.

It doesn't work. Well, it sort of does something. The only values ever provided in the array are 0 for no cloud and 255 for dense cloud, and the patterns in the 64x64 array are always great rectangular swathes. The array might as well be 64 x 64 bits, not bytes.

It really isn't good enough for any sort of weather radar, and, for your purposes, it is certainly worse than simply using the weather reported at the aircraft.

I'm not implementing a facility using such an unfinished SimConnect option. Sorry.

Regards

Pete

[pilotjohn]

I wrote a bit of extra code just to read the cloud array now and then and tried it with different weather patterns.

It doesn't work. Well, it sort of does something. The only values ever provided in the array are 0 for no cloud and 255 for dense cloud, and the patterns in the 64x64 array are always great rectangular swathes. The array might as well be 64 x 64 bits, not bytes.

It really isn't good enough for any sort of weather radar, and, for your purposes, it is certainly worse than simply using the weather reported at the aircraft.

I'm not implementing a facility using such an unfinished SimConnect option. Sorry.

Regards

Pete

Ok... what happens when you ask for a very small area, like 0.5NMx0.5NM; is there granularity to that level?. Does it take into account the altitudes you ask for; that is, is there a difference if you ask for surface to 1000MSL (and there are no clouds there) vs, 3000-6000 where there are clouds?

[Pete Dowson]

Ok... what happens when you ask for a very small area, like 0.5NMx0.5NM; is there granularity to that level?

No. If there's cloud near at all it's then all FFs. I tested with few and scattered clouds, makes no difference. It's rubbish, really.

Does it take into account the altitudes you ask for; that is, is there a difference if you ask for surface to 1000MSL (and there are no clouds there) vs, 3000-6000 where there are clouds?

Not really -- it seems to not know where the cloud tops are, same as I don't except visually. I think it is just going by cloud bases in the area. It ignores cirrus by the look of it as well.

I really don't think it is useful for anything.

Pete