OpenCPN not recognising Virtual COM port

[ktcanuck]

Originally Posted by bdbcat

ktcanuck....

OK, I just received in the mail today a BlueTooth GPS receiver, so this bug has popped onto my todo list.

I would appreciate it if you could enter this bug, with supporting detail, on the Flyspray bug tracker. It will get addressed if it is on that list, and might get lost otherwise.

Thanks
Dave

Will do.

[bdbcat]

Blue Folks...

OK, I'm stumped and stupid on Bluetooth.

I have Bluetooth dongle and GPS receiver. Works fine with O on XP.
On win7-64, however, I cannot get even hyperterm to read the port, never mind OpenCPN.

The port appears in Device Manager, LEDs indicate the device is paired OK, but hyperterm obstinately refuses to open the port. I seems that some other application has opened the port, and failed to close it cleanly, or is still running. But I see nothing in task manager.

Or maybe it is a permissions problem....

Google has been no help so far.

So, how can I get hyperterminal to read a simple SPP port?

Any ideas or tips, so that I can move on to the real issue of OCPN support?

Thanks
Dave

[barnakiel]

I think maybe when XP reads a port/data flow and Win 7 does not then there is a driver issue?

XP may be a 32 driver, win 7 a 64 driver, etc.. Try other drivers. Look up the chipset (on XP, where you can see it) and try other make drivers for the same chipset, this may work.

In any case, with any hardware, I always make sure the hardware is 'seen' by the system all right - and most issues we have had were with drivers.

b.

[bdbcat]

Blue Guys...

OK, some progress.

After much fooling around with drivers, etc., I have gotten OpenCPN 3.2.2 to work with Bluetooth under Win7.
What I see is that if the virtual serial ports do not appear in the Windows Device Manager, then O will not see them in the Connections drop-down list either, as expected. Also, it seems to help if the Bluetooth GPS receiver is paired and transmitting before starting O, although I have not gotten my hands around the logic and timing of this yet. Finally, if a dumb terminal program like RealTerm can open the port and see the NMEA stream, O will also be able to use the port. But remember, only exactly one application may have a given serial port open at the same time, and a crashed application may leave a port open requiring reboot to clear up.

I don't have immediate access to Win8, so I cannot claim that the serial port discovery algorithms in OCPN do the right thing with Bluetooth in Win8.

So, lets break this down into two cases:

a. Win7
b. Win8

Who is using Bluetooth with either of these systems, and what is your experience?

Thanks
Dave

[ktcanuck]

I am remote from my Win7 machine until the weekend but will check then. I have a Qstarz BT-Q818 unit as a back up to the Shipmodul. I have used this with O on a Win 8 64 bit machine. Will check that as well.

[martinlie]

Originally Posted by bdbcat

Blue Guys...

OK, some progress.

After much fooling around with drivers, etc., I have gotten OpenCPN 3.2.2 to work with Bluetooth under Win7.
What I see is that if the virtual serial ports do not appear in the Windows Device Manager, then O will not see them in the Connections drop-down list either, as expected. Also, it seems to help if the Bluetooth GPS receiver is paired and transmitting before starting O, although I have not gotten my hands around the logic and timing of this yet. Finally, if a dumb terminal program like RealTerm can open the port and see the NMEA stream, O will also be able to use the port. But remember, only exactly one application may have a given serial port open at the same time, and a crashed application may leave a port open requiring reboot to clear up.

I don't have immediate access to Win8, so I cannot claim that the serial port discovery algorithms in OCPN do the right thing with Bluetooth in Win8.

So, lets break this down into two cases:

a. Win7
b. Win8

Who is using Bluetooth with either of these systems, and what is your experience?

Thanks
Dave

I have tried the Shipmodul-BT (version 1) to integrate NMEA from a Raymarine C80, and the virtual SPP COM ports (one input, one output) does not show up in OpenCPN 3.2.2, but they do exist in the system (both W7 and W8).

I thought W8 would be the problem, but it has the same behaviour on Win 7 (Home). The COMs works OK in terminals and is also opened by Xport on Win 7. Xport is not compatible with W8.

From Xport/W7 I get a new virtual COM port wich can be opened in OpenCPN and get NMEA data, but my output port (route upload to C80) is not forwarded by Xport wich only support one port.

