[Problems reading weather after FSUIPC upgrade]

Heli:

It is a fact that the old FSUIPC.DLL is stored on 'My Desktop'. But FS2004 won't look for DLL's outside the FS9 directory, will it (apart from the default DLL include paths such as WINDOWS/SYSTEM32) ?

CATIII:

I've also noticed the change, but it apparently relates to what happens when the signature lock is lost.

Pete:

I do it like this:

{
NewWeather h;
strncpy(h.chICAO, icao, 4);
h.ulSignature = 0x000005FC;
fs->write(0xCC04, 8, &h.chICAO);
fs->process();
}

So it appears that the signature does get written last.

Evidently, the lack of READ logs (I see only WriteEx in the log) although I've turned them on, is also worrying me. Anything I can do to check here ?

Jeroen.

[Problems reading weather after FSUIPC upgrade]

Last week I upgraded FSUIPC (3.4.4 -> 3.6.0) and WideFS (6.4.4 -> 6.5.1). After that, my client programs are no longer able to reliably read weather using the New Weather Interface.

I do weather reading like this:

1. Write 4-byte signature (0x00000F5C) and 4-byte ICAO in one pass to 0xCC04 + 0xCC08. Have it processed.

2. Read the ICAO (4 bytes only) from 0xCC08 and Process. If the ICAO is not as requested, sleep for 250 ms and try again. Repeat this 10 times at most.

3. Read the whole NewWeather struct from 0xCC00.

This has worked flawlessly for one year. Since the update, step 2 above fails 1 in 3 times.

The FSUIPC log indicates that weather for the ICAO is effectively requested for. I generally need about 3-4 tries to get the weather. When it fails, I see the 10 requests and that's it. (I've also turned on IPC write and read logging, but it seems that only write logging works. Do I need to turn on something else to see the binary log of what I got back from the read requests ?)

Thanks for helping,

Jeroen.

[Glass cockpit research]

Ok,

It seems you've more or less decided on the platform (PC). From the website you quoted, I made myself a bit of an idea of what you want to do and I think your choice is fine.

What's the current state of the BD-5 construction ?

J.

[Glass cockpit research]

Great idea !

In your place, I would not embed your design in a FS panel. Rather, run it on a separate PC and use FSUIPC to provide data for that program.

It has the advantage that:

1. you won't have to reprogram anything if you want to create a standalone rig for airborne testing.

2. you can test it to the bone with FS and verify that it will perform equally in the flying tests.

For portability reasons, I would surely opt for C/C++ programming. If you send me more details of your design, I might be able to decide if I can help you out with a rudimentary implementation. I'm not exactly a graphics wizard, you see, being a real-time system programmer.

Do you have any ideas of how you are going to interface it with an aircraft (GPS NMEA, ARINC) ? That might indicate already a suitable computing platform to start developing on.

J.

[INTERFACE BETWEEN FSinterrogate e Matlab/Simulink]

