Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About dfournie

  • Rank
    Advanced Member
  • Birthday 01/01/1970

Contact Methods

  • Website URL
  1. I'm actually connecting 4 (as of right now) non-PC, pieces of standalone test equipment/actual GPS units, that, because of their age, only use plain old RS-232.... Thanks for the reply, Pete. Having two will still make things work easier.
  2. Brilliant work, Pete. I too, have wanted this feature for a while but got around the issue by purchasing a third party program (GPSGate by Franson Software). Unfortunately the third party software won't let me do exactly what I've wanted until you expanded this functionality of GPSOut. I would like to respectfully request 2 more instances of the new function you added to allow 4 COM ports -total-. Is this possible?
  3. No worries Pete. My application is a bit different than a normal user, so I wouldn't think others would see this issue. Neverthless, I will be on the lookout for the future released version.
  4. Very good Pete. Version 4.402 indeed seems to fix the issue I saw in 4.40. I've done numerous starts and stops of FSX with good (and constant) NMEA connects. No other problems noted. Thank you, once again for your help.
  5. Pete, I found a copy of 4.30 and re-installed it and my problems seemed to have gone away. I've run and shutdown FSX half a dozen times with good NMEA connects and no crashing. I can't explain it. Perhaps something with how my third party GPS Gate program creates virtual com ports and how FSUIPC knows when the virtual com port has been created.
  6. This is exactly what I've been seeing. The port isn't opened and GPSOut is not flagged as running. For some reason the virtual COM port is not being opened, and GPSOut is trying to send data. If I go to the program I am using (GPS Gate) and do a manual close of the virtual com port and then open the virtual com port, it then "sees" the data coming out of FSX on that virtual port and routes it where I need it. 4.30 and earlier did not require me to minimize FSX, manually close and open the virtual com port and then maximize FSX. In the end it still sends the NMEA around where it needs to go, but it's annoying all of a sudden that I have to perform manual open and closes of the virtual port. It is probably not a problem in FSUIPC, but in how GPS Gate is looking for data to be sent over the virtual com port and realize it's seeing "good" positional NMEA data.
  7. Is there a library kept of all the older builds of FSUIPC. Specifically I'm looking to revert back to 4.30 from the latest November 2008 release of 4.40. I'm getting many crash to desktops with the cause being that Data Execution Prevention is stopping a program that could harm windows, etc.. I'm also experiencing some unusual problems with the GPSOut portion of FSUIPC.
  8. Pete, My apologies if this has been asked before. Has Microsoft ever considered integrating FSUIPC directly into FSX? I know Adam Szofran now works with Microsoft/Aces Game Studio and did quite a bit of work on FSX. Obviously Microsoft is aware of FSUIPC and must have worked with you to ensure FSX compatability. Is this something Microsoft is not interested in taking on? Not to take anything away from you in terms of the financial reward, recognition and high quality and support of your product, but as more commercial products come to rely on FSUIPC I just wondered if it ever was going to head the direction away from a one-man project into something Microsoft would consider adding to the core of the product. I'm not advocating they do or do not, but with the amount of hacking you have had to do on the product and your knowledge of the FS line it seems you would be an incrediable asset to Microsoft's team. Or at the least Microsoft could do something that would allow you to get even more info out of FS at higher rates, etc... Just curious.
  9. I didn't mean to trivialize the process required to get a TCP connection up. I haven't used my CIS degree is a long time - I doubt I could code much anything useful anymore. The more time I spend flying, the less I use and remember basic computer principles. I have been very successful in getting GPSOut to connect with the serial-ethernet converter. It drives the moving maps quite nicely. I'm finding that using UDP is working far better because it really doesn't matter if the moving maps lose a few NMEA sentences here or there.
  10. All that needs to be done is open a Winsock socket connection to the specified port of a specified IP address. On my PC, if I open port 4600 on address (my assigned address for the serial-ethernet converter box) I can send a stream of NMEA data from my PC followed by carriage return/line feed directly to that opened socket. The serial-ethernet adapter box ( just receives the data on that port (4600) and directs it to its built in DB-9. The serial-ethernet adapter has a built in web server to configure each of its COM ports. Either port can be configured as a TCP server, client, or just to listen for any broadcast UDP. I have it configured for UDP listen. I set up GPSOut to send everything over a virtual com port on my PC. The 3rd party software I have (GPSGate) just takes the serial NMEA data and redirects it to port 4600 on The GPS connected to the serial-ethernet adapter sees the NMEA data and gives the proper position. The actual TCP/UDP connection between the PC and the serial-ethernet converter box is handled by this other software I'm using. My train of thought was that if the unique port name dialog box could accept ip address/port information (or a range of ports) then GPSOut could broadcast directly over UDP. All I would have to do is have the serial-ethernet box look for the broadcast and the GPS would have the data it needs.
  11. It's a Serial-Ethernet adapter that works over wireless. Basically it has 2 physical DB-9 ports on it that you can plug into any serial devices. You assign it an IP address (I'm doing it over DHCP), then you open a session (telnet, for example) to it and can send data directly to the IP address and the port (Serial port 1 on the unit uses 4600, port 2 uses 4601). The GPS gets the data and doesn't know it's not connected to a PC. The software the company provides with it is pretty useless. I've managed to get it to work with GPSOut using a third party program that creates a virtual com port and re-directs it to TCP. I was guessing I could try the same thing in the unique name port. I just wasn't sure if you were using it for standard I/O operations.
  12. Can IP addresses and specific TCP ports be entered into the unique port name field in GPSOut? Something like, etc... Or a computer network name? Basically I want to send the raw output out of GPSOut directly to a specific port on another TCP address on my network. Would instead (in a future FSUIPC release) it be possible to have a dialog box in the GPSOut tab that would accept a network name/ip address and a box for sending the output to specific TCP ports? ( 2 - 3 ports) Perhaps accepting a range of ports to send the data to?
  13. That's a pleasant surprise. FSX has no problem importing the older .pln files. That's good forethought by Microsoft. Thanks Pete.
  14. Pete, I know this is a bit off topic, but do you know of (or are planning) a replacement for FStarRC that performs the same functions for FSX? I also vaguely recall a program named FStar to Fs2K that did the same thing. I notice the flight plan formats in FSX now appear to be some sort of XML instead of the old text format from FS2002/FS2004.
  15. I've never actually used the WideFS feature as I'm sending the MSFS position output to real equipment over RS-232. With as advanced as real aircraft avionics are getting, manufacturers still use plain old DB-9 RS-232 to do most of the mudane configuration chores using Hyperterm etc.., and in one case as an actual avionics data bus to transmit non-critical information between boxes. I have found an external program called GPSGate which takes in one virtual Com port and redirects it to as many physical com ports as you want. The only problem I'm having is that GPSOut has to basically send out every sentence it's capable of generating to this one virtual port, and I'm finding that when the data gets to the physical Com ports, each receiving system has to disregard the sentences it can't use. It's just a lot of un-needed data going to the Com ports.
  • 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.