Strange values in 030C

[Luke Kolin]

We are using offset 030C to get touchdown speed, as introduced in 3.522. We have encountered some strange issues with one user where this offset is reporting some exceptionally strange numbers.

While the offset is a 32-bit value, we store the values as 16-bit signed integer, as we do with vertical speed. We've had one user complaining of data overflows, and when we updated the code to preserve the data width and log "unusual" values, he is reporting numerous results where 030C is reporting back a touchdown speed of -59999 ft/min, while taxying.

This is ocurring with different aircraft and at different airports, but appears to be only occurring with one user. He is not reporting any problems at all with vertical speed, which remains within the 16-bit limits of +/- 32767; it's only touchdown speed, and only while on the ground.

Pete, Is there any reason you can think of why FSUIPC might be writing such unusual values into the offset, or even why FS9 might be generating such strange values?

Cheers!

Luke

[Pete Dowson]

he is reporting numerous results where 030C is reporting back a touchdown speed of -59999 ft/min, while taxying.

The units are 256 * metres / sec in any case, as they are for 0ffset 02C8.

-59999 would convert to -12.8 ft/min. If this is after you have done such conversion, how does it end up with such an interesting number as 59999? Do you limit it?

This is ocurring with different aircraft and at different airports, but appears to be only occurring with one user. He is not reporting any problems at all with vertical speed, which remains within the 16-bit limits of +/- 32767; it's only touchdown speed, and only while on the ground.

The location 030C is not in FS, it is local to FSUIPC, and it is only updated whilst in the air. As soon as the aircraft touches the ground, the last value written there is left untouched, until you are next airborne.

On FS2002 and before, it is copied from 02C8 whilst in the air. On FS2004 (only) it is copied from the place in FS where 02C8 in mapped -- somewhere within FS's SIM1 private sim data.

Pete, Is there any reason you can think of why FSUIPC might be writing such unusual values into the offset, or even why FS9 might be generating such strange values?

No, as the data source is the same as for 02C8, and in any case the value isn't touched whilst on the ground.

Why not use FSUIPC's own monitoring facilities to log the values both in 02C8 and 030C? See the Logging page, right hand side. Log as type S32 to the normal Log, then compare the results from the two locations on during a landing. Don't enable this logging too long before the landing as the log will get rather large.

Log the "aircraft on ground" flag too (0366, as a U16) so the moment can be seen.

Regards,

Pete

[Luke Kolin]

If this is after you have done such conversion, how does it end up with such an interesting number as 59999? Do you limit it?

Yes, this number is after conversion, and I'm 99.9% sure I'm not doing any limitation. The code is not with me right now, but iirc I am dumping a warning message when the absolute value of this number exceeds 6000.

No, as the data source is the same as for 02C8, and in any case the value isn't touched whilst on the ground.

Since this is only happenning on the ground for this user before he has ever gotten airborne, it makes me wonder if I'm getting back an uninitialized value. When FS starts, does FSUIPC zero out this offset? What value should I expect to see in this offset if the aircraft has never gotten off the ground?

Why not use FSUIPC's own monitoring facilities to log the values both in 02C8 and 030C? See the Logging page, right hand side. Log as type S32 to the normal Log, then compare the results from the two locations on during a landing. Don't enable this logging too long before the landing as the log will get rather large.

I might ask him to do this right as the aircraft starts, as the problem we are getting is visible before takeoff. Upon landing it appears to be working just fine.

Thanks again for your assistance.

Cheers!

Luke

[Pete Dowson]

Since this is only happenning on the ground for this user before he has ever gotten airborne, it makes me wonder if I'm getting back an uninitialized value. When FS starts, does FSUIPC zero out this offset?

It is part of a large data area for many FSUIPC-maintained values, and, yes, it is all zero to start with.

What value should I expect to see in this offset if the aircraft has never gotten off the ground?

It should be zero if the aircraft has never been airborne, but that does depend on my code seeing the "aircraft on ground" flag. If during initialisation, that flag is zero then there is a possibility that an uninitialised value from FS itself is being copied in, at FS load time. The same value would also be seen in 02C8 though, albeit transiently.

I'm not sure if there's a way I can prevent that -- if the user deliberately starts FS with the aircraft in flight then I have to do this in any case.

Quite honestly, I never expected folks to want to know the touch-down V/S before they've even been flying.

I might ask him to do this right as the aircraft starts, as the problem we are getting is visible before takeoff. Upon landing it appears to be working just fine.

That would probably be too late if this is occurring during FS initialisation. I don't think FS's monitoring starts that early even if it was enabled on the previous session.

If the aircraft has never been airborne to you or your user's knowledge, what would be the use of this value? I must admit I am rather bemused here about what the problem really is.

If it is just some sort of initialisation problem then I could probably try to delay its update until FS is "ready to fly". this is some seconds after it looks ready, for safety, about the same time, for instance, as I start up WideServer.

Regards,

Pete

[Luke Kolin]

If during initialisation, that flag is zero then there is a possibility that an uninitialised value from FS itself is being copied in, at FS load time. The same value would also be seen in 02C8 though, albeit transiently.

That makes sense. The transient value from load might not get cleared until the aircraft gets off the ground for the first time. If I could make a suggestion - you may wish to annotate the documentation noting that the value is undefined and unpredictable before the aircraft becomes airborne.

If the aircraft has never been airborne to you or your user's knowledge, what would be the use of this value? I must admit I am rather bemused here about what the problem really is.

I read all of the values from FSUIPC and then stuff them info an "FDR data" object internally, and only then do I start picking and choosing what bits of data I want to examine - so you are absolutely correct, I don't really need to know the value. However, I think that knowing that the offset result can be unpredictable before the aircraft becomes airborne is of value.

I was curious wether these interesting values were expected behavior, especially since the functionality is so new.

If it is just some sort of initialisation problem then I could probably try to delay its update until FS is "ready to fly". this is some seconds after it looks ready, for safety, about the same time, for instance, as I start up WideServer.

That might be the best solution from a data perspective, but I at least have a workaround currently. Thanks again for you help and the information provided (and by the way, most importantly for that new feature in 3.53!)

Cheers!

Luke

[Pete Dowson]

That might be the best solution from a data perspective, but I at least have a workaround currently. Thanks again for you help and the information provided (and by the way, most importantly for that new feature in 3.53!)

Could you check whether you still get that initial spurious value in 030C using the Beta release of FSUIPC (version 3.536, see Announcements). I added the check on "ready to fly", but I was unable to get the bad value in the first place so I couldn't test it.

Regards,

Pete

[Luke Kolin]

Could you check whether you still get that initial spurious value in 030C using the Beta release of FSUIPC (version 3.536, see Announcements). I added the check on "ready to fly", but I was unable to get the bad value in the first place so I couldn't test it.

Thanks for the change. I will create a special build and send it off to the user who was pretty consistently able to reproduce the issue. I should hear back in a few days.

Cheers!

Luke