So - Bluetooth SPP might be a general problem with OpenCPN? When using Shipmodul-BT, two COM ports are created and on the output COM there will never be NMEA data in, so one cannot assume that a port with no data is a non-good port in my mind.

Thanks for any progress on this, I enjoy a free and open alternative!

[bdbcat]

martinlie....

Thanks for the report.

Just to be exquisitely precise here, let me rephrase your findings and see if it fits.

On Win7, considering input only:
0. Your Bluetooth stack is standard issue Microsoft supplied.
1.Shipmodule BT ports appear in Device Manager.
Before pairing? Or only after pairing? What COM numbers, please?
2. Shipmodule input port can be opened by a comms program, and you see NMEA streams.
Which comm program? Does it use a drop-down list to select the port?
3. OCPN 3.2.2 does not show the port(s) in its drop-down box under Connections tab.
4. If you manually enter the correct port in the OCPN Connections tab, it appears to open the port OK(from the log), but no data ever flows.
5. XPort will open the BT input port, and feed to OCPN.

Have I got it right?

So far, in my testing, if the Bluetooth SPP port appears in the Device Manager, then it will always appear in OCPN drop-down list.
Seems not to be the case in your environment.

As an aside, it is really not trivial for an application to determine whether a serial port is a virtual SPP, an XPort virtual port, a USB-Serial converter, or a plain, old RS232 port. The Windows API is exactly the same for all of them, at least for opening, reading, and closing the port. That is why the SPP problems are so mysterious to me.

Thanks
Dave

[martinlie]

Originally Posted by bdbcat

martinlie....

Thanks for the report.

Just to be exquisitely precise here, let me rephrase your findings and see if it fits.

On Win7, considering input only:
0. Your Bluetooth stack is standard issue Microsoft supplied.
1.Shipmodule BT ports appear in Device Manager.
Before pairing? Or only after pairing? What COM numbers, please?
2. Shipmodule input port can be opened by a comms program, and you see NMEA streams.
Which comm program? Does it use a drop-down list to select the port?
3. OCPN 3.2.2 does not show the port(s) in its drop-down box under Connections tab.
4. If you manually enter the correct port in the OCPN Connections tab, it appears to open the port OK(from the log), but no data ever flows.
5. XPort will open the BT input port, and feed to OCPN.

Have I got it right?

So far, in my testing, if the Bluetooth SPP port appears in the Device Manager, then it will always appear in OCPN drop-down list.
Seems not to be the case in your environment.

As an aside, it is really not trivial for an application to determine whether a serial port is a virtual SPP, an XPort virtual port, a USB-Serial converter, or a plain, old RS232 port. The Windows API is exactly the same for all of them, at least for opening, reading, and closing the port. That is why the SPP problems are so mysterious to me.

Thanks
Dave

Hello, I am now sitting in my boat with W7 and testing and experiences consistent behaviour.

See a collection of screen shots here, I will explain below:
https://www.dropbox.com/sh/x9z67yz1traz8kz/Jqoj5GjS2f

Answers:
0: Yes. No special drivers.
1: Yes. They appear upon pairing and are actually persisted even though the Shipmodul is without power. COM9 input to PC, COM10 output (image device_manager1)
2: I have tested with Putty, Shipmodul config program and Polarcom. In Putty, I must type the port name (COM9), in the others the COMs are listed (images miniplex-config1, polarcom1, putty1, polarcom2). And no, Polarcom is not messing up here, it was installed afterwards.
3: Sure don't, see image opencpn1.
4: Correct. And no response after OpenCPN restart either. And I can open the port in Putty also, so OpenCPN never attempts to open it, it seems.
5: Yes, correct. And I have also tested with Polarcom with serial input and network server output, OpenCPN feeds NMEA from TCP port with no prob.

And since COM10 is for output to the Miniplex-BT, I have tried to set COM7->Xport->COM10 and Polarcom for input from COM9. When trying to upload a route, it seems Xport in that case filters out data since there are no NMEA input, and the route never reaches the plotter. OpenCPN should be able to output a route to all interfaces, not only serial ports (see image opencpn2).

I have tested the same with W8 earlier, same behaviour...

Thanks,

Martin Lie

[silentrunning]

Hi,

