Jump to content
The simFlight Network Forums

Wildfire563

Members
  • Posts

    24
  • Joined

  • Last visited

Everything posted by Wildfire563

  1. :? Ok Now I'm totally confused. I have been testing this for 2 months, and it wouldn't work for me, using exactly the same procedures I've described. Then, after I added the \\.\; COM19 worked. I was happy. I figured perhaps I hadn't tried any com ports below 9 (I thought I had, but it was a possibillity). So then I tried COM9 (no \\.\). It worked. Cool, still sort of following the rules of the game. So then I went back and tried COM19 (no \\.\). It worked. Eh? Perhaps there was some memory?? So then I tried a port I haven't used before, COM18 (no \\.\). It worked. ??? I tried turning the computer off and back on and it still worked on COM18. The only thing I can think of is now some corrected default com port settings are being saved and used for all ports. I suppose this still supports your argument above that the \\.\ is needed for the settings, too. So now I'm going to try it on a couple of other computers and I'll get back to you. Cross my heart and hope to die this wasn't working before. Oh well. Thanks!
  2. But the user needs the \\.\ in front of wcesusbsh001. Is this a similar case, then?
  3. Hi Pete, You hit the nail on the head! According to Johan, if you are using CreateFile() to open the port, all ports above COM9 require a \\.\ prefix. So I entered Port=\\.\COM19 in the [GPSOUT] section of the FSUIPC4.ini file and it worked! Thanks!
  4. I'll ask the author to go into more detail. Thanks for listening!
  5. Some more information from the same thread. The problem, of course is you have to go through a bunch of steps to get it to work. It would be more convenient if GPSOut recognized the ports directly. It's not a huge deal, there are workarounds. But I believe that you'll find GPSGate used more often, and it would be nice if you could support the case. Thanks!
  6. If I look in HKEY_LOCAL_MACHINE\Hardware\DeviceMap\SerialComm I see: Name Data Default (Value not set) \Device\bizVSerial19 COM19 \Device\bizVSerial6 COM6 \Device\Serial0 COM1 \Device\Serial4 COM4 \Device\Serial5 COM5 \Winachsf0 COM3 I'm using MixW to connect ports 4 and 5, and Com6 is another virtual serial port from GPSGate that is set as an output.
  7. Yes, as noted above, I have tried that. For instance, I would create a virtual serial port in GPSGate like COM19 as the input, and then set Port=COM19 in FSUIPC4.ini. So far, GPSGate has not received a signal when I've tried that. I know it works though, because if I use XConn, I'll get a connection in GPSGate. I'll keep working on it and let you know what I find.
  8. Hi Pete, Any chance you could take a look at the following issue? I've been using http://www.franson.com GPSGate to supply multiple devices with the GPS stream from GPSOut for both FS9 and FSX. It also works great with WM5 as it will send a signal using Activesync if you have GPSGate installed on both the PC and PPC. I currently have to use MixW or http://www.eltima.com VSPD to create a pair of linked com ports to get GPSOut to communicate with GPSGate. GPSGate has the ability to use "virtual serial ports" for input, which would obviate the need for MixW/Eltima VSPD. IOW, In GPSGate, you create a virtual serial port for its input, and then you can call out that serial port from GPSOut, and GPSGate should be able to read the input directly because you can attach multiple "devices" to a virtual serial port. Unfortunately, in my experience GPSOut doesn't seem to recognize the virtual serial ports created by GPSGate. Another GPSOut-like utility called XConn (http://www.pocketfms.com/2-downutility.asp#Ubi) does, but it only works with FSX. I do not see the virtual serial port listed under available ports to use in the FSX GPSOut interface, and if I enter the port in FSUIPC.ini (FSX) or GPSOut.ini (FS9) it still doesn't work. I imagine the issue may be you only recognize serial ports listed in the Device Manager? The developer of GPSGate offers the following advice from this thread - http://franson.com/forum/topic.asp?TOPIC_ID=5198 Thanks!
  9. Part of your solution for running multiple GPS reading devices from a single device is Franson GPSGate - http://www.franson.com They also supply libraries for virtual serial port and bluetooth driver creation.
  10. Hi, I'm wondering if anybody has any suggestions for me. My computer does not have any dedicated com ports on the motherboard. I'd prefer not to have to use my last PCI slot to add one. I have a Garmin 396. It uses a USB connection. My computer has lots of USB connectors. Is there a program which routes data from a serial port to a usb port virtually? I have seen a couple of people saying you are connecting your Garmin 396 to GPSOut. How are you doing it? A com port (on computer) to USB (on 396) converter? Any thoughts for how to get the data out through a USB port? I have MapSource and nRoute. Thanks,
  11. Hi, Has anyone gotten FS9 to connect to PocketFMS through GPSOut on an HP Rx5915 Travel Companion with the built in GPS receiver? I've got the setup working fine with my HP Hx4700, but I can't get any "signal" into the 5915. My settings are: [GPSout] Sentences=RMC,PGRMZ,GGA,GSV,GSA,GLL Interval=1000 Port=\\.\WCEUSBSH001 ; the dot is very important Speed=19200 connected using the following procedure: A. Shut off USB access to ActiveSync. You may want to unconnect the cable and do a soft reset of your iPAQ after doing this. 1. Make sure the USB cable is unconnected 2. Start PocketFMS on the PPC 3. connect the USB cable 4. Enable the GPS in PFMS on the PPC 5. Move to the map page 6. Start MSFS 7. Make sure to check back that the GPS is still enabled, enable it again if it is not. 8. That should be it. I definately suggest reading the other thread on http://www.pocketFMS.com on this subject. I've made sure ActiveSync is killed on both the PC and the iPAQ. I've tested it with the Hx4700 and it works fine; so I know there is something I am missing about getting it to work with the 5915 with WM5. I've tried various com ports and no go. I set the internal GPS to connect through the program port (None). The screen says there is no explicit way to turn off the GPS, and that it apparently tries to turn on when something tries to connect to its com port, but, since I've set it to "None", I'm hoping that's not interfering. Anyone have any suggestions? Thanks!
  12. Hi Pete, Being a noob, I didn't understand your instructions. I linked using the MixW drivers with using Wideclient, when no such link existed. I get it now. I never did get the MixW drivers working with Goops. It's possible the problem had to do with it appears to me the MixW drivers fix the speed of the port to 1200, and the minimum speed Goops supports is 2400. David Hite of Goops said he would add a 1200 speed, too. On the other hand, some documentation I read said the speed of the port is immaterial. Not understanding these things, I don't know what the real problem is. I ended up purchasing a serial port bridge driver from Eltima to get the job done and it works great. I have an email in to the MixW folks, but have not heard back from them (as far as I know, anyway, this spam stuff sucks). Thanks!
  13. Well, I've gotten a little further. When using portmon, make sure to start it before you start FS, then you can see the output of gpsout. I downloaded a couple of commercial virtual serial port bridge/null modem programs, and they work fine with goops. For some reason goops can't speak to a port opened by MixW CommEmul. Perhaps it's because MixW fixes the baud rate at 1200 and the minimum baud rate goops can read is 2400??? I don't know. But I was unable to control the port with MixW, and the commercial vendors allowed you to change the port using mode. Any help would be appreciated. I still don't understand why Google Earth was able to see the data output by gpsout, even though it wasn't being reported on the virtual com port.
  14. Hi, I'm sorry I'm so stupid. I'm trying to connect FS9 through GPSout.dll through Goops to Google Earth. I set up gpsout.ini to port=com5. I set up MixW to link ports 5 and 6. I originally was able to use Microsoft's portmon to look at com6 and it showed my gps output coming in to com6. I was able to turn on Google Earth's GPS reader, and it is able to see the data and position the icon in the right place. But Goops 1.91 would not read com6 no matter what I did. Then I did something (killed the gpsbabel process after turning off Goops and GoogleEarth is the only thing I can think of) at which point, portmon was only reporting what was going out on com5. So I rebooted the computer, now portmon doesn't see anything when FS is running. Google Earth is able to read the gpsout data as it sees something, but I can't figure out where it is getting its data from???? Portmon reports nothing on com6. And of course Goops is not working. Is there any way to log the output of GPSout? Is there any way to tell where the data is going? Google Earth can see it. I'm very frustrated here as I know practically nothing about com ports. The first thing I want to know is exactly what GPSout is writing. Then I want to know where it is writing it to and where Google Earth is able to find the data. Why can't portmon see it? Is there a command that I can write on the command line to redirect the data from a com port to a file? I'm so upset, I had everything working the way I expected except that Goops wasn't working right, and now I don't know what is going on or what I did to change it. Everything seems to be functioning, except I can't figure out where the gpsout data is and how to see it and figure out what is going on.
  15. Ahh, maybe that's the trick! Pete's directions keep talking about MixW in the context of setting port=WideFS, but perhaps they are different concepts, use Port=WideFS when running WideClient on a different computer, and use MixW when using GPSout on the same computer. That's Brilliant! (to steal a phrase from a commercial) Sometimes I'm kinda thick. Thank you
  16. Ok, I found the first noob issue. You'll note I have no Serverxxx command in the WideClient.ini. I tried ServerName=localhost, ServerName=BEARCAT, and ServerIPAddr=127.0.0.1, but so far no luck, WideServer is still saying "waiting for clients", and I'm still not getting a WideClient.log file that I can find. I still have MixW set to create com ports 5 and 7, and GPSout port=WideFS, and I keep attempting to connect to both ports 5 and 7 with my client programs listed above. [Config] Port=8002 Window=43,44,886,589 Visible=Yes ButtonScanInterval=20 ClassInstance=0 NetworkTiming=5,1 MailslotTiming=2000,1000 PollInterval=2000 Port2=9002 ResponseTime=18 ApplicationDelay=0 TCPcoalesce=No WaitForNewData=500 MaxSendQ=100 OnMaxSendQ=Log NewSendScanTime=50 Priority=3,1,2 ServerIPAddr=127.0.0.1 [GPSout] Port=COM5 Speed=4800 ; ----------------------------------------------- [user] ;Log=Errors+ Log=DebugAll
  17. So, it seems to me that something is not working on the client side. If I start wideclient.exe, it creates a log file no problem. Plus the fact that FS reports that no clients are connecting tells me I am missing something when trying to run wideclient and wideserver on the same machine. But it won't let me start wideclient.exe and FS at the same time, as the program thinks it is running when FS is running. HELP! Guess I'm going to have to read some more documentation to see if I've missed something :(
  18. A little more information. I downloaded a copy of Serial Port Monitor. And realized that ports 3 and 4 were probably not good choices as port 3 is shared with port 1, so I chose ports 5 and 7 as my pair in MixW. I set WideClient.ini to: ... [GPSout] Port=COM5 Speed=4800 [user] Log=Yes Still no WideClient.log appears, just a single WideServer.log, which keeps repeating that nothing is connecting. Serial Port Monitor reports nothing when FS is running. If I start GPS Diag.exe, If I try to connect on Port 7/4800, SPM reports that the com port has been successfully opened and closed, but no data flows over it. If I try to connect GPS Diag.exe to Port 5/4800, SPM doesn't report anything. No matter what, FS reports that it is waiting for clients to connect. The local WideClient never connects no matter what I do. WHAT AM I DOING WRONG? Sorry, I'm frustrated.
  19. Hi Pete, I'm using FS9.1 and I've got a registered version 3.7.1.0 of FSUIPC, a registered version of WideServer 6.71 and WideClient 6.71. I'm trying to use the virtual com port driver MixW to drive Google Earth (or another GPS reading software) on the same computer as the FS9 installation through GPSout. I've installed the MixW Com Emulation which it says is running fine and I've set up a pair at COM3 and COM4. The only other com port listed under system hardware is COM1. I also tried setting it to COM4 and COM5. I rebooted after each time I changed the settings of the MixW driver. My GPSout.ini is: Sentences=RMC,PGRMZ,GGA,GSA,GSV Interval=1000 Port=WideFS <== also tried WideFs Speed=4800 PosTo6Decimal=Yes WideServer.ini: [Config] Port=8002 AdvertiseService=1 AutoRestart=0 AutoUpdateTime=13 MaximumBlock=4096 NoStoppedRestarts=Yes Port2=9002 RestartTime=10 SendTimeout=15 TCPcoalesce=No [user] Log=Errors+ [ClientNames] 1=YOUR-900O6YG0CM 2=VISTANAV (Note that no ClientName for Bearcat) WideClient.ini: [Config] Port=8002 Window=43,44,886,589 Visible=Yes [GPSout] Port=COM3 Speed=4800 [user] Log=Yes FSUIPC.log: ******** FSUIPC, Version 3.71 by Pete Dowson ********* Running inside FS2004 (FS9.1 CONTROLS.DLL, FS9.1 WEATHER.DLL) User Name="Thomas Perry" User Addr="thomas@flyingscool.com" FSUIPC Key is provided WideFS Key is provided Module base=61000000 ClassOptions: UIPCMAIN=FF7F, FS98MAIN=FF7F, FS2KMAIN=FF5E WeatherOptions(Orig)=40003605[40003605] InitDelay: 0 seconds WeatherReadInterval=4 LogOptions=00000001 DebugStatus=255 2281 System time = 22:12:36 2281 \\BEARCAT\Flight Simulator 9\ 2281 System time = 22:12:36, FS2004 time = 12:00:00 (00:00Z) 3156 AppKey="OPYEDKY9O0YL", Module="VTHMB.DLL" 27453 C:\Documents and Settings\Thomas Perry\My Documents\Flight Simulator Files\Boire 14.flt 27516 AIRCRAFT\Flight One PA-28\PA-28-181.air 27703 Aircraft="PIPER PA-28-181 Archer DREAM FLEET - 1 N15802 - 1 Pilot, 0 Passengers" 32594 AppKey="1C0QAHK9SR36", Module="sbmpjoin9.dll" 32625 AppKey="PKNLXYDZEFFJ", Module="sbmod9.dll" 32625 AppKey="D8OZX4N1OARF", Module="sb3gaugebridge.dll" 32625 AppKey="K7I8RIBFRTH6", Module="sbtrans9.dll" 41813 C:\Documents and Settings\Thomas Perry\My Documents\Flight Simulator Files\UI generated flight.flt 42266 Clear All Weather requested: external weather discarded 45813 Advanced Weather Interface Enabled 89750 Traffic File #32 = "scenery\world\scenery\traffic030528" 92953 Traffic File #34 = "scenery\world\scenery\trafficmanchester" 167547 System time = 22:15:21, FS2004 time = 11:43:31 (15:43Z) 167547 *** FSUIPC log file being closed Memory managed: 2 Allocs, 842 Freed ********* FSUIPC Log file closed **** WideServer.log: ********* WideServer.DLL Log [version 6.71] ********* Blocksize guide = 4096 (double allowed) Date (dmy): 03/02/07, Time 22:12:37.609: Server name is BEARCAT 86906 Initialising TCP/IP server 86906 Initialising IPX/SPX server 86906 ServerNode=0.256.4864.61646.47989 86906 Initialising UDP/IP server 88031 Broadcasting service every 1000 mSecs 98187 Restarting service due to total lack of use 166359 Closing down now ... Memory managed: Offset records: 0 alloc, 0 free Read buffer usage: 0 alloc, 0 free, max in session: 0 Write buffer usage: 0 alloc, 0 free, max in session: 0 Throughput maximum achieved: 0 frames/sec, 0 bytes/sec Throughput average achieved for complete session: 0 frames/sec, 0 bytes/sec ********* Log file closed ********* WideClient.log: No such file Note that even though WideClient log is set to yes, no information from GPSout was logged. I have tried to use Goops to send data to Google Earth - Doesn't work I have tried to use the GPS Diag.exe utility from Ambicom - locks up I have tried to use PocketFMS - locks up I set the com port to read in the GPS software to COM4 and WideClient is set to COM3. Each time I ran the programs, I let it sit looking locked up for at least a minute hoping it would register, and I tried various options. Any hints on how to diagnose the problem here and/or get it working? Thanks, Thomas
  20. Thanks for the feedback Pete. I will update what I submitted before with this new information. Interesting that the laptop numpad keys work, they must not be getting captured by FS since they are probably not standard I guess. Thomas
  21. Hi Pete, Thanks for the suggestion, but it didn't work. In fact, it seemed to negate the use of the arrow keys altogether for control of the aircraft. Perhaps I did it wrong? No, turning numlock on and off has no effect on the arrow keys. But you were correct, the numpad keys still work. It is only the separate arrow keys that are affected. But I am using a Dell D810 laptop, so the only way to access the numpad keys is to hold the Fn key and use the keys in the middle of the regular keyboard. Kind a a pain. As far as I can tell, the arrow keys have no purpose in the ATC window. What I did to try your suggestion was go into the key assignment page of FSUIPC4 and I assigned elevator down to the up arrow key, aileron left to the left arrow key, etc.. After I did this, even with the ATC window off, the keys no longer controlled the plane. I'm not sure what I did wrong. The problem is that now in FSX the ATC window is a separate window (yet still contained within the FS window, I don't understand it completely). Can FSUIPC recognize that key presses are meant for the main window when another window is active? I wrote to FS about it, too. I don't know what they are doing about it. The funny thing is, only the arrow keys are affected, other keyboard controls still work, for instance, even without FSUIPC, I assigned the rudder keys to the z, x, and c keys through FS's normal keyboard control setup, and they still work. And as noted, the numpad arrows still work. So I'm assuming it's a bug more than a funtionality problem. But I don't know. Do you mind taking a look at this? Thanks, Thomas
  22. Hi Pete, As you probably know, in FSX when the ATC window is open, you can't use the keyboard arrows to control the plane. I can do other things like pan the view and control the engines and use the rudder, but I can't use the arrow keys. Is there a facility in FSUIPC4 to overcome this? Am I mistaken? Thanks, Thomas
  23. Just thought I would mention that PocketFMS works great with GPSOut and a USB connection. I use it all the time and have not had any problems with it using an iPAQ 3835 with a 512MB SD card. In fact as long as I leave PocketFMS on, I can quit and restart MSFS all I want and it still connects each time without intervention on my part. There is, however, a problem with older iPAQ's and SD cards. Apparently the authors made a change in PocketFMS v.953 in the way they read their data and the maps no longer display in any version above that. The authors say they are working on the problem, but do not have a solution currently. So we are stuck using .952 until either they find a solution or we upgrade our iPAQ's. I have heard, but have not tried it myself, that upgrading to PPC 2003 will also address the problems. My settings are: [GPSout] Sentences=RMC,PGRMZ,GGA,GSV,GSA,GLL Interval=1000 Port=\\.\WCEUSBSH001 ; the dot is very important Speed=19200 There is a good thread on setup at the PocketFMS.com support forum, but basically, the way I get it to work is too: A. Shut off USB access to ActiveSync. You may want to unconnect the cable and do a soft reset of your iPAQ after doing this. 1. Make sure the USB cable is unconnected 2. Start PocketFMS on the PPC 3. connect the USB cable 4. Enable the GPS in PFMS on the PPC 5. Move to the map page 6. Start MSFS 7. Make sure to check back that the GPS is still enabled, enable it again if it is not. 8. That should be it. I definately suggest reading the other thread on http://www.pocketFMS.com on this subject.
×
×
  • 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.