Jump to content
The simFlight Network Forums
cjellwood

Heading in the Bermuda triangle

Recommended Posts

To re create this annomoly start at Friday harbour as default but with the Cessna 172sp with G1000.

Head in the standard direction 339 degrees and speed up 16x to get there quicker

Just as you approach the first land mass before the mountains the plane shakes and then the heading display goes off mark

Make a few small turns to see the heading display go completely crazy

To confirm this is craziness swap planes to something without G1000 and it is fine again

It is possible to slew to this location but slew must be turned off to show the problem

I wonder what this is about? Surely this is not meant to be?

No idea, sorry. I tried to locate this zone, but failed. Must be quite small. A LAt/Lon might help find it?

Regards

Pete

Regards

Pete

Share this post


Link to post
Share on other sites

it happens inside a large area around Vancouver Intl airport anywhere but here is a position that I reproduced it at.

Lat: N48 48.25

Lon: W123 2.03

You may need to do a few small turns to trigger the problem

Chris

Share this post


Link to post
Share on other sites

Pete, can you help me with what is likely to be the last query I make about offsets because my project is near completion. I am trying to read VOR1 identity from offset '3000' that is type ASCIIZ. Unfortunately VB does not handle ASCIIZ so wondered if you knew of a way to get this info in VB? When this value is 'IND' in FS I can read the first 'I' part using simple byte read but after that I cant work ot out?

Any help on this appreciated although i know you are not a code support forum so dont worry about replying if I simply need to go back to school

Thanks

Chris

Share this post


Link to post
Share on other sites
sorry I see now. The other bytes are in the preceeding offset numebrs such as 3000, 3001 etc

I will put it in an array and use strConv when needed

My DLL will let you read a write ASCII strings to/from FSUIPC. Just define the offset as String and specify the length (in this case 6). It'll handle all the conversion to a .net string for you.

Paul

Share this post


Link to post
Share on other sites

Blimey, there goes 4 hours of my life on this variable but I did come close with this line of code that did not work for obvious reasons

Dim Test As New Offset(Of Byte())(&H3000, 6)

but ofcourse your suggestion solved all problems :P

Dim Test As New Offset(Of String)(&H3000, 6)

Thanks

Share this post


Link to post
Share on other sites

Hello again Pete, sorry to be the bearer of bad news but I think there is another small issue with the G1000 display. I am referring to offset 6050 that I believe is responsible for the DTK value. In FS this value is always shown regardless of being in GPS or NAV mode although it is only relevant to GPS bearing. FSCUIP only shows this value when in GPS mode?

This is not a grand issue but maybe it is a simple fix similar to the previous G1000 problem?

Thanks

Chris

Share this post


Link to post
Share on other sites
Hello again Pete, sorry to be the bearer of bad news but I think there is another small issue with the G1000 display. I am referring to offset 6050 that I believe is responsible for the DTK value. In FS this value is always shown regardless of being in GPS or NAV mode although it is only relevant to GPS bearing. FSCUIP only shows this value when in GPS mode?

In FSX or FS9?

In FSX, FSUIPC4 just relays whatever SimConnect supplies. It does not test any "modes".

In FS9 the whole of that area is merely a slab of FS's own memory that someone found and documented for me. I've never trusted it that much as it seemed inconsistent in any case.

Regards

Pete

Share this post


Link to post
Share on other sites
This is for FSX

What you get is direct from SimConnect, then. If it isn't supplied in some modes, it isn't available in those modes.

6050 is the SimConnect variable called "GPS WP BEARING", and it is in radians. Is this what you want for your "DTK"?

Regards

Pete

Share this post


Link to post
Share on other sites

it is behaving erratically at the moment i.e sometimes it displays correct and other times it is incorrect? I will give it some more time for testing to see if it is my error or at least give you some more info

Chris

Share this post


Link to post
Share on other sites

Hi, this is not important but may be helpfull for future reference.

To get a reliable DTK reading from FSCUIP I use offsets 6028 (GPS Mag Var) and 6060 (GPS Required True Heading).

Add the value of offset 6028 to offset 6060. 6028 is always a negative value so convert it to positive like so (vb)

GPSMagVarValue = Math.Abs(GPSMagVarValue)

This gives the desired output that seems correct to FS DTK reading but is only correct 99% of the time as I found out earlier when setting up a flight plan to go from Rochester (EGTO) -> Southend (EGMC). The FS DTK was showing 29 degrees but my calculations showed 30 degrees (29.51147)???? This is simply because of a math anomaly that seems to appear a couple of times in the radian. I think it occurs in the normal heading output also but is too small for anyone to notice.

