Jump to content
The simFlight Network Forums

BrunoBL

Members
  • Posts

    78
  • Joined

  • Last visited

Everything posted by BrunoBL

  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.
  16. Tuomas, An afterthought to my last post here... I see that your model (GPS196 - oustanding!) also has the NMEA IN feature I described above. Have you tried to connect GpsOut to your unit and see if it will receive data from FS with the "NMEA IN/OUT" interface format? If not, could you be so kind to give it a try if you have the time? I have to think that an NMEA "IN" format option should enable the receiver to get data from its port in the NMEA format... and display it. Maybe (as already suggested here) the unit has to be in simulator mode). I am planning to purchase a GPS receiver, and this feature would be very nice indeed. I am trying to determine if I need to narrow my choices to those receivers with the "AVIATION IN" format in order to have the GpsOut tracking feature. Thanks for your time, Bruno.
  17. Hi Tuomas and All, Some GPS receivers (Garmin 76C, for instance) hava NMEA IN (in addition to NMEA OUT)capability, as described in their manuals. Anyone tried listening to Pete's GpsOut with such a unit (using the more mundane NMEA sentences)? Maybe in simulator mode, while GpsOut is sending streams of data? Best regards, Bruno.
  18. Hi, If you are into programming you can check offset 31E4. By reading it, FSUIPC emulates height above ground for you by subtracting ground elevation from your present altitude. Hope this helps... Best regards, Bruno.
  19. The encoder sits in series between the keyboard and the PC. Any one of the 72 switches may be translated to a character (or a macro sequence). Thus, whatever happens in the encoder goes in through the keyboard input of the PC, exactly as if it were typed in the KB. Other than a flexible configuration (what keystroke sequence - up to 16 characters per event, IIRC - is generated when a particular switch is opened or closed, or both) there is no real programming to it. The plot thickens. I see I have a lot of reading to do! :) But Now I know what to look for. Will go into the documentation with this in mind. I will of course put some of my own effort into this (as you might expect from those who venture into this hobby) but if I get into trouble... will cry for help! :oops: Thanks for the support, Bruno.
  20. Pete, That's out of date. 3.30 is current. Ooopss. Will get the latest. I don't really have a button in the joystick sense. I have the TCAS button on the EFIS panel (and all the other contacts from that panel, too) wired to a keyboard encoder which fools the machine into thinking that I hit a keystroke with each button pressed or rotary switch turned. Maybe there is a way of treating this as a joystick button? Otherwise I may actually get an adittional joystick and wire the TCAS knob to one of its buttons, and thus use your last example (joystick in the 0-15 range). Best regards, Bruno.
  21. Pete, I am running FS2004, registered FSUIPC 3.22 (+WideFS) and PM build 415. After building a hardware EFIS control panel and getting just about every button to work, I can't see how to implement the TFC button (toggle TCAS on/off). As you know, you push the Range knob for this. IN PM's manuals there are discrete offsets to turn TCAS on or off (via the PM command FSUIPC facility), but no toggle option. There is also no direct PM TCAS toggle facility in FSUIPC. Here are the relevant params found in (http://www.projectmagenta.com/resources/PMOffsets.html): 50 TCAS Off 51 TCAS Alt 52 TCAS Callsign 53 TCAS All I can use (and indeed they worked) 50 and 51 above to turn TCAS on or off but, as said, with no toggle. Since I must do this with the same button (push/push for on/off) I thought I would need a "toggle TCAS" offset. One possibility would be moving the keyboard encoder involved in this into the machine running PM, in which case it would be simple to send the CTRL-SHIFT-Z (TCAS toggle which, oddly enough, PM provided as a keyboard macro but omitted the offset for use through FSUIPC). However, my encoder is also used for FS functions besides PM, so I need it in the FS machine. I did query the PM folks about this. I don't have a reply just yet, but anyway I thought you could also give some info on this. I don't think this is the case of conditional programming of the keys in FSUIPC.INI, is it? If so, how would I send a "50" parameter (PM command with param) at the push of a button, and a "51" at the subsequent push of the same button, etc, etc? Best regards, Bruno.
  22. Oh, but I am not using PFC. Only Project Magenta with FS2004. I plan to add (hopefully) CPFlight´s MCP, and most of the rest will be built from scratch. And I will be an old man by then :wink: . I did try to trace who, in which of simFlight´s forums, thought that the combination was not possible and why. I don't know what sort of problem he had, but unless he reads this and comes in, we may never know. Thanks. I cannot even start to imagine how you manage to sort out all kinds of possible problems that people come up with. Granted, after a long time giving support you find that most problems can be more or less categorized, but still software support demands a lot of hard work, not to mention development, debugging, etc. And you still find time to be active on a daily basis in several different forums? You must need more sleep, Pete! :D Best regards, Bruno.
  23. Pete, At this point I have one FS machine with WideFS server and two WideFS clients (one PM and one with my own tinkering with Delphi/FSUIPC). This is what I thought possible, and was surprised that someone stated otherwise. With this cleared up, I will start looking into WideView (and of course extra PCs) to experient with multiple outside windows. Best regards, Bruno.
  24. Hello, Someone posted (here or in a related forum) that you cannot use WideFS and WideView at the same time. Is this so? I never expected this to be the case. How else can multiple outside views be generated while running WideFS? Regards, Bruno.
  25. Ultimately, a simulator like one of those is the goal. The PC running FS will be exclusive to it, and to the display of the front view. I am starting a little shy on all this, given the ambitious and very challenging nature of a project like this one. The multitude of abilities involved (mechanics, electronics, some programming, the integration of all sorts of hardware and software from many different suppliers) suggest that I am in for years of fun. But... will there be time left to fly? :D Pete, thanks for the wonderful and very educating chat. I trully apreciate it. 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.