OpenCPN Fails to Receive Bluetooth Data Feed

[RhythmDoctor]

One reason that OpenCPN may fail to communicate when other programs (PolarCOM, TeraTerm, HyperTerminal) do communicate successfully is that different programs may expect different settings on the COM port.

Check to verify that your Bluetooth adapter is set for no flow control. My Bluetooth adapter came with hardware flow control as the default, and I had to change it.

[CarCode]

As I said Bluetooth depends highly on the used Bluetooth stack running on the PC and the way these different Bluetooth stacks supports the different Bluetooth profiles. For serial communications the so called SPP profile (Serial Port Profile) is used by the Bluetooth stack. There are more than 30 different Bluetooth profiles known. First step to investigate a not running Bluetooth device was to try another Bluetooth stack in my experience. The most common Bluetooth stacks for Windows I know are from Microsoft, BlueSoleil, Toshiba and Widcomm.

Gerhard

[Chris Hayes]

Originally Posted by RhythmDoctor

One reason that OpenCPN may fail to communicate when other programs (PolarCOM, TeraTerm, HyperTerminal) do communicate successfully is that different programs may expect different settings on the COM port.

Check to verify that your Bluetooth adapter is set for no flow control. My Bluetooth adapter came with hardware flow control as the default, and I had to change it.

Thanks for the suggestion. Flow control default in this case reads "Open".

[yachtman]

For what it is worth, as a new user I have been trying out my Nokia gps puck, which is blue tooth connected via a sitecom cn 502 usb adapter, fully updated vista on acer aspire 5630 lap top. The gps works well. Downloaded VSPE emulator, mentioned elsewhere on the fora & succeeded in sharing GPS input with CPN, Auto route, oziexplorer and also sea-clear. Ran all progs for yesterday evening, without crash. I have used this puck for the other 3 progs , and also with a cable input via a sitecom serial to usb adapter with hdard wire connection to a garmin 128.

there is a handy prog from oziexplorer available fromhttp://www.oziexplorer3.com/utils/GpsPortChecker.exe

[Chris Hayes]

Thank you yachtman, i'm running win7(64bit) on an asus eee slate with integrated bluetooth.

[RhythmDoctor]

CarCode is correct - the Bluetooth stack can have a huge effect on a successful connection. I am using the Toshiba stack, and having no problems receiving GPS and AIS over Bluetooth. (I am having problems sending data out to the Autopilot, though.)

Prior to using Toshiba, I did try the Microsoft stack, and it was horrible. I did get it to communicate once using Hyperterminal, but could never get it to work with OpenCPN. And then later I could not even get it to work with Hyperterminal or TeraTerm. It seemed to be very unstable, so I moved back to the Toshiba stack. However, your options for which stack to use may depend on the manufacturer of your Bluetooth hardware.

[CarCode]

Correct RhythmDoctor,

the used Bluetooth stack depends to the Bluetooth chipset but also to the Bluetooth profile which is sometimes the same because not any chipset supports any profile. The most problems I have encountered are the cheap chinese devices. Almost in any case they does not do what have been promised by the vendors. So I never found a chinese device which was declared as Class 1 device for a radio range of 300 feet to send more than 100 feet.
There exists a Bluetooth certification organisation The Official Bluetooth® Technology Web Site
But the chinese manufacturers does not care about it, because it costs them money. Certificated Bluetooth devices are fare more expensive and only these devices have the right to hold the copyright protected blue Bluetooth sign and name.

Gerhard

[haydude]

Gerhard,

I just checked the status on flyspray and it still reports this issue as unconfirmed, undecided, etc. Since this is quite an important matter I was wondering how we could speed up addressing the issue. Is there any other information required? Help on debugging?

To me it is now clear that the problem is due to a fundamental design flaw that assumes fixed bps rates and separate input/output for GPS/AIS/Autopilot, which should be instead configurable. A typical installation involves a bluetooth serial device to be connected to a multiplexer which unifies input and output matching the same bps rate (typically 38400).

[CarCode]

haydude,

I am not the code maintainer for OpenCPN. All I can do is to inform the developers via the Flyspray note.

Perhaps it might be a great task for the developers to make their code running on too much different operating systems. It is intended to run OpenCPN with Windows, different Linux distributions and Mac OS X also.

I see however several people using OpenCPN having problems with Bluetooth mostly with Windows and I know of Windows software which does not have these issues.

So we have to wait until the developers have found a solution.

Gerhard

[CarCode]

haydude,

just reading your new Flyspray comment.
You are saying even your GPS device is not running and not only your AIS/GPS bundle is not.

