Jump to content
The simFlight Network Forums

Problems reading weather after FSUIPC upgrade


Recommended Posts

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.

Link to comment
Share on other sites

Jeroen,

in the file "NewWeather Readme.txt" in Peter Dowson's FSUIPC_SDK you find the following paragraph:

CC00-CFFF (Area 3): Weather reading area [NOTE IMPORTANT CHANGES HERE in FSUIPC >= 3.50)...

the NWI facilities have changed in 3.50 and you have to adjust your weather reading procedure accordingly.

Hope this helps.

Bye!

CATIII

Link to comment
Share on other sites

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.

Well, the only changes have been improvments in the reliability of the reads and writes. Sounds like there was some misunderstanding in the original protocol.

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.

Right. stop there. Do you write this as one FSUIPC_Write of 8 bytes? If not you must write the signature second, not first, as this acts as the trigger.

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 ?

No IPC read logging works identically to the write logging. It has never not worked. It is essential for program development and i use it all the time.

Regards,

Pete

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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) ?

It shouldn't no. There have been cases where folks seemed to get FS2002 to load from the main FS9 folder, but in my experience it only loads from the Modules folder.

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.

No, both are written at the same time, as one 8-byte transfer. So that is okay. It should work flawlessly.

However, in your original message you said:

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.

I would be worried about several things here. One is that 250 mSecs. It is very large. It would be better shorter I think, say 50. Another is that things could change between steps 2 and 3 -- Best to read the whole struct in step 2 and accept it if the ICAO matches.

Even more puzzling is that once the ICAO is written, the weather for that station is continually updated at 1 second intervals thereafter unless and until a different read request is made. This being so, you should always get the correct weather UNLESS something else is using the same facility. Try it with WeatherSet2 for instance -- that actually simply tries to set the ICAO when you ask, with a zero signature so it doesn't interfere with anything else.

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 ?

I notice you mentioned WideFS. Are you running your program on a client? If so, reads are not done through FSUIPC in any case -- that would be far too slow for WideFS to keep scanning for changes to send to all of its clients. WideFS reads go direct to FSUIPC memory, and read/write logging is an option for WideServer/WideClient. The only reason the Writes are logged is that they have to be passed through FSUIPC for action.

So, first test on the FS PC with logging in FSUIPC, check the sequences are all okay. Then go back to WideFS clients. Please update to the latest WideFS interim versions above first, as if we start on logging I need to relate to the versions I can debug. I had intended by now to release WideFS 6.60 (there are lots of changes) but too many things keep cropping up (including holidays! ;-) ).

Rather than outright data logging in WideClient/wideServer, try the Monitor facilities just to keep an eye on the critical locations -- 8 bytes at CC04 for instance. You could do that in both WideServer and FSUIPC on the FS PC, just to crosscheck timings and events.

Another logging which may tell you a lot in the Weather logging in FSUIPC.

Regards,

Pete

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.