vdkeybus

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.