Just registered to offer a heads up on a com port emulator solution which maybe useful to people here. I came across your thread some time ago when I was trying to resolve similar issues. I have no affiliation with this company and I have only used the trial version for testing. Here is the link Centrafuse Localizer.

I also came across another application called TurboGPS which has a config option that allows access to the Win7/8 sensor driver. The developer of TurboGPS may be able to offer some information if someone were to contact him on his forum here he also offers premium support here.

Hopefully that will prove useful to someone in your community.

[bdbcat]

Hello geeks...

Whoa there....
I find that the method O uses to enumerate serial ports does not seem to work reliably on Win764 for Bluetooth SPP ports. A Windows bug, imagine that.

winapi - How come GetDefaultCommConfig() Doesn't Work with Bluetooth SPP Devices? - Stack Overflow

OK, this goes on the list for the next Beta.

Dave

[martinlie]

Originally Posted by bdbcat

Hello geeks...

Whoa there....
I find that the method O uses to enumerate serial ports does not seem to work reliably on Win764 for Bluetooth SPP ports. A Windows bug, imagine that.

winapi - How come GetDefaultCommConfig() Doesn't Work with Bluetooth SPP Devices? - Stack Overflow

OK, this goes on the list for the next Beta.

Dave

FYI - I have tested with Win7/32 and Win8/64.

Please let me know if I can be of assistance for testing any pre-version, my environment is easily accessible.

[bdbcat]

Martin, et al...

I have built a test version of OpenCPN, called 3.3.603.
This version may have some severe bugs; It is not ready for Beta test.

But we may use it to test the Bluetooth serial port detection logic, at least.

Try Options->Connection->Add Connection, and look at the drop-down box for ports. Look for the Bluetooth ports.
That's all we really need to do, although it should actually connect and transfer Bluetooth data if you have that configured.


Download from here:

https://www.dropbox.com/sh/rqkjcgktu....603_setup.exe

You may safely downgrade and re-install 3.2.2 after testing.

Thanks
Dave

[martinlie]

Originally Posted by bdbcat

Martin, et al...

I have built a test version of OpenCPN, called 3.3.603.
This version may have some severe bugs; It is not ready for Beta test.

But we may use it to test the Bluetooth serial port detection logic, at least.

Try Options->Connection->Add Connection, and look at the drop-down box for ports. Look for the Bluetooth ports.
That's all we really need to do, although it should actually connect and transfer Bluetooth data if you have that configured.


Download from here:

https://www.dropbox.com/sh/rqkjcgktu....603_setup.exe

You may safely downgrade and re-install 3.2.2 after testing.

Thanks
Dave

That was a success! I tested on both W7/32 and W8/64, and the stored Bluetooth SPP ports were enumerated in the connections dialog! I will try to connect to my boat/Miniplex tomorrow evening and report back.

[martinlie]

Originally Posted by martinlie

That was a success! I tested on both W7/32 and W8/64, and the stored Bluetooth SPP ports were enumerated in the connections dialog! I will try to connect to my boat/Miniplex tomorrow evening and report back.

So I tested with both W7 and W8 today, W8 failed totally to connect with anything bluetooish, so I gave that up after an hour.

W7 paired, and the COMs were enumerated, but OpenCPN did not connect to them (they were stored ok in OpenCPN, but no connection attempts even after restart of OpenCPN). I could also open the ports in Putty when OpenCPN was running, so they were not being opened.

[bdbcat]

martin....

Lets get straight on some terminology.

The Microsoft Bluetooth stack opens two com ports when the Shipmodul device is detected and paired.

The two ports reflect whether the connection is initiated by
a)the computer ("Outgoing" port) ..or..
b)the Bluetooth device (i.e. Shipmodule in this case) (i.e. "Incoming" port)

Both ports are full duplex, and useful for input and/or output.

It will be rare to need both connections in a single application.

Since the connection is initiated by OpenCPN, you should be using the "Output" port. Shipmodul does not initiate connections, although some other Bluetooth devices may do so.

Here is the related text from the ShipModul manual:

In Windows  two COM ports are assigned to the multiplexer, one for outgoing connections and one for incoming connections.


You must use the port for outgoing connections in your navigation software.

So, please confirm that you are selecting the "Outgoing" connection port in OpenCPN, and see what happens.

I hope this is clear...

Thanks
Dave