As far as I know (Pete should correct me if I'm wrong), FSInterrogate writes to a file. I don't know if and how you could use a 'named pipe' to supply a file stream to Simulink.

Furthermore, FSInterrogate won't accept a file for input, so the real-time capabilities you're pursuing are restricted to visualizing only (i.e. no flight control).

The best thing you could try to do is to use an S-function in Simulink and use the FSUIPC API directly without FSInterrogate. A Simulink S-function is basically a C-program in which you are required to implement about six callback functions. Remember to select MSVC++ as your compiler, so you can include the FSUIPC API in it. If I remember correctly, there is some sample code to implement a (more or less) realtime ADC included with Simulink. Let me know if you don't find it. I'll look it up then (I don't have Matlab here right now). In that case, please also specify your Simulink version.

Good luck,

J.

[Problems driving MS FS2004 Position using FSUIPC]

The main advantage of passing delta LLAPBS values (velocities) is that you can run the sim in normal mode.

Suppose we want to have the plane flying straight and level.

The technique discussed so far involved freezing the sim and passing 50 position and attitude values at precisely spaced time instants per second. This is not an easy task to manage.

What I propose is to keep the sim engine running, send a position, and, from then on, read the position and write the velocities to steer the plane along the desired path. (offsets 3178, 3180, 3188, 31A8, 31B0, 31B8) Because the path of an airplane can be well approximated by a series of straight lines, much less updates are needed and they do not need to be evenly spaced. The nice thing is: the sim engine will keep your motion smooth and, best of all, it is informed of your movements, allowing it to efficiently cache scenery etc.

And you have sound...

J.

[Problems driving MS FS2004 Position using FSUIPC]

Have you tried logging what you send and plotting that afterwards ?

Or you could eventually try to read back what you wrote the last timestep. I don't exactly know how FSUIPC handles combined reads and writes to the same offsets, but I imagine that you might be reading the value right before you actually overwrite it.

Another option is what I suggested already a few months ago: also update the speeds (delta LLAPBHs) and use normal flight mode (no pause or slew). FS will do the smoothing (interpolation) for you and performance may actually be a lot better if you send, like, only 10 samples per second or so.

Keeping the frame rate limiter on would also seem a very sensible idea.

Regards,

J.

[Strange WideFS problem]

transmission rate is about 1100kb/sec in both directions

That looks ok for a 10MBit card. Verify in your network connection property windows (Configuration panel -> Netw. & Internet -> Network, dbl. click the network link) that indeed you're not getting any packet errors.

I exclude your DI-604 because using another PC solves the problem. Neverthelees, there's also a cable tester and diagnostics in the unit which may be useful to trace the problem. I think you have to log in using 'http://192.168.0.1' to use these.

And, finally, try another network card. They're so cheap nowadays that searching for the current problem may be more expensive (time-wise), especially if you could borrow one from a friend.

Regards,

J.

[How i add FS DEFAULT MODULES in my own module]

how i find interface of methods that contains FSUI.dll ????

You can inspect the .dll with e.g. PE Explorer, but, apart from the return value type and parameter types (and number thereof), you won't find any detailed information there.

I guess Pete has already done the horrible job of tracing and guessing in a few DLLs (I'm unsure whether FSUI was one of them; he has mentioned the names in a post not so long ago). When he's back, he might tell you more of his findings.

Out of curiosity: why would you want to interface FSUI.dll directly ? Given the fact some people are already talking FS2006, it might not be the wisest choice to invest too much time altogether in 'revenging' and starting to use this DLL in a new program.

Just to make sure we're talking about the same thing here: this forum discusses the FSUIPC system, which is largely incorporated by the FSUIPC.DLL file. FSUI.DLL is the user interface part of the MSFS executable, and it has no direct bearing to FSUIPC. You are aware of this, I presume ?

Regards.

J.

[Strange WideFS problem]

Three things come to my mind:

1. Check your network connection by sending a large (> 20 MB or so) file between the computers in both directions using the protocol (TCP or IPX) you've selected for WideFS. Don't tolerate any error.

2. Check the settings of the Win XP firewall.

3. Check the log (WideClient.log) which is in the same directory you start WideClient in.

Regards,

J.

[FSUIPC_Open() failure]

so it is the FSUIPC_open () call that fails

I just tested it on my machine with a program I've written earlier using the C library. I get the same message:

   314473  READ0 [P3972]  3304,   4 bytes: 00 00 50 34 
   314473  READ0 [P3972]  3308,   4 bytes: 07 00 DE FA 
   314473 WRITE0 [P3972] (failed, read-only!) 330A,   2 bytes: ED 03

However, my fsuipc->write() doesn't fail for that reason. I believe that we must rather treat the log message as a warning. From your post, however, it's a bit unclear if your program bails out on this.

If it does, check the return value of the write() call (using single-stepping). It should definitely not fail. If anything fails, I expect this to be visible in the return value of the process() call. Have you actually checked this value ? It is one of the FSUIPC_ERR_... defines.

If your program continues to work fine, I wouldn't bother and not forget to turn off the logging...

Regards,

J.

[Writing NWI entries]

Thank you for clearing things up.

I regarded the C800 - CBFF area as 'write-only' and I was puzzled how I could get the ulTimeStamp value mentioned in the NewWeather readme:

only the ulTimeStamp is used -- this is set by FSUIPC to the time at which the specified weather was written to FS.

I therefore assumed I had to use one of the Read's to a read area (from either 0xC000, 0xC400 or 0xCC00) to get it. I was simply wrong.

As to the re-reading thing:

Is it more efficient - during the re-Reading stage - to ask only for the ICAO (using FSUIPC_Read(0xCC08, 4, chIcao, &dwResult)) and, if that 'suddenly' matches, ask for the lot, having a size of sizeof(NewWeather) ?

I indeed meant to probe for the success of a read. You see, until 15 mins. ago I thought the only way of getting ulTimeStamp was by reading in the 3 read areas mentioned earlier, which use an ICAO. Because my program actually needs to modify existing weather, things were easy to combine. Just for clarity, I include my relevant code section here.

bool set_station(char *icao, struct weather *weather, bool activate)
{
    NewWeather w;

    memset(&w, 0, 0x24); // Only set upto nElevation
    strncpy((char *)&w.chICAO, icao, 4); // Insert ICAO
    w.ulSignature = 0x00000F5C; // FSC signature
    fs->write(0xCC00, 0x24, &w);
    fs->process();

    int n;
    for (n = 10; n > 0; n--) {
        char chIcao[4];
        fs->read(0xCC08, 4, chIcao);
        fs->process();
        if (!strncmp(chIcao, icao, 4))
            break;
        Sleep(25);
    }
    if (n == 0)
        return(false);

    fs->read(0xCC00, sizeof(NewWeather), &w);
    fs->process();

    if (weather->wind) {
        struct wind *wind = weather->wind;
        for (int i = 0; i < w.nWindsCtr; i++) {
            if (wind->spd != WX_UNMODIFIED) {
                w.Wind[i].Speed = wind->spd;
                w.Wind[i].SpeedFract = 0;
            }
            if (wind->spd_gust != WX_UNMODIFIED)
                w.Wind[i].Gust = wind->spd_gust;
            if (wind->dir != WX_UNMODIFIED)
                w.Wind[i].Direction = wind->dir;
            if (wind->dir_var != WX_UNMODIFIED)
                w.Wind[i].Variance = wind->dir_var;
        }
    }

    if (activate)
        w.uCommand = NW_ACTIVATE;
    else
        w.uCommand = NW_SETEXACT_PENDING;

    fs->write(0xC800, sizeof(NewWeather), &w);
    fs->process();

    return(true);
}

The function uses a signature and it will fail if someone else 'locked' the weather system.

The function is called for every weather station in the area of the aircraft. Feel free to comment on this function, if you like. My coding style also might not be up to standards...

Regards,

J.

[Writing NWI entries]

Hello Pete,

In the last week, I have accumulated three questions about NWI.

1. The manual states that I should only write a station if the timestamp has changed. Do you mean that I should look at the ulTimeStamp of a NWI Read (at 0xCC00) preceding the intended Write ? Which brings me to question 2.

2. A Read is always in response to a Written request. Is it sufficient to re-Read until the ICAO in the response matches the one specified in the request ? If so, doesn't that imply that ulTimeStamp has changed and, hence, I should never bother about it at all ?

3. Is it more efficient - during the re-Reading stage - to ask only for the ICAO (using FSUIPC_Read(0xCC08, 4, chIcao, &dwResult)) and, if that 'suddenly' matches, ask for the lot, having a size of sizeof(NewWeather) ?

Thanks,

J.

[Force wx refresh in 2004?]

I picked up this old thread because I've found that it is not necessary to use FSUIPC's New Weather Interface to force a weather theme reload from an externally modified .FLT file as described before.

It is sufficient to reset the theme time to zero, apparently forcing FS to reapply the .wtb template to the current aircraft position.

The relevant .FLT file section should e.g. read as follows:

[Weather]

WeatherType=0

ThemeName=weather\themes\foggedin.WTB

ThemeTime=0.0

The .WX file associated with the flight is apparently disregarded in this case.

J.

[Elite ProPanel + FSUIPC - any help possible here?]

It might be the Elite communications thread that got a timeout on one of its I/O operations to the panel and stops working. The I/O operations may include the timed SendMessage() call to FSUIPC if they have used a separate process (not a module) for the panel driver.

This can be due to the Elite program being suspended temporarily because the FS process needs more processing time (as might happen during loading of a menu window). If in windowed mode, Windows task swapping and thread processing is a bit different and the interruption might be shorter.

Depending on whether or not you use the COM or USB version of this panel, check the interrupt and handshake settings on the COM port (and verify you have the correct cable if you're using hardware handshake - NOT a 3-wire type; you might lose data from a packet that doesn't fit in the UART FIFO).

You might also want to start an application (e.g. Word with a big .doc file), minimize it and run your FS setup (in windowed mode). Then Alt-Tab to Word (which is bound to suspend the FS and Elite driver tasks for a while) and see if the problem is reproducible.

In any case, I don't think FSUIPC is to blame here. IMO, it is the responsability of a driver program to properly deal with timeouts.

J.

[Jittery motion when writing Lat/Lon/Height to FS2004]

Also, does FS2004 use the WGS-84 elipsoid for lon/lat data

I think the scenery is based on it indeed. You could check this with the authors of NAV3, Courseplanner, FSNavigator, etc. I think some of them use other WGS-84 databases (than the FS2000 scenery, which is quite hard to decode) and still get quite accurate positionings.

I have tried this in slew mode, and in normal mode, and the result is the same.

I also noticed that, when slewing, the plane sort of 'flies' to the new location. Maybe you could try a totally different approach:

For large displacements, slew it. For small ones, write an 'autopilot' in Simulink which actually flies the aircraft through your LLA coordinates using FSUIPC. Frame rates and smoothness will be uncompromised. The additional benefit is that you get the pitch, bank and attitude (PBH) for free, something you didn't mention of having. And you will need a lot less updates because the plane will interpolate the track perfectly for you.

And you get sound as well :-).

It might require a modified flight model with increased 'engine power' and drag to allow the 'autopilot' to better follow the track.

Just a thought for those wanting to bypass the FS flight model.

J.

[FSUIPC startup behaviour]

Hi Pete,

I've made a C++ wrapper class (fsuipc_wpd) for the FSUIPC client, which takes care of proper error processing. The class is based on the SDK code for Borland, which I also moved in a class (fsuipc).

The result is that I'm using the existing FSUIPC_open() (now: fs->open()) which contains the following part:

	if (!SendMessageTimeout( // send the request
			m_hWnd,       // FS6 window handle
			m_msg,        // our registered message id
			m_atom,       // wParam: name of file-mapping object
			0,            // lParam: offset of request into file-mapping obj
			SMTO_BLOCK,   // halt this thread until we get a response
			2000,	      // time out interval
			&dwError)) {  // return value
		*pdwResult = GetLastError() == 0 ? FSUIPC_ERR_TIMEOUT : FSUIPC_ERR_SENDMSG;
		return false;
	}

	if (dwError != FS6IPC_MESSAGE_SUCCESS) {
		*pdwResult = FSUIPC_ERR_DATA; // FSUIPC didn't like something in the data!
		return false;
	}

I removed the retrying mechanism that was originally there, because SendMessageTimeout() already waits for a FSUIPC response to the message.

However, while I'm trying (one time per second) to make the FSUIPC link, and FS2004 is fired up, I'm getting a successful SendMessage() call (it returns TRUE), but dwError is equal to FSUIPC_ERR_DATA. However, no data was ever sent to FSUIPC.

Is this a possible scenario or should I investigate further for a bug in my software ?

Thanks for the assistance,

J.

[Weather questions]

Hello Pete,

Thanks for clarifying. I've started experimenting a bit with WeatherSet2 and a program of my own. I found out that only cloud types 1, 8, 9 and 10 should be used (Cirrus, Stratus, Cumulus, Cumulonimbus). Using any other number crashes the weather system. It took me a while to find out the reason of the crashes and I just mention it here 'to whom it may concern'.

J.

[Weather questions]

Hi Pete,

I've got some weather questions.

First, is there any way of having FS2004 load a weather theme on command ? I have tried changing the WeatherTheme entry in a .FLT file and reloaded that using FSUIPC, but it doesn't seem to work. It seems as if the weather theme in a .FLT file isn't reloaded until you enter and exit (with OK) the World.Weather menu. But that may be an FS2004 bug. Haven't had time yet to install the patch. Maybe it is fixed now.

The reason I want to load a theme is that it seems a lot easier to do than setting the whole environment with FSUIPC's NWI, because I need only a limited set of 'weathers'. What do you think ?

Second, after some experimenting with WeatherSet2, I got the following questions: (first I do a Clear All Weather and then I set the station to 'GLOB'):

1. Can I only enter one visibility layer ?

2. If I only set GLOB weather and set none of the stations, the GLOB weather is applied all over the world, right ? Have you any idea (tests or so) how much different 'weather hot-spots (local weather settings at ICAO's, LAT/LON pairs)' FS can hold ?

Third, after snow has fallen, is there any way of 'removing' the snow in FS2004 ? Clearing all weather doesn't help.

Thanks,

J.

[Nearest Airport]

Found it again on Flightsim.com:

FS2004 Airport database by Mohammad Omar. Including ICAO, latitudes and longitudes.

J.

[Nearest Airport]

I think you have 2 options for FS2004:

You can read:

(FS path) \Scenery\ (name, namw, eure, eurw, etc...) \Scenery\AP*.BGL

These contain most, if not all, airports, including the ones that are further detailed in dedicated BGL files like Amsterda.BGL, Paris.BGL, etc... You will need a disassembly tool like Alessandro Antonini's BGLXML to extract the facility data into XML.

Another option is to skip this step and just download the whole airport directory in database format. I encountered it a while ago on Flightsim.com but I don't know the name and I'm not sure if it contains the latitude and longitude of each airport.

In either case, you have to program something to 'find the nearest'.

J.

[External flight dynamics model.]

the plane is jerking back and forth

Perhaps the visual output and the simulation engine are running in two separate threads in FS ?

Back and forth: do you mean the plane is really going backwards some of the times ?

BTW: 45 fps is very ambitious. Turn on some clouds, go near an airport and watch that number fade away... What is this application that requires more frames than the eye can perceive ?

J.

[FSUIPC 3.30]

and have come to a conclusion that FSUIPC 3.30 is the culprit

I think a more careful examination is in order here. First of all, check if any of your plugins still has its .dll wandering around in your \Modules folder. Especially after an FS crash, the files will likely be 'in use' and uninstallers may fail to delete it (and also fail to tell you).

Then, make sure that no clients are trying to access FSUIPC. If there are, the FS lockup may be due to them (it's not that[\i] hard to bring FSUIPC down with bad calls...).

I'm not sure whether WideServer relies on FSUIPC. I think it does (i.e. it is also a client), but in any case, try removing it (WideServer.dll) as well if you have it.

Please let us know if adding FSUIPC.dll still crashes FS.

J.

[Need tutorial help]

I've never worked with VB.Net, but you seem to make some mistakes regarding the ordering of calls, which is something I do know from using the C/C++ SDK.

It is essential that you write your code according to the guidelines contained in the VB.net SDK:

' FUNCTION LIBRARY FOR FSUIPC

' based on C code supplied by Pete Dowson

'

' BASIC USAGE GOES LIKE THIS:

' - call FSUIPC_Initialization() to initialize important vars at beginning

' of program.

' - call FSUIPC_Open() to connect with FSUIPC if it's available.

' - call a series of FSUIPC_Read and/or FSUIPC_Write and/or FSUIPC_WriteS (be careful when

' combining these in the one transaction, for your own sanity).

' - call FSUIPC_Process() to actually get/set the data from/to FS.

' - For reads, call FSUIPC_Get to retrieve data read from FSUIPC (New for VB .Net)

' - repeat steps 3, 4, and 5 as necessary

' - at program termination, call FSUIPC_Close().

So, before you Get() something, you should have Open()ed a link, issued some Read()s or Write()s, and issued a single Process() call.

Hope this gets you rid of some logical errors. Syntactical ones (ByVal, ByRef, the way textboxes are treated) are, as implied in the beginning, not exactly my area of expertise...

J.

[FS2004 View control]

To all,

In a multimonitor setup with one PC, I would like to turn the sideviews on and (temporarily) off with a FSUIPC command. This may be useful when doing approaches in precipitation, which tends to reduce the framerates so much that it becomes impossible to do the final landing.

Is such thing possible in FS2004 and/or from FSUIPC ?

To Pete Dowson in particular,

If I remember correctly, you're running a comparable setup with a Parhelia card. What framerates do you get under these circumstances ?

Regards,

J.