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