Jump to content

SMP CLOUDS ALTITUDE


vfsintes
 Share

Recommended Posts

Hhello I have been reading the topics about the positioning ofthe clouds +-150m that means around 450/500ft.

here I'm fliying at GMMX that is 1528ft AMSL and with METAR that says SCT026 that is 2600 AGl then is around 4100 AMSL, XP11 last version shows this layer of SCT clouds (tyoe of cloud = 3) at 4100 till 6100 ft AMLS, that is ok, but I get clouds from 6500 till 10000. You can see in the picture the type of cloud, base of the cloud, and current altitude, in yellow top right of it(base 880 m), you willl see I'm fliying at 10.000ft and 7800 ft and it shouldnt been in that way, Can you check it please? I also put a pic with 3200 ft AMSL and you will see clouds over, when I should be  just under them, +-150m. Can you check it please??

 

Kind regards

 

cloudsnotok.png

cloudsnotok2.png

cloudsnotok3.png

Link to comment
Share on other sites

Your log shows that SkyMaxx Pro was explicitly told to create a cloud layer at around 6500 feet. So, the error seems to be in wherever that data came from.

What are your settings on Real Weather Connector, and do you have X-Plane's weather settings configured to use real weather? It kind of looks like something is misconfigured there, or the METAR data being used by X-Plane is different from the METAR data you're looking at.

 

Edited by sundog
Link to comment
Share on other sites

Here attached some pictures of what you say using dataref editor and developer console.

 

Yopu can see that the dataref and skymax representation doesn't match. Also RWV and SMP configs included and LOG. It looks like SMP takes in account the TOP instead of BOTTOM dataref of clouds....XP11 last version.  You can check at picture 8 that includes datrefs in green. Also you can see that the dataref value is the same also in the top right yellow data, so due to....who nows why?, datref and clouds doesn't match.

 

Please check.

 

cloudsnotok4.png

cloudsnotok5.png

cloudsnotok6.png

cloudsnotok7.png

cloudsnotok8.png

Log.txt

Link to comment
Share on other sites

In this case, it looks like things are actually working properly. In your final image, I see that you have a dataref placing a cloud layer at 1791 MSL, and our log shows us placing one at 1591 MSL. The 200 meter discrepancy in what is reported is intentional; it's to account for the size of the individual puffs that make up our clouds, and ensure that the base altitude where you're truly "inside" the cloud and not just within its edges matches up. Basically there is a 200 meter difference (this number can vary based on your settings) in how SMP and X-Plane define cloud layer altitudes, and we're just correcting for that.

I think something else was going on in  your original image, though. This effect wouldn't account for a difference in thousands of feet from what you expected.

Also I'm curious why you're running RWC in "never" mode... you're basically disabling it entirely.

Link to comment
Share on other sites

No sir, please check the dta I have just sent to you:

First picture: 1747m MSL: SKYMAX create it at 2432 (check console picture, cyan text).

Second picture: 1129 MSL: SMP 1814

3th picture: 1129 MSL: SMP 1814

4th picture: 802 MSL: SMP 1487

5h picture: 906MSL: SMP 1591

 

Plase check this data because there is more than 200meters, I also consider that the +-200m should only be used in top, imagina OVC 200 ft and you get OVC 800 FT NO SENSE IN APP.

 

Plase check the data I hae just sent to you and you will see the big differences, always around 700m over the cloud layer.

here attached the last picture at the end of flight in red the dataref and SMP values Dataref 1250, SMP 2190... again around 700m....

 

Here the LOG DATA that ALSO INDICATES  2190 instead of 1250+-200.

 

SkyMaxx Pro: Changing cloud conditions.
SkyMaxx Pro: Created cumulus congestus layer alt 2190.324707 size 198421.000000 density 0.500000
SkyMaxx Pro: Cloud conditions changed. Current target visibility is 43848.000000

 

Kind regards

 

PD: I get RWC dissabled because it doesn't work as expected, we all know the problem for downloading clouds, but I use NOAA for the rest of weather data.

 

 

 

