Lat & Long Offsets

[VOZzer]

Hello Pete,

I am trying to use Offsets 6010 and 6018 for FSX to display the Lat & Long co-ordinates. I am aware that they won't display straight outta' the box (ie lots of versions required), but when I study these Offsets in SIOC IOCPConsole Log, I don't get any readings at all.

I was expecting random gibberish readings from the Log at first (this is good; as whilst not correct readings, it at least proves they are working), but these Offsets seem stone cold dead, at least in SIOC.

Is this like the NWI Offsets which have to be "filled" before reading? Is there something I'm missing? I am just trying to get some sort of reading from 6010/6018, conversions will be taken care of later.

Thanks,

Jack :D

[Pete Dowson]

I am trying to use Offsets 6010 and 6018 for FSX to display the Lat & Long co-ordinates.

Yes, okay. Those are populated by the FS GPS.

I am aware that they won't display straight outta' the box (ie lots of versions required)

Sorry, what does that mean? I don't understand either part of that statement.

but when I study these Offsets in SIOC IOCPConsole Log, I don't get any readings at all.

Why not use the FSUIPC monitor to display them in FS? See the Logging tab, right-hand side. Much easier. Or at least use the tool provided in the FSUIPC SDK -- FSInterrogate. I've no idea what "SIOC IOCPconsole" is.

I was expecting random gibberish readings from the Log at first (this is good; as whilst not correct readings, it at least proves they are working)

Again, where do you get this from? Why "random gibberish". What have you been reading? As far as I can see these are populated correctly straight away.

but these Offsets seem stone cold dead, at least in SIOC.

Report it to whoever supports SIOC then, please. Maybe it isn't reading those offsets as 64-bit double floating point values?

Is this like the NWI Offsets which have to be "filled" before reading?

Sorry, what does that mean?

Is there something I'm missing? I am just trying to get some sort of reading from 6010/6018, conversions will be taken care of later.

What conversions? They are in degrees already.

Regards

Pete

[VOZzer]

Hi Pete,

Sorry for my late reply. I am now happy to say that I've gotten the Lat/Lon Co-Ords to work, in the end I scrapped the GPS Co-Ordinate Offsets in favour of a complex Lat/Long High/Low calculation... But everything works.

However, I'm now in a bit of trouble with some other offsets. Offset 0E92 for example, Wind Direction.

I am currently using the following calculation:

- Multiply Offset 0E92 by 360

- Divide the answer to above calculation by 65536

- (Wind Direction)

Howeer, this isn't working for me. I am getting readings such as -4, 730... etc. BTW, these are the SIOC calculated readings (Offsets after being processed by the above wind calculation). am I doing the wrong calculation?

Secondly, wind speed. Offset 0E90 is giving readings like 70 Knots when the wind speed is only 5 knots. I am not currently applying an ycalculation to this Offset, according to my findings it is already in "correct" form (ie ready for something like SIOC)(?).

I am also facing trouble with Offset 0580 (Heading of Aircraft for FSX). I apply the following calculation

- Divide Offset 0580 by 360

- Multiply this value by 4294967296, which is (65536*65536) as per the FSUIPC SDK Offsets Status Manual.

- (Aircraft Heading for FSX)

Thanks very much for reading,

Jack :)

[Pete Dowson]

I am currently using the following calculation:

- Multiply Offset 0E92 by 360

- Divide the answer to above calculation by 65536

- (Wind Direction)

Howeer, this isn't working for me. I am getting readings such as -4, 730... etc. BTW, these are the SIOC calculated readings (Offsets after being processed by the above wind calculation). am I doing the wrong calculation?

No. More likely you are trying to do this in a 16-bit word, where, of course, as soon as you multiply by 360 you overflow its capacity. The value 65535 for instance (the largest possible value in a 16-bit unsigned word as 0E92 is) represents 359.99degrees. Ty multiplying 65535 by 360 then dividing by 65536. Use a calculator. What do you get? Now wonder why you aren't getting the same result.

Anyway, why not use the tools provided to show you what is going on? FSInterrogate, FSUIPC logging, and the FSUIPC Monitor. Please help yourself by using what is provided!

Secondly, wind speed. Offset 0E90 is giving readings like 70 Knots when the wind speed is only 5 knots.

You are most certainly making a mistake then. Use the tools as I just said.

I am also facing trouble with Offset 0580 (Heading of Aircraft for FSX). I apply the following calculation

- Divide Offset 0580 by 360

- Multiply this value by 4294967296, which is (65536*65536) as per the FSUIPC SDK Offsets Status Manual.

- (Aircraft Heading for FSX)

You have that completely backwards! You are misreading the documentation. You must multiply by 360 and divide by 65536*65536.

How are you having so much trouble over things which folks have sorted out quite happily now for over 12 years? None of these offsets are any different than they were with FS98, and there are literally hundreds of applications using them. I get the feeling that you are misunderstanding something quite fundamental. Perhaps if you used the tools provided you would work out what is wrong with how you are looking at things?

Regard

Pete

[VOZzer]

About the Wind Speed... All I do is define the Offset in SIOC... And then I tell SIOC to do absolutely nothing to this value. I can't understand why it is reading things like 70 if I apply no calculations to it.

Please check it with FSInterrogate or with FSUIPC's own logging or Monitoring. Maybe the 70 is correct and the 5 you are comparing it with is for a wind layer elsewhere. The offset you are reading is the ambient wind speed at the aircraft, as shown at the top of the screen when you do Shift+Z.

I'm not too sure what you are saying by "overflowing its capacity". Does this mean that I cannot use these Offsets in SIOC?

Sorry, I've no idea wehat SIOC is or is not capabable of. All i know is that the usual mistake is reading a 16 or 32 bit value which contains for its maximum value the highest possible reslut, and then converting it within those 16 or 32 bits. The normal way of treating them in as program is to copy then original into a floating point vatiable and doing the computations there. That way you don't lose fractions nor overflow the space.

Also, where is this FSUIPC Monitor? All I find is a payware tool by a website called "Ruzcool".

It's on the right-hand side of the Logging tab in the FSUIPC options dialogue. It is documented in the documentation provided with FSUIPC. Please try using "search" in your document viewer!

Pete