What kind of Bluetooth stack runs on your Windows?
Could you please make a test using the free PolarCOM soft? But at first only with your GPS device and not with your AIS/GPS bundle. This seems to be another issue.

Gerhard

[OyvindO]

Just for the Record (for what it might be worth),
I've been testing several different GPS devices with O-CPN, among them two different HOLLUX BT devices; The GPSlim 240 and the M-1200.
I'm using Win XP Pro running on a Dell notebook, and I use the standard MS BT stack (Which I think is based on WidComm?).
Both devices work perfectly with all kinds of stand-alone GPS testing SW that I have been able to find and test (GPS Info, MS PortMon, HyperTerminal, GPS Viewer, GPS MultiLogger, GPSView, SiRF Demo, etc.), but they both fail with OpenCPN.

The error message given is always "Could not Open Serial Port COM2"
I have tried tweaking O-CPN in every way possible, but with no luck except in one instance. Of all the 100+ times I've tried, it actually worked once and I could see the stream in the Data Stream Window and AutoFollow did work. But it was only that one time. After closing O-CPN it could never again succesfully open the serial port. And mind you, it makes no difference whether the BT GPS is on or off. O-CPN simply fails to communicate properly with SPP UART.
This is definitely a O-CPN issue since all other SW works just fine.

Rgds
Oyvind

[CarCode]

Oyvind,

Microsofts Bluetooth stack is not based onto Widcomm, it is intended to work with all Bluetooth chipsets.

You must use the SPP Bluetooth profile, that's correct, but this is done automatically while setting up the pairing procedure between the device and the Bluetooth stack. The serial port profile (SPP) creates a virtual serial port then which is seen during this procedure in the MS Bluetooth stack software as well also in the device manager. Please look at:
Setting Up GPS | Official OpenCPN Homepage
which shows however an USB device but that is identical to a virtual Bluetooth device.

Never use a COM port number 1 or 2 because these numbers are reserved to real physical COM ports - even your computer does not have any serial connectors - and not to virtual COM ports.

Sadly OpenCPN has not a mechanismen to find automatically the right COM port number as other programs have. The OpenCPN source code is intended for Windows, Linux and Mac OS X and these operating systems have different ways to find a correct COM port. So it might be difficult to implement such an automatismen for OpenCPN.

Look however into your device manager for the correct COM port number and enter it into OpenCPN. You will see it working in any case with OpenCPN. The trial and error methode does not work here! If you are doing it wrong for 100+ times, it remains wrong at all!

Gerhard

[OyvindO]

Gerhard,
Thanks for your comments.
I was only guessing that the MS stack was based on Widcomm - it is not important. In any case I use of course the SPP. I've tried numerous different COM ports. When connecting my BT GPS, SPP by defualt assigns COM4 which - for whatever reason never shows up in O-CPN. I can type "COM4" in the field but that doesn't help. So I redirected it to COM2 which happened to be avaialable on my Dell. And COM2 did show up in O-CPN and could be selected, but it still didn't work.
Whether I use COM4 (default) or the redirected COM2, it all works well in all other applications. just not in O-CPN.
I never expected O-CPN to autodetect my GPS input port. I was simply hoping that O-CPN was able to successfully recognize and initiate a BT SPP port.
In my opinion this is a timing issue. Initiating a physical COM port can be done in milliseconds, but initiating an SPP takes much longer and I have a feeling O-CPN exists long before the SPP has a chance to respond.... But this is just a wild guess...

Oyvind

[CarCode]

Oyvind,

major problem is the lack of an automatism in OpenCPN and users then try different things until the whole system blocks.

You need not to care about SPP, this is done automatically during Bluetooth pairing.

You may however assign another COM port number to your device but never below COM4 for a virtual COM port! Please believe me.

See your Windows Device Manager.

Gerhard

[OyvindO]

Gerhard,

Automatism is good, but I'll settle for less if I could only get it to work :-)
I know that the SPP is created during pairing.
And, of course I tried assigning other COM ports as well (6,7,8...)
Nothing works with O-CPN, that works well with other apps.
The reason I landed on COM2 is becuase it actually showed up in the pull down list in O-CPN after I assigned it. It sort of felt somehow promising...

But again, I couldn't care less as to which COM port I need to use, as long as I can get it to work, which I can't - no matter what COM port I choose...

So, my conclusion remains; There is something wrong inside O-CPN.
I'm sailing from Borneo to Thailand next week, so I guess I have to buy a hardwired GPS and give up my wireless BT attempt for now...

Ship'O'hoi...

Oyvind