Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About BrunoBL

  • Rank
    Advanced Member
  • Birthday 01/01/1970

Contact Methods

  • Website URL

Profile Information

  • Location
    Rio de Janeiro, Brasil
  1. Hi, When replying to Rotodyne's "considering learning to code for this - need help" thread, I posted code fragments for just that: getting nose, right and left gear positions. It is Delphi, but not that much different from VB. Take a look at it. Best regards, Bruno
  2. Please allow me to post my view, as I also started out with many of your doubts. After a while I finally understood what was involved and went from there to writing my applications for FS via FSUIPC. It is really much simpler than initially it seems. You need to write a program that goes along the following generic lines: 1. estabilish connection with FSUIPC (one line of code). 2. read any variables you wish from FS via the FSUIPC interface. (one line of code per variable). 3. Tell FSUIPC to process the read (one line of code). 4. close the connection with FSUIPC. (one line of code). That's it. Steps 1 and 4 are done only once, at the begining and end of program respectively. If you need constant update of the values (likely), then do all the reading (step 2, above) inside a program loop. I do step 3 inside the loop, too. How you go about to implement the above will obviously vary according to the programming language you use. I used Delphi, in which case you need to make available for the compiler a library of functions written for it, called "PFUSER.PAS". This library contains the actual code for functions you will be calling from within your code. It is available from the SDK, as is all the necessary information on how to use the FSUIPC interface. Strictly speaking, the library isn't needed but by using it you bypass the need of a lot of low-level programming. Just call the library functions passing the right arguments and you're done. If it is of any use, here are code fragments from my Delphi application. The application does all sorts of things, as varying wind noise intensity depending on indicated airspeed and lighting up the red/green landing gear status (locked/transit) anunciators on the instrument panel. So suppose you want to read IAS and the 3 landing gear leg positions. A program could look like this: ----------------------------------------------------- {Do the following only once, at the begining of your program,} {to estabilish communication with FSUIPC:} FSUIPC_Open(SIM_ANY, dwResult); {Then, begin a loop (this fragment would be inside a Delphi "timer" } FSUIPC_Read($0BF4, 4, @gearLeft, dwResult); // left gear position FSUIPC_Read($0BEC, 4, @gearNose, dwResult); // nose gear position FSUIPC_Read($0BF0, 4, @gearRight, dwResult); // right gear position FSUIPC_Read($02BC, 4, @IAS, dwResult); // IAS FSUIPC_Process(dwResult); // Process the reads {here you can use your variables (IAS, gearLeft, gearNose, } {gearRight) as needed. Don't forget to convert to meaningful } {quantities: knots for the IAS, etc. For instance, to convert } {IAS to knots, do this: } IASKnots := Round(IAS/128); {end the loop here} {Just before your program ends...} FSUIPC_Close; ----------------------------------------------------- Hope this sheds more light than shadow on the matter! As Pete explanined, do not fiddle with TCP/IP, networking, ports or anything like that. Just talk to FSUIPC directly. Do take a good look at the SDK. there are working code examples (for Delphi and other languages). Good luck! Best regards, Bruno.
  3. Pete, Thanks for reminding me of the wonderful days of APL. I programmed in VS APL under VM/CMS (a mainframe OS quite common at the time) in the early 80's for a large financial company. I wonder if it is still used? Best regards, Bruno.
  4. Pete, This is the beauty of talking to who knows. You've pretty much seen it all. No matter what mistakes your users keep repeating (this one at least!), there is a good chance you've either seen it before or have the resources to infer what the problem is. Just as you predicted, despite updating WideServer in the FS machine I failed to update WideClient on one of the four machines in my network. Exactly the one in which I tried running PM's MCP demo! To further complicate diagnosis, PM Glass Cockpit (runs in that machine too) did not complain or misbehave in any way, so I only noticed something wrong when trying the demo program. All is running fine now. Thanks again for the great software and great support. Best regards, Bruno.
  5. Hi Pete, I am using a registered FSUIPC 3.411 and WideFS 6.41, and I am having a bit of trouble with PM MCP (demo version). After a few email exchanges with Jonathan and Enrico, PM suggested that I post this here. I am scratch-building a 737 MCP. For test purposes I initially used only the default FS2004 737, and assigned the MCP functions (via FSUIPC dialog facilities) to the default (not PM) 737 autopilot functions. Everything worked fine except, of course, the more involved MCP logic such as LVL CHG which Microsoft did not implement on its autopilot. So far, so good: my hardware panel exactly replicates the default 737 autopilot panel. Being satisfied that my wiring and connections were OK, I decided to use PM's MCP to control my panel and changed my assigments accordingly (from default Microsoft autopilot to PM MCP commands). This is when the strange MCP behavior started. All MCP push buttons (N1, VOR/LOC, etc) work as expected, but the rotary switches "stick" once they are moved. That is, if I touch a rotary switch then its value keeps increasing (or decreasing) forever until I change direction again with the rotary switch. It then changes forever in this new direction, etc. At first both Jonathan and Enrico thought that this was a keyboard encoder problem (I am using Hagstrom) but I completely removed the encoder, deleted FSUIPC.INI, restarted everything and reassigned the rotary functions (PM MCP SPD INC and DEC, for example) to two joystick buttons and, indeed, the problem persisted. So far I have detected the following: If I run the PM MCP demo in the same machine as FS2004, then I have no problem whatsoever (with or without the keyboard encoder). With the MCP demo in a remote computer, I can command PM MCP SPD INC or DEC via that PC's keyboard, but if I touch an INC or DEC joystick button the problem reappears (in effect disabling even the keyboard command). My original MCP rotary swithes were not assigned to joystick buttons but rather to keypresses (via the Hagstrom encoder), but PM suggested that I change them to joystick buttons instead. I did (I am actually pressing buttons on a real joystick for the tests), but that did not fix the problem, so I presume the trouble is not encoder-related, or even keypress-related. The network seems to be OK, I routinely run PM Glass Cockpit in the remote PC with no problem at all. I am about to give up and settle for running the MCP software locally in the FS2004 machine (which I would very much rather avoid). Have you seen anything like this? Do you have an idea of what may be wrong? Best regards, Bruno.
  6. Hi, It has been posted in other threads that aviation GPS units that do talk to GPSout must be put in "simulator mode" in order to turn off their internal receivers. You can give it a shot in your unit and see if it works. Please don't forget to keep us informed of your results! At any rate, I too have been intrigued by "NMEA IN/OUT" being only "OUT" in fact, since it seems that most receivers which can be fed from external NMEA sources are those with "aviation" or AV400 interface (thanks for implementing that in GPSOut, Pete). One user did report here that his marine receiver (a bulky one, too, according to him) can handle NMEA IN from external devices. But this does not seem to be the norm with handhelds. Best regards, Bruno.
  7. Pete, It is interesting to see how a one-man product like yours never ceases to be improved. Somehow you manage to put out version after version and still personally provide online support. You said in another thread that people have to do other things like sleep and eat. I wonder how you manage to do it all. The radio panels I am building will (for the time being) also be of the single-display (no stby freq) type. I managed to get away with it by setting the radio type to not having a stby frequency in the aircraft.cfg file, as you suggested. Works like a charm, and I don't even need the displays actually working (they aren't assembled yet), since I see NAV1, NAV2 and ADF frequencies in Project Magenta's ND and they get updated as I turn the respective rotaries. Cool. I don't use a lot of joystick buttons. Most of my inputs are via a keyboard encoder. But the "at present" bit makes me feel I could hope for conditional keys facilities too... :wink: Best regards, Bruno.
  8. Pete, Just did. You know, I think I never even noticed that it behaved this way in the default panel. I guess I had to look at this with the critical eye of testing a new radio panel's wiring to see it. Go figure. Naturally, diferent people are coding diferent parts of the product. In situations like this, the diferences stand out. Wow! ...You wouldn't care to tell us a bit about them, would you? :D Best regards, Bruno
  9. Hi Pete, I finally got my hands on a few rotary pulse switches from Alps, and started playing with an MCP panel and radios. All is going fine, but I came across a strange behavior in NAV1. For these quick tests I am not programming anything (and shouldn't need to) as FSUIPC interface seems to have all the facilities to the internals I am interested in. The trouble is with Nav1 Radio Fract Dec. (decrease decimal part of NAV1 receiver frequency). This facility seems to behave exactly like Nav1 Radio Fract Dec Carry, and sets the frequency integer to the next lower value when you go "below zero" on the fractional digits. Since there is a specific "Carry" version of this facility (and since both "Inc" and "Inc Carry", on the other hand, behave as axpected) it seems something is awry. Maybe FSUIPC is looking at the same locations for both facilities? I didn't try to program NAV1 directly using FS2004 offsets. As I said, at this point I only tried using FSUIPC dialog faciilities for this. Best regards, Bruno.
  10. Tuomas, Will check out the charts. Thanks. Great chat. Enjoyed every bit. I even discovered that a local Garmin distributor did not know about the "aviation in" interface, and promised to take a closer look at this after prompted by my inquiries. Pete, if you are listening, sorry for the offtopic conversation :oops: . Somewhere along the thread we drifted from AV400 sentences via FSUIPC to wonderful flying places, outstanding simulators built by a team of enthusiasts... isn´t this what it´s all about? ...Will try to adhere more strictly to the topics in the future, though. Best regards, Bruno.
  11. Tuomas, I agree that it is unlikely that gen purpose receivers have AV400 capability. It seems I will have to choose between this and some eye-candy colored display! [later, after looking at your pics...] WOW. You put really first class crafstmanship into the simulator! I had seen (pictures of) Simkits before, but your panel is truly awsome. A must-see for anyone interested in hardware cockpits! It is a very nice departure from the current trend of glass (Airbus and Boeing) cockpits. What kind of display are you using? From the picture it does not seem to be a simple monitor placed in front of the windshield. Is it a collimated visual system (like the airline-type simulators)? Also... Great, great pictures of your flying environment. Beautiful. We have a little airport near Rio, called Angra dos Reis (SDAG, Should be iin FS2004 default scenery) that somewhat resembles Kumlinge. But in our case, there are some hills not too far off the threshold opposite the coastline, which can make approaches a bit uncofortable (both in real life and in FS2004) until you get used to the place. I downloaded the Kumlinge scenery (and associated files). Will try it out when I get home from work later this evening. Best regards, Bruno.
  12. Thanks, Tuomas, for bringing this subject up. I am considering a new GPS, but I am still not sure if I this feature will tip the scale towards an aviation-specific unit. My intended use for flying will be pretty much limited to situation-awareness and amenities like ETE to waypoints, recovering a flight's track, things like that. But there are some cost-effective mapping, non-aviation models that could be put to good use with the above in mind and also allow user map (and of course data) upload, have color displays, etc. But... displaying FS2004 positoin in a real-world GPS receiver would be *very* nice, and far superior to the unit's own simulator mode (for learning), too. Tough decision. That didn't work in my old Garmin 45XL (marine), either. Too bad. I asked Garmin about this for one of the models I am interested in (GPSmap 76C), and this is the relevant part of their answer: But... "more than likely" is different from "yes" :? . The plot thickens. Best regards, Bruno.
  13. I got to try this recently on an almost-10-years-old Garmin 45XL. Although it has a "NMEA/NMEA" interface option (implying NMEA input/output?) it did not read any data from GPSout. All of the unit's other data input/output are functioning properly. The unit is set to read NMEA (0183 version 2.0 - to be confirmed) sentences. I may get hold of a more recent receiver (a friend's Garmin 76) and experiment with it. Best regards, Bruno.
  14. dfournie, Thanks for your input. Is there such thing as a "simulator mode" (receiver OFF) in your marine GPS? Didi you have to use this mode in order to get data from GPSout? Best regards, Bruno.
  15. Alternators, generators and inverters are different things, actually. Alternators and generators provide electrical power from a mechanical input, the former producing AC and the latter DC. An inverter converts DC to AC and thus needs a working source of DC (generator or battery) to function. Some aircraft use alternators (despite loosely terming them generators) and do not need inverters for AC power, except for generating standby AC from DC if the alternator fails. Others use true (DC) generators and must use inverters to power any AC instruments installed. The King Air seems to be one of those (I've never flown one), and that is why Flycol needed the inverter on/off switch. Still, FS has no inverter switch, so the generator switches will have to make do. Best regards, Bruno.
  • 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.