So not to babble on, here is the code that does the job and gets a DTK output 100% of the time

Dim GPSMagVar As New Offset(Of Double)(&H6028)

Dim DTK As New Offset(Of Double)(&H6060)

Dim GPSMagVarValue = .GPSMagVar * 180 / 3.1415927

GPSMagVarValue = Math.Abs(GPSMagVarValue)

GPSMagVarValue = FormatNumber(GPSMagVarValue, 5)

Dim DTKValue = .DTK

DTKValue = DTKValue * 180 / 3.1415927

DTKValue = FormatNumber(DTKValue + GPSMagVarValue, 0)

Share this post


Link to post
Share on other sites

yup, same thing happens with normal heading (0580). When FSCUIP output = 28.47746825, FS display is still showing 29

watch out for this if dealing with radians that are displayed as fixed rather than moving all the time.

Chris

Share this post


Link to post
Share on other sites
The FS DTK was showing 29 degrees but my calculations showed 30 degrees (29.51147)

That is probably just because you are rounding to the nearest degree whilst the FS display is rounding down (truncating) to a degree. Sunch rounding differences occur all over the place.

So not to babble on, here is the code that does the job and gets a DTK output 100% of the time

Strange that you have to do this, when all the GPS values are provided direct by SimConnect, no processing by FSUIPC, and they are probably all sent at the same time. Sounds like there's some sort of bug in FSX.

Regards

Pete

Share this post


Link to post
Share on other sites

Hi Pete, can you help me with these 2 queries?

1. Is there any reason why FSCUIP would not work with a chinese version of FSX? I ask this because I am handing the EFIS project over to a Chinese guy who will ofcourse need to by FSX to work with it. Just need to know if he will be required to use English version or not

2. Lately I am working on writing NAV/COM values back to FSCUIP. Am I correct by writing the values back in the read format i.e 0x1234? I am getting unknown errors when I try writing NAV back to FSCUIP in this format (UShort)

Chris

Share this post


Link to post
Share on other sites

1. Is there any reason why FSCUIP would not work with a chinese version of FSX? I ask this because I am handing the EFIS project over to a Chinese guy who will ofcourse need to by FSX to work with it. Just need to know if he will be required to use English version or not

I don't know of any reason why not.

It is "FSUIPC" by the way, not "FSCUIP".

2. Lately I am working on writing NAV/COM values back to FSCUIP. Am I correct by writing the values back in the read format i.e 0x1234? I am getting unknown errors when I try writing NAV back to FSCUIP in this format (UShort)

I think you need to find out more about these "unknown errors" -- if YOU don't know them, who does? How do you even know they are errors?

The formats for read and write are identical, but you have to be sure they are legal frequencies. not all possible BCD values are valid frequencies. NAV ones go up in .05's, COM one's go up in .025's so the last digit goes 0, 2, 5, 7, 0

Pete

Share this post


Link to post
Share on other sites

something that is confusing me is the fact that I am not reading the NAV value as described in the doc? I read as UShort and expect something like '0x1370' but instead I am getting '4976' ? I then take this value and apply hex conversion to get the frequency. Any light on that matter would be great because it is bugging me although it is not a problem for my software. Also I am writing NAV as 4976 successfully

The errors I mentioned earlier were basically me going round in circles due to breaking FSUIPC when writing invalid data. If I write the value in wrong format etc then FSUIPC decides to only output COM1 / COM1STBY data. No problem there, just more useless info from me (I should write the data correctly)

Thanks

Chris

Share this post


Link to post
Share on other sites
something that is confusing me is the fact that I am not reading the NAV value as described in the doc? I read as UShort and expect something like '0x1370' but instead I am getting '4976' ?

4976 (decimal) is identical to 0x1370. They are the same number, the same set of bits, they are indistinguishable, just different ways of stating the exact same number! The bits are 0001001101110000. That's the binary you actually read. It equals 0x1370 in hex and 4976 in decimal. Decimal is to base 10, hex is to base 16, binary is to base 2. If you are going to do any programming you must learn to understand a little about numbers!

Why don't you use FSInterrogate and look at what it returns -- it shows you hex and decimal? You'll soon figure it out by actually looking at what you get!

I then take this value and apply hex conversion to get the frequency.

You don't really need to do any "hex conversion". The digits are there already. That's what's so easy about "BCD" (Binary coded Decimal), you need no conversion to get character forms, except for shifting the bits out. The bottom 4 bits are "0" which gives 0. the next 4 bits up are "7", the next "3" and the next "1" -- hence 1370. Just shift out 4 bits at a time and convert them to characters by adding the character '0'.

