Jump to content
The simFlight Network Forums

cjellwood

Members
 View Profile  See their activity

  • Posts

    60

  • Joined

  • Last visited

 Content Type 

Posts posted by cjellwood

  2. Offset 282C issue

    in FSUIPC Support Pete Dowson Modules

    Posted

    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

  3. How to know that I'm in the runway?

    in FSUIPC Support Pete Dowson Modules

    Posted

    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

  4. FSUIPC for Linux

    in FSUIPC Support Pete Dowson Modules

    Posted

    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.

    Can you tell me, then, what FSUIPC applications you have ready on Linux? I don't understand the point of a Linux WideClient if there are no applications?

    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

  5. FSUIPC for Linux

    in FSUIPC Support Pete Dowson Modules

    Posted

    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

  6. FSUIPC for Linux

    in FSUIPC Support Pete Dowson Modules

    Posted

    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

  8. Heading in the Bermuda triangle

    in FSUIPC Support Pete Dowson Modules

    Posted

    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

  9. Heading in the Bermuda triangle

    in FSUIPC Support Pete Dowson Modules

    Posted

    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:

  10. Heading in the Bermuda triangle

    in FSUIPC Support Pete Dowson Modules

    Posted

    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

  11. Heading in the Bermuda triangle

    in FSUIPC Support Pete Dowson Modules

    Posted

    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

  12. Heading in the Bermuda triangle

    in FSUIPC Support Pete Dowson Modules

    Posted

    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

  17. Heading in the Bermuda triangle

    in FSUIPC Support Pete Dowson Modules

    Posted

    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)

  20. Heading in the Bermuda triangle

    in FSUIPC Support Pete Dowson Modules

    Posted

    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

  23. Heading in the Bermuda triangle

    in FSUIPC Support Pete Dowson Modules

    Posted

    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

  25. Heading in the Bermuda triangle

    in FSUIPC Support Pete Dowson Modules

    Posted

    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

    heading_fault.jpg

×
×
  • Create New...

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.