Jump to content
The simFlight Network Forums

tim arnot

Members
  • Posts

    2,866
  • Joined

  • Last visited

Posts posted by tim arnot

  1. ...despite all the postings on their site saying it will be on sale on the 28th. It's now the 1st in the antipodes and the site is still say

    They've put back the main release after the bandwidth fiasco of the pre-pay release. The intention is that the last pre-release download will have a clear 24 hours with the product. Me, I can't buy anything until the bank deigns to issue my new ccard (it's been 2 weeks and 3 phone calls now :evil: -- don't let your card get cloned! :evil: :evil: )

  2. Excellent news. 8) We've just taken on two new QFIs, with a third starting next month, so we don't have any insructor openings down here, sadly. The CFI has also just got his PPL Examiner's ticket, so we're now 'self sufficient'!

  3. The one thing close to M-K that's worth a visit is Bletchley Park -- birthplace of the modern computer during WWII, and home of the Secret Decoder Ring that cracked Enigma. There are very few things or places we can truly say this of: If it wasn't for Bletchley Park, and the men & women that served there, we wouldn't be speaking English today.

  4. file.php?id=69786

    Looks like we've got a new tower.... *AND* a new SATCO! :shock:

    "Port first became popular among the English when they went to war with France, and could obtain French wines. Unlike normal wine port it is fortified by adding grape brandy during the fermentation process. This makes it more stable during temperature changes and allows it to last longer during sea travel. "

    One might wonder if the English went to war with France ...just to get access to their wines ! 8)

    Egads, :lol:

    "At war" is proobably the normal state of things between England and France, based on the last 1000 years of history (and I think the score is pretty much even. Trust me, the French are *not* cheese-eating surrender monkeys. Okay, the bit about the cheese is true!)

    Oh, and the Engish also invented champagne, in the mid 17th Century...

  5. Another new version has hit the streets. ILS support, intersections, vertical route profiling, cheese detector...

    Heck even our beloved Fritz was seen with it, muttering something about Finding Lizzy, or Nimoy or somesuch! :shock:

    Just click on my sig

  6. A well-known FS news site, not a million miles away, didn't even spell my name rite... :wink:

    Do I care? No not really. If I had a pound for every time someone spelled my name wrong (and it's easily done since my name does not take the "usual" spelling), I'd be overweight. Actually........ :lol:

    Tim (someone with a $50 a year website, pretending to be a real company...)

  7. 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

  8. 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

  9. 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?

  10. 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 = "&lt;??&gt;";   // 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

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.