cloudsnotok9.png

Link to comment
Share on other sites

I guess I don't understand the data you're showing me. What is that "nube B2" display in the upper right corner? Where does that come from? I don't think I've ever seen that.

In the first picture, I see that we created a cloud layer at 1487 meters, and then another one at 2432 meters (based on how SMP positions clouds). This is pretty close to the "nube B1" and "nube B2" values you're showing there.  

I'd encourage you to actually fly up there and see where the clouds really are; the data we write in the log is only for internal debugging purposes, and is not intended to give you a complete picture of where all of the clouds in SMP are. 

Link to comment
Share on other sites

OK, so I've been digging into our logic of how cloud altitudes are determined all morning here.

While we're not interpreting the tops as bottoms or vice versa, there are a few special cases that can result in the adjustment for "scud" or the size of the bottom row of puffs to be larger than it probably should be. I think you're hitting one of these cases.

We'll refine how this works in SMP version 4.8, which we're working on now. I'm also going to remove those log messages as they just generate confusion; we still need to adjust our internal idea of where clouds are to match X-Plane's definitions, to match X-Plane's coordinate system, and to avoid various anomalies, and so the altitudes we use internally will always be different from what you set in the X-Plane UI. That doesn't mean they are inaccurate, however.

These issues are all specific to when you're running Real Weather Connector in "never" mode. Hopefully a new Gizmo release will come out shortly to fix the weather download issue that prevents you from running in "always" mode. ("automatic" and "external injector" modes both should work fine.)

Edited by sundog
Link to comment
Share on other sites

Please take in account that base level of the clouds is a high resolution measured value by ceilometers, usually less than 50ft error. That means that the base level of the clouds should be under 50 ft error in the new development, top can be +- 100m if you want but, base (bottom) should be really consistent within METAR values. Then base value must be equal to xplane cloud base value, almost layers 0 and 1, 2 can be modified.

 

Kind regards

Link to comment
Share on other sites

The problem is where do you define the "base level" of the clouds? Clouds are wispy; does the "base" start at the lowest point where any wisps might extend to, or does the "base" start where the cloud is entirely filled with water vapor? That's the only uncertainty we're talking about here.

I would also argue that in real life, the clouds in a layer are not all at the exact same base altitude. They vary a bit. You can specify an altitude at a given point, say over an airfield, but the larger layer of clouds isn't a perfect slab.

Basically we're trying to provide an even more realistic experience than what the METAR reports can reflect, while still respecting the data in the METAR.

Link to comment
Share on other sites

Hello again, I understand what you mean in terms of high altitude clouds, usually over 6000 ft AGL. But in terms of METAR it's really important to be accurate due to minimums, for instance ILS CATI usually need visibility of the runway minimum 200ft AGL. If cloud base is not well represented maybe you can get BKN 001 (not really estrange in winter and  in cities close to the sea) where you should theoretically go around in ILS CATI but now you can get perfectly clouds in a 700AGL that it's no as real as. Maybe could be a good idea to use different logics in 0 and 1 clouds layer and different in 2. 

 

Kind regards

 

Link to comment
Share on other sites

Dear Sir, I offer my self to be betatester of your new SMP development. Please take in account the next points.

 

  • XP minimum cloud layer thickness is 2000ft, then we get a problem with METARs like FEW014 SCT020. I recommend two solutions, one is only create a layer using the maximum coverage of the METAR and the lower base, in this METAR we will convert FEW014 SCT020 to SCT014.
  • Increase transition time till 30s, if we get no clouds and we get now BKN it could be better to get 30s to make the transition (or just the opposite, from BKN to clear).
  • Be really careful with bottom cloud level (base) and try to use the dataref (or METAR value) +- 50ft, no more.
  • Try to mix and be aware of the clouds level, it means that if I get one layer from 4500 AMSL to 6500, another from 7500 to 12500 and the last one from 15000 to 18000 AMSL, try to avoid mixing them and maintain the distance and bottom layer position, the top can be variable (+-200m/600ft) but never reach the base of the next layer.

Kind regards

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...