GPSOut and virtual Serial port support

[Wildfire563]

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

The virtual ports created by GpsGate are not displyed in the Device Manager. That is the only difference. This means this is is a enumeration problem.

If WinGPS enumarates the ports found under

HKEY_LOCAL_MACHINE\Hardware\DeviceMap\SerialComm

it will be able to connect to the virtual ports created by GpsGate.

Another solution would be if WinGPS allowed you to manually enter a COM port. Once connected there is no differense. Same Win32 API calls.

Thanks!

[Pete Dowson]

I imagine the issue may be you only recognize serial ports listed in the Device Manager?

In GPSout, I read the Port parameter from the INI file and use it directly in the form "\\.\" in the CreateFile call. That's it. The only check on the name is that it isn't "WideFS" because if it is obviously I do something different.

In FSUIPC4 (as opposed to GPSout.dll) I also check for "" because that will appear if none is set.

The developer of GPSGate offers the following advice from this thread - http://franson.com/forum/topic.asp?TOPIC_ID=5198

The virtual ports created by GpsGate are not displyed in the Device Manager. That is the only difference. This means this is is a enumeration problem.

If WinGPS enumarates the ports found under

HKEY_LOCAL_MACHINE\Hardware\DeviceMap\SerialComm

it will be able to connect to the virtual ports created by GpsGate.

Only FSUIPC4 ennumerates the *unused* ports, but it does this by trying to open COM1 through to COM254 in turn. This is only to populate the drop down selection list, as an aid. There is a facility to enter any port name you wish (that's how the USB devices are specified). Or you can simply edit the INI file directly, as you had to with GPSout.dll.

Another solution would be if WinGPS allowed you to manually enter a COM port. Once connected there is no differense. Same Win32 API calls.

Haven't you tried this? Both GPSout and FSUIPC4 allow any names.

Regards

Pete

[Wildfire563]

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.

[Pete Dowson]

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.

Sounds like the Port isn't really called "COM19". If it were it would certainly be found in my enumeration attempts in any case and listed, as I try CreateFile on all COM ports 1 to 254 when building the list.

The fact that it isn't really "COMn" seems to be supported by the fact that it doesn't appear in the COM port list in Device manager either.

You need to find the "true" name. Maybe FileMon (from http://www.sysinternals.com) will show what it is when you run "XConn", whatever that is, though I think that only monitors true disk files.

Regards

Pete

[Wildfire563]

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.

[Wildfire563]

Some more information from the same thread.

This is a workaround to solve the "not showing up in the device manager" problem.

Run the Add hardware wizard from the Control Panel

click Next

check "Yes, I have already connected the hardware"

click Next

Select "Add a new hardware device" (end of list)

click Next

check "Install the hardware that I manually select from a list"

click Next

select "Ports (COM & LPT)"

click Next

In "(Standard port types) select "Communications Port"

Click Next

Click Next

Click Finish

The new port will now show up in Device Manager with a yellow exclamation mark indicating a problem ("Windows cannot determine the settings for this device....").

But, functioning or not, a new port number is allocated.

The new port will show up in apps that use the device manager for retrieving information about existing ports.

Note the port number, and add a virtual port in GPSgate using this new com port number.

Any app set to use this port number will now in fact connect to GPSgate

I have tested this with MaxSea and Shipplotter for retrieving and sharing GPS and AIS data, and it works fine.

Another feature is that other devices that use com ports for input, and use the device manager information for self configuration, are stopped from allocating ports already in use by GPSgate (that was initially my problem and is not an uncommon behavior of mobile phones and Bluetooth adapters).

/mats

********************************************

Thanks mats for the info!

There is actually one more step that needs to be done. By following the steps above the COM port added in the Device Manager will have an arbitrary number. Not necessarily the same number you created in GpsGate.

To address this problem, follow those steps:

1. Note which number the Virtual COM port in GpsGate has. E.g. COM4. You see that in the "Output" tab in the "Settings" dialog of GpsGate.

2. Open the Control Panel

3. Double click on "System"

4. Click on the tab "Hardware"

5. Click on the "Device Manager" button

Under "Port (COM & LPT) you see the added port with yellow exclamation mark. Now, this port might have a different number than the one found in GpsGate.

To fix this you either remove the Virtual Port in GpsGate, and recreate it with the COM port number found in the Device Manager.

Or:

6. Right click on the COM port with yellow exclamation mark in Device Manager. Select "Properties".

7. Click on "Port Settings" tab

8. Click on "Advanced..." button

9. Select the matching "COM Port Number" in the drop down with the same name.

10. Click OK on both dialogs.

OK! Your GpsGate virtual port is now matching the "phony" port created in the Device Manager, and application that only enumerates ports in the DM can see the port.

The COM port number is not updated in the Device Manager until you re-open it.

Regards,

Johan

Franson Support

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!

[Pete Dowson]

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.

That's easy to say, but how? What IS the port name? It is obviously not COM19. Is it "bizVCOM19"? They say the standard API can be used, but first the port has to be opened, and that needs a name! There's nothing I can do without it, and none of the information you are posting tells me that.

Regards

Pete

[Wildfire563]

I'll ask the author to go into more detail.

Thanks for listening!

[Wildfire563]

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!

[Pete Dowson]

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!

That's extremely odd, then, because I add the \\.\ part to ALL names before using them in the CreateFile call -- I'm sure I said this earlier. You need it for all COM ports. If you are also adding this it means two things:

1. The name in the CreateFile call is now "\\.\\\.\COM19"

2. The name when setting the COM state (parameters like speed and bits per character) is \\.\COM19. With 'normal' COM ports this isn't used, only the COMn part is used -- including COM9 and above.

As long as it works and you are happy, that's fine, but I don't understand and your explanation doesn't help me to, unfortunately. It must have something to do with the way that particular application is coded.

MixW manages to make virtual ports which look like real ones, so I don't know why that program cannot too.

Ah well.

Regards

Pete

[Wildfire563]

But the user needs the \\.\ in front of wcesusbsh001. Is this a similar case, then?

[Pete Dowson]

But the user needs the \\.\ in front of wcesusbsh001. Is this a similar case, then?

Must be. Good point, I never thought of that. Maybe, for such non-Serial Serial ports it's actually the setting of the CommState which needs that part of the name. as well. Maybe I am opening COM19 correctly with the CreateFile, but the settings are then all wrong.

I'll tell you whatI'll try including the \\.\ in the name for the setting of the COMM state for ordinary ports. If that works, then you can try COM19 without the \\.\.

Give me a few days. I'm in the middle of something else at present.

Regards

Pete

[Wildfire563]

:?

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!