Jump to content
The simFlight Network Forums

dfournie

Members
  • Posts

    102
  • Joined

  • Last visited

Everything posted by dfournie

  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 192.168.1.100 (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 (192.168.1.100) 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 192.168.1.100. 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 192.168.1.1:4600, 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.
  16. Pete, I'm sure this really isn't of high importance to many GPSOut users but I was wondering about a future addition to allow simultaneous output to multiple COM ports with different sentences. Something like RMC, GGA, etc.. to COM 1 (or 2, 3, ....), and AV400, etc.. to COM 2 (or 3, 4, ...) simultaneously. Would this be difficult to achieve? Would you feel this to be a useful addition?
  17. AV400 format does not exhibit the same problem. Altitude is always right on.
  18. This is a very interesting find. I had also previously noticed that the GPS altitude displayed on all of the GPS's (5 of them, one of them being the Avmap) I use with GPSout never exactly matches the altitude displayed by MSFS. I never really thought much about it because in real aircraft the GPS altitude displayed tends to always be off slightly from the barometric altitude because of the reasons given above (geoid, ellipse calculations, etc..) But this is being simulated. The Avmap and Garmin 396 for example have a built in terrain database that has elevations at approx 10m - 1km accuracy (depending on where your at). I suppose it's remotely possible that these untis are somehow processing the incoming MSL and performing a calculation on it. This really shouldn't be the case because the NMEA spec is very specific about what each string must contain. Pete has everything spot on. If the MSL altitude is being sent out by MSFS in the NMEA altitude string it should show that -exact- value on the GPS. I seem to recall that I did not see this problem when I ran GPSout in AV400 format out to my Garmin 396. I'll have to hook everything up and try to recreate it on that one.
  19. Is it possible to write an airspeed into the appropriate offset location (TAS, IAS, Ground Speed) while FS2004 is paused, and then to unpause FS and have the aircraft at that set speed? I've been experimenting with writing into those locations, and with the velocity locations, but when I unpause FS it seems to revert back to the airspeed it was at, at the time it was paused. It seems to ignore the speeds I'm giving to it as soon as pause is released.
  20. I just got the first subscription disk today for Jeppesen FlightDeck/Navsuite. $2000 a year doesn't get you what you'd expect. All US approach plates, Hi and Low enroutes, some sort of moving map capability with 28 day updates. I need to spend some more time getting into it. I installed it on a Tablet PC with a touch screen and it seems to perfom well. Definately not geared to off-line flight planning like Flitestar. It's really for in cockpit use. After using it for only a few minutes I think it's a shame that Jeppesen doesn't seem to want to expand/continue their General Aviation flight planning, but seems to be sinking considerable resources into their Corporate aviation products. Guess you need to go where the $$$$ are.
  21. I sent an e-mail to Garmin tech support some time back, inquiring if they ever planned to give their units the ability to accept NMEA IN so that the (any) handheld could be used as a remote map from another source (GPSOut). Their reply to me indicated they were rather offended that someone would want to send NMEA into it from another source. As though it would "infect" the Garmin. They don't get it. From a pure business sense, I do see their logic though. Lowrance does not subscribe to this same train of thought.
  22. Wow, Jeppesen Corporate World Wide. That was a pricey one. I believe the corporate version can output flight plans to real world Flight Management Systems as well. Somewhere I have a old copy of Jepp View which I believe can act as a plug in to Flitestar Corporate and provide all the worldwide Jepp approach plates making them accessible from within FliteStar/FliteMap. I've got 9.16 and other than using it for real flight planning I've been using it with your FStarRC and another converter I found called Flitestar to FS2K. They both work quite well. Yeah, I forgot that FlightPrep is pretty much US - oriented. I put a copy on one of Tablet PCs we have at work and it seems to work very nicely. All the approach plates are geo-referenced and can display the aircraft flying the approach on them.
  23. Jeppesen had a reason for this. They originally had the capability in Flitemap for the program to be used as a moving map and flight planner depending how much the user paid to enable those features. They have since moved away from Flitemap and discontinued it. Flitestar 9.16 and up will only communicate with an attached GPS to upload/download flightplans. You can still buy Flitemap from various places, but Jeppesen told me they were phasing both Flitemap and Flitestar out and initially reducing support options for Flitemap. Flitestar won't be phased out for some time. Jeppesen is replacing the Flitemap capability with a new subscription product called Flitedeck/Navsuite. The subscription starts somewhere around $1250 a year. It's geared for in-cockpit Electronic Flight Bag use and does include a moving map with NMEA, etc. input. Check out http://www.flightprep.com. It's a product I completely stumbled upon a few months back. They make a very cool software package that includes a moving map, and has all the US approach plates/STARS/SIDS. I think its called Chart Case Pro.
  24. Garmin GPS 72 cannot accept NMEA input. It can only output it. I bought a GPS 76CsX not too long ago and it won't accpet NMEA either.
×
×
  • 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.