Pete Dowson Posted January 25, 2009 Report Posted January 25, 2009 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
cjellwood Posted January 25, 2009 Author Report Posted January 25, 2009 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
cjellwood Posted January 26, 2009 Author Report Posted January 26, 2009 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
cjellwood Posted January 26, 2009 Author Report Posted January 26, 2009 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 Chrs
Paul Henty Posted January 26, 2009 Report Posted January 26, 2009 sorry I see now. The other bytes are in the preceeding offset numebrs such as 3000, 3001 etcI 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
cjellwood Posted January 26, 2009 Author Report Posted January 26, 2009 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
cjellwood Posted January 28, 2009 Author Report Posted January 28, 2009 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
Pete Dowson Posted January 29, 2009 Report Posted January 29, 2009 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
Pete Dowson Posted January 29, 2009 Report Posted January 29, 2009 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
cjellwood Posted January 29, 2009 Author Report Posted January 29, 2009 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
cjellwood Posted January 29, 2009 Author Report Posted January 29, 2009 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)
cjellwood Posted January 29, 2009 Author Report Posted January 29, 2009 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
Pete Dowson Posted January 30, 2009 Report Posted January 30, 2009 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
cjellwood Posted January 30, 2009 Author Report Posted January 30, 2009 it is sorted, that is the main thing :) thanks Chris
cjellwood Posted January 30, 2009 Author Report Posted January 30, 2009 Hi Pete, my crazy project is as good as complete now so have uploaded small video of it to youtube. Thanks again for your help! http://www.youtube.com/watch?v=VaKLGdpxAHA Chris
Pete Dowson Posted January 30, 2009 Report Posted January 30, 2009 Hi Pete, my crazy project is as good as complete now so have uploaded small video of it to youtube. Thanks again for your help!http://www.youtube.com/watch?v=VaKLGdpxAHA Chris Looks goodexcept you spelled FSUIPC as "FSCUIP" in the title. ;-) Pete
cjellwood Posted March 12, 2009 Author Report Posted March 12, 2009 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
Pete Dowson Posted March 12, 2009 Report Posted March 12, 2009 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
cjellwood Posted March 12, 2009 Author Report Posted March 12, 2009 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
Pete Dowson Posted March 13, 2009 Report Posted March 13, 2009 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
cjellwood Posted March 13, 2009 Author Report Posted March 13, 2009 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
Pete Dowson Posted March 13, 2009 Report Posted March 13, 2009 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
cjellwood Posted March 13, 2009 Author Report Posted March 13, 2009 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:
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now