Any light on that matter would be great because it is bugging me although it is not a problem for my software.

What's "bugging" you? I don't understand.

The errors I mentioned earlier were basically me going round in circles due to breaking FSUIPC when writing invalid data.

Breaking FSUIPC? !!!!! HOW!? Please, I need all the information, dumps, logs and so on if you are managing to break FSUIPC. What are you telling me? :-(

If I write the value in wrong format etc then FSUIPC decides to only output COM1 / COM1STBY data.

FSUIPC cannot and never does "decide" what or what not to "output". It outputs nothing at all. Please explain! nothing you are saying is making any sense!

Why don't you use the TOOLS provided? FSInterrogate, Logging and so on. There's absolutely everything supplied that you need. All you seem to say here is that you've no idea what you are doing and that you are breaking FSUIPC? I really do not like that!

:?

Pete

Share this post


Link to post
Share on other sites

I am using FSInterogate and it shows format as 0x1135, sorry I just expected to get that figure exactly when reading as UShort directly. My brain lives for the moment unfortunately. Last year I did a CCNA course that required me to learn about Hexidecimal etc including the task of memorising subnet mask tables but now I cant remember any of it? I learn fast but forget fast also

About the code breaking, it seems to be writing COM1 that makes the problem occur. I recreated the problem by writing "11.2" as a single to &H34E offset. Basically after I write that to COM1, I get an obvious error in my application but after a reload I see there is no radio data whatsoever? To resolve this issue I have to reload FSX, general game reset does not fix it.

dont worry about my error reports too much, I am a renown bug magnet that can catch a bug that would normally take a million years to find during the normal cycle. They normally go un noticed unless I am around the PC although I would not say this is a bug, just an oversight on the road to perfection.

Chris

Share this post


Link to post
Share on other sites
I am using FSInterogate and it shows format as 0x1135, sorry I just expected to get that figure exactly when reading as UShort directly.

You would do, if that's what the value was. It is nothing to do whether it's a "USHORT" or whatever, you are letting the variable type confuse you all the time!

It's the way you (YOU) view the number, whether in decimal or hex or whatever. FSInterrogate can show it in decimal, if you like, but then it wouldn't be so easy to read as a frequency, because it is encoded as BCD, which means it reads easily in hex. Equally, you are sure to be able to view numbers in your debugger in hex too, if you wish. All programming tools have options to view numbers how you want, whichever best suits their use.

I recreated the problem by writing "11.2" as a single to &H34E offset.

A "single"? What is that? Do you mean a 32-bit floating point number?

Ugh! WHY? What on Earth is a "single" 11.2 supposed to represent? It isn't even remotely like any valid frequency in any case, even if it was a 16-bit BCD encoded number, which it most certainly is not, as a 32-bit floating point number! If you want a frequency of 111.20 you write 0x1120 (or presumably &H1120 in your language). All this is clearly documented, and not only that you can actually SEE it all in FSInterrogate. There is no excuse!

Offset 0x034E is a two-byte (16 bit) value, representing the COM1 frequency in BCD. If you are trying to set it to some weird value, quite unlike any frequency it can possibly accept, then the result will be unpredictable. It will certainly NOT "break" FSUIPC. It shouldn't crash FS, but it could -- in some places, writing rubbish will certainly have a good chance not only of crashing FS but possibly corrupting your FS installation!

This is not "FSUIPC breaking", it is YOU trying, for some weird reason, to crash or corrupt stuff inside FS. Remember, FSUIPC is merely your gateway to the innards of FS. If you want to completely wreck things you can, but don't expect help.

You have a responsibility, as a programmer interfacing to FS. You are responsible for the data you write. If you are going to experiment writing rubbish to assorted offsets then do NOT ask me for any more support. It is a complete waste of my time, and I'm not going to keep lecturing you about it. Just follow the rules, write valid data, don't experiment using floating point where it most certainly is not used, nor vice versa!

Sorry, but I'm not going to answer any more in this vein. I'll answer reasonable questions, but not stuff involving daft experiments writing rubbish data just to see what you can break.

:-(

Pete

Share this post


Link to post
Share on other sites

i am not writing crap to see what I can break, it was an error in my code that resulted in a break!

Like I said before, I was going around in circles looking for problem in my code where I did not realise that a previous problem had caused there to be no data from FSUCIP radio offsets. If you ask what caused the break then I will tell you whatever caused it which I have done

You are correct that this wrong data should not be going into the app, BUT also your app should not break if it ever did happen.

I was expecting a response similar to, "thanks Chris, it is not a bug but worth noting cheers". blah blah :cry:

Share this post


Link to post
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

×

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.