cjellwood

Hi Pete, Recently I attempted to crate a gauge in my project for 'battery load' which is offset 282C. I have a strange problem with its output that is really baking my noodle as I have never come across this issue before having used over 50 offsets so far in my project. When I read 282C using the interogator it shows the corect values i.e value = 0 during normal flight or value = -12 when there is an electrical failure. That is great but when I use this offset in my software it does not give the value = 0 during normal flight? What I get is a fast flickering of values between -1 to -9 ? My read code is very simple Dim ElecBattM As New Offset(Of Double)(&H282C) and there is no factoring applied. The strangest thing is that during an electrical failure it does give the correct value i.e value = -12 as it should. So why am I getting a good value from interogator but flickering wrong values in my code? It does not make sense! :roll: Chris

Hi. I may be missing the point here so apologies if this is not helpfull. Offset 0366 lets you know if the plane is on the ground or not. Maybe no good for runway landing confirmation but can be used in conjunction with this airport/runway xml file. It gives you airport co-ords, runway co-ords plus other usefull data such as helipad, parking spot co-ords that could make more usefull features in your application. http://www.leons-world.com/files/AirportData.zip Credit to James Kier for helping me create that xml file. Another file is available that provides VOR, NDB and ILS data available on request. Chris

sorry Pete, I have just realised WideFS is a 2 part program. I was under the impression earlier that WideFS connect directly to FSUIPC where FSUIPC is the host. I was wrong so you are 100% correct that another client/server may as well be built from scratch for linux. There is only a handfull of offsets that need to be thrown over the the linux client so it need not be a complex issue. In fact i already made a version of WideFS for windows in an earlier project so i just need to port the client to Linux. i really dont like Linux, my Linux loving friend helps me out with the bash complexities so i dont get my hands dirty. The display app i have is primarily written for windows but being compiled for the beagle-board as we speak. It is basically the EFIS, PFD panels for Learjet 45 that can easily be run on windows via a seperate display or run on a network pc via widefs (not uncommon from any other FSUIPC app). The reason for the linux requirement is so the display can run on the beagle-board which is very small and power efficient compared to a normal pc. It can run 3D apps like a desktop whilst only pulling 2 watts of power! Ofcourse the downside is that it only runs small Linux distributions on ARM processor. It basically mimics a typical 'embedded' style system where the user turns on the unit and the display appears instantly. The benefit is mainly for cockpit builders that want a break from having 20+ networked pc's hidden behind the deck. I foresee many apps using this technology very soon for FS Chris

creating a 'middle' host program is the obvious solution as you say, but i get the feeling an easier solution is available. I dont want to pry too much into the workings of WideFS which is a commercial app but would you divulge neccessary info regarding sockets and libraries used for the WideFS connection? Assuming it is written in C++, the library that is used in WideFS is likey to be available in the linux compiler also. There will be many happy bunnies if a WideFS for linux is developed so i would be happy to hand it over to your control in exchange for the required knowledge to develop it EDIT: sorry Pete, I have just realised WideFS is a 2 part program. I was under the impression earlier that WideFS connect directly to FSUIPC where FSUIPC is the host. I was wrong so you are 100% correct that another client/server may as well be built from scratch for linux. There is only a handfull of offsets that need to be thrown over the the linux client so it need not be a complex issue. In fact i already made a version of WideFS for windows in an earlier project so i just need to port the client to Linux. Chris

Hi Pete, I second the WideFS request for linux because i have some great EFIS, G1000 displays running on the almighty BeagleBoard http://www.beagleboard.org but no communication app to get data from FSUIPC :( You say that the interface to FSUIPC is published, can you tell me more about this? I think i know what you mean but not 100% sure. i have worked on remote socket apps for data transfer before but need as much info as possible. When this linux data handler is ready i will share with all free of charge Chris

thats fair enough, if it was FSUCIP breaking then it would be worth noting but obviously it is an FS thing. I have coded boundaries into my input device now so only the correct data is ever allowed into FSUCIP (as shuold be, user responsibility) Chris

oh, and it is possible to write crazy NAV frequencies such as 112.91 without error As you know the stages are 10,15,20,25 etc normally. The bad effect that occurs from writing as above is that when this data appears in FS, the following happens Example: Write 112.11 to NAV1 via FSUCIP switch to FS screen control and increment the value to find that the stages now go up as follows: 112.16 112.21 112.26 112.31 so not good, but no error as stated in previous posts worth noting? Chris

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:

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

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

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

I always get that wrong lol

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

it is sorted, that is the main thing :) thanks Chris

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

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)

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

This is for FSX Chris

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

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

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

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

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

it seems that is not the only problem with the G1000 as I discovered today. It looks like I have actually found a Bermuda Triangle within FS that affects only the G1000 heading display. This morning I was testing my app and loaded the default Friday Harbour with Cesna 172sp (G1000 version) but as it was loading my little son started crying for a feed. FS was left running on its own so the plane was heading straight for the mountains at heading 339 degrees When I returned to the pc I discovered that the heading display in G1000 was showing the wrong reading? FSCUIP output remained at 339 degrees but the G1000 display was showing 220 ??? I then made a few small turns to discover the G1000 heading moving very eratically and completely out of sync with normal motion possibly twice the normal rate of turn. The G1000 heading is completely useless from this point, it never recovers even if you return to the start position. A reset is required 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? Chris

thanks Pete, yer a legend! It has been a good day all round. Me and eldest son went to Southend airport today for some instrument tuition and ended up meeting some engineers who gave me a back stage pass to the Vulcan area where they were turning it around and firing up the hair dryers. One does not realise how huge this bird is until it move 2ft above your head. Anyway, pressure settings were explained and I was able to tune to ATIS for the QNH data so to make the pressure adjustment. The adjustments are very modest so I dont think my virtual life was in danger when not giving it due respect in FS :)